So I tried to report the fact that a smoothstepper will continue to output a pulse train on the charge pump even in the event of an error in Mach...even in the event of a serious system crash, even in the event that I tear the power cord from the computer. Not only that, it will also continue to jog the machine into oblivion if you happen to be jogging when this happens - Power failure, cord ripped out, the extremely unlikely scenario of windows crashing, etc.

I reported this on the Warp9 forum, and all I get is flack.

As you can see, my machine isn't a sherline with stepper motors scavenged out of floppy drives. If I had not set up the limit switches directly in to the servo amp, which by the way folks, don't EVER forget to do this if you can, but if I had not, it would have slammed 1KW/3KW peak of power in to pure bashing, crushing excitement.

With a working charge pump, this would never have happened.  If I had powered the smoothstepper from the PC, true, in the event of a power failure, this would never have happened either. but then again, with all the other boards, MPGs, analog spindle controls, etc, I have to use an external 5V supply for them all, so no smartie pants telling me that USB power is the solution to my problem.

My system is set up seriously. All my amps have and use "Servo Enable" inputs from one line out of Mach. They have logic and motor power input. Logic is always on. On top of servo enable, the motor power input wires, all three phases, go through a contactor on yet another enable line.  The spindle has a contactor AND a VFD, each on their own I/O lines, and all of this goes through my E-stops AND charge pump enable.  The servo fault lines and spindle fault lines all go in to an external e-stop input on the PLC. This is a big, dangerous machine, and I can't afford to drop $10K on a new Fagor controller.

Ooh!  That is BAD!  The SS should be getting some kind of "heartbeat" from the PC that acts as a deadman to protect against exactly that situation.  A trivial thing to implement, since it's using USB communications, it's got the perfect timebase for this functionality.  I find it hard to believe Greg would've designed it that way.   More likely it's just not working in the release you're using.  Was this with the latest plugin?

Regards,
Ray L.

If my reply was seen as flack I apologise, it was not meant as such. I may be wrong and I will know tomorrow when I test and I will admit if I am wrong
 I am thinking that if the SS loses communications my lathe will stop. If it doesn't then yes you are correct it needs to be addressed but as I  never relied on the chargepump when I had the parallel port  I am thinking it will act the same way.
Hood

Some people sell milk for a living. I make my living from these robots. I may not have spent my entire life building industrial automation, but certainly more than a few years. People are free to question my judgement, call me an idiot, a liar, spit on me, ignore me, etc, etc, etc, but please have some courtesy and don't do it automatically and immediately. I feel like I'm a hippie trying to convince the president that going to war in Iraq is a bad idea with the feedback I'm getting!



"Very good, now set up your enables like they should be and your fault signals like they should be "

and other stuff like

Dont understand this, if you are meaning the SmoothStepper could develop a fault and then send an axis or two or three going wildly out of control then please tell me how the chargepump would stop this happening?"

and better yet

Please give an example of where the chargepump would come into effect with regards mach and then why this would not be the case with the SmoothStepper.


Trust me when I say I've been on Warp9's web site and downloaded the absolute latest version of everything I could after I discovered this problem, only to discover that I already had the latest version of everything.

As far as implementing a dead man switch, watchdog timer, charge pump, whatever, I KNOW it can be done. There's a little blinky LED on the Smoothstepper that's just blinking like mad when it's happy.

I firmly believe that any charge pump and safety circuit should be totally independent of all other boards, and totally analog, and barely keeping its head above water in regards to remaining turned on from the pulse train.  Safety is important, and if you think you can ignore it even on your little piss-ant nema-23 hobby mill or CNC dremel built out of MDF, think again. On top of it all, you have to have those hard, non-computerized stops built in too. Put guards around things and places that can pinch, poke, or crush to a pulp, keep your hands out of the way, use two-hand logic on machines, wear your safety glasses, don't work on stuff when it's live, and don't stick your fingers in places that they shouldn't go.  The Mach3 manual preaches about it, and so will I. When you ignore these things, you'll end up like the last guys I saw - One machine, a nice, cheap Chinese tube filling and sealing machine. Granted, the guys on the production floor are idiots, but this machine chopped off two fingers in one week, and the following Tuesday, chopped off a third. I should give credit where credit is due, and note that this wasn't the same person getting more and more fingers cut off.  The problem finally got tracked down - no interlocks, badly placed sensors, and generally a poorly thought out or poorly implemented safety system.

That first one was my very last response after all your flowery language so I fail to see how that was a lot of flack. If you see the rest of the questions you  quoted as flack then I am sorry, I was enquiring to see the situations that things could happen. Maybe I speak a different way from you, well so be it but it was not intended as flack. I will type no more in case you get offended by it and see it as an attack.
Hood

Hi,

Any sort of safety feature is a bonus and should be added if at all possible.

As an example, the ModIO I designed has a charge pump feature. As soon (configurable delay) as  a Modbus master stops sending requests to the ModIO, the ModIO will disable the outputs. 

To me this is just common sense.

I would expect that if you pulled out the USB cable of the Smoothstepper, all the outputs, including the spindle control would be disabled. It probably does this but I haven't checked.

It would also be useful for the Smoothstepper to have a chargepump output similar to the parallel port functionality (maybe it does). It would then retrofit well with breakoutboards that require such a signal.  This chargepump signal would be removed if the SmoothStepper detected that Mach was not communicating with it, or if the SmoothStepper detected a fault with itself.


As an example of poor safety functionality, I was developing a motherboard for the ncPod. While testing the spindle control functionality, I accidentally pulled out the USB cable to the ncPod. The ncPod did not seem to detect the problem and continued to output the spindle PWM signal.  The ncPod has sat on the shelf since that moment.

And in the end make sure you have a proper Emergency Stop circuit as gumbyrulesyou  has stated. It make me shudder every time I see someone write that they have their EStop feeding into Mach3. The purpose of that input is not so that Mach3 can perform an EStop. It is there to politely notify Mach3 that an Estop has occurred and been handled by the appropriate Estop circuitry. After all the EStop buttons are sometimes hid because Mach3 is doing something wrong. In fact ArtSoft should probably replace the EStop input with something more appropriatly labelled, in both the software and manuals.

Cheers,


Peter.

Your safety message is recieved, Gumbyrulesyou, and you did well as I just had to stop and think.
Safety is part of our culture at work and ingrained that we take it home with us. So hat's off
to you.
As we all know, combined words have a tone. We all cover a lot of territory in here and quick concise questions or
reponses can be construed differently on the recieving end. Enough said!

A cutter cuts whatever it touches and it dosn't matter if it's skin or paper.
RICH
 

Hi all,

I have replied to this in the Warp9TD forum.  It is a problem that I will address tomorrow.  If the SS loses communications with the PC it should stop jogging, but it doesn't.  Even if it doesn't lose communications, the current implementation could be a problem if a jog-off command were swallowed.  Motion from gcode and step jogs will stop as soon as the SS runs out of data, but continuous jog movement is generated on-board.

Thanks,

Greg

you can't preach too much safety ! ,

one rule NEVER Trust software , and alway have safety circuits ( and ones that work and are tested from time to time ).
and yes i have seen a person seriously injured , through a machine , it changes your perspective very quickly .

congrats for finding a problem , and letting everyone know , safety should always be top of the list .


Dave

JUST one thing to add, Your ESTOP should NOT rely on any input or control from the computer or other logic based device to SHUT DOWN THE POWER TO THE MACHINE to stop machine movement as fast as possible in the event of a runnaway or other emergency. THe Estop should have shut down the power regaurdless of what any thing else does.

I noticed your story does not mention you useing the ESTOP?

Just a thought, (;-) TP