Advanced Search

I'm trying to configure an existing LinuxCNC machine (simple XYZ) in manual mode using physical mechanical switches for axis selection and Jog Plus/Jog Minus.
It works in joint mode.
But it doesn't seem to work in TeleOp mode. 

I operated same things from using HAL Pin manually without wireing configuration, but I got the same result.

What I did using HAL Pin (in TeleOp mode)  was..
1) confirm manual mode in LCNC. (all axis homed )
2) Turn on/off some pins in Show Hal configuration (N=axis char)

halui.axis.jog-speed ( set to 500 )
halui.axis.N.selected
halui.axis.N.is-selected
halui.axis.N.plus/minus

I tried another method using halui.axis.selected.plus/minus, but same.

Should I use another pins?
What am I missing ?
Which pin should I check ?
Could you guys help me solve this problem, please ?
 

Had a 1 hour 30min meeting with Rob and YangYang, and Andy Pugh was also there for the first half an hour, it was extremely nice to make both acquaintances.
We discussed a bit of everything, I've asked Rob when he has time to take a look at the 9d branch and give me some direction on it.
We did not talk about 1500mx, but in general, we agree that ideally in our dream TP, Kinematics need be moved first, and be the reference for limits pos-vel-acc-jerk. We agree S-curve early in the planner is more ideal than what Tormach does now, we agree Tormach  SLERP approach does not have continuity for jerk control, Rob warned about Beziers, as they will be a headache for look-ahead. It was very productive meeting in my opinion, I talked maybe too much lol, but it was kind of necessary to have Rob understand what are the problems we face with the current architecture.
Anyhow I pointed him at what has been done so far in the 9d branch, and asked him to give me an honest opinion, since everything is vibe coded, hope it does not do his head in, but I told him to be honest, and if I have to scrap everything and start from 0, I would accept that...
YangYang will still work on improving planner 1, since that is still the most battle tested codebase we have, the 9d branch is an exploratory branch, which will be used to explore different approaches, and see what sticks, I think is a good approach, because out of me playing with Ruckig got YangYang interested in it, and he now moved it in the source tree and is using it heavily to fix the slights spikes we were seeing before.
Ruckig has MIT license, and we also had AI port it to C++ 11 because we want to support old debian 10, we still have machines running on it, which I am not interested in updating to debian 13.
github.com/mika4128/ruckig.git

Thanks for the additional details — this is very helpful.

At the moment I don’t have EtherCAT hardware available, so I’m starting by validating the architecture with what I already have: Modbus (mb2hal / Python bridge). The goal is to first prove the PLC-as-master / LinuxCNC-as-motion-controller workflow, including startup handshaking, heartbeat, status exchange, and command flow, before moving to other transports like EtherCAT.

Your description of the startup sequence, heartbeat bit, status propagation (power, E-stop, homed), and the PLC-driven workflow matches very closely what we are trying to implement. It’s also very encouraging to hear this has been running reliably in production for years with operators completely abstracted from LinuxCNC.

Once this is stable with Modbus, we can evaluate other interfaces, but for now the focus is on validating the control model and the command/status contract between PLC and LinuxCNC.

Thanks again for sharing the detailed workflow — this is exactly the kind of practical guidance we were looking for.

It can be that the motor speed needs to be ramped up, like it is by linuxcnc.
Setting 6000 rpm as a step is quite challenging.
Anyway, 3000 rpm is more than decent for a stepper motor.

Consider to use csp mode, that's what most people do.
The position feedback is lagging two servo cycles when using ethercat
and a velocity loop has a hard time.

If you use csp, the position update will stop in your scenario, and the motors will stop.
Check out the SDO listing, there is a max current setting (per motor).
 

Here is what I managed to squeeze out for velocity. It seems 10000 set 60rpm so I must have had them at 3000rpm. They were really squealing. If I bumped it up to 600000 they stalled and sat there squealing.
>halcmd: setp lcec.0.0.0-target-velocity 500000

In the process of trying this, I made an interesting observation: I knew my 24V 5A psu is too small and will lose out at some point. It tripped about 2-4 seconds after I changed the 4th motor from target-velocity 0 to target-velocity 500000. All 4 motors stalled and the drive's LED's blanked. The psu reset, the drive lit up, then a few seconds later, all 4 motors resumed full speed. This cycle continued about twice, then I stopped two motors.

I checked dmesg, sure enough, it showed ethercat had come and gone several times.

The fascinating part is the way the drive remembered its previous state after a power droop. I have this running in velocity mode. Position mode 8 would hardly be affected by the following scenario: I envision the potential of a power droop stopping the pc then moments later the servos continue in their most recent trajectory, meanwhile the pc slowly boots... I guess on machinery where this would matter, the e-stop ciruit would also release, preventing anything from moving uncontrolled.

