homing & encoders

seb_kuzminsky wrote:

This all works great with single-feedback servo systems. And it would work great on your machine if you used the stepper in velocity mode, and used your encoder as the sole source of position feedback.

Ok, ill try that tomorrow, the example above was just to make clear that there allways is a offset when an index- occurs. Alex_joni took that "offset" into the discussion... If you are wondering what i am doing:

Im working with some people on a production system, we want to use pallets to pass the parts from one machine to another machine. The NC-Code is saved inside the pallets (kind of usb-stick), also the working-offsets (in absolute-position). So we can just put the pallet with the (unfinished parts) on a machine (even 10 days later) and the machine knows what to do with that part without finding Offsets again or spending time to find the right progam for that part... Thats the reason i need the absolute position of the linear encoder -> and the home on index.

Hi all, i've put the stepgen into velocity-mode and now the modified stepgen with the reset-pin works great, i mean indexing works as desired, together with the Pid-setup i got a very smooth runnig mill, tolerances are now lower than 1/005mm on each axis even with the low-resolution linear encoders.
was hard to find the right setup for this, most examples are made for servos, so if somebody needs a setup for steppers with linear- encoders, just let me know...

regards & thanks Thomas

Yes, ive tested the stepgen with velocity- mode and this one produces joint-following- errors when the index was hit, changed back to my version of stepgen (with the reset-pin) and it worked, its not only working, tolerances are the best i've ever seen on a machine like that. Also the steppers run nearly like servos, heres an video of the first runs with linear encoders /Stepper motors/ PID and Stepgen in velocity mode :



Deadband has to be > 1/2 Resolution of the encoders to prevent the steppers from oscilating.

regards, Thomas

I still got some problems when a joint-follow error occurs, switching the machine on results in in high stepgen accellerations, if this happens i have to switch the machine about 5 times of and on (always getting a joint follow error), each time the stepgen gets slower until it reached the "right" position. seems that the same happens on a index reset. Resetting the way i did lets the axis accelerate as defined from 0 to VEL.... As you can see the machine is running fine, ive tested all possible combinations of MAX_ACCEL, STEPGEN_MAXACCEL...

if i set the accel & velocity values very low (i mean VERY LOW!) it seems that the problem is gone, doing this also the unmodified stepgen reset on index works...

Thomas

seb_kuzminsky wrote:

That looks great, thanks for the video!

But i dont understand why you'd get following errors with the standard stepgen. In the config you've described, the stepgen.position-fb should not be connected to anything at all - how can its value cause a following error?

Well, if the stepper is accelerating higher than the machine can handle the encoder-position will fall behind... this will cause an joint-follow error....

Sorry to dig up an old thread, but I would love to see your config files gtom (hal, ini, etc). I have a stepper machine with Mesa hardware and encoders that I would like to give a try at running in velocity mode with pid.
Thanks,
Tom

I would also love to see your config files gtom (hal, ini, etc). I have a Bridgeport with 2 parports,steppers and encoders that I would like to try at running in velocity mode with pid.
Thanks,
Joe