My experience with Cnc stuff is inch per minute. I run Delrin at F75. Aluminum at F22. In one of your examples 7.61" per "second" that's much faster than most machining is done. 7.61*60=456inch per minute. You need a very expensive and fast spindle to make running fast speeds worthwhile. Anybody using super fast spindles i.e. 50-100k rpm would not be likely to care about a Prop based controller as these would be very expensive machines with sophisticated controllers. I can't imagine most machines milling aluminum or Delrin needing more than 100ipm max if that. Maybe there are applications using gcode that are not just milling but I am not aware.
Also keep in mind that 20tpi is common to cheap benchtop machines. You rarely see that type high pitch on bigger machines, ball screws are common on bigger machines at much lower pitch i.e. 5 turns or 10 turns.
that is a relief. Since I really like the multi-Axis in one COG driver.
And looking thru the Gcode manual I found, I develop the feeling that I will need another COG to handle circular interpolation, that seems to be not as easy.
As a suggestion you maybe want to consider doing circular calculations before a move and storing the path in ram or external ram. For example in the real world let's say you are running a very large arc and have a reason to pause the machine which involves a decel of x distance to a stop then to resume accel > run to completion. If you are doing the arc interpolation real time it seems like a big challenge to decel out of that move and be able to resume. If the moves are precalculated then it seems easier to decel that move and resume.
I think some cadcam software may allow to export gcode using lines only vs arcs. But my experience is it may grind to a slow pace to run many little lines compared to running an arc.
I found this interesting but kinda confusing; each axis only receives an update at either 30/60/120Hz intervals but the "it creates a series of intermediate path points" can only mean that the axes maintain their last commanded velocity. Full document is attached.
There are several important features to note about the path control mode. First, the path point buffer
can be continuously reloaded with new points while the motor is moving. The path point buffer can
hold up to about 4 seconds worth of path data, but if a desired motion is longer than that, new points
can be added to the buffer while moving to create continuous motions of unlimited length. For some
applications, it is desirable to only keep a small amount of data in the path point buffers at any time to
allow the host to change the path on-the-fly with a minimal delay.
The second important feature is that when the PIC-SERVO SC moves from path point to path point, it
doesn’t simply jerk from one point to the next - it creates a series of intermediate path points so that it
moves to the next path point with a constant velocity. Path points are calculated as the positions
where the motor should be at either 30, 60 or 120 Hz intervals. If, for example, the host created a set
of path points at 60 Hz intervals, the PIC-SERVO SC would calculate intermediate path points at
1953.125 Hz intervals. The effect of this intermediate smoothing with a multi-axis system is that all
of the axes will move from one path point to the next along a straight-line segment. This internal
smoothing allows path points calculated by the host to be spaced much more widely apart, and
requires much less data to be sent to the PIC-SERVO SC .
The obvious question in specifying path points at a relatively low frequency is: “how accurately will
the motors be able to follow my ideal path”. In fact, for typical applications, this error is very small.
For example, let’s say we have an X-Y table with two motors and we wish to move along a circular
path. If we were to move along a 1.0” diameter circle at a speed of 1.0” per second, and we
approximated the circle by a series of straight line segments spaced at 30 Hz intervals, the maximum
error between the straight lines and a true circle would be 0.00028”. If we switched to 60 Hz
intervals, the maximum error would drop to 0.000069”. Slowing down the motion or increasing the
radius of curvature would further increase the accuracy.
Path points are downloaded are downloaded to the PIC-SER
As a suggestion you maybe want to consider doing circular calculations before a move and storing the path in ram or external ram. For example in the real world let's say you are running a very large arc and have a reason to pause the machine which involves a decel of x distance to a stop then to resume accel > run to completion. If you are doing the arc interpolation real time it seems like a big challenge to decel out of that move and be able to resume. If the moves are precalculated then it seems easier to decel that move and resume.
I think some cadcam software may allow to export gcode using lines only vs arcs. But my experience is it may grind to a slow pace to run many little lines compared to running an arc.
Yes, running a arc thru singe-step commands will grind down everything. I am not sure abut the other part.
accel/decal is not done yet, but my current plan is to solve this by manipulating my step-counter-frequency - if needed - between movements.
For some sort of abort/interrupt mechanism I would ramp down using my step clock as fast as possible and then stop the step-clock.
To resume I could ramp up alike.
And I still would be at the same step in the calculation in the supposed circular interpolation as I am now in my existing linear calculation.
Somewhere in between finishing the command, at clock-step 34567 or whatever.
I do indeed see some need to be able to backtrack to the beginning of the move or even some moves before, to get the right velocity to finish the aborted move.
@Mikster,
Yes, I am pondering this also.
my current control-loop or axis-controller, has a speed problem. with now 64 internal steps (for better resolution) and double stepping, (for some dithering) I can reach around 30,000 Hz with a single axis COG, 14,000 Hz with a 2-axis COG. The 3-Axis-COG goes already below 8,000 Hz.
So I am hitting some boundary there.
But if I would use this as a control-loop, not stepping single steps, but (using counters?) just supervising say 10 steps per step or something like that?
My stepper routine gets called once per step inside of the stepper COG and has old position, new position, step direction and reports its new position back to the HUB.
So it could also manage current movement and changes in that movement, instead of raw positions. Even some PID loop?
The path control mode is basically what I do with my steps-between max-steps factor of currently 64.
But this is not done at 30/60/120 Hz but at fastest step frequency of all axis times 64.
In case of a 1-axis COG my internal step-counter for intermediate steps maxes out at about 960,000 Hz
In case of a 2-axis COG my internal step-counter for intermediate steps maxes out at about 448,000 Hz
Currently I do no ramping, just smooth out the frequencies of all axis when working together.
Next step will be to compare the velocities of each axle between two movements. and if the velocity difference is over some limit, ramp down the end of the first movement to a certain amount and ramp up the start of the next movement to a certain amount.
That is the basic idea I have currently. To get there I need to buffer my Gcode-parser results to inspect them before sending them to the axis-controller(s), to create the needed ramping information.
I will need to build a array of command-buffers to solve this, but HUB-RAM is actual not a concern, yet.
The whole axis-controller-Demo running 9 axles is just 1,298 longs long and has still 6,877 longs free
I did some cleanup and implemented the safer waitcnt for my main clock, as discussed in another thread. Works like it should. Perfect.
I also fiddled with the resolution between the main axis step. Using shifting instead of mul/dif I have now 256 steps in between for calculation, but 16 steps for the step counter, this averages quite nicely over small and longer moves.
So I guess. Sadly I don't have any equipment to really show some traces, besides the LEDs of the quickstart.
The attached version V 1.2 now is able to set one pin for direction and one pin for step each axis.
I am using Quickstart LEDs for axis U-X, easily changed in the constants of gcodetest.spin.
So if somebody could test this with a scope/logicanalizer and upload some graphs, I would be very happy.
setting Debug to 0 disables all debug output (gcode command D0) and then one just needs to capture the pins.
Comments
Also keep in mind that 20tpi is common to cheap benchtop machines. You rarely see that type high pitch on bigger machines, ball screws are common on bigger machines at much lower pitch i.e. 5 turns or 10 turns.
that is a relief. Since I really like the multi-Axis in one COG driver.
And looking thru the Gcode manual I found, I develop the feeling that I will need another COG to handle circular interpolation, that seems to be not as easy.
Mike
I think some cadcam software may allow to export gcode using lines only vs arcs. But my experience is it may grind to a slow pace to run many little lines compared to running an arc.
I found this interesting but kinda confusing; each axis only receives an update at either 30/60/120Hz intervals but the "it creates a series of intermediate path points" can only mean that the axes maintain their last commanded velocity. Full document is attached.
Yes, running a arc thru singe-step commands will grind down everything. I am not sure abut the other part.
accel/decal is not done yet, but my current plan is to solve this by manipulating my step-counter-frequency - if needed - between movements.
For some sort of abort/interrupt mechanism I would ramp down using my step clock as fast as possible and then stop the step-clock.
To resume I could ramp up alike.
And I still would be at the same step in the calculation in the supposed circular interpolation as I am now in my existing linear calculation.
Somewhere in between finishing the command, at clock-step 34567 or whatever.
I do indeed see some need to be able to backtrack to the beginning of the move or even some moves before, to get the right velocity to finish the aborted move.
@Mikster,
Yes, I am pondering this also.
my current control-loop or axis-controller, has a speed problem. with now 64 internal steps (for better resolution) and double stepping, (for some dithering) I can reach around 30,000 Hz with a single axis COG, 14,000 Hz with a 2-axis COG. The 3-Axis-COG goes already below 8,000 Hz.
So I am hitting some boundary there.
But if I would use this as a control-loop, not stepping single steps, but (using counters?) just supervising say 10 steps per step or something like that?
My stepper routine gets called once per step inside of the stepper COG and has old position, new position, step direction and reports its new position back to the HUB.
So it could also manage current movement and changes in that movement, instead of raw positions. Even some PID loop?
this is quite interesting.
Mike
But this is not done at 30/60/120 Hz but at fastest step frequency of all axis times 64.
In case of a 1-axis COG my internal step-counter for intermediate steps maxes out at about 960,000 Hz
In case of a 2-axis COG my internal step-counter for intermediate steps maxes out at about 448,000 Hz
Currently I do no ramping, just smooth out the frequencies of all axis when working together.
Next step will be to compare the velocities of each axle between two movements. and if the velocity difference is over some limit, ramp down the end of the first movement to a certain amount and ramp up the start of the next movement to a certain amount.
That is the basic idea I have currently. To get there I need to buffer my Gcode-parser results to inspect them before sending them to the axis-controller(s), to create the needed ramping information.
I will need to build a array of command-buffers to solve this, but HUB-RAM is actual not a concern, yet.
The whole axis-controller-Demo running 9 axles is just 1,298 longs long and has still 6,877 longs free
Enjoy!
Mike
Please see attached.
sadly can't open your pdf, Adobe reader states "Root Object missing or invalid".
Mike
http://www.baldormotion.com/support/SupportMe/ApplicationNotes.asp
http://www.baldormotion.com/support/SupportMe/Downloads/DocsLib/an00115-001 - Trapezoidal Move Calculations.pdf
Impressive!
I also fiddled with the resolution between the main axis step. Using shifting instead of mul/dif I have now 256 steps in between for calculation, but 16 steps for the step counter, this averages quite nicely over small and longer moves.
So I guess. Sadly I don't have any equipment to really show some traces, besides the LEDs of the quickstart.
The attached version V 1.2 now is able to set one pin for direction and one pin for step each axis.
I am using Quickstart LEDs for axis U-X, easily changed in the constants of gcodetest.spin.
So if somebody could test this with a scope/logicanalizer and upload some graphs, I would be very happy.
setting Debug to 0 disables all debug output (gcode command D0) and then one just needs to capture the pins.
Enjoy!
Mike