Small problem with Moonlite focuser

Sequence Generator
1

This is not a new problem for me, just the first time I’ve had a chance to really take a look at what is going on. The Moonlite ASCOM driver is running on 64 bit Windows 7, SGP is the latest beta version.

Here’s the symptom: The first time SGP tries to connect to the focuser (using “Connect All Equipment”, the connection will fail and throw a message box to that effect. Simply by clicking the Connect icon on the sequencer, the focuser will connect. Once I have gone through this cycle, for the rest of the session, the focuser will always connect on the first try. Here’s the pertinent part of a typical log:

21:44:19.958][DEBUG] [Cleaner Thread] Cleaning finished…
[08/03/17 21:44:19.961][DEBUG] [Main Thread] UI layout found, loading layout at C:\Users\OEM\AppData\Local\SequenceGenerator\sg_ui_config.xml
[08/03/17 21:45:09.406][DEBUG] [Main Thread] Performing deserialize…
[08/03/17 21:45:09.447][DEBUG] [Main Thread] Loading custom filter names…
[08/03/17 21:45:09.493][DEBUG] [Main Thread] ReflectDataModel: Transferring data model to the view…
[08/03/17 21:45:09.548][DEBUG] [Main Thread] Retreiving new equipment objects…
[08/03/17 21:45:09.548][DEBUG] [Main Thread] New camera object (SBIG Camera) dispatched…
[08/03/17 21:45:09.558][DEBUG] [Main Thread] New filter wheel object (SBIG Filter Wheel) dispatched…
[08/03/17 21:45:09.567][DEBUG] [Main Thread] New environment device object (No Environment Device) dispatched…
[08/03/17 21:45:09.570][DEBUG] [Main Thread] New focuser object (Moonlite DRO Focuser Driver) dispatched…
[08/03/17 21:45:09.580][DEBUG] [Main Thread] New telescope object (Gemini Telescope .NET) dispatched…
[08/03/17 21:45:09.598][DEBUG] [Main Thread] New rotator object (No Rotator) dispatched…
[08/03/17 21:45:09.601][DEBUG] [Main Thread] New dome object (No Observatory) dispatched…
[08/03/17 21:45:09.604][DEBUG] [Main Thread] New flat box object (Manual Flat Box) dispatched…
[08/03/17 21:45:09.615][DEBUG] [Main Thread] New safety monitor object (No Safety Monitor) dispatched…
[08/03/17 21:45:09.617][DEBUG] [Main Thread] New auto guider object (No Auto Guider) dispatched…
[08/03/17 21:45:09.617][DEBUG] [Main Thread] No change in plate solver object…
[08/03/17 21:45:09.868][DEBUG] [Main Thread] Populating the form controls…
[08/03/17 21:45:09.960][DEBUG] [Main Thread] Added row 0…
[08/03/17 21:45:10.065][DEBUG] [Main Thread] Added row 1…
[08/03/17 21:45:10.174][DEBUG] [Main Thread] Added row 2…
[08/03/17 21:45:10.304][DEBUG] [Main Thread] Added row 3…
[08/03/17 21:45:10.465][DEBUG] [Main Thread] Added row 4…
[08/03/17 21:45:25.074][DEBUG] [Main Thread] Connecting camera in main thread…
[08/03/17 21:45:25.088][DEBUG] [Main Thread] Connecting SBIG camera…
[08/03/17 21:45:25.147][DEBUG] [Main Thread] SBIG Driver name: SBIGUDrv.DLL Ver 4.92 Build 1
[08/03/17 21:45:25.147][DEBUG] [Main Thread] SBIG Driver version: 4.92
[08/03/17 21:45:26.134][DEBUG] [Main Thread] SBIG Camera Name: SBIG STF-8050 CCD Camera
[08/03/17 21:45:26.135][DEBUG] [Main Thread] SBIG Camera Firmware: 2.48
[08/03/17 21:45:26.135][DEBUG] [Main Thread] SBIG Camera Num Readout Modes: 11
[08/03/17 21:45:26.137][DEBUG] [Main Thread] Connecting SBIG guider camera…
[08/03/17 21:45:26.137][DEBUG] [Main Thread] SBIG Guider: Could not query tracking information info (CCD_INFO_TRACKING)
[08/03/17 21:45:26.137][DEBUG] [Main Thread] SBIG Camera does not have onboard guider
[08/03/17 21:45:26.210][DEBUG] [Main Thread] Camera cooler detected…
[08/03/17 21:45:26.211][DEBUG] [Main Thread] Camera cooler is OFF…
[08/03/17 21:45:26.242][DEBUG] [Main Thread] SBIG CFW Firmware: 65
[08/03/17 21:45:26.242][DEBUG] [Main Thread] SBIG CFW Num Positions: 8
[08/03/17 21:45:26.284][DEBUG] [Main Thread] Connecting ASCOM focuser…
[08/03/17 21:45:28.739][DEBUG] [Main Thread] Failed to connect to focuser. : Exception has been thrown by the target of an invocation. (System.Runtime.InteropServices.COMException (0x80040407): Command error in Connected)
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object args, Boolean byrefModifiers, Int32 culture, String namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object providedArgs, ParameterModifier modifiers, CultureInfo culture, String namedParams)
at qy.ml(Boolean A_0)
at qs.ic()
[08/03/17 21:45:28.740][DEBUG] [Main Thread] Disconnecting ASCOM Focuser: ASCOM.MoonliteDRO.Focuser

