Emergency Stop programming
RobertW
Posts: 66
Hello,
I am looking to add an emergancy stop to a program using either one of the switches or buttons on my Prop. Prof. Dev. Board.· I have tried using a·REPEAT WHILE INA[noparse][[/noparse]Pin1] <>= 0·loop that watches INA[noparse][[/noparse]Pin1] which sort of·works, but when I branch to·methods in other objects I seem to have to use·a similar·repeat loop in each method.· I think there could be an easier way but am not sure what it would be.· I know that this is a common feature on some robotic vehicles and on machine controllers so I bet someone already·has a solution...· Any suggestions?· Thank you.
I am looking to add an emergancy stop to a program using either one of the switches or buttons on my Prop. Prof. Dev. Board.· I have tried using a·REPEAT WHILE INA[noparse][[/noparse]Pin1] <>= 0·loop that watches INA[noparse][[/noparse]Pin1] which sort of·works, but when I branch to·methods in other objects I seem to have to use·a similar·repeat loop in each method.· I think there could be an easier way but am not sure what it would be.· I know that this is a common feature on some robotic vehicles and on machine controllers so I bet someone already·has a solution...· Any suggestions?· Thank you.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.
They allow you to do just that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
What about running one COG as a watchdog? It uses a defined memory location to see which other COGs should be stopped in case of hitting the button.
This simply is a bitmap in which each COG can switch on and off the emergency brake feature by setting/clearing the according bit. As only 8 bits are needed, the watchdog can use another byte to indicate which COGs have been stopped, so that a supervisor has the chance to detect that and reload the COGs.
The loop of the watchdog is pretty easy:
check the button-pin until it's been pressed
read the watchdog-configuration to get the watchdog-bits
for each COG-bit (except the own COG-bit of course) which is set do a COGSTOP
write the bitmask of stopped COGs back to watchdog-configuration and clear the watchdog-bits
( wait until the watchdog-bits contain at least one bit again )
There are exceptions. IE: Cutting power to some machines motors may cause them to coast dangerously. (Ofcourse the proper solution to this is a break on the motor...)
0v = button pushed
2.5v = normal state.
5v = wire cut
bottom register must be by last switch
this is how fire alarms work though they use 24v
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.
1. Use a COG to monitor the "stop" pin; when it's in the stop position, do the "reboot" command.
When the system reboots, it should check the stop pin and behave accordingly.
2. An alternative would be to have whatever you need to stop (motor, servo, stepper, etc...) run
by a loop in a cog managed by variables that you control external to the cog (main spin code manager).
In this run loop, you can check the "stop" pin and stop all activity and sen status to the manager.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I was programming industrial controls.
The REAL emergency-stop was always HARDWARE that switched off the energy
(NO software between detecting and switching because software is much more
complex than a simple switch and could fail for many more reasons.
As far as I know robots all axles of the robot has a brake
the brake is opened by eletricity and closed by a strong mechanical spring
working in "pressure-mode" (means when brake is opened the spring is pressed not pulled)
(I don't know the details but I guess there are minimum two springs every single capable of
closing the brake very hard and the security-factor against overloading the spring will be a factor of 5)
This construction gives the highest security that is possible
push the emergency-button which switches of eletricity
and the robot stands immediatly still
even if the powersupply of the brake-opener should fail for any reason
(cable broken, fuse blown or whatever) the brake will close
But the software has to detect a emergencystop anyway
and therefore the effort is to have a variable that is used in EVERY loop.
and abort the loop if variable value is on abort
this construction allows to generate DIFFERENT abortion-values that can indicate
the REASON WHY the program aborted
one way to make this a little bit easier is to use the result-value of the method
whenever it is not used for other purposes
CON c_OutOffRangeERR = 103 PUB DoWhatEver (parameterlist....) : Code ..... if Somevalue "outOfRange" Code := c_OutOffRangeERR ...inside EVERY loop
programming a abortion EVERYWHERE is one of the differencies between "hobby"-software and "industrial"-software
best regards
Stefan
Post Edited (StefanL38) : 4/4/2009 7:43:14 AM GMT
I read your post and took a long brake. But I still can't stand commenting your post.
"I was programming industrial controls."
"programming a abortion EVERYWHERE is one of the differencies between "hobby"-software and "industrial"-software"
This pretty much reads like "I am the king and what I tell you is the one and only truth"! I have to say: I don't like such kind of comments.
As a professional you should know, that·a solution might be good for·a lot of similar problems, but there is alway an exception where you should start thinking again and not doing it like you ever did it before.
E.G. Having a full stop build in HARDWARE obviously was a good thing in the area you worked in, but it can be desasterous in other areas. Switching of the power or maybe an engine might be good in a project for another this would be dangerous. As you already mentioned we don't know enough of Roberst special problem to give such kind of ultimate advice. We can only show him some directions.
My direction was to implement some kind of watchdog. And as far as I know watchdogs are industry standard as well. A lot of other microcontroller architectures have a build in watchdog for that purpose.
Your abort-suggestion of course works. But we talk about a multi-core system. The abort condition might be spread over several COGs. For example COG 1 drives the motor, COG 2 measures the distance to objects. Then a condition in COG 2 has to stop COG 1. Now comes COG 3 which is responsible to receive commands from an RC. In case the RC sends an emergency brake command, COG 1 has to stop motors as well...
Your advice is to have the loop check a abort variable. Here it is important to know the response time of each subroutine call you do in your loop. So, for long running code you need several abort checks to guarantee the needed response time.
And that's where watchdogs are good. When you implement a watchdog your loops can do whatever they need to do. They are simply stopped by the watchdog, if the abort-condition is met.
I·guess having a general watchdog object would be a nice idea for the ObjectExchange ... have to think about that!
·
Chill out man, I read Stefans post too and didn't take it in quite the same way that you did, I just think things are getting lost in translation.......
He's offering free advice at the end of the day in an effort to help someone out, he can't be criticised for that can he?
Every one has their own inimitable style, I remember deSilva had similar criticisms but everyone forgot all the good he did and all the help he gave to others on this forum.
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX - The home of the Hybrid Development System and PropGFX Lite
my post was not meant in a manner like "I am the king and that's the only truth"
or something like that. I apologise if somebody read this "message" between the lines
I just wanted to describe the "upper" end of security-requirements
I wanted to express that industrial software has to have a reliability of 99% or more
and that the security-requirements are higher than for a hobby-project.
I had to make these industrial-applications as FOOLPROOF as ever possible. I've seen enough maintenance-guys
from real big companies that did try all kinds of things to get a machine working again.
Because they did NOT look into the manual.
They tried things without thinking even ONE minute about if this could make sense
philosophy: "if this does not work - try that - maybe it is not working too !"
Of course I did NOT develop software for dozens of companies in hundreds of complete different applications
The control-software I did develop for PCs had about 30000 lines of code running in several threads
and there were really HUNDREDS of abort-checkings in it to make sure - what you mentioned -
that the responsetime is kept short.
Your idea about the watchdog is a good solution if a complete restart of the control is no problem.
So I'm excusing for the inconvenience my earlier post might have caused
best regards
Stefan
@Coley:
I think in my post I did not say that Stefan should better stop posting or that his post in general was not valuable. Maybe I misinterpreted some of his comments because of his style, e.g. highlighting "REAL emergency stop", using "always HARDWARE" ... and so on. Now that I know that style and that I know he did not mean it like I interpreted it, I'll not blame him again.
In fact my main subject was to point out that we should know a little bit more about the problem to give real good advice.
@Stefan:
Even the upper end of security-requirements has different goals which have to be reflected in programming. And the platform you develop your software on has impact on the way you can/should do it as well!
A watchdog does not necessarily mean to stop execution of the running program. As we are running our SW on a propeller the watchdog can simply have the task to check the different abort conditions. To stay in the example from my 1st post: The watchdog simply checks the output of the distance control COG and the RC COG. If one of the abort conditions is met it can do several things:
- stop a COG which want's to be stopped in a certain condition
- start an emergency handler
- simply set a flag or a status
or whatever is useful for the given problem.
I truly think that such a watchdog which runs parallel increases maintainability of the code and can increase responsiveness because this is the only task it has to perform.
Have a nice day or evening or whatever matches to the timezone you live in ;o)
Thank you for the replies and suggestions.· I am looking to build a simple 'home-built' lathe.··I should have mentioned this earlier, sorry.· In a simple form, this will require a spindle motor, 2 axis drives (X and Z), a visual output (I am degugging·using a TV screen and would like to evently switch to a VGA), and some input devices (currently using the switches and buttons on the Prop. Prof. Dev. Board).· I am building it for my own personal use so I need it to be safe, hence this is why I am starting with some form of e-stop control.· @ StefanL38, I know where you were going with your need to be 100% foolproof·for maintance personnel unwilling to read a manual·but I don't require that in this particular application.· I just need a safe way to stop the machine with a message output.
· Just like some of the·CNC machining centers and lathes·that we have·where·I work, and as best as I understand, when the e-stop is pressed all axis and spindle drives stop immedately and an error message is shown on the screen.· Before I started the thread, I was think of starting one of the cogs and using it as a dedicated watchdog.· My thinking was that if the program was running and the e-stop was pressed then it could branch immedately to stop (or pause)·certain things and keep certain things running (ie, the computer screen for messages)·but not shut down the whole Propeller chip and not have to wait until it comes across a certain point in the code.· As others commented, I do know that in 'real' applications, and mine eventually,·that the e-stop may work differently by cutting power to certain features, etc. but wiring one of the switches on the board provided a simple input method to trigger the Propeller to do something and display a message on the screen.
· As I wrote in my initial posting,·what I have tried is using·REPEAT WHILE INA[noparse][[/noparse]EStopPin] <>= 0.· I was looking for a possibly better way of proving this type of control instead of having each method contain the same REPEAT WHILE loop.· The idea of having a watchdog cog and then doing a COGSTOP to turn off the appropriate cogs when needed seems to be a good starting point.· When I tried this before, I did not have much luck.· I believe that I was not sending information between the methods correctly.· I need to revisit this idea.
· I have·limited·machine control knowledge, some high school and collage computer programing, and picked up the Propeller around Christmas '08.· I believe I can get to where I am going with the Propeller manual, suggestions from the Forum, and some constructive criticism.· As always all suggestions are welcome.· Thank you for the suggestions and comments already posted.
-Robert
For me it's currently about 8AM on Saturday.· I am feeding a bottle to my son with one hand and typing with the other.
Your comments about running in parallel is why my original thought was to start a new cog early in the program for a watchdog and let it run in the background just checking the appropriate pin then do something when the correct condition exists.
As I just wrote, I need to go back and try this idea again.
Thanks.
-Robert
as a lathe is not a project wich requires to reduce the selling-price from 50 dollars to 44,90 dollars
how about a solution with two propellerchips ?
First Prop for controlling the spindle and X/Z-axis
Second Prop for displaying status on a VGA-screen and minor controlfunctions
then the first prop could restart and the screen will still show what is going on
Another idea:
the watchdog-cog could control some external electronical gates that are insertet in the signalway from the propeller to the motors
or - as it still should be an emergency-stop
OR-ed inputs:
one directly from a hardware-switch
one from a propeller pin
this would give the possability of stopping the lathe when pressing "the red button"
and stopping when for example when a tool runs too fast into material or whatever can be detected by software as a fault
best regards
Stefan
why would you need 2 propellers? You need one COG for TV or VGA, one for spindle, one for x-axis and one for y-axis (in easy programming - I'd guess one COG can handle all motors), one COG for input-devices and maybe one running the main-program. That's 6 COGs, 2 left for watchdogging ;o) But again, here we have not enough knowledge of the surrounding hardware.
When I have some time I'll try to write a general watchdog object, as I believe this would be usefull for more applications. In my imagination you could set it up to do the following:
One end switch on both sides and both axes switches off the corresponding axe. -> and maybe run an emergency procedure to go back some steps before full stop.
A sensor input which checks the spindle turns could switch of the spindle if it seems to be stuck with stopping the x and y axe motors as well.
The emergency brake button will turn off anything.
....
OR-ed inputs? Shouldn't it be AND-ed inputs?
Truth table says:
0 OR 0 is 0 -> Motor stopped
0 OR 1 is 1 -> Motor runs
1 OR 0 is 1 -> Motor runs
1 OR 1 is 1 -> Motor runs
So, with an OR I don't see that the propeller could intercept. An AND with pull-down resistors would work. Both have to pull the input-lines to high to allow the motors to run. If one of both says 'No' or is disabled, no motor can run.
By the way, what does <>= mean? Shouldn't it be ina[noparse][[/noparse]pin]<>0?
I have to go for shopping now. Have fun with your son and wish you have a nice day.
@StefanL38
I can see the reasoning behind 2 Propeller chips, 1 to run full time and 1 that might be reset in the event of an emergancy stop.· This is similar to jazzed's suggestion earlier.· I was hoping to avoid something like this by using the parallel nature of the cogs but it is an option to explore since I did buy a second chip just in case I accidentally·turn the first one into a one-time smoke generator·[noparse]:([/noparse] ...
@MagIO2
Does the TV or VGA outputs require 1 or 2 cogs.· For some reason I seem to remember reading that it requires 2.· Either way with your estimation of cogs required it would be 6 or 7 with 2 or 1 cog(s) left for watchdogging.
The additional hardware is still to be determined.· I was thinking of using stepper motors for each·axis.· Any thoughts?
As far as the meaning of <>=, on page 250 of the Propeller manual, it says that it is 'Boolean: Is not equal'.· Reading the title of the column again·though, I might be using the wrong symbol since I am not looking to·assinging INA anything, I am just using it to check to make sure·it is not equal to zero (or ground).· Always learning, always learning...
Thanks guys,
-Robert
if you want to do it with one chip I personal have a lack of knowledge.
I do not know if it is possible to do a cogstop commanded from cog 1 to stop cog 3
If this is possible it is no problem. I would have to test his too to know it.
But maybe someone else in the forum here can tell ?
Driving steppermotors is no problem.
there is an algorithm called "Bresenham-algorithm" which allows to drive two steppermotors
simultatinously by ONE cog at any ratio speed1 : speed2 for the speed of the two axis.
I attach a PDF telling the basics about bresenham
What I did not understand was your question about page 250
could you post the interesting lines of code ?
best regards
Stefan
Post Edited (StefanL38) : 4/5/2009 11:19:10 AM GMT
Reset of the whole propeller looks a bit problematic for me in case you want to do more than just have a emergency brake button, because you loose all your state information then. Or you need external hardware which stores the reason for the reset. Please remember, the propeller is not one of the fastest microcontrollers when we talk about startup-time. First it waits for a PC, then it has to load the full 32kB from the serial EEPROM, then it loads the 512longs into the COG. I don't see a reason for doing it that way. The propeller itself doesn't even have any problems which would give a reason for the reset.
I'd give it a try with the SN754410 which can be used as stepper motor driver and where you can find some code in the Objec Exchange for.
I didn't even know <>= before, but the = looked like an assignment for me. Yes, you're right: always learning. But learning is good!
yes, stopping one COG from another one works. Otherwise the COGID parameter of the cogstop command in SPIN and in PASM would not make much sense. (And I already tried it)
best regards
Andreas
We thought stopping the spindle in the shortest possible time would be the safest. So we selected the "DC injection" braking mode of the VSD. This sure stopped things quickly. The spindle shaft stopped dead, but the jaws attached to the end of the shaft had a lot of inertia, unwound themselves off the spindle thread, and shot off across the workshop.
I guess the lesson is to think long and hard about the true safety issues at a physical / kinetic level, and try to limit things mechanically. Make sure the X and Z have travel limits to stop them hitting the jaws etc. Thick polycarbonate guard cover hooked up to the hardware e-stop. Ensure the tool is fully retracted before restarting the spindle ('home' limit switches required) ... this is just for a start.
You need a 'recovery from E-stop' sequence in your program which safely brings the lathe from its "unknown", e-stopped state, back to a ready-to-start state.
It would be worth carefully reading the safety section on the manuals on your lathes at work to glean the subtle things they do to ensure safety.
What motor are you using for the spindle? Does it have an inbuilt brake?
tubular
As always, thank you very much for the suggestions and comments.
@StefanL38
On page 118 of the Propeller Manual, it shows how the COGSTOP command can be used:
... PUB Stop if Cog cogstop(Cog~ -1) ...Also, thank you for the stepper motor algorithm.· I have downloaded it and plan on reading it later today.· I also remember reading an article in Servo magazine a few months ago that explained about driving stepper motors with a Propeller.· I believe it was part of a 3 or 4 part monthly series written by some people from Parallax.· (Sorry I don't have the article in front of me with the arthor's name).
@MagIO2
I must be remembering that the VGA / TV methods then require a minimum of 2 cogs, just like you said, 1 for the VGA or TV objects and 1 for the main program.
Also, thank you for the part number for the stepper motor driver.· I will look up the data sheet and try to understand it better.· Have you personally used this driver?
@Tubular
Thank you for the lathe safety suggestions. The VSD that you mentioned, does this stand for Variable Speed Drive?· If yes, what did you use? Would you recommend this for someone with limited electronics / motor drive experience (ie, me)?
To all:
A·few posting ago there was some discussion about using AND or OR in conditional loops.· Would I be wrong if I said that it depended in the use of each condition?· Using AND, could it be said that if E-stop is not pressed AND·motor drives are not overloaded AND cycle start is pressed then run, etc.· Using OR, could it be said that if E-stop is pressed OR motor drives are overloaded OR three dogs bark, well you get the point, then stop machine.· For some reason I seem to remember that it is better to use OR statements in safety applications.· Is this true, or does it not matter?
Also, any suggestions on stepper motors and drivers·and spindle motors and drivers·to use?
Thank you
·
This appears to be similar to what I am looking for.· No need for <> 0 just use a NOT operator.· Very simple.· I will have to try this also.
-Robert
No, I didn't use the stepper motor drivers yet, I only stumbled over the driver in the object exchange. Even if you don't want to use this particular driver chip, the driver software could be useful for learning or maybe can be adapted for other chips.
*sigh* Well I'll just tell you what I did with the last controller I built. It was a simple single axis drive for a backstop on a breakpress. I used a gecko drive to control the motor, which features a disable input. When the EStop string is broken, that input is activated, cutting all control to the motor. The prop will also detect this, and won't allow movement until the EStop condition is fixed, and the axis is homed again.
I personally don't do any per-every-loop checks. Relying on a complex computer type system is always a bad idea imo. The EStop is hardwired to do what it needs to do. I don't even check with the prop very often. Since the EStop latches the signal for a minimum amount of time, and the props control is already nullified durring this time, it's only important the the prop gets around to checking it eventually. In this system, a full couple of seconds would have worked actually. Anyway, I check for the EStop in the prop once per main control loop, and once in the homing loop also. All other loops are guaranteed to exit in a timely manner, as they don't require external input. (They operate on internal prop data only, such as ascii string parsing, etc..)
Food calls me, just wanted to throw out how I did it last.
Really, you need to evaluate your situation with safety in mind. I believe your detection problem lies in using a dedicated cog for error detection, that signals or cogstops other cogs, not display however.
Post Edited (James Newman) : 4/5/2009 9:52:52 PM GMT