Advanced Search

Rod, not it, it never is.
See point 2 on his reply, he can hear the solenoid inside the plasma switch on, so the relay is closing and switching stuff on.

Ich kenne Easy Probe nicht aber ich kann mir vorstellen, dass du für Tool 99 einen Durchmesser eingeben musst:

 

Hello everyone,

this will most probably turn out to be a rather long write and it is my first time posting here so please bear with me. I would say I am a beginner with LinuxCNC, despite being quite the general GNU/Linux nerd but I have done a lot of reading on the forum and the docs in the past month.

I have "inherited" so to say the machine from the person who wrote this post . The backstory is in there if you need any more context.

In short, I am still sort of stuck at the same problem the colleague before me couldn't resolve, namely the machine (servos, spindle and IO) being inconsistent with its EtherCAT connection (I assume). The first sign was that initially it was basically a coin flip as to whether the .ini program would even start. Most times it exited with an error about the Master PDOs not being correct and dmesg would report some random pin (that was defined in the xml) not being present. Different LAN cables were tried, but that didn't help so I was initially worried the IO was busted, but I pushed on and managed to drastically improve this problem in particular. I discovered that the OS was trying to establish an Ethernet connection over the LAN cable which to my understanding can definitely disturb EtherCAT communications. I made sure to disable that which allowed me to basically launch the .ini with certainty. It is still not perfect, since sometimes after a reboot I need to restart the EtherCAT driver with ethercatctl restart and/or replug the cable but after that there are no issues with this until the next reboot at least.

Just as I thought I was out of the woods, I would notice that on some executions of a test program I would run (not all, still a coin toss), the machine would emit uncomfortable noises as the axis moved. Not only that, but usually when I would leave it running for a few hours, I would find LinuxCNC reporting some random each time IO error and the program having stopped (interestingly it is the same behavior that I observe upon directly yanking the LAN cable out as it is in operation). I see in the previous post my colleague had the same issue which you guys suggested was due to a packet loss of some sort. And so it would seem, as ethercat masters -v does sometimes report lost frames. Sometimes in the tens, sometimes in the hundreds, sometimes in the thousands.

The one suspicious thing I think I have spotted is the latency test. It would run between 30k-65k ns but as ethercat masters -v start counting up on lost frames, the latency increases two or even threefold. The lost frames would then stop increasing and normal behavior is resumed. Since I couldn't find a great reference, do you believe these latency numbers are to be expected?

I am quite stumped on what to do. I tried monitoring for lost packets through WireShark on the Master PC, but there was no odd behavior there. The irq_coalescence suggestion by rodw didn't seem to help and setting refClockSyncSycles to -1 as suggested by db1981 didn't allow me to launch the .ini in the first place. Although I do admit I didn't quite understand what setting it to -1 is supposed to achieve. I see that in order to do this you would need to apply some sort of patch, but since that was for lcnc 2.8 I am not sure if I should try this on the current version 2.9.3. How would I go about installing it when my EC installation is through the repositories instead of from source?

Do you guys have any ideas on what I could attempt? I think my plan for the short term will be to try to use a laptop as a WireShark middleman to better monitor for packet loss according to the PDF I will leave in the attachments (I have no source for it sadly). If that doesn't yield anything, I will probably try to replace the IO module with some sort of other IO Ethercat board and redo the mappings to see if it is indeed the IO after all, while triple checking for faulty wiring as I go.

I am also attaching my .xml, .hal and .ini files just in case.

Any help or suggestions are very appreciated. Do let me know if I can specify something I've missed in this post. Thank you!

PS. I realize I should probably mention that the onboard PC is running off a SATA SSD to which I cloned my LinuxCNC virtual machine test bench to. From what I have seen there do not seem to be any driver discrepancies or errors, but I thought I would point it out as it is yet another quirk in my setup.

This is my guess
linuxcnc.org/docs/stable/html/plasma/qtp...asma:qt-contact-load
It will take time for the oxidisation to burn off maybe 10 cycles or more.

its not finding your xml file, try

loadusr -W lcec_conf ./ethercat-conf.xml

Hallo Aciera,

die button x0 y0 z0 , tool 99 anwählen funktionieren.

Die abtast button nicht.
in der hal anzeige kontolliert.

karlhe
 