It is almost like the driver is slow to instantiate (even though SGP is giving it somewhere around “forever” to get its act together). This is not a big problem now, since I am not doing unattended remote, but it probably will be in the future. Any clues as to where to look?

Thanks for any input.

2

I’ve tried and don’t see a problem. I’ve set up a profile with various simulators and a MoonLite DRO focus controller. Connect all just works.

Something that might help is to enable logging in the focuser driver - Check the Trace On checkbox in the focuser setup.

Then run what you need to do to reproduce this and post both the full SGP log and the full Moonlite driver log with some comments saying what you did and when.

The driver log should give it’s perspective on what’s going on.

3

Thanks Chris,

I’ll do that. I suspect it is something local to my system, not the ASCOM driver or there would be more reports of misbehavior. It is very repeatable but, as I said, only happens once per session.

4

this happens to me as well. the same focuser controller would occasionally “jump”, reporting a wildly different position. i decided the controller must be bad - sent it back to moonlite and ron sent me another.

i had a spare controller, and while it has never jumped, it exhibits exactly the same ‘failure to connect on first try’ problem. i have not tried the replacement controller but i expect it will do the same thing. the ascom log shows no response from the controller on that first try so i’ve decided this problem is either the PC, the usb-serial driver, or the hub i am using, all of which i have changed since using the spare controller last. i never had this problem until now.

i have been considering a script that runs at login that simply sends a few bytes to the controller com port to see if that solves the problem.

rob

5

For what it is worth, this often happens to me as well. “Connect All” often fails to find the focuser, but re-trying works. I’m not sure that the behavior is consistent, that is, sometimes it might work on the first try… I haven’t kept a close eye on it. I will enable logging and see what results I get. (It is cloudy here so I’m not sure when my next run will be.)

I’m using the Moonlite Dual Controller.

Karl

6

Rob and Karl, thanks for the info, it is good to know I’m not alone :slight_smile:.

From a few (more than I’d like to admit) years of developing third party application using serial ports, I smell a race condition. The DC power distribution on the mount has been such that the focuser and CPU are powered up simultaneously. I just went out and switched the focuser to the camera DC buss so I can control it independently.

This is not a definitive test but I ran three trials, from a cold power up of all equipment, and the focuser connected the first time every time. I’ll give it some more testing and report back if this seems to be a reliable workaround.

Chris, I’ll gather up some logs and post them. I really don’t suspect this is a problem with the ASCOM driver, more likely on the Moonlite side.

7

