Advanced Search

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.

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?

Also, unless I'm missing something, it's already sending back the raw count?

At this point, I've diverged quite a bit. I'm willing to do the work to separate it out, but do you want a big ugly PR or a stack of single-topic ones? I would start with a noop that makes indentation consistent (prefer 4 spaces, but 1 tab also works).

I'm also adding support for the new W55RP20 (docs.wiznet.io/Product/Chip/MCU/W55RP20/w55rp20-evb-pico), which has the W5500 on different GPIO and also conflicts with the example config.  I also bought a RP2350 version to play with.

I asked my imaganiry AI friend to take a look at it thusly:

"A friend of mine is trying to get a custom linuxcnc HAL component up and running and he's getting an odd runtime error of "hal:turret:1: character unknown ' '"

The documentation for hal stuff is here:http://linuxcnc.org/docs/html/hal/comp.html take a look and see if you see anything out of place."

While sending the comp file along.
The replies seem pretty reasonable:



I see two issues:

1. The actual error (line 1) — almost certainly smart quotes

The "character unknown ' '" error on line 1 means the halcompile lexer is hitting a byte it doesn't recognize. Line 1 has a doc string:

component turret "4-position pneumatic...";

Those " " quotes are probably Unicode smart/curly quotes (U+201C/U+201D) instead of plain ASCII double quotes (U+0022). Super common when the file was written or pasted through a rich text editor, Google Docs, macOS Notes, Word, etc.

Fix: Have him run this to check:

cat -A turret.comp | head -1

If he sees M-bM-^@M-^\ or any multi-byte sequences where the quotes are, that's the culprit. Replace all smart quotes with plain ASCII " quotes. Quick fix:

sed -i 's/[\xe2\x80\x9c\xe2\x80\x9d]/"/g' turret.comp

2. Secondary bug — FUNCTION name mismatch

He declared function _; (underscore = unnamed/default) but then used FUNCTION(turret) in the C section. Those have to match. Should be either:

FUNCTION(_) {

Or better yet since it's a single-function component, just skip the FUNCTION() wrapper entirely and put bare C after ;; — like the ddt example in the docs.

3. Minor — int diff inside switch/case

case 0:
...
int diff = target - position;

Declaring a variable inside a case without braces can choke some C standards. Wrap it:

case 0: {
...
int diff = target - position;
...
break;
}

The smart quotes are almost guaranteed to be the "character unknown" error. The FUNCTION mismatch will bite him right after he fixes that.

Okay, my two setups are here:
github.com/TriodeGirl/LinuxCNC
The AXIS one works, the Probe_Basic is the issue.
I am using a MESA 7i96s board set at 10.10.10.10
I have E-Stop enabled, and am supplying a suitable active signal to the pin input. This works under AXIS.
Many thanks.

Hi eraserhd,

Thanks for debugging this. I've not worked on the RP2040 for some time. This Remora port was a hotel room project when I was travelling for work.

I'd be interested to see a pull request to merge your work. If you have time you might also look to update the stepgen to send back the raw count like the recent Remora code for STMs, that way the latest Remora Linuxcnc component could be used.

On second thought, I will need to include the G10 offset stuff.

Just because I set HOME = 0 for both axes doesn't mean the HOME_OFFSET is the same for both.  And if I plan to use G54 offset to get the parting tool tip at spindle centerline I need the switched X-axis G54 values to be the same as V's.

Hmm...

Hallo Zusammen,

kennt jemand oder kann sich auch an das folgende Problem errinnern und kann mir helfen.

Ich habe eine CNC Spindel 2,2Kw mit Frequenzumwandler von Aliexpress. 

Jetzt habe ich ein Grundsetup vom Frequenzumrichterfür die Chinaspindel wie auf der Seite von Stephan -> Estlcam  gemacht.

Gem. Frequenzumrichter-Einstellung soll die kleinste Drehzahl bei 6000U/min sein. Gesteuert wird das Ganze über eine Mesakarte und bei der Hälfte der Drehzahlvorgabe wird auch die halbe max. Spannung also 5V von 10V von der Mesakarte an den Frequenzumrichter ausgegeben.
Soweit so gut, aber:

Jetzt verhält es sich so, dass wenn ich 12000U/min vorgebe also 5V an dem Frequenzumrichter anliegen, der aber ca 18000U/min ausgibt.

Da ja hier viele so eine China Spindel mit Frequenzumrichter haben hoffe ich ihr könnt mir helfen, wo und wie ich was verändern muss, um das die Vorgabe auch vom Frequenzumrichter richtig umgesetzt wird.

Viele Grüße
Stephan