Dynamic Steps per Unit for fast rapids

[JHChoppers]

I was wondering if anyone had ever dynamically changed the Steps Per Unit to allow for faster rapids?

This would allow you to have very high steps per unit for the accuracy during cutting, then dynamically change the Steps Per Unit with SetParam(ParamName As String, ParamVal As Double), perform the rapid move, then set it back.

I am not sure how you could trap the rapid moves to set this parameter, possibly change the post processor to generate an M code between rapids and feed rates ?

Thoughts on this ?

Thanks,
JH

[BR549]

2nd question would be WHY(;-) If you spend that much time in rapid then I would think you might want to fix that part first(;-)

If servo driven first plan only the #steps to meet accuarcy levels then the rapids would take care of themselves.

No point in having .00001 steps for .001 accuracy then complain about slow rapids. Not picking on you just an example.

For your example How would you control accuracy when you changed the steps(;-) The steps per are to MAKE the machine move the distance correctly.

If you change those midstream then MACH would be lost as to where it actually was and could NEVER return to a know point.

Just a thought, or three (;-) TP

[JHChoppers]

You limited to how fast Mach can drive the pulse train.  If your machine has .0001 per step, you rapids might cap out at say at 400IPM.  If you wanted 1000IPM for rapids, you could dynamically change the scale to .001 and change/scale the distance.  Then change it back for feed rates moves.

You would only have to trap the rapid calls for G0.  If the code block contained G0, change both the scale and the distance to increase your rapid speed that is limited by the pulse train.  Once the move is completed, you change it back.

[Hood]

Best bet is external controller, SS, Galil Kflop etc etc then you dont have to worry about electronic gearing to get the rapids and you maintain the resolution. PP is definitely not the best for servos in my opinion.
Hood

[BR549]

The moment  you tried to dynamically change the steps per MACH would loose track of position as it depends on the MATH to keep track of position. From that point there is no going BACK (;-).

Then you have the problem CAN the motors even RUN that fast(;-)accurately AND the acell settings problems(;-)

The several times we have tried something LIKE that we had to refhome the machine before continuing as at that point MACH was lost.



BUT give it a whirl and see what you getts, (;-) TP