BYN not working on Parallels virtual machine

[rofus]

Hi,

 

I downloaded a trial of BYN to use with my D750 on Parallels virtual machine (Windows XP SP2). I have Digicamcontrol working fine with my camera, but with BYN like with my old D90 is impossible to make it recognize my camera.

 

I thought my D90 was the problem, but now with my new D750 is the same problem. I had same problem with Beta, it sounded like you were going to test it and make it work on virtual machines like Digicamcontrol does (I know you use a different way to connect to the camera), but it doesn't work even now on final version of BYN.

 

Any chance you'll get this sorted out in the future?

[rofus]

Guylain thanks for your reply

 

Because I'm stubborn I kept going on with tests. And I actually SOLVED the problem! (if anyone will have the same).

 

In Parallels the solution is to enable the USB3 support (I have a latest generation USB3 Macbook with a powered USB3 hub on the mount with all my equipment connected). Enabling USB3 in Parallels solved the problem, now BYN can connect to the D750!

 

I suppose is because latest Parallels is native on USB3 and not old USB2 for Macbooks having USB3 ports?

 

Anyway it works, including USB bulb shutter release and Liveview. Hopefully will be useful to other Mac users wanting to use BYN (will report more as soon as I get clear sky and I get to test more into a real session).

 

Tested on Macbook Pro 15 latest expanded to full spec, Parallels latest, Windows XP SP3 32bit guest operating system, OSX Yosemite 10.10.4

[Gillie]

Am having the same problem, but have tried everything I can think of to make the camera connection.

Using a D5200 with a Macbook Pro (which is about 4 years old.)

The strange thing is I've had success making the connection, but now its not happening.

 

I would like to know what the correct procedure is for the camera hookup and for the BYN program initialization. 

 

Anyone?

 

Gillie

[astroman133]

You can start BYN anytime, but you should only Connect with the camera is plugged in and powered on.

 

Does Windows recognize that the camera is present?  If Windows doesn't see it then BYE won't connect.

 

Windows needs to be told by Parallels that the camera is connected and available.

[s3igell]

Am having the same problem, but have tried everything I can think of to make the camera connection.

Using a D5200 with a Macbook Pro (which is about 4 years old.)

The strange thing is I've had success making the connection, but now its not happening.

 

I would like to know what the correct procedure is for the camera hookup and for the BYN program initialization. 

 

Please make sure that you have USB2 and/or USB3 Enabled in Parallels.

Beyond that, as BYN is a Windows App and most of the Forum Members are Windows Users, perhaps you could PM the OP (rofus) for some additional support.

[rofus]

Hey Gillie,

 

funny how we users of Parallels are not considered 'Windows' users, isn't it? We're not PC users for sure (luckily!), but Windows users equally even if 'on demand' only when we need it for compatibility

 

Ok jokes aside, your Macbook doesn't have USB3 so you won't have the USB3 switch on Parallels. Anyway you said you were able to connect in the past, so it must work I suppose now as well.

 

I'm not sure what could be, as the others said make sure the camera is visible by Windows, first of all checking that when connected and switched on is then assigned to Parallels and not to OSX. One thing easy to forget with BYN is to take out the memory cards. I forgot myself couple of times and BYN was not connecting/working correctly because of the time reading the cards (even if they're super fast).

 

Other than this, not sure what else to suggest. First check that camera connected/switched on is assigned to Parallels, then that Windows actually can see it (Device Manager), and that memory cards are out of the camera

[s3igell]

Funny how we users of Parallels are not considered 'Windows' users, isn't it? We're not PC users for sure (luckily!), but Windows users equally even if 'on demand' only when we need it for compatibility

 

