Control logic if one drive fails?

[cncb]

I have had some thoughts about one grey area with the control system with a 3 axis cnc router that would hopefully provoke a discussion. And that is the case where a drive may blow (internal fuse) or fail or a cable connection down stream fails (either poor connection and vibration) or otherwise. The best example where there could be damage is a dual stepper gantry. One geckodrive fails but the other one keeps chucking on racking it. I've had this happen a few times due to poor crimp on connectors that I finally dumped later on with the phase wires coming loose. The gecko drives are known for their reliability and I haven't had a single issue with my 203vs, but has anyone thought about some kind of control circuit inside the enclosure that would have a condition such as if one drive goes down for any reason that the others should as well so that nothing bad could happen? My initial thoughts were to go from what I have now - individual fused protection to a single fuse thats rated for the entire load of all 4 steppers/geckodrives. But I wouldn't want to rely on ONLY a major fault for this to work.

Looking forward to any responses on the topic.

[domino11]

The fuse is only part of the fault path. What if a Gecko stopped working but did not blow the fuse? How would you know and signal this condition to your control hardware? You would definitely need some type of feedback mechanism to do this kind of thing. Not as simple as it first sounds. Your finger on the Estop is probably the best safety measure.

[cncb]

Well put and thus my endings with the fuse part of it. My fingers are always close to an estop but its hard to catch a gantry racking until you hear a crunch. I'm not looking for an overly complicated feedback system, as it is I'm using open loop steppers!

[domino11]

What you are looking for is possible, but it would most certainly involve a lot more circuitry than you might think. Also by the time the fault circuitry triggers, the crunch will also have happened and the work will still be ruined. Encoders on dual shaft motors might be a start, as well as a comparator type circuit, maybe with a microcontroller to sample the step pulses, the encoder feedback, then it would be able to trip an Estop if the proper conditions are not met. Timing, the conditions you want to test for (all iterations) would have to be defined and tweaked. Wow this is starting to sound like a lot of development time.

Mike Richards is probably the guy around here that has tried it, or has seen someone else try it. :)

[riesvantwisk]

last week I though that may be this can be measured within the Gecko drive. I am sure there is some control circuit there that can/does measure the current for each stepper motor. When a stepper goes out of control, or the gecko reports something 'evil back (evil needs to be defined) then this can be feed back into EMC or MACH3, or even EMC or Mach3 can monitor the current 10 times/second.

I have no idea if this is possible, but my first thoughts where that the gecko could be a potential place to measure performance in a relative economic way, I wonder if Maris ever though about that and if something like that is measured. May be there is already a pin available within the gecko that can be put back into the BoB after all, the Gecko can detect already some faults.

Obvious having a a encoder that feeds back into EMC/Mach3 would be the almost ultimate check, but this is more costly, but I believe some EMC2 people are doing this already.

Keep in mind however, that a machine like this should be operated with a person around and shouldn't be left alone.

Ries

[Gerald D]

The optional proximity switches at the ends of the gantry will detect when it starts to lift off the rails and will cause an e-stop.

[PEU]

I think if a gecko fails while the other tries to keep moving either will happen what Gerald says (limit switches trigger a fault) or the still working one will trip and fault due to overcurrent

[MetalHead]

You could also upgrade the system to have encoders. They would give feed back and tell you if one is not moving.

Servos would do the same thing, but these options are pricey solutions to a not so common problem.

[Richards]

Gerald's solution is the best and easiest to use.

The problem with measuring current is that if the pinion gear came loose, the motor would still be turning (and drawing current) but the gear would be slipping.

An encoder and a circuit that compares encoder pulses to step pulses is elegant, but it would probably cost at least $100 per motor. It would probably also require a microprocessor per motor. A microprocessor only costs about $2.00 (Atmel 89C2051 or similar), but they require a $1,000 programmer, a circuit board, an oscillator, a reset circuit, etc. For those of us who work with them all the time, none of that is a problem, but I suspect that most builders wouldn't have ready access to everything needed.

I vote for Gerald's idea. A proximity switch would activate when the gantry lifts about 4mm or so, which would probably be just as quickly as an encoder because of the necessary allowance for electrical noise. (Remember, an encoder signal is usually between 2.5VDC and 5VDC. That signal has to run from the physical motor back to the control box. Along the way, it can be distorted by all the other electrical signals. On my 60X120 Shopbot, one of the x-axis cables is over thirty feet long because of the 'bow' that Shopbot once used. A 30-foot 'antenna' picks up a lot of unwanted electrical noise.)

[riesvantwisk]

I always though that the switches where used to detect end of axis, but now I see how it's working.
Agreed, that's by far the best solution...

Ries

[bradm]

I happen to agree that the proxy sensors work well -> mine have triggered in response to over aggressive Z axis plunges, and that's a good thing.

A minor quibble with Mike's observation about encoders. He is correct that commercial encoders will run you hundreds of dollars. For those handy with electronics, however, you can use a printer and transparency film to create encoder disks, use two infrared led/phototransistor sensors, an op amp, and a microcontroller, and have a low budget encoder. If you choose from the MicroChip PIC, Atmel ATMega, or Parallax Basic Stamp lines of microcontrollers, you'll find that you can get away with very inexpensive (< $100, or even < $10) development environments, and many premade boards that are under $30 each. You'll need to be an electronics hobbiest, though. Also, you are likely to end up with far less resolution than a commercial encoder, although sufficient for the task and at a much lower price.

