Advanced Search

No, not that.

So, if I tap just once, for example 0.1 mm, the axis moves 0.09 mm and it takes about 1-2 seconds for it to adjust.
It's exactly the same at 0.01 mm.
At 0.001 mm, I have to tap several times before anything moves, and it takes quite a while for the axis to adjust.
I did some calculations:
17Bit encoder and 10mm spindle:
1mm = 13107,2 inc = 35,38°
0,1mm = 1310,7 inc = 3,5°
0,01mm = 131,0 inc = 0,35°
0,001mm = 13,1 inc = 0,035°

The A6 should easily manage that.I don't think autotuning alone will be enough.
You'll probably have to adjust some settings in the driver.
 

I tried coping what you have above (with the appropriate name changes) to the handler file, but I still get all zeros in the table.

 

Good morning,

If you want to keep an I/O as first device I suggest EK1100 instead, or have the servos first.

If you want encoder for rigid tapping I suggest EL5152 and a suitable encoder with A/B/Z signals.

EL5122 does not support Z signal, and you'd have to create a virtual one, more laborious, and possibly never as precise/repetitive.

Using EL5122 or EL5152 as first device on DC also not advised, they are not  conmonly used that way, so I'd avoid it.

I've been think about your debian 10 immediately OP, and I suspect that points to your debian 10 running in free mode and not DC.

Just a stab, you are loading 'custom_postgui.hal' twice, which does not make a lot of sense:






Generally it would be quite helpful if you told us what actually is not working.
Start your config from the terminal and share the output you get there.

Good morning everyone. If I wanted to change the current first slave from Vipa to Beckoff, I was wondering if the EL5122 board for TTL encoders is supported and if connected in Hal, appropriately, can reset the encoder counter, in order to perform rigid tapping.

EMBED_TAB_LOCATION = ntb_preview
or
EMBED_TAB_LOCATION = ntb_user_tabs

Did you try these?

5 axis machining, robotics?

Define very imprecisely +- 1mm?

Most likely your servo drive doesn't report 0 position at the start.
Look at the pin joint.N.motor-pos-fb to verify that.
I am not aware of any good way to fix this more than to manually set the encoder
value to zero, via some device specific sdos. I'm doing that.
It should be described in the manual in that case.

Hi Hakan,

Thanks for the trace, it pointed straight at the bug. I reproduced your observation on my hardware and the root cause is exactly the "bad initial reference time" you flagged, but only in M2R mode. R2M is unaffected because it only writes the ref clock (sync_reference_clock_to) and never reads it back.

I added a small debug capture inside the dcsync callbacks (same columns as yours: cycle, pll-err, ref_time_lo, app_time) and logged the first 10 cycles. Before the fix on M2R:


Between cycles 1 and 2, app_time_ns jumps by 4,295,000,000 ns (4.3sec). Same shape as your lcec.write-all trace.

Mechanism, walked through the code:

1. Cycle 0 pre_send reads ref_time_lo = 1,875,535,147. At this point our first frame carrying ecrt_master_application_time() has NOT yet been sent (cycle_start queues it, the actual send happens later in pre_send). So the read is the slave's own free-running DC SystemTime from before it received our epoch, exactly your speculation about the 0x92C offset register. lcec's unwrap code then seeds master->ref_time_ns = (app_time & 0xFFFFFFFF00000000) | 1,875,535,147.

2. Cycle 1 pre_send reads ref_time_lo = 1,037,346,343 (now valid, slave has received our app_time and rebased). The 32-to-64-bit wrap detector sees 1,037,346,343 < 1,875,535,147 and adds (1LL << 32) to master->ref_time_ns. False wrap.

3. With ref_time_ns now 4.3 billion ns ahead of dc_time_ns, the resnap logic in pre_send divides the diff by the period and snaps app_time backwards by 4295 periods. That's your +4.295e9 jump.

4. PI then only has to absorb the sub-period residual, which is why your cycle 3+ looks normal.

