Advanced Search

it seems to me that this is "not sporty". Together we must force the correctly given commands to be executed correctly. G38.3 should not produce such errors.
You suggested changing the interface to qtplasmac, but it uses the same g-code and linuxCNC. And I have a milling machine.
Unfortunately, my level (of knowledge) is not yet such that I immediately understand the "right path" from the hints of the M130. I would appreciate more precise instructions.
Editing the source code file, as suggested by AkkiSan and Aciera, in my opinion = the right path. And I would be ready to experiment. But I need instructions on exactly how to get v2.9.7 to use these changes.

My recommendation is to migrate your plasma machine to use qtplasmac which has obsoleted the thcud component.
It does not use g38 but probes with external offsets and also retains your probe away from the material.

I have used gcode probing for plasma without issues. I suspect your problem is related to your gcode given M130 is a custom gcode.

I would do some testing of your probe moves as MDI commands to isolate your GUI and custom gcode

Interesting to see you switching between spindle and axis.

I wonder how it works with setting a position in PV mode.
Setting position and velocity at the same time, I am not sure that works.

v2.9.7, encountered the same problem – Die Warteschlange ist nach dem Prüfen nicht leer.

I see that references to this string have been found in the source files.

From the description " 2. Das probe_flag ist wahr, aber die HME-Befehlswarteschlange ist nicht leer: NCE_QUEUE_IS_NOT_EMPTY_AFTER_PROBING" follows that such an error should occur, for example, in the combination -
g38.2
g38.2

But when executing g38.3 (single), such an error can never happen. Maybe it would be wise then to disable some of the checks completely for the 38.3 command option?

The process is greatly influenced by the speed setting -
1. The kinetic energy of an impact is a function of the square of the velocity g38.3 (strain)
2. the machine does not stop immediately. After operation, a stop occurs and during this time the Z coordinate changes. An example is flights: at speeds 110=0.006785, at 180=0.012583. According to the sensor documentation "scan speed 200". Acceleration at my Z axis = 5000.
3. the reverse stroke of g38.5, accordingly, first overcomes the flight from g38.3, then the hysteresis of the sensor and now braking and stopping with its flight. 

In my case, reducing the speed of the G38.5 from 300 to 200 increases the overall processing speed - by reducing flights (g38.3 at speed 110)

And if possible, please give instructions for (beginners) - I’ll take this file and make changes to it. How exactly to get the system to use these changes? I mean the timid hope that there will be a cunning way without a complete reassembly.
 

Can you verify that encoder position or pos-fb doesn't change after a few seconds?
Just so we know?

You may not be able to fire up halscope in time for that,
or if you are unable to catch it in halshow.
I propose you use sampler/halsampler.

Add last in your hal file

Adjust net names to yours.

Within a few (10 max) seconds after you started linuxcnc type the command "halsampler -t data.out"
After the coordinate on the axis screen has happened, hit Control-C on halsampler.
You have now a readable file of recorded values. Open the file in Excel/Calc and plot XY plot.

 [/code]

I have not, I'll give it a look.

If I set the drives to display encoder count the value doesn't change when I close lcnc so if it were an encoder feedback issue I'd expect to see changing values on the drive its self.

have you looked at the values of the pos-fb pins in halshow?
halshow can be started automatically from a saved session using the [APPLICATION] section of your ini file:

I've found the EtherCat experience to be absolutely positive so far. I had this retrofit up and running (with a lot of help from the forum) in a day or so compared to about a month on the previous machine.

While it's certainly possible that it's related to EtherCat, I don't think so. The machine movement is absolutely rock solid and silent and so long as I don't enable the machine until Lcnc has updated the position values.
Lcnc is changing the machine start possition after it loads and it looks to me like it's loading the g54 values from the linuxcnc.var file about 5 seconds after it loads. It seems to correspond with the axis toolchanger message in the bottom right disappearing but that could be purely coincidence.
The 'jump' occurs every time I restart Lcnc but I'm not powering off the drives. If I set the drives to display encoder count the value doesn't change when I close lcnc so if it were an encoder feedback issue I'd expect to see changing values on the drive its self.
It seems more like an issue of incorrectly saving machine coordinates on close or load.

langdons wrote:

Well a slightly newer version could work too.

