Screw comp on master/slave axis
Moderator: cnckeith
-
ekbiker
- Posts: 11
- Joined: Thu Dec 14, 2023 11:39 am
- Acorn CNC Controller: No
- Plasma CNC Controller: No
- AcornSix CNC Controller: Yes
- Allin1DC CNC Controller: No
- Hickory CNC Controller: No
- Oak CNC controller: No
- CNC Control System Serial Number: 0008DC111213-1115230156
- DC3IOB: No
- CNC12: Yes
- CNC11: No
- CPU10 or CPU7: No
- Location: Los Angeles
Re: Screw comp on master/slave axis
Nice list, actually I think I would benefit from some of those on the list. I'll ask one more time, after this I'll shut up. I can help code the individual screw comp on paired axis. I have industry experience on many programing languages, including C, C++, and C#. It's free for you, what have you got to loose. I'll sign any NDA you want. You decide if my implementation is good enough to accept, you control the whole process. I'll write tests too and give you all rights over any code I write.
Re: Screw comp on master/slave axis
Just to add some perspective -- and not to argue one side or the other of where this should be on the priority list -- I will describe how I understand slaving/pairing fits into the pipeline of Centroid CNC operation.
There is a lengthy sequence of things that have to happen to get from a line of CNC code that says, for example, "X1.2345 Y7.6543" to where the motion processor is deciding what the encoder count position of each servo motor should be, every 250μs.
1) Apply the current G code modals to determine what kind of movement, if any, that line requests: part rotation, drilling mode, arc mode, arc plane, scaling, etc..
2) Convert from local coordinate system to machine coordinate system
3) Break arcs and canned cycles down into individual linear segments
4) Convert distances from inch/mm/other units into encoder counts
5) Break long moves down into a series of shorter moves, so none exceed the maximum length in encoder counts
6) Apply accel/decel rules based on programmed speeds, accel/decel ramp rates, and direction changes (turning corners, stopping, reversing)
7) Send those processed vectors through a first-in / first-out queue to the motion processor for execution.
By my understanding, from its first implementation to present, axis slaving/pairing has been implemented between (6) and (7), through the relatively simple expedient of copying all the requested movement of the master axis into the fields for the slave axis. This is why it would only work if the encoder counts/rev, revs/inch, direction reversal, achievable max rates and accel rates, etc. were identical.
Screw compensation or volumetric compensation would be applied in step (4). That is where we have to decide how many encoder counts away from machine zero each servo motor needs to be, to put the tool at a given coordinate position.
So, making the requested change is not so much a matter of adding additional code to the existing implementation, to look in compensation tables for the slave axis instead of the master axis; but is a matter of applying the rule that says "slave axis must do everything master axis does" at a different stage of the process (probably between steps (3) and (4). As is always the case with complex software, this will need to be done with a wary eye out for unintended consequences.
Edit: another factor not addressed above -- and one ripe for unintended consequences -- is jogging control with jog buttons and MPG handwheel. Jogging movement is generally handled down on the motion control processor, and not in the PC software which parses G codes. But having different screw compensation tables for the master and slave axes implies that, when jogging that paired axes, the two servos are required to make differing amounts of movement. For this feature to be implemented properly, all axis jogging movement would need to be done with screw compensation applied.
There is a lengthy sequence of things that have to happen to get from a line of CNC code that says, for example, "X1.2345 Y7.6543" to where the motion processor is deciding what the encoder count position of each servo motor should be, every 250μs.
1) Apply the current G code modals to determine what kind of movement, if any, that line requests: part rotation, drilling mode, arc mode, arc plane, scaling, etc..
2) Convert from local coordinate system to machine coordinate system
3) Break arcs and canned cycles down into individual linear segments
4) Convert distances from inch/mm/other units into encoder counts
5) Break long moves down into a series of shorter moves, so none exceed the maximum length in encoder counts
6) Apply accel/decel rules based on programmed speeds, accel/decel ramp rates, and direction changes (turning corners, stopping, reversing)
7) Send those processed vectors through a first-in / first-out queue to the motion processor for execution.
By my understanding, from its first implementation to present, axis slaving/pairing has been implemented between (6) and (7), through the relatively simple expedient of copying all the requested movement of the master axis into the fields for the slave axis. This is why it would only work if the encoder counts/rev, revs/inch, direction reversal, achievable max rates and accel rates, etc. were identical.
Screw compensation or volumetric compensation would be applied in step (4). That is where we have to decide how many encoder counts away from machine zero each servo motor needs to be, to put the tool at a given coordinate position.
So, making the requested change is not so much a matter of adding additional code to the existing implementation, to look in compensation tables for the slave axis instead of the master axis; but is a matter of applying the rule that says "slave axis must do everything master axis does" at a different stage of the process (probably between steps (3) and (4). As is always the case with complex software, this will need to be done with a wary eye out for unintended consequences.
Edit: another factor not addressed above -- and one ripe for unintended consequences -- is jogging control with jog buttons and MPG handwheel. Jogging movement is generally handled down on the motion control processor, and not in the PC software which parses G codes. But having different screw compensation tables for the master and slave axes implies that, when jogging that paired axes, the two servos are required to make differing amounts of movement. For this feature to be implemented properly, all axis jogging movement would need to be done with screw compensation applied.