I have Linux and Hackintosh and Andy (Android) and Win10 and WinXP VMs running (well stored - they don't get much actual USE when Windows runs most Apps that I want/need), but that doesn't make me claim to be an Apple User, either...

 

Parallels - the App/Environment which Gillie is struggling to configure successfully - is an OSX App, making that particular challenge one for Apple Users to answer.

[rofus]

Not relevant to discussion, was just the usual funwar I just don't think is good to confuse operating system/hardware/brands...different stuff.

 

If you're on Hackintosh and use OSX as well than you're an OSX user, but not a Mac user. And if you use OSX you're an Apple user indeed.

 

Only difference with me is that I'm not a PC user but a Mac user (hardware, even if we share basic architecture), apart from that we run same stuff (I have a full Windows7 on bootcamp also as Mac runs natively Windows).

 

This is important becayse BYN runs on Mac, Mac users make no difference what operating system they run, if natively or not, because the hardware supports both in many ways (native and vm). And being Mac users a growing number, I think Guylain is right spending the time he spent trying to make BYN work correctly on virtual machine, and I think Gillie question is useful to be public here, more than private message, because Mac users (and so potential users of BYN) are only going to be growing as long as BYN popularity grows (I'm sure it will, and most Mac users I know use Nikon)

 

I say all this because I seem to read sometimes a reaction, from users and not developer, like "oh you're mac and virtual machine is your problem do not distract developer from other more important tasks"

 

Gillie let us know if you sorted out your problem!

[astroman133]

One note regarding your post...it is my understanding from previous posts by Guylain that BYE and BYN contain no specific code for running in a virtual machine on a Mac.  BYE and BYN are straight .NET Windows applications.  If they do run in a VM it is because the VM provides an adequate emulation of a PC and the hardware resources that the apps need.

[rofus]

BYE and BYN don't contain any code to run on Mac (with or without VM), they don't need to indeed. But sometimes small details can create problems on VM (Nikon SDK not talking nicely through virtual machine) and Guylain was really admirable to always try to figure out what's the problem and willing to do something, if he can, to make his app(s) working also on a VM environment. Like it happened in the past when I helped Digicam dev, small changes (not dedicated code) make the app more compatible with a VM. That's what I meant

 

On a different problem, when I told him about the LiveView of BYN not being really working as supposed to (crop vs digital zoom), and despite others saying I was wrong, he recognised exactly what was the problem, sent me even a beta to test something he did, and was genuinely trying to sort it out.

 

Rare to have developers so committed, and on other astro forums I'm also saying that BYN works without problems on Mac in Parallels (or other VMs probably) , because I keep using it night after night without problems When/if the LiveView will be sorted out will be perfect, but is already fundamental to my long night sessions planning

[admin]

I'm not sure what the issue is

 

It is impossible for me to test all virtual machine permutations, in fact I don't test any virtual machines. I have several users using BYE and Canon DSLR un VM but I'm aware of any BYN users.

 

Does your camera connect without a VM?

 

Regards,

[rofus]

Hi,

 

yes my camera works perfectly with and without VM. I actually can tell you the error is not about the Windows XP in the VM, because I have another instance with Windows 8 and it doesn't work as well with BYN.

 

Actually it works perfectly also in the VM just not in BYN. I use Digicamcontrol and other applications and they can find the camera, tether it, transfer pictures etc. It seems is a problem how BYN connects to it (native/Nikon SDK), you told me that beta was going to be changed and rewritten in the other way to be more compatible/stable.

 

If you want I'm ok doing some beta testing, I've done the same for Digicamcontrol, if you have any extended log/debug version I'm happy to test it. Parallels is arguably the most common VM on Macs, and I think once that is solved it would work also on VMWare.

[admin]

What I asked was if you camera does connect to BYN without a VM, in a native Windows OS.

 

I'm tied to using the Nikon SDK and I have no plans to rewrite it using another protocol such as the one DigiCam control uses

 

Is there a menu option in the D750 for communication? If yes it must not e set to PTP. Not sure of their is such an option on the D750.

[admin]

Oh, do you have anything other than XP in a VM to try? Could be a Nikon SDK issue on XP given your camera is recent and XP is not... just a guess.

[rofus]

Hi,

 

 

thanks for your replies I tried it with Windows 8 on the same VM (Parallels), same problem. Camera works ok on a native Windows XP (no VM).

 

There's no communication option in the D750 for USB, it just works.

 

Thanks for explaining about the Nikon SDK, sadly it's (in)famously known to be very iffy...that's why it doesn't work (is a known issue) on VM because it requires unneeded and not standard privileged access.

 

Good luck with BYN, I'll keep using Digicam and the others (none of them using Nikon SDK, don't why you use that but I'm sure you have your good reasons You just miss about all the Mac world, that is quite big and growing.

[admin]

The decision to use the Nikon SDK was done early in the the process and it was done thinking it would be the most efficient way to communicate with the camera. As it turns out it does have its issues but for the most part it is very good... once the communication is established. Had I known what I know today I may have chosen PTP as a protocol, but it's to late now as it would require a complete rewrite of the camera interface module

[s3igell]

Thanks for explaining about the Nikon SDK, sadly it's (in)famously known to be very iffy...that's why it doesn't work (is a known issue) on VM because it requires unneeded and not standard privileged access.

 

Good luck with BYN, I'll keep using Digicam and the others (none of them using Nikon SDK, don't why you use that but I'm sure you have your good reasons You just miss about all the Mac world, that is quite big and growing.

 

Sadly, there are numerous Windows Programs that are very Useful (or Critical) to AP Imaging for which Apple OSX users find themselves unable to Use.  Most are stymied because of Issues that exist between Apple (OSX and BIOS) and VM Software - some successfully worked around through use of BootCamp instead of VM.  It's frustrating to see such Users complain to the Application Developer for failings of the OS and/or VM (or ultimately the OS Selection of that User) - the App Developer has nothing to do with those issues.

 

I'll wish you well with your usage of DigiCamControl as your AP Imaging App, but you'll be missing out on numerous Critical Features:

You get Image Control, including a Capture Plan Feature, but you get no integration to AstroTortilla for Plate-Solved Targeting nor to PHD/PHD2/MetaGuide for AutoGuiding and Dithering. Nor do you get Screen-Stretching/Curves Tools to go with the Histogram displays.

You get LiveView Display for Framing and Focusing, but no Point-Source Focusing Metrics (FWHM, HFD, StdDev) nor support for Bahtinov Focus Mask usage.  Nor do you get User-Configurable Reticules for your Framing tasks.

You get LiveView Capture that can be turned to Planetary Imaging Use, but does it implement a 5x (or 10x) Zoom or other provision to afford 1:1 Pixel Resolution.

You get no direct or indirect support for Drift Alignment, nor ASCOM Controls (another Windows-exclusive) to tweak Motorized Focusers or Nudge Mount Pointing or manage a Motorized Filter Wheel.

 

DigiCamControl offers numerous Features not implemented in BYN, even if most of those have little application toward AP Imaging.  But, given the list of AP Imaging-specific Features provided by BYN, you might want to explore other avenues toward Better OS Support on your chosen Apple PC/Laptop.  Or at least have the Grace to NOT ABUSE the Developer of BYN over the difficulties that you are experiencing...

[rofus]

Hi,

 

I don't think I was not abusing anyone...quite the opposite I was a user wishing to pay and just reporting something, nothing else, because I'm not the only one at my astronomy club with this problem. And by all means the problem is not BYN but the Nikon SDK

 

Digicamcontrol has everything (planner, PHD drizzling integration, liveview) I need, other things are missing and others are unique to Digicam...anyway that's not the point, I just hope some day I'll be able to try BYN and on my actual setup, not going to change it because of one single software not working.

 

Let's hope maybe Nikon will solve the problem with the SDK

[admin]

All is good at my end.

[s3igell]

Digicamcontrol has everything (planner, PHD drizzling integration, liveview)

 

Support for PHD Dithering in DigiCamControl - that I did not know (not listed on Features Page nor in downloadable Manual.pdf - but since have found it in a Site Search).  That is Good To Know, for while I'm a faithful BYE/BYN User, there are some Nikon DSLRs for which BYN is Not Supported because of the lack of SDK.  And for those Nikon DSLR Owners, it will be good to be able to point them toward DigiCamControl.

 

Thanks

[rofus]

Yesterday I had some clear skies so I did some preliminary tests of BYN on Parallels VM/Windows XP 32bit and a Nikon D750.

 

So far the only 'bug' (I think) I discovered is this one:

 

- when shooting using shutter to any value apart from 'BULB', there's a problem. For example I select 5 (seconds), I click Preview or Start session, and BYN triggers the camera but starts the countdown only AFTER the 5 seconds are finished. So when the camera closes the mirror, BYN thinks the exposition is starting, while it just finished. So the countdown goes and in the meantime it says 'Downloading' (because the picture was taken already).

 

That means obviously that for a 30 secs exposure I have to wait 60 seconds total before going on. To solve it I have to leave Shutter on 'Bulb' and select the time (also if short like 5s) from the time of the exposure.

 

Anyone else having this problem? I tried enabling/disabling on camera the 'exposure delay' and 'mirror lock up' on or off to see if anything changes, but it doesn't work anyway.

[admin]

That's a bug, I'll fix that.  Tanks for reporting it

[rofus]

That's brilliant thank you, I'll report if I find anything else. I really enjoyed using it last night, quite useful interface functions (for me) in particular for the focusing, and it seems quite stable as well.

 

Are updates automatically checked by the program at startup? Or do I have receive emails if any new version?

 

Looking forward to test it further before trial expires so I can be sure and buy the license, it works really well.

 

Any chance (not sure is possible due to bandwidth over usb) to have a better LiveView preview? When zoomed in the quality is not comparable to the one obtained by zooming in on the screen of the camera, could be useful to have a higher quality video streamed in particular when collimating or focusing with a Bahtinov mask

 

Also adding something for collimation in the zoom box would be useful to many I think when they collimate using unfocused stars (a pattern might greatly help visual evaluation).

 

Thanks for quick replies!

[admin]

The image on the LCD during live view is what you see in BYN so I don't understand the degradation in quality

 

Some high end models do have exposure simulation, make sure to enable it. Disconnect the camera from the computer, turn live view on, click the ok button to turn live view simulation, connect the camera back to the computer... Is live view better?

[admin]

 

- when shooting using shutter to any value apart from 'BULB', there's a problem. For example I select 5 (seconds), I click Preview or Start session, and BYN triggers the camera but starts the countdown only AFTER the 5 seconds are finished. So when the camera closes the mirror, BYN thinks the exposition is starting, while it just finished. So the countdown goes and in the meantime it says 'Downloading' (because the picture was taken already).

 

That means obviously that for a 30 secs exposure I have to wait 60 seconds total before going on. To solve it I have to leave Shutter on 'Bulb' and select the time (also if short like 5s) from the time of the exposure.

 

Anyone else having this problem? I tried enabling/disabling on camera the 'exposure delay' and 'mirror lock up' on or off to see if anything changes, but it doesn't work anyway.

 

This is fixed, it will by in BYN 1.0.2 later this week.

[admin]

Are updates automatically checked by the program at startup? Or do I have receive emails if any new version?

 

To receive emails you need to subscribe to changes to the download file   You need to do this at each release.  So when you get a notification, you download the file and subscribe to changes to the new file version

 

Regards,

[rofus]

Hi Guylain,

 

thanks for fixing that bug, cannot wait for new version it would save some time! I subscribed to file changes as you suggested and I'll do also for new versions.

 

I'll give the live view a test later. What I mean by minor quality is that basically live view zoom in BYN seems like a 'digitally zoomed in' version of the screen-fitting live view (like a digital zoom), and not a 'cropping' of the original high resolution live view. This does not happen using LiveView on the camera lcd.

 

This is very easily noticeable as I use a Bahtinov mask to focus: 'cropping in' the live view on the camera screen I can clearly see the diffraction spikes as I crop on the star more and more. Doing exactly the same thing (just after few seconds) using LiveView in BYN I cannot see the diffraction patterns, because the same star is just a 'blob' of giant pixels, just as the full resolution live view in BYN was 'digitally zoomed in' making those pixels giant instead of showing me a cropped version (I never zoom in more than 1:1).

 

I hope the explanation is clear, not sure how to explain better

[admin]

I just uploaded the new release, see the download section

[rofus]

Hi Guylain,

 

I downloaded and tested the new version. I found two problems with it:

 

1) when starting, I get this error on Windows XP 32bit (I click 'Continue' and it continue loading, and shooting/focusing/planet modules seem to work anyway..but the error definitely seems a problem with something about 64/32 bit compatibilities?)

 

 

2) Now using any shutter other than bulb starts the countdown correctly, but still not properly: it doesn't detect the Exposure Delay Mode (that instead Bulb recognises correctly). So I have on camera an Exposure Delay of 2s, BYN starts the countdown when the mirrors flips and not when really the exposure starts (from 1s to 3s later). Not a big problem as it was before, but something I'm sure you want to address, because it works correctly when using Bulb 

 

