Hello Guest it is March 28, 2024, 07:31:27 AM

Author Topic: Lost step on large gcode program  (Read 5754 times)

0 Members and 1 Guest are viewing this topic.

Lost step on large gcode program
« on: November 29, 2011, 10:25:36 PM »
I have a lost step issue (or gained step) that I can solve. I spend 40 hours on the past two weeks to try to resolve this issue and i just return to the point I was at the beginning. I have no more idea and need help and idea from anyone who want to help.
I discover this problem when I want to mill a plastic mould during the finishing passes. The Gcode get 1:30h to finish at 300mm/min (12in/min) feed rate (30000 lines). The offset at the end on the Z axis was around 0.8mm (0.031in). So i scrap the job and do it again with slower feed rate. Results were worst.


Thing I already done:
To verify the integrity of the mechanical line in the axes, I just glue a metal plate on the rear shaft of the motor, then I home the axe and mark with a razor blade the position. Each time I home the axe, the mark on the metal plate and the motor must be aligned. That tells me that there is no mechanical movement in the coupling and no backlash in the ball screw. It’s also a good way to verify lost step because it’s independent of any raise in temperature that can occur in the ball screw that can make the axe move. I glue those plates two week ago and after several hours of machine run, the marks are still aligned.
To measure the lost step, I home the machine then I switch in jog mode with a fine step (0.001mm or 0,00004in) a normal step on my stepper motor is 0.025mm (0,001in) so this jog step is much smaller than my motor step. I then jog till the home switch led light on and read the displacement. After homing, the out-of-phase is always between 0,0400mm and 0,0425mm every time I do it. This difference is due to the time that mach3 and motor take to react when the home switch is trigged. Base on that, I run a G-Code program and after that run, I jog to the home switch to measure the out-of-phase in machine coordinate.
I put an encoder with 1000 ppr on the Z axe. This encoder gives me exactly the same amount of step lost that the homing method give me.
I first thought of PP problem, I read a lot of post on that forum. I find someone who has a similar problem which gets solved by the SmootStepper PP replacement.  It was the easiest way and less time consuming way to fix the problem. So I bought a SmoothSteper board.
 The SS didn’t solve my problem. But that helps on the general operation of the milling. All axes run smoother and the spindle can run at 1 RPM very smoothly. It’s a great board for all this.
Then I extract the 600pound milling from its hole and open the control panel. I re-wire the control of the drive. I use coaxial wire with the shield ground on the SS casing only. The SS casing is an aluminum casing which is supposed to be a good Faraday shield. I didn’t put those wires into the wire tray to maximise the distance between those wires and the power line. The minimum distance is around 4in and there is no parallel path between the controls wire and the power line. Base on the fact that the Stepper Gecko drive can have ripple voltage of 600V, the induction on in the control wire must be less than 0.5 V in the worst case scenario. The USB cables pass in the tray, I think that the communication protocol in USB removes the induction problem that can occur in the USB cable itself.  I speak with a colleague who have 40 year in the RF industry and know A LOT about induced noise. He tell me that a low frequency noise (<100 kHz) is the more difficult noise to get rid of with shielding. Special shielding material must be used. He also tells me that the coaxial cable I used will surely remove around 20 dB of noise which must be enough to solve my problem. 
All this work to remove noise didn’t solve the lost step problem.
I then wrote down a GCode who dig a square pocket inclined at 30 degree around the z axis. The step down is 0.05mm (0.002in) and the dimensions are 100mm x 100mm (4in x 4in) at federate of 600mm/min (24in/min) I toke 20 minutes to complete the run. The axe Z home exactly at the same place each time because there is no that much move in the Z axis. But the X and Y axes always home with an out-of-phase (or lost step) of about 0.05 for X and 0.07 for Y. If I run this code several time, I always get the same results. If I run this test at 1200mm/min (48in/min) feed rate, there is no lost step. If I run this test at 100mm/min (4in/min) the resulting lag get worst. Running those test without spindle give the exact same results. In constant velocity mode, the pattern is similar but the out-of-phase values are different. Increasing the pulse width in the motor turning screen didn’t change the results.
So I get lost. Is someone having an idea to solve this issue?
I think its will be a good idea to wrote down a macro who run the same pocket GCode over and over, record the out-of-phase into a file then change something like feed rate and run the gcode again. This program can get statistic result on a specific run and may be very useful to resolve lost step issue. I try to make a gcode who move down a little, stop and move down a little a couple of thousand time. The point of this code was to be able to know if I lose or gain step. But when I run this code, I home at the exact same position. If someone have an idea to create a gcode who can do this kind of work.
PLEASSE HELPPPPP 

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Lost step on large gcode program
« Reply #1 on: November 29, 2011, 11:04:22 PM »
Try changing the motor tuning to 1/2 the current values of vel and accel then retest to see IF the problem goes away.

(;-) TP

Offline RICH