Hi Grotius,
Kudos on the terrific progress on jerk limited multiaxis look-ahead planner.
Is there anything we can help with in porting the development to Linuxcnc?
My feeling is that we may want to break up the planner into 2 parts, i.e., RT and non-RT parts.
The geometry / path modification i.e. clothoid fillets, spline conversions etc, can take place in non-rt whereas the actual trajectory planning can be kept inside RT.
My feeling is that the heavy computational burden is in the path modification rather than the look ahead planner. The heavy computational parts can be handled in the non-rt section where loop time deadlines are not a critical consideration.
For this we will have to introduce a layer in milltask that will keep a queue for the readahead from the Gcode file and optimize the path.
I am guessing there will be 2 types of path modification constraints:
1. Add clothoid fillets between 2 moves that are long enough to qualify for clothoid filleting
2. collecting multiple small line segments and fitting a spline on them. This may be something a little more complicated than Douglas-Peucker algorithm applied to small line segments with the G64 Qxx settings.
Then we may need to add these two new entities into AddLine and AddArc commands that send the motion blocks to the RT queue inside the RT trajectory planner tpmod_scurve

Time/trajectory lookahead with jerk limitation could be carried out by tpmod_scurve RT component.

One more interesting feature we may want to account for in this new planner development is kinematic planning. Taking into account the speed and acceleration limitations of the joints involved in the move. This can be done by breaking the moves into small enough segments and checking the max velocity and acceleration at the end points of each of the small segments.

-automata

jimwhiting wrote:

What doesn't work great so far is the home offset - it moves, but it is quite violent... I appear to be missing a setting to control the acceleration/velocity of the moves on the carousel. The settings I have found so far will slow it down during homing, but appear to not affect the position mode once homed.

Likewise I have the jog forwards and reverse working, however still quite violent compared to what I would like.

 

Andy Pugh may chime in a more accurate response, but I think carousel.comp doesn't manage velocity or accel/decel when set to 'counts' mode and the counts-target pin is used.

In the velocity modes fwd-dc, rev-dc, align-dc pins all affect the motor velocity, but there don't appear to be specific accel/decel settings.

If you read the online manual (I suspect you've done so already), 'counts' mode can be used as either a position or velocity command.  I suspect that because you are using the counts-target pin via ethercat the servo sees a position command and moves there (and stops) at fastest possible speed.

In my counts-mode carousel config the position is sent to a stepgen (itself in position mode), and the stepgen runs at the max values.  So velocity & accel are adjusted in the stepgen setting, not with carousel.comp pins or parameters.

So I think in your case the easiest thing would be to adjust the servo drive to limit the max velocity and accel.  You'd treat the servo drive essentially like I'm using my stepgen settings.

An alternative would be to put your servo in velocity mode - like a 'dumb' motor - and switch your carousel config to output a velocity & direction command to a PID component, and the PID output is sent to the drive.  Velocity & accel would be adjusted in the PID.

I think I can help you. You can add me on WeChat: 304394405. I will use AnyDesk to assist you remotely.

spumco wrote:

tommylight wrote:

Do my scratcher's count as odd?

 
Of course they do.  Those things are goofy

OK, plenty more videos of those and other CNC builds on that youtube channel, enjoy.

I think the device name that is displayed in HalShow is missing  

 

I looked at Rod's configuration here , and the device has no name.
maybe with cia.402 it is not needed

tommylight wrote:

Do my scratcher's count as odd?

 

Of course they do.  Those things are goofy

What I meant is, in that latest master code the external-pause pin is built in to qtdragon/hd so you don't need the pause_pin.py file to add the pin.
You would still need the part that calls an oword program on abort.

Can you run linuxcnc in a terminal, with DISPLAY = qtvcp -d qtdragon_hd in the INI and post it?

Sorry 157.480 usteps per mm
(25000/(6.25*25.4))

Note that this is a really high gear ratio
and I would not expect accuracy better than
say 1/4 full step ~= 0.2 mm

 

Just had this issue the other day. I don't think you have to compile from source if you don't want to. I'm on a Raspberry Pi 5.

It looks like EtherLab changed the name of their distribution repo from IgH to EtherLab. Check out the new location on this page under the Debian section.
etherlab.org/en_GB/getting-started

Relevant instructions:
export KEYRING=/usr/share/keyrings/etherlab.gpg
curl -fsSL download.opensuse.org/repositories/scien...ebian_12/Release.key | gpg --dearmor | sudo tee "$KEYRING" >/dev/null
echo "deb [signed-by=$KEYRING] download.opensuse.org/repositories/science:/EtherLab/Debian_12/ ./" | sudo tee /etc/apt/sources.list.d/etherlab.list > /dev/null
sudo apt-get update

You will have to remove the sources list of IgH if you don't want errors during apt updates.

I don't know if you guys rebuild images between releases, but if it's possible to remove the IgH repo in favor of the EtherLab it may be helpful.