Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

disable abort button

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.

0 Kudos
Message 1 of 5
(5,004 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 5
(4,991 Views)
quick answer is no it is not
I you have to check if your motor is stopped or not use some feed back from your motor for example feed back from encoder or tachometer to be sure your motor is stopped
0 Kudos
Message 3 of 5
(4,966 Views)

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.


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 5
(4,958 Views)

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!

Message 5 of 5
(4,944 Views)