grandixximo wrote:

@PCW
Agreed that an ideal TP should always obey constraints, and the full stop fallback is the correct mechanism to achieve that. No argument there.
The question is whether strict enforcement should be mandatory or an integrator choice. A 20% jerk overshoot on a 1ms grid at a G1 corner is not an unknown uncontrolled violation, it is small, bounded, and predictable, and on drives with internal interpolation the mechanical system never sees it. That is a different situation from the uncontrolled external factors you are rightly warning about.
The practical concern is cycle time. On a complex CAM toolpath with many short segments, mandatory stops at every corner that fails the jerk test could multiply execution time significantly. That is a real regression for integrators who have matched their drive capabilities to their application.
So the proposal is: implement the jerk-aware full stop as an option, off by default to preserve existing behavior, and let integrators who need provably clean command streams or are running drives without internal interpolation opt in. That gives you the mathematically correct behavior when it is needed, without penalizing everyone else.
 

non budget drives always have more step filtering to suppress these behaviour... I think from differential calculus it is exactly that we need count with some limits of movememt caused by curving, jerk implementation fundamentally ...

it should be switchable from Gcode directly by user, who knows whats is doing... if the trajecotry tolerance is too high and velocity in that moment is non sensing plus path is small segmenting... some overlimit during small amount of time are acceptable(timing tolerance and spiking toleracne should be controlled by the user)

bending(trajectory) the tolerance - to handle this situation is non sense 

So here's an interesting problem for anyone following along...

I cut the parting slide stepgen scale by half (JOINT_3) so the V-axis can be programmed in diameter mode.  When set like this jogging/MDI/g-code is just like X in diameter mode - very intuitive.

Getting ready to test G96 CSS and double-checking everything - set G54 offsets, etc.  I enable switchkins and everything's fine...

But now the virtual X parting slide is only moving half the distance it should.  DRO is following the movement - it's moving at half the distance it should as well.

Ok, got it - I've got the scale cut in half, and LCNC is cutting that in half again when I switch the kinematics and am commanding an X move.

Easy solution: change the JOINT_3 scale back to full-distance value when switchkins is active.  But...

LCNC instantly throws a JOINT_3 following error when the scale switches.  Bugger.

I can double the V-axis/JOINT_3 scale and fiddle with the jog values, but that will still leave the V-axis G54 offset wonky.  I write the V-axis offset to the X-axis when switchkins is enabled (along with max/min limits) so the parting slide tool-tip at centerline can be set to "X0" for CSS.

How can I have my cake and eat it, too?

• V-axis/JOINT_3 to be in diameter mode when switchkins is not enabled, and
• X-axis/JOINT_3 to be in diameter mode when switchkins is enabled
• No following error when enabling switchkins
• All programming in G7 mode - switching back and forth between G7/G8 is going to cause my brain to hurt and a crash.

there was a surface map project a while back, not sure if that would be something that was useful or not. but i never really used it much, it seems like it was for larger routers that may have uneven beds, so im sure it could be configured for your use case. maybe the creator of it can chime in. I will ping them on the chat and ask if they can step in and reply.

I would tend to disagree. An ideal TP should always obey constraints, and this is possible
even with a zero P value (motion simply stops at the corner) and enough lookahead.
The TP slows enough on non-differentiable features that it can both obey constraint
bounds and deviate less than P from the programmed path.

If the TP does not obey constraints, some external and likely less controllable
factor will determine the bounds.
 

I made this work around that seems to be robust.

if cur_task_mode_mon == 1 and cur_interp_state_mon == 1 and cur_queue_mon == 0:
cmd.abort()

M30 is actually read into the buffer and executed, but the inerp has already reset before updating the line number que. That is a bug in Linuxcnc and breaks the standard function of M30 in RS274.

I may simply modify my lcnc to fix the issue. But for now, the above works and should only activate if the yask_mode is manual, which M30 does actually set on M30 read, the task_state is idle, which it should be, and the queue is empty. Which is the planner que.

Tommy,

The replies demo what is actually happening in hopes I may get some guidance to fix it. My question is above them.

The attached screenshot of a 20 tooth pocket shows a larger view of the program operation.  It runs by drawing nested figures inside each other by shortening (or lengthening) each side of the figure while drawing it.  The shortening (or lengthening) values are recorded in a table as they are encountered  when the figure is first executed. A multiple of the values is used for each execution of the figure and the values remain constant for the entire pocketing operation. The table starts at memory location 100 and the operators manual says that location 31 to 5000 are "user defined" so we can have lots of sides. Notice that the pocketing operation evolves such that the shown 40 sided figure produces a circular (or 20 sided) area that needs to be Pocketed to complete the entire pocket operation. I doubt that commercially available packages (eg autocad) can duplicate this activity easily since they would require an exhausting specification of each nested figure before executing it.  G-code's ability to process subroutines allows us to have the figure execute itself here for pocketing purposes. It also gives us the ability to hack individual sides and thereby make really ugly figures. 

That's all the information in the PDF.

sudo dmesg -wH
[Apr 4 07:43] EtherCAT 0: Master thread exited.
[  +0.000016] EtherCAT 0: Starting EtherCAT-IDLE thread.
[  +0.000038] EtherCAT ERROR 0-3: Failed to receive AL state datagram: Datagram initialized.
[  +0.000017] EtherCAT 0: Releasing master...
[  +0.000001] EtherCAT 0: Released.
[  +0.024165] EtherCAT ERROR 0-0: AL status message 0x001A: "Synchronization error".
[  +0.001309] EtherCAT 0-0: Acknowledged state SAFEOP.
[  +0.014483] EtherCAT ERROR 0-1: AL status message 0x001A: "Synchronization error".
[  +0.001578] EtherCAT 0-1: Acknowledged state SAFEOP.
[  +0.010458] EtherCAT ERROR 0-2: AL status message 0x001A: "Synchronization error".
[  +0.000839] EtherCAT 0-2: Acknowledged state SAFEOP.
[  +0.011212] EtherCAT ERROR 0-3: AL status message 0x002D: "No Sync Error".
[  +0.000528] EtherCAT 0-3: Acknowledged state SAFEOP.
[  +0.007163] EtherCAT 0: Slave states on main device: PREOP.
[  +0.783938] EtherCAT WARNING: Datagram 000000007d6dd556 (master-fsm) was SKIPPED 1 time.
[ +12.203295] EtherCAT: Requesting master 0...
[  +0.000003] EtherCAT: Successfully requested master 0.
[  +0.001335] EtherCAT 0: Domain0: Logical address 0x00000000, 112 byte, expected working counter 12.
[  +0.000003] EtherCAT 0:   Datagram domain0-0-main: Logical offset 0x00000000, 112 byte, type LRW.
[  +0.000009] EtherCAT 0: Master thread exited.
[  +0.000002] EtherCAT 0: Starting EtherCAT-OP thread.
[  +0.000030] EtherCAT WARNING 0: 1 datagram UNMATCHED!
[  +5.267792] EtherCAT WARNING 0-0: Slave did not sync after 5000 ms.
[  +6.879988] EtherCAT ERROR 0-3: Timeout while setting state OP.
[  +0.007489] EtherCAT 0: Slave states on main device: SAFEOP, OP.
[  +3.132001] EtherCAT 0: Slave states on main device: SAFEOP, OP + ERROR.



 

@grandixximo
According to my understanding, the P-tolerance is intended to prevent the need to slow down to speed 0 in a corner and to reduce the speed before the corner to such an extent that the 'corner' can be driven through without exceeding the jerk and acceleration.