DRO feedback to CNC controller SW

[jtodd]

Pardon my ignorance, but I'm rather new to CNC. Maybe this is something obvious, but I haven't found mention of it yet.

I've just purchased a vintage 2000 Shopmaster/Shoptask Eldorado 2000 (ball screws, stepper CNC, DRO.) I'm having a heck of a time working out the backlash, but from what I hear that is typical (.002-.005 on all axis measurements.)

It seems to me that there is an obvious solution for backlash, as well as a good "hint" for limit and home positions: the DRO. It seems obvious that the DRO actually "knows" where the X, Y, and Z positions are, regardless of how far the steppers are spinning. Why isn't it more common for the DRO to relay this information back to the computer head-end? It's a pretty obvious solution, but in the last few weeks of digging through this (and other) archives, I've never seen it mentioned. None of the CNC software that I've demo'ed (FlashCut, Mach 3) seems to have any provision for DRO feedback. The DRO I'm using looks like it has a spot on the bottom that is a DB-9 -shaped cutout, but there doesn't appear to actually be a serial feed.

Wouldn't this solve a huge number of headaches if the controller actually knew the real distances the steppers were driving the axis movements?

- backlash avoided
- blockage or collisions detected
- inaccurate stepper software configurations detected
- manual adjustment compensation reflected on controller
- more?

JT

[cam1]

Hi:
Just some thoughts.
Mechanical backlash (slop or play) cannot be avoided or repaired by positional feedback.
Most OEM's like Fanuc,Fagor etc have the provision to use positional feedback from optical scales (direct reading of position), as opposed to rotary encoders.
My rationale for the lack of this provision on lower end CNC controllers (no aspersion inteneded) is the requirement to be able to perform (I/O). They generally output pulses that are converted to rotary motion. These systems imply position. In order to be able to run closed loop, you would need to be able to read and compare the number of steps generated vs. the actual position. This tends to complicate things, and drive the cost up, as you need to be able to read/convert/compare/correct this data probably 10 times/s or faster.


regards

[jtodd]

Originally Posted by cam1 Hi: Just some thoughts. Mechanical backlash (slop or play) cannot be avoided or repaired by positional feedback. Most OEM's like Fanuc,Fagor etc have the provision to use positional feedback from optical scales (direct reading of position), as opposed to rotary encoders. My rationale for the lack of this provision on lower end CNC controllers (no aspersion inteneded) is the requirement to be able to perform (I/O). They generally output pulses that are converted to rotary motion. These systems imply position. In order to be able to run closed loop, you would need to be able to read and compare the number of steps generated vs. the actual position. This tends to complicate things, and drive the cost up, as you need to be able to read/convert/compare/correct this data probably 10 times/s or faster.

I do agree that it cannot stop backlash or prevent it. However, compensating for backlash during free operations seems to be fairly valuable, and even while performing cut tasks it seems like it would be useful to know where the tool was landing.

A serial port can operate at 115000bps, and there are certainly inexpensive and easiy-available chipsets that can push data fairly rapidly. Combined with very fast desktop machines, I would think that this would be easily possible at very high speeds if the DRO was able to provide X/Y/Z back to the controller. I don't know if I would say that the DRO would "control" the system in a closed loop fashion, but it would certainly help in zeroing points or curve vectors against reality instead of "guessing" based on belief of backlash hardcoded data and accuracy of steps. I'd think that the DRO would be frequently referenced, but not used as the canonical source which was used to provide pulse data to the steppers.

Just like modern networked computers use their internal clocks for time reference, but every few minutes or hours will go out and synchronize themselves with a stratum-1 time source to account for slop in their inexpensive crystals. I would think that every X milliseconds the controller would examine it's assumed positional data against that which was provided by the DRO and compare the two. If there is a minor discrepancy, repair it. If there is a large discrepancy, halt and alert the operator. If the machine is in a free move, then use the DRO as the actual position and reset internal assumed positional data so that the next cut is true to the zero position. (sorry if my nomenclature is off here - I'm still getting the handle on things)

I'm not arguing with you - I'm simply trying to figure out why this wouldn't be standard practice to improve accuracy and avoid burned out servos/steppers. It seems to be such a cheap way to improve performance, and I've not seen any references for it in Mach, which seems to be software that has every other bell and whistle imaginable.