With all of that said, I think it's overkill. My opinion is that open loop steppers and proximity sensors are more than sufficient. The extra feedback you gain will only apply in a limited number of scenarios.

[riesvantwisk]

I didn't bother yet to look into the proximity yet as they run for 100USD each here in Ecuador. But come to think of it, this might be a good idea to buy them whenever I am in Holland or US again.

One problem I see on the encoder solution is that if one pinion is off teh rack, or slips, the Encoder would show correct positions on the shaft, while in the mean the gantry goes bad.

Ries

[cncb]

Well the proxy switches could be used to detect the gantry jumping its rack/rails or stopping it before it hits the hard machine stops on an over travel but how would they work in the logic I was talking about? I understand the communication is a complex logic for most of our setups without encoded servos but I mean some way to stop all geckodrives/stepper motors if one quits. You wouldn't want the machine running at all if the z stops, y stops etc.

[domino11]

Brian,
I think that the point being made here is that the ability to detect the scenario you suggest is difficult. It can be done for some time and money, but do you want to invest the time and money over what a proxy setup would give you?

[Richards]

Brian,
Depending on your break-out-board and your setup, if a proxy sensor is sensed, the outputs from the break-out-board will be shut off, which will stop all of the motors. You will have to re-zero all axes before continuing the program, but because the proxy sensor should see the problem within 2 - 4 mm, most likely the part will be saved.

With my Shopbot PRT-Alpha, which uses Oriental Motor's 'Alpha' motors/drivers, the system tries to 'catch up' for 1/2 second. If I'm running at 8" per second, that's 4 inches of messed up parts. In other words, a motor/driver that costs over $1,200 each is basically useless because the motors are not synchronized. Gerald's idea would work much better at much lower cost with the added advantage that you would have a very minimal 'divot' to worry about instead of the 4" gash that I would get.

[Gerald D]

If a y-axis motor fails, the proxies tell you nothing. And if another monitoring system is added, that too could fail (probably then being the most complex part of the system) which puts you back at square one.

Depends on whether one wants to save damage to the machine (and clamps), prevent fire, or save the job from a miscut. There is no foolproof system that will prevent all of these.

(it must be realised that a jumped gantry doesn't mess up rails/racks/gears so that isn't a big concern in the first place)

[cncb]

I guess I'm still missing it here. I'm not concerned about proximity sensors. You are saying that its a huge investment for what proxy sensors already give me? But all they do is prevent over travel or for you guys over travel and or if a gantry jumps the rails/rack. They have nothing to do with monitoring the status of the steppers/geckodrives - but the status of the position of the axis. :o And if I'm totally missing the boat here I apologize, it has been a long day. :rolleyes:

[MetalHead]

If you are worried about the gantry jumping the tracks you maybe could put a proxy sensor that runs along the rail. In the event the gantry lifts up off the rail it would have the same effect as the current proxy switch and could be used to stop the machine.

You may be able to fit these to the stop blocks also.

[bradm]

Brian, I think what you are missing is that many of us don't see the need to monitor just the motors and the drivers, because experience shows that they are far less likely to fail than other things. More likely to fail are grub screws; human error resulting in crashes, etc. So monitoring systems or design that copes with these, and in addition catch many motor and drive faults are the focus.

[KenC]

Just have this pop up my head, can we use magnetic sensors to count the rack gear tooth, use this info & turn it into a linear decoder to close the loop? and add micro processor to figure out the rest to check on motor failure?

[Gerald D]

Ken, that would be the best way to detect a loss of carriage movement. But it would be a complex system, the reliability of which is unproved......so, in the early days we will see failures of the monitoring system giving false stops. And, on the day that it must work, it probably won't.

After that monitoring system is reliable, then the thoughts will go to monitoring for a broken/blunt cutter, or a stopped router, or an overheated bearing, or a clamp that has come loose, or the dog getting sick under the table, etc.

The starting point in all of this is to decide "what is your fear?". What is the real concern that you want to minimise, or eliminate? A gantry jumping off the rails is NOT a fear in itself - it doesn't do damage, some argue that it prevents damage.

This thread started with the "fear" of a drive failing, and immediately recognised that it may just be a bad connection after the drive. Well, the best way to reduce this fear is to minimise the number of connections (no connectors on the control panel), and to make sure you have the best of industrial quality on the few connections. Yup, the "keep it simple and stupid" is what I advocate - extra monitoring systems go against the KISS principle.

[domino11]

And also not to mention the time and expense of it all! :)

[normand blais]

the piece start having a bad router mark before the gantry start lifting .to late anyway

[Gerald D]

Normand, it is often not so bad . . . the router mark & gantry lift happens more with the first rough cuts. By the time you do the final cut, you already know where the clamps are located, and the router mark is removed.

[normand blais]

Sometime you win sometime ...Last week i lifted the carriage by accident, I never actualy done it on purpose . I told the machine to toad the file to cut but the file was zz zzfile . I was glad I did not break the new2 inch 170degre vbit. I tough the screw in shaft with 1/4inch thread look weak but it stalled the router lift the carriage and did not break

[Gerald D]

Ouch!