Following Error (and more)
19 Oct 2013 19:32 #40064
by jorsborn
Following Error (and more) was created by jorsborn
I am trying to solve a drift issue on my gantry cnc router. I've had it up and running for several months now. I've always cut simple patterns up until now. I am making a sign and using a small cutter to pocket the text. I set it up and let it run the other day and came back to find the characters were progressively moving. The gantry axis is off by roughly a half inch by the time it was completed.
Now, I've experienced a loose shaft coupler before and that behaved differently. I've verified that the shaft couplers are tight. I don't believe I am slipping.
In my google searches I've found others that had drift issues when the step/dir pulses were too narrow for the G540. That's easy enough to correct so I started looking into my hal file to find....
I changed this (for all 4 step generators) to...
I restarted the engraving process and it promptly halted with a joint following error. Why would I get a joint following error by simply adjusting the pulse width for the step generators? 3000 is much less than the base period.
Any thoughts?
Now, I've experienced a loose shaft coupler before and that behaved differently. I've verified that the shaft couplers are tight. I don't believe I am slipping.
In my google searches I've found others that had drift issues when the step/dir pulses were too narrow for the G540. That's easy enough to correct so I started looking into my hal file to find....
setp stepgen.1.steplen 1
setp stepgen.1.stepspace 0
setp stepgen.1.dirhold 40200
setp stepgen.1.dirsetup 40200I changed this (for all 4 step generators) to...
setp stepgen.1.steplen 3000
setp stepgen.1.stepspace 3000
setp stepgen.1.dirhold 40200
setp stepgen.1.dirsetup 40200I restarted the engraving process and it promptly halted with a joint following error. Why would I get a joint following error by simply adjusting the pulse width for the step generators? 3000 is much less than the base period.
Any thoughts?
Please Log in or Create an account to join the conversation.
19 Oct 2013 21:23 - 19 Oct 2013 21:24 #40065
by PCW
Replied by PCW on topic Following Error (and more)
This is probably because previously stepspace was 0 which allows the stepgen
to generate a pulse every base thread period, with a non-zero step space, your maximum
step rate will be halved (assuming the reset option was used)
details are in the stepgen manual
man stepgen
to generate a pulse every base thread period, with a non-zero step space, your maximum
step rate will be halved (assuming the reset option was used)
details are in the stepgen manual
man stepgen
Last edit: 19 Oct 2013 21:24 by PCW.
Please Log in or Create an account to join the conversation.
19 Oct 2013 21:37 - 19 Oct 2013 21:39 #40066
by ArcEye
Replied by ArcEye on topic Following Error (and more)
Hi
Have a look at this spec sheet for the G250 (the G540 is made up of these)
www.geckodrive.com/g250x.html
The timings for a stepgen are in nanoseconds and confusingly the spec sheet uses microseconds for steplen and stepspace and nanoseconds for dirhold and dirsetup.
However it should be apparant that your dir figures are 40200ns and the spec sheet gives 200ns and the step figures should be 2000ns and 1000ns
I would suspect that the original config was definately missing steps, with steplen and space set to virtually nothing. Try it with the figures as per the spec sheet.
Whether you get a following error is down to a lot more than the stepgen timing, would need to see your ini and hal files to check what base period, velocity and acceleration are being used.
The changes you made probably just pushed it over the edge that it was teetering on previously
regards
EDIT - pipped by PCW - must do that Mavis Beacon course!
Have a look at this spec sheet for the G250 (the G540 is made up of these)
www.geckodrive.com/g250x.html
The timings for a stepgen are in nanoseconds and confusingly the spec sheet uses microseconds for steplen and stepspace and nanoseconds for dirhold and dirsetup.
However it should be apparant that your dir figures are 40200ns and the spec sheet gives 200ns and the step figures should be 2000ns and 1000ns
I would suspect that the original config was definately missing steps, with steplen and space set to virtually nothing. Try it with the figures as per the spec sheet.
Whether you get a following error is down to a lot more than the stepgen timing, would need to see your ini and hal files to check what base period, velocity and acceleration are being used.
The changes you made probably just pushed it over the edge that it was teetering on previously
regards
EDIT - pipped by PCW - must do that Mavis Beacon course!
Last edit: 19 Oct 2013 21:39 by ArcEye.
Please Log in or Create an account to join the conversation.
20 Oct 2013 05:55 #40071
by jorsborn
Replied by jorsborn on topic Following Error (and more)
Thank you! I was looking for those figures on the G540 but couldn't find them directly. I've adjusted my stepgen to conservative values (with respect to the datasheet).
I still receive following errors with this. I am a bit puzzled with the following error. All I've done is lengthened the pulse length of the step pulse and it causes a following error. My base period is roughly 40,000 ns. There's plenty of time in that 40,000 ns to observe the direction and step length requirements. Since there is only one step per base period I don't see how this could have put me over the edge. Maybe I have a misunderstanding of what actually causes the following error. As I understand it you get the following error when a particular task was not completed within the allotted time slot (base period).
Regardless, I started playing with the figures and found that I had to dramatically reduce the acceleration on the z axis to get it to work without following errors. Below seems to work when just jogging around... but I am currently cutting air to see if the following error pops up again.
setp stepgen.0.steplen 2200
setp stepgen.0.stepspace 2200
setp stepgen.0.dirhold 500
setp stepgen.0.dirsetup 500I still receive following errors with this. I am a bit puzzled with the following error. All I've done is lengthened the pulse length of the step pulse and it causes a following error. My base period is roughly 40,000 ns. There's plenty of time in that 40,000 ns to observe the direction and step length requirements. Since there is only one step per base period I don't see how this could have put me over the edge. Maybe I have a misunderstanding of what actually causes the following error. As I understand it you get the following error when a particular task was not completed within the allotted time slot (base period).
Regardless, I started playing with the figures and found that I had to dramatically reduce the acceleration on the z axis to get it to work without following errors. Below seems to work when just jogging around... but I am currently cutting air to see if the following error pops up again.
[EMC]
MACHINE = router
DEBUG = 0
[DISPLAY]
DISPLAY = axis
EDITOR = gedit
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
MAX_FEED_OVERRIDE = 1.2
INTRO_GRAPHIC = linuxcnc.gif
INTRO_TIME = 5
PROGRAM_PREFIX = /home/jorsborn/linuxcnc/nc_files
INCREMENTS = .1in .05in .01in .005in .001in .0005in .0001in
PYVCP = custompanel.xml
[FILTER]
PROGRAM_EXTENSION = .png,.gif,.jpg Greyscale Depth Image
PROGRAM_EXTENSION = .py Python Script
png = image-to-gcode
gif = image-to-gcode
jpg = image-to-gcode
py = python
[TASK]
TASK = milltask
CYCLE_TIME = 0.010
[RS274NGC]
PARAMETER_FILE = linuxcnc.var
[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
BASE_PERIOD = 48000
SERVO_PERIOD = 1000000
[HAL]
HALUI = halui
HALFILE = router.hal
HALFILE = joypad.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal
[HALUI]
# add halui MDI commands here (max 64)
MDI_COMMAND = G38.2 Z-2 f16
MDI_COMMAND = G10 L20 P0 Z.062
MDI_COMMAND = G0 Z2
MDI_COMMAND = G0 X0 Y0 Z0
[TRAJ]
AXES = 4
COORDINATES = X Y Z Y
MAX_ANGULAR_VELOCITY = 360.00
DEFAULT_ANGULAR_VELOCITY = 36.00
LINEAR_UNITS = inch
ANGULAR_UNITS = degree
CYCLE_TIME = 0.010
DEFAULT_VELOCITY = 4.00
MAX_LINEAR_VELOCITY = 40.00
[EMCIO]
EMCIO = io
CYCLE_TIME = 0.100
TOOL_TABLE = tool.tbl
[AXIS_0]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 12
MAX_ACCELERATION = 30.0
STEPGEN_MAXACCEL = 37.5
SCALE = 1736.237
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -48.5
MAX_LIMIT = 48.5
HOME_OFFSET = 0.0
[AXIS_1]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 12
MAX_ACCELERATION = 24.0
STEPGEN_MAXACCEL = 37.5
SCALE = 1736.237
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -99
MAX_LIMIT = 99.0
HOME_OFFSET = 0.0
[AXIS_2]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 3
MAX_ACCELERATION = 2
STEPGEN_MAXACCEL = 6
SCALE = 4000
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -6.0
MAX_LIMIT = 6.0
HOME_OFFSET = 0.0
[AXIS_3]
TYPE = LINEAR
HOME = 0.0
MAX_VELOCITY = 12
MAX_ACCELERATION = 24.0
STEPGEN_MAXACCEL = 37.5
SCALE = 1736.237
FERROR = 0.05
MIN_FERROR = 0.01
MIN_LIMIT = -99
MAX_LIMIT = 99.0
HOME_OFFSET = 0.0Please Log in or Create an account to join the conversation.
20 Oct 2013 15:38 - 20 Oct 2013 15:41 #40078
by ArcEye
If those are your new figures, the old ones must have been very high.
When I first looked at them I thought they were pretty restrained, until I realized that it was an imperial config and everything was 25 times higher than I first thought!
You may find you have some more scope for tuning.
Very simply put the following error occurs where the physical axis movement cannot match the commanded movement.
Normally with stepper systems it is because the rate of step generation required to achieve the acceleration and velocity commanded, cannot be achieved by the stepgen.
This is the full chapter and verse
wiki.linuxcnc.org/cgi-bin/wiki.pl?Following_Error
Very rough and ready tests that tends to show up problems are;
Hold down the shift key and jog an axis, releasing the arrow key then suddenly pressing it again
(If velocity and acceleration are too high this usually give following errors)
Write a test program which rapids to a point, does a move at normal feed and then rapids in the opposite direction to home.
Repeat this approx 20 times, and if you have not had any problems, see if you are actually homed or if you are short of the home position
(The latter will indicate missed steps on the rapid back to home)
There is a limit to what can be expected from Nema 23 steppers with a maximum of 3.5A at 45 - 50V
regards
Replied by ArcEye on topic Following Error (and more)
I had to dramatically reduce the acceleration on the z axis to get it to work without following errors
If those are your new figures, the old ones must have been very high.
When I first looked at them I thought they were pretty restrained, until I realized that it was an imperial config and everything was 25 times higher than I first thought!
You may find you have some more scope for tuning.
Very simply put the following error occurs where the physical axis movement cannot match the commanded movement.
Normally with stepper systems it is because the rate of step generation required to achieve the acceleration and velocity commanded, cannot be achieved by the stepgen.
This is the full chapter and verse
wiki.linuxcnc.org/cgi-bin/wiki.pl?Following_Error
Very rough and ready tests that tends to show up problems are;
Hold down the shift key and jog an axis, releasing the arrow key then suddenly pressing it again
(If velocity and acceleration are too high this usually give following errors)
Write a test program which rapids to a point, does a move at normal feed and then rapids in the opposite direction to home.
Repeat this approx 20 times, and if you have not had any problems, see if you are actually homed or if you are short of the home position
(The latter will indicate missed steps on the rapid back to home)
There is a limit to what can be expected from Nema 23 steppers with a maximum of 3.5A at 45 - 50V
regards
Last edit: 20 Oct 2013 15:41 by ArcEye.
Please Log in or Create an account to join the conversation.
20 Oct 2013 15:39 #40079
by jorsborn
Replied by jorsborn on topic Following Error (and more)
I think I've got the following error figured out. I am puzzled though as to why I have not had more problems with following errors. Unless I am completely misunderstanding something. My base period is 48000 ns. With that, I can generate 20833 pulses per second. Given that my scaling is 1736.237 I get a maximum velocity right about 12 ips. However, my rapids were set to use a 40 ips (MAX_LINEAR_VELOCITY). That's not possible with my base period and I don't understand why I never got a following error before when steplen was 1 and stepspace was 0. I am still not understanding something.
Please Log in or Create an account to join the conversation.
20 Oct 2013 15:42 #40080
by jorsborn
Replied by jorsborn on topic Following Error (and more)
We must have posted at the same time! I'll take up your suggestion and run that test. I am getting better. After adjusting the steplen to 3000 (left stepspace at 0) I have reduced the drift from roughly 1/2 inch to roughly .050.
Please Log in or Create an account to join the conversation.
20 Oct 2013 15:50 #40081
by ArcEye
Replied by ArcEye on topic Following Error (and more)
I have added a link to the full C&V on following errors, probably need to refresh the page to see it
This is what PCW was talking about, when there is a stepspace of 0
I assume it enabled the stepgen to keep up in terms of step generation, even though the driver was unable to respond properly and lost steps, giving your original problem
For any more detail, will have to ask PCW, he is the expert in this sort of area.
regards
This is what PCW was talking about, when there is a stepspace of 0
I assume it enabled the stepgen to keep up in terms of step generation, even though the driver was unable to respond properly and lost steps, giving your original problem
stepgen.N.steplen u32 rw
The length of the step pulses, in nanoseconds. Measured from rising edge to falling edge.
stepgen.N.stepspace u32 rw (step types 0 and 1 only) The minimum
space between step pulses, in nanoseconds. Measured from falling edge to rising edge. The actual time depends on the step rate and can be much longer. If stepspace is 0, then step can be asserted every period. This can be used in conjunction with hal_parport’s auto-resetting pins to output one step pulse per period. In this mode, steplen must be set for one period or less.
For any more detail, will have to ask PCW, he is the expert in this sort of area.
regards
Please Log in or Create an account to join the conversation.
22 Oct 2013 14:06 #40157
by Rick G
Have you tried increasing the STEPGEN_MAXACCEL ?
Rick G
Replied by Rick G on topic Following Error (and more)
I started playing with the figures and found that I had to dramatically reduce the acceleration on the z axis to get it to work without following errors
Have you tried increasing the STEPGEN_MAXACCEL ?
Rick G
Please Log in or Create an account to join the conversation.
22 Oct 2013 19:47 #40168
by andypugh
I think you may be miss-reading the config (actually, failing to guess what else is in the config).
A step len of 1 and a step space of 0 is indicative of a config that is using what used to be called "doublestep".
This uses the "reset" hal function to set any high step pins back to zero after the specified delay time. This allows one step per base thread, twice the rate of a non "reset" configuration.
In such a configuration the step length is set by the reset-time.
www.linuxcnc.org/docs/html/hal/parallel_...ml#_using_doublestep
Replied by andypugh on topic Following Error (and more)
I would suspect that the original config was definately missing steps, with steplen and space set to virtually nothing.
I think you may be miss-reading the config (actually, failing to guess what else is in the config).
A step len of 1 and a step space of 0 is indicative of a config that is using what used to be called "doublestep".
This uses the "reset" hal function to set any high step pins back to zero after the specified delay time. This allows one step per base thread, twice the rate of a non "reset" configuration.
In such a configuration the step length is set by the reset-time.
www.linuxcnc.org/docs/html/hal/parallel_...ml#_using_doublestep
Please Log in or Create an account to join the conversation.
Time to create page: 0.364 seconds