very interesting re: power race condition. right now i have a modern robotics power controller/hub attached to an intel stick PC. when the modern robotics switch is thrown, the camera, the focuser controller, stick PC and the rotator are all powered up at once. i guess i would not have thought of this as the problem because the power-on reset of all of that junk is just the first step - eventually the USB buses have to be enumerated by the PC and i’m sure there’s a fair amount of (soft) resetting that goes on in that process. i suppose it could be the case that the USB/serial in the moonlite controller has been properly reset but the AVR/PIC or whatever it is downstream of that depends on a good POR and that’s not happening for some reason. simply sending it a few bytes over the usb/serial interface seems like an unlikely candidate for unwedging it.

at any rate it is true in my case that if i reboot the PC, as long as the moonlite controller had been connected to successfully before rebooting, it continues to connect on the first try post-reboot. so i think you probably are on to something here.

rob

8

I’m not sure what you mean by [quote=“BobT, post:6, topic:5989”]
The DC power distribution on the mount has been such that the focuser and CPU are powered up simultaneously.
[/quote]

Is the CPU the PC that’s controlling things? This looks like a complex system where you are controlling the power to the devices. Or do you mean that you turn the power to the MoonLite control box on and immediately try to connect?

The MoonLite controller seems to go through a sequence where it’s displaying things before it is ready to operate and it wouldn’t surprise me if it isn’t able to handle commands at that time. If that’s the case logs may not help because all they will show is that the controller isn’t responding.

It’ll be good to run this to earth, I don’t like unresolved issues.

9

Chris,

The “CPU” is a micro ATX computer running Windows 7 and all my telescope control and imaging software mounted on my OTA. DC power was being applied to it and the Moonlite at the same time. The power switching isn’t complex, I use an 8 channel USB relay module to allow me to sequence power via a very simple-minded C# application that lets me manually select what is powered up. It was probably a mistake to have the computer and the focuser on the same relay channel, just wasn’t thinking at the time.

You’re right, the Moonlite controller just chokes and dies if you try to send it a command during its initialization cycle. The attached logs show a failed startup and a successful one.

ASCOM.MoonLite.1050.424570.txt (425 Bytes)
ASCOM.MoonLite.1133.442620.txt (19.6 KB)

I don’t think you need to spend any of your valuable time chasing this, it is a design error on my part.

10

Yes, nothing I can do until the hardware is ready.

11

although you are able to control your power sequence so that the moonlite controller comes on after the PC, i’m not sure why that should be a requirement for proper operation. for instance sometimes i have a USB disk attached to my laptop; i’ve never had an issue with having it powered up before my laptop or vice versa. i don’t know of anything in the USB spec which specifies a host/perhipheral power sequence.

i think there’s probably some kind of hardware design problem (or hopefully, firmware) in the moonlite controllers.

rob

12

I suspect the Moonlite driver was trying to communicate with the COM port before the computer gets fully booted up and gives up if it can’t open the port. I can only speculate on this. At any rate, switching the focuser over to a DC buss that comes up after the computer is booted seems to have cured the problem, it has not recurred since the change.

13

You may be over thinking this.

I’ve just watched my DRO box start and it takes about 12 seconds before the normal display appears. Before that it may not accept commands. Nothing to do with USB.

It was worth finding out what was going on but I don’t see a need to pursue this further. If you do then I suggest that you contact MoonLite directly.

14

i just confirmed that powering up my moonlite after the PC was powered up alllows the controller to connect on the first try, same as bobT. in my case i only waited until the hub was found, probably by the BIOS since i only waited a few seconds after powering up the PC before plugging the moonlite controller in.

in all cases it is way more than 12 seconds before i ever try to talk to the moonlite after power-on. the intel stick PC is dreadfully slow and it takes minutes from power-on until SGP is up and running.

i think there’s a real problem here, but i agree there’s nothing for you to do.

rob

15

I was a bit surprised that your PC could be running in less time than the MoonLite.

