Advanced Search

@ruediger123
For your exact parameters: 1ms cycle, 50 m/s³ jerk, 5 m/s² acceleration, P0.01 on a 45° corner, the only cornering speed that mathematically fits within the jerk limit on a 1ms grid is zero. Any non-zero cornering speed produces a direction change that cannot be absorbed within the jerk limit given the grid resolution. This is not a tuning issue, it is a fundamental property of discrete-time trajectory execution on a fixed clock.
In practice the planner currently exceeds the limit only slightly, and for most servo drives this is acceptable because the drive interpolates internally at a much higher rate and the mechanical system never sees the spike. What HALscope shows is the command stream quantized at 1ms, not what the motor actually does.
That said, an option to automatically fall back to a complete stop when the jerk-constrained cornering speed rounds down to effectively zero could be useful, giving integrators a way to get mathematically clean HALscope traces at the cost of cycle time on sharp corners. Worth considering as a TP option.

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.

RotarySMP wrote:

I just realised that the main Gmoccapy screen now behaves nicely. However, now I no longer have the tab for Andy's lathe macros.

You still have it - it just moved to the user tab section.

Damn,
I am sick of this device!
Had it working with one register, redid it all properly, wrote a script to set them all and now none of the vfd registers are showing. I'll check dmesg again later....

I'll look at your tip... 

10K wrote:

Problem came back! Something updated, possibly Debian, and now my screen is too wide again. See attached photo. What's different is that I can't set it to Start as Windowed and then back to Start as Fullscreen to fix the problem. Also, the modification to Gmoccapy by alex_sar earlier in this thread does not work anymore, although it did for 6+ months.

My touchscreen monitor is set for native resolution, 1024 x 768

I have the latest version of Debian Bookworm.

I thought that updating everything might help, so I updated LinuxCNC from 2.92 to 2.93 and Gmoccapy from 3.4.6 to 3.4.8. No joy.

Help me newbynobi, you're my only hope!

Can you post your configuration? Its this still an issue with LinuxCNC 2.9.8 ?

I just realised that the main Gmoccapy screen now behaves nicely. However, now I no longer have the tab for Andy's lathe macros.

It's not really an error in your INI file. The lathemacro just needs too much space for some reason and in ntb_user_tabs is just more space available

Hans got me sorted out. I had an error in my INI.
He had me replace:
EMBED_TAB_LOCATION = ntb_preview
with
EMBED_TAB_LOCATION = ntb_user_tabs
Now it has stopped scaling.
Big thanks to Hans for getting that straight.
Cheers,
Happy Mark

from your latest output, both PDO entries are clearly 16-bit and your XML uses bitLen="16", so that part looks correct.

also, halType="u32" does not mean the PDO is 32-bit. It only affects how the value is exposed in HAL.

it doesn't look like a bit length issue anymore.

given that, I would focus on:

- XML syntax issues (even a small typo can break it, and LinuxCNC may stay silent — checking dmesg helps here)
- verifying that the PDO/SM structure matches exactly what `ethercat pdos` reports
- keeping the mapping minimal until it reaches OP

once it reaches OP, then refine the mapping.

I struggled a lot because it was a topic I didn't understand at all. I added the pdos and the lcec_configgen result, but I didn't understand what kind of structure I was supposed to create.
When 32 bit = 16 bit
ceka@debian:~$ ethercat slave
0 0:0 OP + XINJE-DS5C1 EtherCAT(CoE) Drive Rev4.0 v3.7.70
1 0:1 OP + XINJE-DS5C1 EtherCAT(CoE) Drive Rev4.0 v3.7.70
2 0:2 OP + XINJE-DS5C1 EtherCAT(CoE) Drive Rev4.0 v3.7.70
3 0:3 SAFEOP+ERROR E EM32DX-E4   ????????????????????????????????????????????
ceka@debian:~$

SAFEOP+ERROR E EM32DX-E4

old now

ceka@debian:~$ ethercat pdos
=== Master 0, Slave 3 ===
SM0: PhysAddr 0x1000, DefaultSize  128, ControlRegister 0x26, Enable 1
SM1: PhysAddr 0x1400, DefaultSize  128, ControlRegister 0x22, Enable 1
SM2: PhysAddr 0x1800, DefaultSize    5, ControlRegister 0x64, Enable 1
  RxPDO 0x1600 "RxPDO0-Map"
    PDO entry 0x7000:01, 16 bit, "OUT"
SM3: PhysAddr 0x1c00, DefaultSize    7, ControlRegister 0x20, Enable 1
  TxPDO 0x1a00 "TxPDO1-Map"
    PDO entry 0x6000:01, 16 bit, "IN"
ceka@debian:~$

lcec_configgen
<slave idx="3" type="generic" vid="0x00004321" pid="0x01100073" name="D4">
      <!--EM32DX-E4-->
      <syncManager idx="0" dir="in"/>
      <syncManager idx="1" dir="out"/>
      <syncManager idx="2" dir="out">
        <pdo idx="1600">
          <!--RxPDO0-Map-->
          <pdoEntry idx="7000" subIdx="01" bitLen="16" halPin="out" halType="u32"/>
        </pdo>
      </syncManager>
      <syncManager idx="3" dir="in">
        <pdo idx="1a00">
          <!--TxPDO1-Map-->
          <pdoEntry idx="6000" subIdx="01" bitLen="16" halPin="in" halType="u32"/>
        </pdo>
      </syncManager>
    </slave>
  </master>
</masters>
ceka@debian:~$


Would the `lcec_configgen` command help? Could someone write the correct configuration for me?


 

Always something new to learn. Write-once sdos, ok.
If you aren't too bored of the device you might try with initCmds
if you understand the format of the input file. I struggle there but
there are examples I guess.