For the rest it seems to work, sky is cloudy so I cannot test further but that seems it all for now. Thanks for the update, I hope these tests can be useful for you!

[rofus]

The image on the LCD during live view is what you see in BYN so I don't understand the degradation in quality

 

Some high end models do have exposure simulation, make sure to enable it. Disconnect the camera from the computer, turn live view on, click the ok button to turn live view simulation, connect the camera back to the computer... Is live view better?

 

Hi,

 

I tried this as well but nothing changes, and yes I have Exposure simulation always on.

 

To make it even more clear, I made a test and screenshots so I can show you exactly what I mean when I say that BYN actually just zooms digitally in the full screen low resolution live view instead of actually cropping in and showing that smaller part, that means all measurements are not accurate because is just a digital zoom.

 

In the image below you see a screenshot of BYN liveview. Then on the left there's another image, just under the zoom box, that is just the white zoom box zone of the big live view magnified, like literally taken and zoomed in 200% or more...so basically low resolution zoom in.

 

On the bottom I added a picture I took with my iPhone of the same zone, same live view, as it appears 'cropped in' (not digitally zoomed in) from the camera, and even from the poor picture quality you can see that camera doesn't digitally zoom, it just crops that part of the liveview giving full details not just bigger pixels.

 

I think it's a fundamental problem for all the measurements, not sure if the same happens in BackyardEOS (don't have any Canon to test), but this is probably definitely something to look into...just making pixels bigger makes the zoom box and relative measures not accurate at all and not useable I think.

 

Let me know if this explanation/screenshot is clear and if you need any more tests

 

[admin]

If you press pause, make changes, then click resume.  Did live view change?