If it helps the failed log shown above shows that the serial port has been instantiated correctly and a message sent successfully. What’s happening is that no reply has been seen, the serial port has timed out, and the connect attempt fails because of that. If the port didn’t exist you would get a different error in the log. I think this means that the USB stuff is sorted out.

Try watching the display as it starts. It flashes several colours, then shows a prompt to press a key to get into a setup menu before going to the normal display. That should be long gone but if it’s still showing that will be significant. A momentary power glitch could do that.

16

this is exactly what i see in my logs as well, which is why i’m thinking that it’s not so much the USB but perhaps the logic past the USB/serial converter that’s not being reset properly under some conditions. clearly the act of sending those initial bytes causes it to wake up, but i suppose it wakes up after whatever timeout you have programmed into the driver expires. maybe the timeout could be made longer?

rob

17

So I’ve done some more experiments.

First, the Moonlite will set up the serial port when the USB cable is connected, no need to have power to it. You can see it’s serial port.

If you try to connect in this state it won’t, there’s no response. This also applies for a few seconds after the power is on, while it’s screen is showing solid colours. Once the prompt saying “Press any key for Menu” it seems OK.

Not at all clear. There is no need to send anything to cause it to wake up. If it was this would affect everyone. All you need to do is wait a few seconds to allow the hardware to start.

I’m not able to see your hardware but my guess is that for some reason the moonlite hardware isn’t being started as soon as you think. Try looking at it, perhaps your power controller is turning it off for a short time, or perhaps it’s turning power on just before SGP is started.

Could one of the other devices that’s being started at the same time with Connect All be doing something that will cause this? A power surge that’s resetting the moonlite hardware perhaps.

18

there’s got to be some kind of hardware issue here since 2 different controllers exhibit the same behavior, i don’t think it’s a bad controller, but i think there could be some issue with the firmware for the AVR or PIC or whatever microcontroller is in the thing. or it could have to do with the power-on situation.

my controller does not have any display. it’s the “mini controller v2”.

why do i have to wait a few seconds for the controller to start? as i’ve mentioned, minutes have gone by between the time the power is applied and the time i try to connect to the controller with SGP. it always, always fails to connect on the first try and always connects on the second try. this is why i’m saying that sending some bytes to the RS232 interface causes it to “wake up”.

there is no power controller per-se. it is a modern robotics combo power distribution/USB hub. when i throw the switch, all of the powerpole outputs are simultaneously energized. yes, it’s possible there’s droop on the 12V rail at that point because the focuser, the rotator and the camera are all connected to this rail, and there is a lot of inductance present.

here is what i’ve taken to doing. when i start SGP, i click the button to connect the focuser. then i get the dialog that the connection failed. then i choose “connect all” from the menu and everything connects - camera, filter wheel, focuser, rotator, flat panel, bluestick. this works 100% of the time. this is why i say “clearly the act of sending those initial bytes causes the controller to wake up”. aside from a USB reset there’s no way for the PC to reset the moonlite controller and certainly no way for it to power cycle the controller.

i don’t think it makes sense to say that “if this were true then it would affect everyone”, because it didn’t affect me when i had a completely different power/usb architecture on an older version of the rig. what i am saying is that for some reason, in this setup, the controller seems to be a little bit wedged, and sending those first commands causes it to eventually become unwedged. how long it takes i can’t say because there’s a lot of clicking and menu choosing which again takes seconds.

how long is your serial timeout? i wonder if it’s possible that the moonlite would respond if given more time, or given another command.

i don’t think there’s any visual feedback on the mini v2 controller, so i cant tell if it’s been reset or is not ready?

btw am i using the wrong ASCOM driver? the driver is called “DRO” and you are referencing a moonlite with a display…

rob

19

I realize this does nothing to help with your problems, but I experience none of these issues with the NiteCrawler Focuser/Rotator version 6.2.6286 (latest). All hardware ASCOM connections work first time/every time. Win10 Pro, Celestron Unified 6.0.0.6338, SGP 2.6.0.24 – no problems with .23 as well.