It’s not clear to me where to find this. All I can find is
Dragonfly-Install.exe (the link I posted above)
It’s not clear to me where to find this. All I can find is
You are right. I can also only find that one now on the Lunatico website. Could send you the installer, but it is a 10MB file. Probably best not to send as an attachment here on the forum.
Perhaps better to await Jaime from Lunatico to step in and point you to the correct installer. I guess the one you found will install both the Windows software to control the Dragonfly as well as the accompanying ASCOM drivers, but I am not sure how that is organized right now and do not want to screw up my installation by executing some installers. Jaime should be able to clarify in coming days.
Ok, Sounds good. Fwiw, I did install the one that is available and chose all the options, but no Dragonfly devices are showing in either Dome or Switches.
that install file is correct - the latest version. Just a new naming schema to make things easier.
I’m surprised you don’t find Dragonfly devices under Dome or Switches.
Have you run the software? I cannot check at this very moment, but I’m wondering if we are making the registration on the first run of the program…?
No, I had not run it. I thought the installer would install the drivers, but I ran it and it’s ok now. Thx.
@Ventania I did some testing… I don’t have an actual DragonFly to test with so I cant fully test, but did discover that SGPro will not add a switch to the list if it can’t find any (child) switches for the switch device. SGPro will need to connect at least one time with the Dragonfly in order to inspect its switches. I have fixed this issue and now the DragonFly will always show up in the list even if SGPro cant find any switches for it. For now, though, please try:
- Close SGPro
- Connect your DragonFly to the machine
- Connect to the DragonFly with the DragonFly app
- Start SGPro
After SGPro queries DragonFly for its switches, it will show them from that point forward without having to connect the dragonfly.
Good to see that progress is being made. Tomorrow I will be at my observatory site again and will be able to do some testing. Will download the latest SGP 4.1 beta, that should be .728 if I am not mistaken. Or should I await the next beta release? I do not have easy internet access at my observatory, so will report back with results later this week. OK?
I will be releasing beta 729 tonight I hope. If using 729, you can disregard the steps above.
@Ken @jaime Just been able to do some tests with .728 and a Dragonfly connected to my computer. Unable to get this to show up as a Switch in SGP, although perfectly able to have SGP connect to the Dragonfly as a Dome. No difference in starting and connecting Dragonfly before SGP or letting SGP trigger launch of Dragonfly software.
There is a smoking gun though and it points outside of SGP. When running the ASCOM Diagnostics tool it is unable to connect to Dragonfly Switch and also unable to connect to Dragonfly Dome, even when the Dome is connected in SGP. I do not understand that at all. No difference in ASCOM Diagnostics tool 64bit or 32bit.
Error message: Run time error ‘91’: unable to contact device.
Also when retrieving properties with ASCOM Diagnostics tool: Run time error ‘91’: object variable or With block variable not set.
Update: running ASCOM Diagnostics tool with Admin credentials while running Dragonfly and SGP with regular user credentials. Perhaps that causes these effects?
Further update: running all with Admin credentials only gets rid of the run time errors, but ASCOM Diagnostics tool still unable to connect to Dragonfly Dome or Switch while able to connect to Pegasus UPBv2 Switch.
This was done with Dragonfly and Pegasus software running, both connected to their devices. This time without SGP running though.
Using ASCOM platform 6.5 (not yet upgraded to SP1).
I won’t be too surprised if there’s any issue, other than this being the first report, but I haven’t changed the server code in a while.
There is a quirk in our software, because of the way we implemented the comms broker; for a smooth operation, it is best if you launch the software before connecting via ASCOM; this way, there are no delays that may cause an exception.
About administrator vs regular user: yes, that’s a problem, everything should be launched from the same access level, otherwise they won’t find each other.
I am not going to be able to test in a few days - if you could confirm the issue(s), I’ll appreciate it very much!
Hi Jaime, all these tests were done with Dragonfly software running and connected prior to launching ASCOM Diagnostics tool and attempting to connect from there.
I prefer to run everything with normal user credentials, but ASCOM Diagnostics requires admin credentials. No problem to run everything with Admin credentials for these tests though.
Let me know if you want me to run further tests.
I found a stray dragonfly so I just passed both the conformance tests and also the diagnostics. For both the dome and switch driver. In 32 and 64 bits. Everything worked fine.
For the diagnostics, it worked with either the Dragonfly software running beforehand as administrator or not running at all. It failed if previously launched as a normal user (I get the '91 error - but it makes sense with the different access levels)
Meanwhile updated to ASCOM 6.5 SP1 and SGP .729. Accessing all as Admin user for now while testing these ASCOM Diagnostics vs. Dragonfly issues.
When launching SGP it still launches the Dragonfly software. It also shows the Dragonfly switch now in the Control Panel and always as connected. Impossible to disconnect. In the Sequencer window I can connect and disconnect the Dragonfly observatory (roof).
ASCOM Diagnostics tool still unable to connect to Dragonfly switch or dome, neither as 32bit nor as 64bit. Even with Admin credentials showing the 91 run-time errors.
ASCOM Diagnostics tool able to connect to Pegasus UPBv2 though, both with and without Admin credentials.
Any suggestions on how I can make this work or what I can do for further analysis? Other than the misery of uninstalling and reinstalling the lot. Would like to avoid that if possible.
Will try with an another computer with same astro software setup tomorrow.
OK, progress is being made. After reboot (always a good idea), running ASCOM Diagnostics as Admin and letting that launch Dragonfly Switch and Dome, I could connect to both. Successfully on both computers I have available.
Returning to SGP it gets weird. First time letting SGP launch Dragonfly it did actually show the “children” of the Dragonfly switch in the Control Panel. Unfortunately the Dragonfly software could only show Not Init as roof status and SGP could not connect to the Dragonfly dome.
Closing all and starting Dragonfly again it showed the correct roof status. Starting SGP it did not show any of the Dragonfly switch details (“children”) anymore, but SGP could connect to the Dragonfly dome.
In summary I can use the Dragonfly dome with SGP if I start the Dragonfly software first, but then I can not connect to the Dragonfly switch. This is fine with me, but not as it should be.
Alternatively I can let SGP launch the Dragonfly software, it will then show the Dragonfly switch details but is still unable to connect to that device. SGP is then also unable to connect to the Dragonfly dome. Not even the Dragonfly software can control the roof in this case.
OK to use for now while the issue with Dragonfly switch remains unresolved.
Any other Lunatico Dragonfly users on this forum?
So there is a quirk with our software; when you launch the dome, or switch driver, they in turn launch, if not already present, another program that keeps the comms up. If you then disconnect from the driver, the main program keeps running, hidden in the notification area.
While this is something we’ll change in the future, it has worked well so far - as long as everything is always run at the same privilege level. I understand running ASCOM diagnostics, but in this case I think it only adds noise to the situation.
Let’s see if anyone else is having problems.
I bought a PPBU V2 two weeks ago and set up a new PC from scratch using all the latest software including SGP v4 64 bit, I would have to go to my obsy to check version. All working fine, I don’t use switches ( not sure what they are) but I just connect the power box using its own software before I boot SGP. Works great, love the PB and keep coming across new benefits of using it.
Your Pegasus UPBv2 is a switch: it allows to switch power and data connections to other devices on and off via software. The Pegasus UPBv2 is indeed a great device that is now fully supported in SGP 4.1. Lunatico Dragonfly is in many ways similar to Pegasus UPB2 albeit focused on power rather than data.
Question is still if there are other astrophotographers out there that use SGP as well Lunatico Dragonfly?
Sorry for the delay in responding. I was on the road the past couple of weeks. I set my rig up last night with the latest Beta version of SGP installed. The sequence started with no issues this time. It appears as though the changes you made have taken care of my issue with the Pegasus Power Box V2. Thanks for all the effort in making this happen. It is appreciated.
Hi Ventania - sorry for the late reply to this thread as a longtime Dragonfly and SGP user.
I have two remote rigs in Spain, each with a Dragonfly and running SGP 3.2. These rigs have no issue at all. I have a backyard ROR observatory in the UK with a Dragonfly and SGP using the latest beta 18.104.22.1683 and I have been experiencing problems with regular disconnects to the Dragonfly Observatory controller during a sequence since using the beta. This causes the roof to become unslaved. To resolve this, I open the Sequence window, reconnect to the Dragonfly Observatory and then am able to tick the slaving option again. I am imaging now as I type and have had this disconnect 5 or 6 times since commencing sequence 3.5 hours ago.
I have up to now thought these disconnects were perhaps a network cabling problem: my hub and cables are 5 years old. I have replaced my switch hub and ethernet cable from my mount to the hub (10 Micron GM1000) as I have also observed mount disconnects in the last few months. This evening I have not observed any mount disconnects (which I hope is progress). I have not yet replaced the ethernet cable between the Dragonfly and switch hub. I plan to replace the ethernet cable between Dragonfly and hub as soon as tonight’s sequence completes to see if that cures my disconnecting. If my disconnects persist, I may also download SGP 3.2 and install this in a separate folder to see if the disconnects are repeated with the older non-switch version or if they cease. This will rule out any Dragonfly/SGP 4 beta issue I think, pointing to a hardware network/cable/ethernet problem.
I open the Dragonfly software on my PC before starting SGP and have done this since the first switch beta rather than open SGP and have it start the Dragonfly app. I do not use the switching functions of SGP but instead use Dragonfly scripts for powering on/off equipment, triggering UPS, safety closures for my roof via the Cloudwatcher and Solo.
As general information, I have not observed any disconnects with my Solo or IP webcam nor between the house computer and ROR network (via power line adapters, ethernet over mains) and remote connection via AnyDesk to the observatory PC.
Good luck and I will report back when I have further findings.
Hi Barry, thanks very much for your comprehensive reply. I was considering calling out to other Dragonfly users as this thread started with the Pegasus UPB and (once that issue was resolved) got sidetracked by me towards the Dragonfly. Understandably many or most users will only consult this forum when they run into trouble. I am sure there are lots of happy SGP4 users with a Dragonfly, but it could be hard to get their attention. Glad you entered the discussion here.
@Ken or other moderators: feel free to move the Dragonfly related posts in this thread to another thread. Not sure how you guys usually deal with that.
So far I have not had any problems with SGP 3.2 and Dragonfly, but I do with SGP 4.1 and Dragonfly as described in previous posts in this thread. Unfortunately this has now boiled down to some generic problem with SGP 4.1 in my particular setup that is perhaps not even related to the Dragonfly. Ken is helping me figure that out while working on possible solutions in the next beta.
I also use Dragonfly to control my ROR observatory on a rural site. Hardly any internet connection there, so no real remote operation, other than from my house at that site over a LAN that is partially wired and partially wireless. I am very pleased with the setup where SGP controls the entire session and Lunatico products like CloudWatcher and Dragonfly ensure the roof gets closed and the session gets paused when clouds roll in overnight. GNS will wake me up with an alarm when necessary. All in all a great way to make the most of a clear night and still get some hours of sleep without running the risk of rain or other issues damaging the equipment. I am sure you appreciate all of this just as much. Only thing missing is to be able to do this using SGP 4.1.
On my obervatory computer I had to roll back to SGP 3.2, but on a regular laptop I have continued testing SGP 4.1 with and without Dragonfly. This was all daytime testing, mainly to review connectivity and other functionality. While doing that I found the same intermittent connection issues that you describe between SGP and Dragonfly, or actually between the Dragonfly application and the Dragonfly hardware while SGP is apparently trying to connect to the Dragonfly ASCOM driver.
In my case the cables are also almost five years, the network switch is even much older and the wireless access point and router are about a year old. All network connections have proven to be fine and stable though for RDP sessions to the observatory computer and for an IP webcam to keep an eye on the mount from within the house. It is only when using SGP 4.1 with the Dragonfly that I notice these connectivity failures. Without any further proof that does not mean that this is actually caused by SGP 4.1, but you might want to check if the problem disappears when rolling back to SGP 3.2 same as on your remote location.
It is also my preference to first start all other applications that are used by SGP, prior to starting SGP itself. This will eliminate any timing issues in the communication when SGP connects to hardware via the drivers launched by those other applications. This is also advised by Lunatico developer Jaime.
At least you can run a sequence with SGP 4.1 and your Dragonfly, although you do suffer from these disruptive network connections. In my case I can not even start an SGP 4.1 sequence. Surely the rootcause must be related to my particular configuration. It is good to know that there is light at the end of the tunnel as you have shown it is possible to operate a Dragonfly with SGP 4.1 and run a sequence. Many thanks for that confirmation.