JT

[cam1]

Hi: I agree that it's a great Idea, generally speaking though CNC machines always track positional following errors (always comparing commanded distance to achieved distance), and will fault out if the deviation is larger than the tolerance. I'm no expert on the topic, but I have gained some appreciation on how much work the processor has to do in order to scale input signals. In the end I'm convinced that if it was economically feasible to do it commercially, then it would have been approached. My guess is that alot of people use precision ballscrews and powerful steppers to overcome the uncertainty of losing position. Some older CNC machines (with worn ballscrews or failed rotary encoders) get retrofit for scales. DRO's with glass scales are alot cheaper than they used to be, so you may find someone else with the same interests.

regards

regards

[Hans_G]

Here's a good link explaining how common DRO's work: link

1) update rate is slow
2) nothing synchs the positional output, in other words, if I'm accelerating (like when interping a circle, where backlash is a problem) and I get a message from the DRO saying "I'm at X", the question is "when were you at X?"
3) most closed loop motion controllers use quadrature encoder, SSI, or resolver feedback. So the DRO communication scheme isn't compatible with existing motion controller schemes.

There's also a thread in this forum from a month ago where a guy in the UK hacked the DRO a bit to do some interesting things. Hasn't been updated in a while.

[bertmiller]

i converter my x3 to xy cnc this way.
i used dro's explained on this website:
http://www.shumatech.com/support/chinese_scales.htm
they have the ability to update every 20ms.
with a speed of 1cm/s that relates to 0.2mm/20ms.
thats not fast and can indeed not be used for direct tracking of the table position.
i made an interface pcb with a 89s8252 that sends the data via the serialport to my computer with 9600 baud.
i solved the timeproblem to addapt my cnc program to move slowly when the table position has become within 0.5mm of the end position.
this results in great accuracy. last week i milled a 32.00mm wide box and my digital scale reads out 32.00mm.
here a video of my milling machine:

YouTube - X3 sieg / black and red X3 converted to 2axis cnc milling

YouTube - X3 sieg / black and red X3 converted to 2axis cnc milling

i have alot of backlash on my x3: 0.25mm (0.01")
but with this kind of feedback thats no problem at all.
but i cant make circles or round shapes, that would require faster feedback.

[jtodd]

Originally Posted by bertmiller i converter my x3 to xy cnc this way. i used dro's explained on this website: http://www.shumatech.com/support/chinese_scales.htm they have the ability to update every 20ms. with a speed of 1cm/s that relates to 0.2mm/20ms. thats not fast and can indeed not be used for direct tracking of the table position. i made an interface pcb with a 89s8252 that sends the data via the serialport to my computer with 9600 baud. i solved the timeproblem to addapt my cnc program to move slowly when the table position has become within 0.5mm of the end position. this results in great accuracy. last week i milled a 32.00mm wide box and my digital scale reads out 32.00mm. i have alot of backlash on my x3: 0.25mm (0.01") but with this kind of feedback thats no problem at all. but i cant make circles or round shapes, that would require faster feedback.

That is very interesting! I am surprised you only went with 9600 baud - would not a faster baud rate make things better and allow you to make curves?

Is there a standard serial syntax for these type of events, or did you make your own protocol?

Also: what controller program are you using that allows for the feedback of DRO input? I think this is the most important and difficult part.

JT

[bertmiller]

i have made my own cnc program with delphi 4 with the ComDrv32 package.
this made it posible to do this. but puts up great barriers if i want to mill more complex shapes.
i made my own gcode as well. very simple x and y movements.

with 9600baud it would take about 3ms to transfer the data to the computer while the data is send each 20ms out of the dro scale.
didnt thought of using higher baudrates.

i have a feeling that the dro values i get in the program are lagging behind on the actual position and that its also a little random on high feed.
at highest speeds its 0.1mm lag. 10 times slower and its 0.01mm and this is the speed i finetune the position with great results. i stop the motor 0.05mm before i reached the endpoint. it takes about 5ms to stop the motor. also goes via serial port.

with the first testruns i did with this system i had conclude that i needed ballscrew and rotoryencoder feedback as well to make more complex shapes.