Advanced Search

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.

Ooops, I did not set  pos_cmd_out but its not needed and could be removed from the component

langdons wrote:

The fan in my mom's decided to run at full speed one day,

Do you mean PC?
-
Back on topic:
-Power off the PC, unplug the power cord, wait 2-3 minutes
-Open the PC, pull out the Mesa 5i25
-Use an old clean cotton t-shirt to clean the contacts on the board, mind the parts near it, use a bit of force while moving back-forth on the contacts only
-Use an old clean toothbrush to clean the PCI slot on the PC, you can use a bit of alcohol on the brush
-wait 15 minutes if alcohol used, if not plug in the Mesa board
-insert the power cord, power on the PC
If it still does not work, try another PCI slot.
If it still does not work, enter the PC's BIOS and see if it has an entry for automatic assignment of resources, set it to manual, save reboot, test again.

Try the attached component

Untested. Probably has some typos but the logic should be sound.

hi,
I was hoping to enable and disable adaptive-feed from halui but could not find a way to do that. I was hoping for some help on modifying halui.cc so adaptive feed can be directly changed from the hal layer via a panel button. It would be good to have an indication also of the current status of adaptive-feed from halui. 

Currently adaptive-feed can be modified via Gcode M52 P1 and P0. It can also be changed from the linuxcnc python module via the command channel which makes me believe that it should be changeable from halui.cc too.

I mean one easy way  to do this would be to make a python user component that imports the linuxcnc module and will check the halui status from the stat channel and update on a pin and set it from the command channel via monitoring a couple hal pins for changes.

However, I feel halui is the appropriate place to put pins for operating the machine from the machine panel.

regards,
-automata

Mark you might be better off just getting a different VFD. either way i had my Grok with my pro account deep dive that dogshit manual. here's the reply, YMMV but this was the output


Don't worry, I feel your pain — this 1999 Lenze manual is dogshit (modular design, everything scattered or in separate booklets, zero useful index for braking stuff).
Here's the actual practical answer for using an external braking resistor on an 8200 series drive:
1. First check if your drive even HAS a built-in brake chopper (most do up to ~11 kW, none above that).
Look at your type plate (e.g. 8213EB… or 8224EB… etc).
→ 8201 – 8214 (0.25 – 11 kW) → built-in brake chopper + PB terminal = yes
→ 8215 – 8218 (15 – 30 kW) → some have it, some don't (check if PB terminal exists)
→ 8221 and higher (37 kW+) → NO built-in chopper → you need external brake unit (8250 or 9350 series)

If your drive HAS a PB terminal (built-in chopper)

Connection:
Braking resistor goes between +UG (or DC+) and PB.
Polarity matters — +UG to one side of resistor, PB to the other.
Minimum permitted resistance (Rmin) and max continuous braking power is listed in chapter 3.4 / 3.5 rated data tables for your exact type (e.g. 8202 = 100 Ω min, 8213 = 47 Ω min, etc).
The chopper is ALWAYS ACTIVE — there is NO parameter to “enable” it.
It switches on automatically when DC-bus reaches ~770–780 V (400 V units) or ~400 V (230 V units).
If you get OC5 (overvoltage) during deceleration → either ramp too short, resistor value too high, or resistor power rating too low for your duty cycle.
Just set your deceleration time (code C0012 = Tdec or Tif) short enough so the drive actually needs to brake hard and the chopper kicks in.

If your drive does NOT have a PB terminal (8221 and higher, most cold-plate versions, etc)

You need external brake unit (8250 for up to ~45 kW, 9350 for bigger).
The brake unit connects to the DC-bus terminals (+UG / -UG or DC+ / DC–).
The resistor then connects to the brake unit itself.
Separate manual (material no. 393658 or 394036 — the ones mentioned in part G of your PDF).
The manual doesn't have the info because Lenze split it into separate booklets like a psychopath.
No code like C0023 or C054 to enable the chopper — if the hardware has PB, it just works when you connect the resistor.
That's it. Connect it, don't go below Rmin, size the resistor power for your actual braking duty (usually 10–20% ED is safe), and you're done. No secret parameters, no bullshit.
(If you tell me your exact type code I can tell you the exact Rmin and recommended Lenze resistor part number.)

Really all you need to port across is your ~/linuxcnc folder

unknown wrote:

After looking at the error message it seems that this would be an issue for PCW to advise on. Maybe corrupted firmware, just a blind guess.

Could be.

Randomly not working after not being used for 18 months without any clear reason is pretty odd.

If firmware is indeed the culprit, perhaps running sudo apt update && sudo apt upgrade would install a new linux-firmware package and overwrite the existing (and potentially broken) firmware, which could fix the issue.


Hardware weirdly breaks all the time!

The fan in my mom's iMac decided to run at full speed one day, and it remains at full speed without the aid of a 3rd-party fan control app.
I had an old PC that I installed LinuxCNC on; one day I powered it off and it never turned on again (stupid HP).
Then I moved the HDD to a new computer and then one day the PSU fan of that computer decided to break!
But why?