next testing round in 3d contouring, 25k line and later are critial and we can observing high accel-cmd peaks ... I am not expert, I need to ask you guys before create any outcomes... I can chare gcode file but here it exceeding limit

Thanks nanowhat, I checked my version and it’s actually 1.6 Could you help me understand how to disable EoE in this version?

Thanks a lot, Lorenzo.

Does RIO have any additional backlash comp that isn't set in the HAL file?
I seem to be getting a consistent 0.038" of extra steps when changing direction, but it isn't an instant amount as you can see with this logging with a dial indicator.
I also checked my machine with larger repeated moves to see if something was slipping, but it hit the exact same spot repeatedly.

Here is the motion vs dial log:
g1 x0.000 = x0.000
g1 x0.100 = x0.100
g1 x0.150 = x0.150
g1 x0.200 = x0.200
--- Change direction
g1 x0.100 = x0.060
g1 x0.050 = x0.010
g1 x0.000 = x-0.038
--- Change direction
g1 x0.050 = 0.050
g1 x0.200 = x0.200
--- Change direction
g1 x0.000 = -0.038
g1 x0.010 = x-0.019
g1 x0.015 = x-0.009
g1 x0.020 = x0.000
g1 x0.025 = x0.010
g1 x0.030 = x0.021
g1 x0.035 = x0.030
g1 x0.040 = x0.040
g1 x0.100 = x0.100
g1 x0.200 = x0.200
--- Change direction
g1 0.190 = 0.179
g1 0.180 = 0.160
g1 0.170 = 0.140
g1 0.160 = 0.120
g1 0.150 = 0.110
g1 0.140 = 0.100
g1 0.130 = 0.090
g1 0.120 = 0.080
g1 0.000 = -0.038

amanker wrote:

I was using remora on BTT Octopus pro board. Few days back I had to remove the board for some reason. Now it's not working. Nothing has changed. I tried erasing and reflashing remora by stm32 programmer. Tried changing spi cable from board to rpi4. I can see remora firmware is working on board. I added blink module to verify remora, it's working. I can see via UART console that remora ha loaded correctly and comes to idle state.
But on LinuxCNC side machine don't comes out of estop. No configuration changed. Tried new trixie image but can't compile remora due to incomplete pointer error. Don't know what's going wrong?  
 

Hi,

I'm not sure I can help for the estop state in lcnc. I would start by checking the payloads in both BTT firmware and hal component.

For the compilation error, I ran into the same error when I was trying to compile my TMC5160 component and solved the problem by changing the code a bit. As I'm not a coder, I have no big idea what I'm doing, but sounds like a casting problem to me. You can try following changes in the rp1lib.c of the linuxcnc component:

Replace the lines:

dws = &inst->spi[spi_num];
spi = &inst->spi_dev[spi_num];

with

dws = (struct dw_spi*)&inst->spi[spi_num];
spi = (struct spi_device*)&inst->spi_dev[spi_num];

and:

dws = &inst->spi[spi_num];
cfg = &inst->spi_cfg[spi_num];
dev = &inst->spi_dev[spi_num];

with:

dws = (struct dw_spi*)&inst->spi[spi_num];
cfg = (struct dw_spi_cfg*)&inst->spi_cfg[spi_num];
dev = (struct spi_device*)&inst->spi_dev[spi_num];

After those changes I was again able to compile my component and could use it. BUT I didn't try it on a RPi5 actually using the rp1 lib, just on a RPi4.
Hope it helps.

You are right, my apologies, I was looking at it on my phone, and it formatted it intuitively. We'll be looking into it, thank you for reporting

Which error are you referring to?
seems to be caused by PCI-express link power management
Which version of the ethercat library are you using? 1.6 by default has ethernet over ethercat active, and it doesn't seem to be compatible with linuxCNC. With 1.6, one must compile the library from source to disable EoE.

it was true:

16 bit IN TRUE ini.traj_arc_blend_enable

I was running the torus gcode (from the torus.png --> image to gcode with whatever defaults)

EDIT: here's the gcode that triggered the bug:

 
 

Which G-code did you use for the test? I'd like to try it myself.

Could you try again with arc blend enable to true?

OK so the bad ini values seem to be LinuxCNC defaults (they were not specified in my ini file)
With more reasonable values set the errors are of much smaller magnitude bu there are still accel violations: 







Note that the acceleration (green) which has a constraint of 200 IPS/S sometimes obeys this constraint
(right side of screen) but sometimes ignores it (spikes toward center of screen reaching more than 1500 IPS/S)


ini file settings: 



 

 

 

PCW wrote:

These are in inches.

So my understanding would be:

So 20 IPS max Velocity
200 Max accel (~1/2g) so 1/10 second to maxvel with no jerk limit (old TP)
2000 Max jerk  so 1/10 second to full accel

Which (jerk=2000) actually sounds a bit low

I was doing some math to create paths (not real time) a little while back and on my machine with 0.5G (5000mm/s/s) a jerk of like 50000mm/s/s/s was the starting point of usefulness, and 500000 would probably be where I end up. So your 10:1 seems a logical place to start.

BUT, it shouldn't matter. Jerk should never create a following error, it should be mathematically precise, even if its comically low for real life machines.
 

Those ini values do not cause an issue with the old TP (0)

I'll check your suggestions in a bit...
 

These are in inches.

So my understanding would be:

So 20 IPS max Velocity
200 Max accel (~1/2g) so 1/10 second to maxvel with no jerk limit (old TP)
2000 Max jerk  so 1/10 second to full accel

Which (jerk=2000) actually sounds a bit low

Thank you Peter for looking at this.
I see a few issues with your ini.txt

16 float IN 1e+99 ini.traj_default_acceleration
16 float IN 0 ini.traj_default_jerk
16 float IN 1 ini.traj_default_velocity
16 float IN 1e+99 ini.traj_max_acceleration
16 float IN 0 ini.traj_max_jerk
16 float IN 1e+99 ini.traj_max_velocity


these settings seems a bit waky, if you want to have jerk control you need
ini.traj_default_jerk
and
ini.traj_max_jerk

to be more than 0
and the 1e+99 max acc and velocity, is this something people actually run with? is it something is supported without f-error on TP0 aka old TP?