Try whatever came right before "Bookworm", see if it's old enough.
 

Thats the thing. The LinuxCNC version before Bookworm was on a Wheezy ISO. There was no linuxcnc version released on Bullseye (5.10 kernel) which precedes Bookworm. We don't want to hear Ubuntu being suggested. That's bad advice (as is using Wheezy which is akin to suggesting people drive a Model T Ford)

Can you tell about your computer hardware and how you installed linuxcnc?  What Linux version?  What does a latency-histogram --nobase --sbins 1000 display? There could be network latency issues on newer Debian versions, but that only affects Mesa ethernet cards. I would be looking more at secure boot, isolcpus and BIOS settings.

Hello everyone.

I've always been very curious about how LinuxCNC code works, and I participated in translating the documentation into Spanish when it was at version 2.8. Now I'm looking for opinions in a forum about a need some of us might have (I suppose): documentation of the source code itself.

I love images. A flowchart is a treasure for me. Yes, I know: code is the best documentation... but sometimes it's a real headache (we all know that, right?).

That said, let's get down to business!

I've prepared the PDF attached to this post. First of all, apologies: some of it is in Spanish (mainly the descriptions), but that doesn't obscure the general idea.

The document relates to the halcmd_completion.c file and is just an example. It only took me half a day to prepare, and the flowcharts haven't been proofread. I insist: I'm asking for your opinions on my vision, not for technical corrections.

This isn't the time to discuss the file itself, but rather to share my idea for documentation. I believe any "novice LinuxCNC coder" can find guidance with this type of "document".

I'm also aware that this is a user forum, not a developer meeting place, but... what about "high-end" users?  

Thanks in advance for your comments.
J.M. Garcia a.k.a. Abu

I think I have seen those 83 errors as well, probably some issue with how it starts/stops but I agree that should not be an issue. I might try that with the "built in" drivers to see if that behaves any better.
Errors that don't really cause any known issues on my end but I did fix is
<pdo idx="0x1702"> to 0x1600
<pdo idx="0x1b04"> to 0x1A00
That maps to the truly variable PDO mapping, the ones you have set are fixed PDO mappings, and when lcec tries to write to them it gets errors and writes them to the dmesg logs. In addition if you use the correct ones you can map whatever PDO's you want.
I am pretty sure with the xml file you used it does not configure DC sync. When I use the built in "driver" type="OmrG5_KN04H" I see a message about the DC sync, when I use the example xml it does not, which makes sense because its not enabled in master.

refClockSyncCycles = "-1" for older versions of linuxcnc_ethercat ( i.e. lcec ) syncToRefClock="true" works for newer versions.

For anyone out there trying to use variable PDO, for some reason my drive does not support 0x60f4. It took me a long time to figure that out.

Check the DRO on the attached images, sometimes the Z axis changes, sometimes the Z and Y, but never X.
I would say definitely not LinuxCNC issue, and definitely feedback/drive/interference issue, but i am not sure how the feedback is done in EtherCAT, although i vividly do recall reading somewhere about it having some unacceptable (for me) issues with encoder feedback.
Sorry i can not help more, but since that time i really lost interest on EtherCAT, and sticking to Mesa as much as humanly possible.

Apologies in advance, I'll probably describe this wrong but hopefully the video makes it clear. 
I'm in the early phase of a Weeke router retrofit. I've got my Delta Ethercat drives up and running with LCNC thanks to a lot of help over in the Ethercat section of the forum.
I've got an issue at the moment that I think is probably just basic Lcnc behavior stuff. After I launch Lcnc and Axis loads the axis positions are updating and the machine is trying to move to that new position (if it's enabled at the time). It seems to happen just as the "axis" dialog box in the bottom right corner disappears If it's not enabled then the position for the axis update and everything is good from then on. It looks like Axis is importing the stored values from linuxcnc.var about 5 seconds after startup, the g54 values I think.
If the machine is enabled at the time when the update happens the drives are seeing this position update and trying to teleport to the new position at what seems to be max speed and acceleration making for some very noisy and unpleasant sounds. 
What do I need to do to get rid of this behavior?

Video shows it all pretty clearly. Even though you'll hear me saying that it doesn't do it the first time it clearly does. You can see the Z axis (I think) move about 50mm right at the start of the video.