*
  • *
  •  7,427 7,427
    • View Profile
Re: Lost step on large gcode program
« Reply #2 on: November 30, 2011, 06:52:50 AM »
Your comparing the movement of the metal plate ( which is very small ) to the encoder. The bigger the metal plate circumference the better to get an accurate
reading of movement. ie; a razor blade mark is say .005" or so and based on the position and measuring of that mark you can be off by +- whatever. You can do the math.
Gets tougher to try to measure a micro step and the stepper may not even rotate / change when a micro step pulse is sent and the movement can be different over a full revolution.
  
Got to go later......
RICH
« Last Edit: November 30, 2011, 06:57:31 AM by RICH »
Re: Lost step on large gcode program
« Reply #3 on: November 30, 2011, 09:56:29 PM »
One step on the motor is 1/200 of a rotation. I now have a problem where i lose 0,2mm. 0,2mm is 0,0254 turn. On a 1 in diameter plate, this error represents 2mm. This error can be easily identified with this system. One step is 0,4mm (0,015in) on this diameter. So it's still easy to find a lost step. I actually run my Gecko at 10 micro steps per step. This system is not intended to find 1/10 on a step but something like 8 full steps or 80 micro steps.
I use an encoder on the Z axis. Those little things have a cost of 150$. I don’t really want to buy some for the other axis. In fact, if mach3 have the possibility to resolve position with encoder feedback, I buy 2 more right away.
I don’t compare the encoder with the metal plate. I use the metal plate to verify the home position only. The plate and the motor have only one mark. If the axes stay stiff, when you home the axis again, the mark should align. I do this only to remove the option of axis slip to help resolve the lost step problem.
Re: Lost step on large gcode program
« Reply #4 on: December 06, 2011, 11:17:53 AM »
just a suggestion, but turn off the toolpath display

Offline RICH

*
  • *
  •  7,427 7,427
    • View Profile
Re: Lost step on large gcode program
« Reply #5 on: December 06, 2011, 08:09:03 PM »
A lost step can take place in the electronics side or the mechanical side and they can be related.
The electronics side is rather difficult to test without the proper equipment. The normal flow on the electronics side is
PC output to bob, BOB output to drive, DRIVE output to the motor. What we did was use a pulse counter which monitored
 the outputs noted above. The custom counter had 6 independant calibrated inputs and was accurate to some 20 ppm or so.
Not my equipment and can't remember all the specs. We varied the kernel speeds ie; 25, 35, 45  and sent a number of different
pulses relative to a movement. We also sent pulses which would  cause the motors to to rotate one revolution. So for any
sent number of pulses from the computer to the motor we could compare and see if there were any differences.
You could also send one to ten pulses and watch how the system repsonded. That took care of the electronics side.

Mechanical side components were motor output pulley, belt to a pulley on ballscrew, and finaly the lathe crosslide
attached to the ball screw nut. A circular indicator about 6"  in diameter and divided into 200 parts was attached
to both timing pulleys. A calibrated optical allignment scale ( 10"  measuring  length  was used ) was mounted on the
crossslide. To read the scale an optical alignment scope ( 40x at 12"  distance) and calibrated optical micrometer
which could measure directly to 0.0001" was used to read the scale.

Thus what we had in place was measurement of the electronics / pulse count and also mechanical movement
which could be directly related. Example; A movement of the axis commanded in Mach for one rev of the motor.
In the ideal world, then pulses should all match up from pc to the motor ( drive was  micro stepping 10x)
 the motor should only turn 2000 steps, and that number of steps would equal an exact linear movement of the axis.
 The counter would show any difference on the electronic side, the two pulley indexers should match based on the
gearing reduction, and  the linear travel should be be correct. You also had MACH's DR0 to look at.

So the above could be used for differernt feed rates, velocities, and linear travels. One must realise that
if the steps per unit are not correct then results will  be faulty. The ball screw should be mapped for linear deviation
in both directions of travel. Backlash of course is needed to be accounted for and same goes for bearing preload.
Even belt tension should be adjusted. The above would all be for some shorter length of the screw movement.
In this case it was for 3" as that was the travel I was interested in looking at for thread testing.

In general Mach DRO was extremely accurate, 25khz kernel was used, different motors had different stepping ability
 but were repeatable  per rev,  the pulley and timing belt combo was very accurate but note that belt tension can
cause  lost steps but repeatable motion after a rev in one direction, my ball screws have a different backlash and gain
when going in different directions, the nut contributes to backlash and definitely bearing preload influences the backlash.

So where is that goofy lost step, well you need the right calibrated equipment and measuring procedure in place to even
try and find it..... if it even exists under a set of circumstances. Note that all of the above are under somewhat limited
 conditions. Throw in complex gcode and movements and good grief and a bunch of other factors come into play
such that you don't know what the hell you have measured or what was the cause of the lost step.

Stepping or pulsing aside for now,
RICH