Earlier today I disassebled this drive and discovered it appears the encoder feedback part of the pcb is fully populated except for the connectors. I will try to connect an encoder and try to activate that... see if I get counts in velocity mode.

One more observation I made while I had it apart: the pcb is conformal coated - a sure sign of decent quality!

A few more details:
Because you will have 2 separate controllers (PC with LinuxCNC and a PLC) startup handshaking has to be worked out. In my case, I set up the linux pc to autostart on power just like a PLC does. Then, on the linux PC I set LinuxCNC to Auto Start on boot. After a few seconds of delay, I Auto Start the "Python Bridge" script. The Python bridge requires that LinuxCNC be up and running before it starts because the python linuxCNC module goes out and looks for linuxCNC to be running. This all takes less than a minute.

Once the Python bridge is up and running it does two things, checks the status of LinuxCNC and starts setting and unsetting a bit in the PLC via modbus. The bit sets and then resets every 250 ms. This is my heartbeat that lets the PLC know that everything is up and running. LinuxCNCs status concerning "Power On", "E-Stop active", and "Axis Home Status" are all read by the Python bridge and this information is passed to the PLC through registers and bits. The PLC then directs that power be turned on, after confirmation that the power is on (again through the python bridge) the PLC issues a "Home All Axis" command. After all axis are homes the Python bridge sets a bit in the PLC that lets the PLC know its ready for operation. In this control scenario, the PLC is always the Master controller, it just checks on and commands LinuxCNC through the Python bridge script. 

Safety is handled like any other industrial set up. A separate safety controller (not the PLC or LinuxCNC) disables all motion and potential in the machine including disabling the CNC servos. The PLC and LinuxCNC are both wired into the safety output so they both stop any motion in the event of an emergency stop. When the safety status is cleared, the PLC issues a "Power back on" command to LinuxCNC and then a re-home command. 

It sounds like a lot, but it is really straightforward and pretty simple once you get the workflow sorted out. 

The machine as it is today can produce 28 unique product variations (potential is almost limitless) and the operator only has to select the
product number via the HMI. Everything else is handled in the background automatically. The operator doesn't have to have any knowledge or CNC experience to run the machine. Training takes less than 30 minutes for a new operator.

The output in syslog, from dmesg, is very quiet.
Here is what it looks like when I start the ethercat master

You have these line
From this also it looks like your slaves don't come in contact with the ethercat master.
You have of course double checked that you have configured and are using the right network adapter.
Good idea to test with another PC. If you have multiple network adapters, you can try with another.

I saw in your output a message about ec_master tainting the kernel.
It's not an issue with secure boot? You had it running so I guess not.

I'm using the latest ASDAsoft v5.5.0.0, could this be the case? Otherwise its the servos firmware as you mention.

There is also the option of equipping the LinuxCNC PC with an EtherCAT slave interface.
Data exchange can then take place via this interface.

Awesome! Rony didn't come back to me.

Thank you very much for this screenshot. For a long time, I couldn't understand why the manual didn't match the hardware. It seems that the old firmware was done differently...
 

Lichuan promptly (as in 'same day') responded to my request for manual and software. They're shared here:
git.gitcoding.net/nwe/lcec_4x_stepper.git

Thanks for sharing your experience — this is exactly the kind of real-world example we were hoping to hear about.
Your description matches very closely the architecture we are targeting: a PLC/HMI as the cell controller (sequencing, recipes, operator workflow, interlocks), and LinuxCNC used strictly as a motion controller. The Python “bridge” approach you described, using Modbus TCP on the PLC side and the LinuxCNC Python interface on the PC side, is a very pragmatic way to implement a clean command/status boundary between the two domains.
What I find especially valuable in your example is that the operator never interacts with LinuxCNC directly: the PLC/HMI owns the workflow, selects the product/recipe, and LinuxCNC is treated as a subordinate motion engine that executes the required paths and reports status back. That is exactly the separation of responsibilities we are aiming for.
It is also very useful to hear that this setup has been running in production for several years, daily, with good reliability. This addresses one of the main concerns in industrial environments: long-term robustness and maintainability, not just theoretical capability.
Your comment about Modbus TCP being “simple and universal” is also a good reminder that, in many industrial contexts, simplicity and familiarity often translate directly into better supportability and uptime.
Thanks again for sharing this — it’s a very strong reference point for PLC + LinuxCNC architectures in real machines.

royka wrote:

Thanks, yes I can suggest it, it runs pretty stable.

Have you got an image for this?