Following Error (and more)
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 40200
I 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 40200
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?
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
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!
Please Log in or Create an account to join the conversation.
setp stepgen.0.steplen 2200
setp stepgen.0.stepspace 2200
setp stepgen.0.dirhold 500
setp stepgen.0.dirsetup 500
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.
[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.0
Please Log in or Create an account to join the conversation.
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
![B) B)](/media/kunena/emoticons/cool.png)
regards
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
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.
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.
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.