Advanced Search

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.

I'm struggling to launch a gladevcp panel from my gmoccapy interface. I've queried the web for examples and feel that I'm on the right track, but without success.  I'm open to any suggestions.

I've attached my .ini file along with my gladevcp.ui and custom_postgui.hal for reference.

FYI - I have a laser crosshair that I use to locate the program start for a project. The laser can be toggled by either the gladevcp panel or via a toggle switch on the machine. I've wired up the machine such that either source will set an input pin high to turn on the panel LED. If the laser is toggled via the machine toggle, I want a visual indicator to remind me to turn it off manually.
Once I get the panel to display and the led to toggle properly, I may split the input to I get a visual indicating which source toggled the LED, but for now I just want to get the panel up and working. There is no custom python handler needed at this time.

Thanks for the replies. The spindle.0.revs seems to be right when turning by hand, and when driving with the VFD active it is hard to tell exactly, but it seems to be correct as well.

Trying in constant speed instead of surface speed is a good idea, I will try that next.

And regarding diameter and radius, the man page I even linked says:

Note: When G7 Lathe Diameter Mode is in force, the values for I, J, and K are diameter measurements. When G8 Lathe Radius Mode is in force, the values for I, J, and K are radius measurements.

I don’t know how I overlooked that, it is really obvious now.

I set up front and back angles, but it needed diameter to start displaying the inset shape.

However... it's displaying the tool tip past centerline when the tool is at X0.  I tried fiddling with the table angles (-87 & -32 vs 342.5 & 287.5) and it didn't make a difference.

Same display issue when the WCS rotation is in effect.

Below photos has tool #2 active.

 

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.

I am surprised that you have tool cones and not lathe tool shapes in the graphics. You should have a reasonably accurate picture of an insert.
You may need to set up frontangle and backangle in the LinuxCNC tool table for that to work, as well as the orientation.