03-04-2016 04:19 PM
I am writing a VISA based VI to control a pair of Cool Muscle CM1-C-23L20C servo motors. They are accessed via USB, and my codes are working at this point. However, when everything is finished, I need to make the operation as "bullet proof" as possible. At this point, if you abort the VI or stop it otherwise, the motors will continue to run as per the last serial command that was executed. My plan is to "hide" the abort button using the :File »VI Properties, select Window Appearance from the Category drop-down, and click on the Customize... . I would include a "STOP" button on the front panel that when activated, will triger an inner case statement that would send the proper commands to the motors to stop them and then exit the VI. Like wise, could I take the boolean output from my "Simple Error Handler VI", and "or" it with the output of the STOP button, to trigger the safe shutdown case statement in the event of an internal error?
Does this seem to be a reasonable solution to avoid leaving the motors in a running state?
Thanks.
03-04-2016 07:07 PM
@zwartpete wrote:Like wise, could I take the boolean output from my "Simple Error Handler VI", and "or" it with the output of the STOP button, to trigger the safe shutdown case statement in the event of an internal error?
Does this seem to be a reasonable solution to avoid leaving the motors in a running state?
It is a common practice to stop a VI (go to a safe shutdown state) in the even of an error.
But the fact that you are dealing with something this critical tells me that 1) you need a controller with a watchdog so that it will stop if messages stop coming and/or 2) you need an electrical e-stop to stop the motors when something goes wrong.
I never trust Windows when it comes to a control system. It is too unpredictable (random crashes, program freezes, Windows randomly does not let your application run, inconsistant timing, etc). But if your servo controllers have some safety built in (like a watchdog and/or e-stop), then it is not the worst thing in the world.
03-05-2016 06:17 AM
03-05-2016 01:15 PM - edited 03-05-2016 01:30 PM
The concept we really need to discuss is "Fail-Safe"
It is not unique to any specific programming language. It is not specific to any class of hardware. It IS a foundational system design component. The first rule of system design is that "It MUST NOT cause unintentional damage to personnel or capitol!" The rare cases where "Destructive Testing" is necessary are out of scope for the rest of this post (lecture)
The System design MUST respect the first rule from conception! You cannot just "shoe-horn" it in as a final stage of development. I'm even going to coin a phrase I have never heard used before that I think is very discriptive "Wille E. Coyoting the design."
Patching system design flaws with software is a recipe for trouble as seen here with a sound conclusion drawn at 10 seconds in.
Learn from their mistakes and don't release that until your team has reviewed the system design.
03-05-2016 04:05 PM
All,
Good advice from all. I do plan on having a mechanical "Emergency Stop" switch readily available to cut the motor power in the eventuality of a computer or other hardware failure. I can also implement a feedback loop from the motors to check their state.
Thanks!