Fix is in v1.41.0-pre2. A ref_seeded flag discards the first nonzero read; the second nonzero read seeds the unwrap state without wrap detection; steady-state wrap detect takes over from cycle 2 onward.

After the fix on the same hardware:


No phantom 4.3sec. The cycle 1 to 2 delta is now 32 ms (32 periods), which is the real initial phase error between the slave's rebased SystemTime and our app_time at startup, snapped to whole periods by resnap. PI absorbs the ~190 us sub-period residual over the settle time. pll_reset_count stays at 0 because the first resnap fires with dc_diff_ns == 0 and skips the counter increment.

So your speculation about the slave maintaining its own time and adding an offset after rebase is consistent with what we observe. The lcec bug was specifically the wrap detector treating the pre-rebase read as the baseline for the post-rebase read.

R2M in the current master was already correct in this respect (no read, no bad baseline), so no change there.

Thanks again for the clear debug output, it was the whole reason this was easy to pin down.

Could you test my 1.41~pre2 release on GitHub, to confirm you get the same result?

github.com/grandixximo/linuxcnc-ethercat...ses/tag/v1.41.0-pre2

But be warned even with this fix the OP time in my case remain about the same, the hardware has to do OP to run in DC, and it does take time, I agree with Rob's assessment, having the first device on the network be a good DC device is a must if you want good DC, I could try to debug what is the problem with papagno's first device, and I am also trying to get Ethercat to fix the function where we will be allowed to move the DC reference to arbitrary devices in the network, at the moment this function is present in the API but does NOT work.

This is simply restart after few minutes LinuxCNC was closed (servos had time to drift apart)
 
12s OP
Then quickly close and open again (servos had NO time to drift apart)
 
3s OP

if you want to get similar logs
 

As far as AssignActivate 0x300 to 0x730 I don't use this type of sync as i run in pos-cmd I don't think is necessary in my use case, but it should work, I think 0x300 should work fine for pos-cmd, if you use vel or torque command with internal PID you might want to look at 0x700 or 0x730

I have a working laser config at github.com/JTrantow/configs/tree/main/router3 This directory also works as router so look at laser.hal and laser.ini.

motion.analog-out-00 is the laser output pin from the gcode. I use a mesa card with pwm but I've also used the linux pwm with no problems.

If you use F360 the following post processor will work for simple laser cuts and is compatible with lightburn generated gcode.

github.com/JTrantow/LinuxCNC-F360-Cutting-Post-Processor

1. gcode
2. hal
3. GUI's
4. hardware

Dear friends, honored to be member of the community , as a new migrant from Mach3 i raelly shocked of the level of profissionality and experience and i admit " i regret about the long years i was afraid to join LinuxCNC " , I ask the profissionals to create a roadmap to help of generating new generation of experts to the community, from a to z :
- the programming skills needed.
- the CNC basic and advanced knowledge .
- linuxcnc, system terminology and construction.
this is a basic idea and i hope our superiors and expert to descuss this issue and sure this is a great investement in the future   

I have a few questions regarding the Remora ETH source code. I understand it's built on the lwIP stack.

Does lwIP significantly impact the servo cycle timing? Does it cause noticeable lag/jitter?

Has anyone attempted to implement their own custom stack with Zero-Copy support? I suspect this would yield a decent performance improvement.

How is the time domain problem solved between the PC's servo cycle and the STM32's time domain? Or does the system simply operate in a fast response mode — processing commands immediately upon arrival from the PC?

If the time domain mismatch isn't handled properly, you simply cannot achieve precise velocity and acceleration control, especially when dealing with position feedback from the encoder.

Thanks.

andypugh wrote:

Having looked at this a few times, I think that the best place to do it is actually in a G-code filter. ie calculate the heading from the G-code and insert / append C axis moves as appropriate.

One way I guess, but how does the gcode continually update the heading on a G2 or G3 as it traverses the arc? I found this had to  be done in motion. This will work, I just got taken over by other priorities which are now subsiding.