MechMate CNC Router Forum

Go Back   MechMate CNC Router Forum > Electrical & Electronic > 70. Control Systems
Register Options Profile Last 1 | 3 | 7 Days Search Today's Posts Mark Forums Read

Reply
 
Thread Tools
  #1  
Old Mon 01 March 2010, 19:00
cncb
Just call me: Brian
 
Connecticut
United States of America
Control logic if one drive fails?

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.
Reply With Quote
  #2  
Old Mon 01 March 2010, 21:11
domino11
Just call me: Heath
 
Cornwall, Ontario
Canada
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.
Reply With Quote
  #3  
Old Mon 01 March 2010, 21:23
cncb
Just call me: Brian
 
Connecticut
United States of America
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!
Reply With Quote
  #4  
Old Mon 01 March 2010, 21:36
domino11
Just call me: Heath
 
Cornwall, Ontario
Canada
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.
Reply With Quote
  #5  
Old Mon 01 March 2010, 21:40
riesvantwisk
Just call me: Ries #46
 
Quito
Ecuador
Send a message via MSN to riesvantwisk Send a message via Skype™ to 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
Reply With Quote
  #6  
Old Mon 01 March 2010, 23:38
Gerald D
Just call me: Gerald (retired)
 
Cape Town
South Africa
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.
Reply With Quote
  #7  
Old Tue 02 March 2010, 04:52
PEU
Just call me: Pablo
 
Buenos Aires
Argentina
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
Reply With Quote
  #8  
Old Tue 02 March 2010, 04:55
MetalHead
Just call me: Mike
 
Columbiana AL
United States of America
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.
Reply With Quote
  #9  
Old Tue 02 March 2010, 05:09
Richards
Just call me: Mike
 
South Jordan, UT
United States of America
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.)
Reply With Quote
  #10  
Old Tue 02 March 2010, 06:26
riesvantwisk
Just call me: Ries #46
 
Quito
Ecuador
Send a message via MSN to riesvantwisk Send a message via Skype™ to 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
Reply With Quote
  #11  
Old Tue 02 March 2010, 07:17
bradm
Just call me: Brad #10
 
Somerville(MA)
United States of America
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.
Reply With Quote
  #12  
Old Tue 02 March 2010, 07:30
riesvantwisk
Just call me: Ries #46
 
Quito
Ecuador
Send a message via MSN to riesvantwisk Send a message via Skype™ to 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
Reply With Quote
  #13  
Old Tue 02 March 2010, 10:38
cncb
Just call me: Brian
 
Connecticut
United States of America
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.
Reply With Quote
  #14  
Old Tue 02 March 2010, 11:02
domino11
Just call me: Heath
 
Cornwall, Ontario
Canada
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?
Reply With Quote
  #15  
Old Tue 02 March 2010, 14:26
Richards
Just call me: Mike
 
South Jordan, UT
United States of America
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.
Reply With Quote
  #16  
Old Tue 02 March 2010, 20:11
Gerald D
Just call me: Gerald (retired)
 
Cape Town
South Africa
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)
Reply With Quote
  #17  
Old Tue 02 March 2010, 20:28
cncb
Just call me: Brian
 
Connecticut
United States of America
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. And if I'm totally missing the boat here I apologize, it has been a long day.
Reply With Quote
  #18  
Old Wed 03 March 2010, 04:34
MetalHead
Just call me: Mike
 
Columbiana AL
United States of America
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.
Reply With Quote
  #19  
Old Wed 03 March 2010, 06:27
bradm
Just call me: Brad #10
 
Somerville(MA)
United States of America
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.
Reply With Quote
  #20  
Old Wed 03 March 2010, 20:15
KenC
Just call me: Ken
 
Klang
Malaysia
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?
Reply With Quote
  #21  
Old Wed 03 March 2010, 22:32
Gerald D
Just call me: Gerald (retired)
 
Cape Town
South Africa
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.
Reply With Quote
  #22  
Old Wed 03 March 2010, 23:12
domino11
Just call me: Heath
 
Cornwall, Ontario
Canada
And also not to mention the time and expense of it all!
Reply With Quote
  #23  
Old Thu 04 March 2010, 11:58
normand blais
Just call me: Normand
 
montreal
Canada
the piece start having a bad router mark before the gantry start lifting .to late anyway
Reply With Quote
  #24  
Old Thu 04 March 2010, 12:18
Gerald D
Just call me: Gerald (retired)
 
Cape Town
South Africa
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.
Reply With Quote
  #25  
Old Thu 04 March 2010, 14:30
normand blais
Just call me: Normand
 
montreal
Canada
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
Attached Images
File Type: jpg IMG_5040_1.JPG (70.0 KB, 152 views)
Reply With Quote
  #26  
Old Thu 04 March 2010, 19:27
Gerald D
Just call me: Gerald (retired)
 
Cape Town
South Africa
Ouch!
Reply With Quote
Reply

Register Options Profile Last 1 | 3 | 7 Days Search Today's Posts Mark Forums Read

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Specs of the PC needed to drive the MechMate's Mach control box Gerald_D 80. Computer Hardware & Software 80 Thu 11 June 2015 23:05
Newbie needs help with figuring out drive configurations (slaved drive for x-axis) ikeike 701. Motor Drives 5 Mon 04 January 2010 21:06
Slaving a motor - put its drive in parallel to another drive on the same BOB output J.R. Hatcher 70. Control Systems 34 Mon 16 November 2009 09:13
Ladder Logic Richards 70. Control Systems 0 Thu 07 August 2008 09:32
Anyone has any idea if this drive is something I could use off eBay? Kim Mortensen Archives 1 Thu 08 February 2007 17:40


All times are GMT -6. The time now is 05:37.


Powered by vBulletin® Version 3.8.3
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.