I have a 4 axis router with step/dir servos using a 7i76EU+7i85 to command the servos and read the encoder feedback.  I have the servos reasonably tuned running closed loop.  But I'm seeing a following error spike on homing to index for the W axis (XYZW) on the first attempt at homing the machine after power up.  After the initial encoder position reset on the homing index it will home fine the 2nd try and works after that. If the machine was parked at the W-zero location when Linuxcnc is turned off and started it does not do the following error.  For some reason it seems like Linuxcnc is not ignoring the F-eror on the encoder index reset for the W-axis like it should.  Any Ideas how to fix this?

Here are my main hal and ini config files.
 

Thanks it should work fine with the 2 RCPWMs and the sserial on TB4

Small update:

I aligned all docs with the actual runtime behavior and added a practical diag.sh guide.

Quick start is now simulation-first and profiles are clarified as declarative contracts.

Some parts were previously implicit (in my head), so this pass was mainly about making those assumptions explicit and removing ambiguity.

No changes in runtime/semantics — just making it easier to use and debug.

Now waiting for real hardware feedback.

Ok, it is reset of latched estop.
And how to realise reset button for external errors, for example drives errors or external devises (torch head or edm generator)?

Also i couldnt startup halui component, but somehow flexgui send power on signal to drives , i want to know how to use the same logic and send signal the same way

It doesn't sound pll-related if you get clunks when idle/standing still.
You can try and record this. If the clunks are from commanded position disruptions
you should see it as disruptions in position feedback.
You can record long sequences to try to catch it. Use the "sampler" hal component.
Possibly add a ddt component to take the derivative of the position feedback.
It will show some spike/peak when a clunk happens, if there is something with the position.
Plot the data, and evaluate.
 

I know Windows 11.1 uses a GPT partitioning. Everything I've read indicates that if I used Rufus to make the USB live stick on a GPT partition that I could do a dual boot install. I turned off bitlocker on the Windows files, turned off secure boot, turned off fastboot under the power settings, and shrank the windows partition to give me 50GB for the install. The install asked me for a missing file related to a sound card and didn't recognize my network (wifi). I selected manual partitioning and did not see any of the partitions other than the USB stick. The live version booted and ran fine. Running gparted showed the EFI partition with an error triangle alongside. I suspect this has something to do with GPT but I can't figure out what.
I'm trying to install this on an HP Laptop. Any thoughts?

Nice, thanks for testing it

And yeah, honestly you did a better job than the docs there
At that moment they were a bit messy and could easily lead in the wrong direction.

I just went through and cleaned them up properly (quick start is now simulation-first, no profile/topology needed, and observability is aligned with what diag actually shows).

So what you ran is basically the intended path, just not well explained before.

If you get time later to try it on real hardware, that would be really interesting to hear about.

Appreciate you taking the time to try it.

The config was previously working just fine. I dont know what changed that caused this.

Ill check dmesg again when im home.
As for the working state after the DRO populates... Its hard to say. I can definately move every axis just fine, but theres a 50% chance that clunks occur. Sometimes more clunks, sometimes less clunks. Sometimes they even appear mid-cycle which is a no-go.

ive swapped out all the ethernet cables now, re-imaged my lcnc host, even used a new host without any success.

first thign i see is you ar emissing the postgui hal file that is required. you need to uncomment the ini for that line and copy over the probe basic post guiio hal file as is stated in the docs.

it looks like you may have missed a few steps, go beack through the machine config section in the docs really carefully and make sure you have done all of the steps accordingly and i think you will find things will work as expected.

kcjengr.github.io/probe_basic/machine_config.html

ewlsey wrote:

Go easy on me. I tried to read through this whole thread, but there's a lot to digest. 

--snip--

I know it's not a "real" control, but it's pretty amazing they could get all that to work (along with g-code interpreter, etc) on an 8 bit AVR microcontroller. 

 

Just now I discovered:
GRBLHAL = 32 bit
GRBL = 8 bit
Thanks for bringing this up. A long time ago I read all about GRBL 8-bit and sort of gave up on it. Now I notice the main project is 32 bit. Now that seems worthwhile. Cheap 32-bit MCUs today pack some punch.

That said, I'll leave the S-curve talk for the pros.image missing /media/kunena/emoticons/smile.png

Go easy on me. I tried to read through this whole thread, but there's a lot to digest. 

How does the current linuxcnc approach compare to how S curve acceleration is being done in GRBLHAL? 

I've tried to read the linuxcnc servo loop code, but it's pretty well impenetrable. 

However, GRBLHAL is very cleanly written and well commented. From what I can see, it has many features discussed here.

It has a backwards (and forwards) buffered trajectory planner with prescribed tangential acceleration. It has buffered segment interpolation. Both run outside the realtime loop, but the segment buffer is fast enough for feed overrides and holds to feel instantaneous. 

I know it's not a "real" control, but it's pretty amazing they could get all that to work (along with g-code interpreter, etc) on an 8 bit AVR microcontroller. 

The current HAL version offers jerk limited acceleration, though I have to say its utility is a bit questionable for industrial machines. I believe the GRBL equivalent of the "servo loop" only runs at 100Hz, so you would need really low jerk values to see an effect. But, the framework seems sound.

Thanks!
I looked it over and tried the simulation. It's looking good. Later this week I hope to find time to try it on my hardware.

rodw wrote:

Why can't you use more than one thread instead of a FGPA?

 

Thanks, I've been wondering too. I've been dreaming about kinematics using multiple realtime threads. Does anyone know whether/why it would not do?

Just asking specific questions on the forum may be enough to get you going.

 

TAKUYA wrote:

It seems like the drives arent going into OP right away. The delay is always different. Sometimes the DRO is instantly filled with the encoder read (but converted to axis position) values, sometimes it takes up to 10 seconds. 

 

Seems a bit unexpected to have up to 10 second delay before OP on ethercat. Is this a new config or was it previously working?

Does anything relavant show up in dmesg?
Once it finally populates the DRO, is everything working after that?