1 Attachment(s)
Why is it that ACP gets "stuck" sometimes? Can't you do something?
I was editing this today and thought I had physically deleted an add-on message, instead I deleted the whole damn thread! This is a repost of a message from 2013:
Let's say the focuser is designed with an electrical tick counter that produces a pulse that's sent to the serial (via USB) input. On the PC is a driver that manages these ticks and sends signals to the motor to drive the focuser. Now ACP wants to change the focus count
09:37:43 Focus change of 644 steps required
ACP can call the focuser's (ASCOM) standard functions via passing through FocusMax. This allows both ACP and FocusMax to do things with the focuser. ACP sees just the standard functions common to all focusers. It asks for the current focus count, then adds 644 to it, then tells the focuser to move to the new focus count by calling the Move() function. It's possible that the focuser system is crude, and this function won't return until the move has been successfully completed. Or the focuser could be a bit more sophisticated and return from the Move() command immediately, starting the focuser on its way. In this case ACP would periodically fetch the IsMoving property of the focuser and wait until it goes false. One way or the other, at this point ACP would move on.
Given the above, what went wrong? On the surface, ACP would call Move() then try to fetch IsMoving, but one of these calls never returned control back to ACP. We can stop here because ACP is out of the picture at this point. It is in a state of suspended animation, enforced by Windows due to calling across process (program) boundaries. Why the call to change the focus position failed to complete successfully is anyone's guess, and I spend a lot of my time making educated guesses for others on things like this. "Educated" because I have experience and I ask for evidence to help. But that activity takes away from my ability to work on the software we develop and sell. On the other hand, a significant part of our business is support and we take pride in living "software is a service business not a product business" so I try to help people with their systems since we operate at the top of the food chain. It's sometimes a thankless task but I am happy with myself anyway :-)
I can hear the programmers out there saying "Well just spin off a separate thread to monitor it". Guys it ain't that simple. First there are hundreds of calls to devices. Second the observing logic is all done in script, one of ACP's most important advantages. Can you imagine ACP layering itself on top of every device standard interface and implementing watchdog processes for every interface member (function/property) of every type of device out there? And how long DO I wait for the focuser to finish moving? Or the dome to finish slewing? Oh, well make those things settings. Are you starting to get a bit uncomfortable? Could this be getting into the realm of "gold plating" (overdesign)?
There is probably an argument to be made for a completely external watchdog timer program. Let's say it has to be "pinged" by ACP on a regular basis. If ACP gets jammed up by some device screwing up, the watchdog would see that from the pings stopping. Now let's decide what we should do if something screws up and hangs the main part of the system. Turn off tracking right? But what if the screwup is in the mount and its driver? Or the focuser twists itself off the telescope? And what if ACP is jammed up? How do we get to the dome/roof or mount anyway? Maybe the driver is a simple DLL that loads into ACP's process. We could attempt to close the dome/roof (oops, maybe the roof is a low hanging dangerous design, now we have to park the scope and maybe lower the pier before closing, and can that be done with an electrical contact?) then kill the power to all of the devices (since from the watchdog's point of view we have no clue what has failed). Send a text message to some people and tell them things are messed up? That might be a useful thing.
If you've read this far you get the stress that I feel whenever I deal with device issues, let alone the question about why don't I provide oversight and recovery. A watchdog program that runs a script or program might be a useful thing... The script could attempt to do things and/or send messages. But how do you test this? How do you create all of the possible jammed up modes of things to make sure that you can really safe the observatory without damaging something?
One last thing that I get asked on a regular basis: Why don't you just make a single program instead of relying on all of these separate pieces? The answer is "modular architecture enables complexity". Imagine an aircraft with one giant black box in the belly with 1,000 Cannon connectors and bundles of wires leading in and out of it. Everything is in there, engine controllers, navigation systems, radios, cockpit voice recorders, the autopilot and stability augmentation system, environmental controls, electrical system controls, drivers for all of the instruments and lights, transducers for the fuel tanks and controllers for the valves and pumps, you name it. Would this be a practical way to design the aircraft? Could you practically maintain it? Would it be less or more prone to catastrophic failure? I know there are "all-in-one" astronomy programs out there. I just don't think that's the right way to design and implement complex systems. Instead I prefer to work in a competitive environment where companies fight for "best of breed" of the different functions, and standards exist by which these components can be assembled into systems. And in the modular world, for an unusual application, one of the components could be specially made yet fit into the architecture, avoiding the need to make a whole new "all-in-one" program for a different type of mission.
I hope this answers not only Leo's original question but also give you some insight into my design and business philosophies. I'll leave you with a quote from Antoine de Saint-Exupéry, a French aircraft designer and (perhaps more famously) author from the early 1900s. This reflects what has been my design philosophy for most of my engineering career:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Attachment 11098
