@NWE

Thanks — that clears it up. I now understand that you meant the PLC driving LinuxCNC, not LinuxCNC driving the PLC.
That is exactly the architecture we are aiming for: PLC as the authority for machine state, sequencing, and operator workflow, with LinuxCNC acting as a subordinate motion controller responsible for trajectory planning, interpolation, and coordinated motion.

Where we are still looking for practical guidance is the shape of the interface between the PLC and LinuxCNC — in other words, what has proven to be a clean, maintainable, industrial-friendly command/status boundary without turning into a large custom integration project.

From your experience, do you see this working best as:

Discrete I/O + handshaking
(cycle start, feed hold, abort/reset, mode select, jog enable, plus status bits like ready/running/done/fault), with parameters passed via registers; or

A fieldbus/protocol approach
(e.g. EtherCAT, Modbus TCP/RTU, etc.) with a defined command/status register map.

For safety, we fully agree with your description: E-stop, STO, door interlocks, and power isolation are all handled by dedicated hardwired safety hardware, independent of both PLC and LinuxCNC. Software only receives “safety OK / safety tripped” status and never has authority to energize the safety chain.

If you have examples of a minimal but robust command/status block that has worked well for you (which bits/words you expose, how you handle “busy/done/fault”, parameter latching, etc.), that would be extremely helpful.

Marcos DC wrote:

@NWE
Thanks for the explanation. In our case, the PLC cannot be a “drive-by-wire” remote control for LinuxCNC. The PLC must be the authority of machine state, sequencing, and safety, independent of the PC. LinuxCNC is treated as a subordinate motion controller, similar to how a PLC supervises an industrial robot controller.

That is the key architectural requirement we are trying to address.

I meant the other way around. PLC driving linuxcnc

Most PLC's and touchscreen HMIs do pretty much everything in their software. For workcell controllers intended for operator safety, you need a combination of hardwired safety controllers and power disconnects that can be locked. LinuxCNC has many available interfaces for communicating with PLCs. Ethercat, discrete I/O, analog, RS232, RS485, CAN, Modbus TCP, Modbus RTU. Probably more. Safety controlling is outside the domain of LinuxCNC.

On systems where the PLC/computer automatically start/stop 250HP machines or even 1/4HP machines, every machine on the premises has a dedicated power disconnect switch that can be locked. If that disconnect switch is on, the machine must be assumed to be running, whether or not it is making noise. Everything is prominently labeled with danger signs, reminding personel that the process equipment starts/stops automatically.

Plus we have the hard wired safety circuit that disables everything and only communicates to LinuxCNC that it has been disabled. LinuxCNC cannot activate this safety circuit. Not even an industrial PLC is qualified to run this safety circuit, only dedicated fail-safe safety controllers do that.

Jocman post=342013 userid=24026
As I've 2 lan cards (the onboard and a second PCI board), I tried to launch
ip a
when connected to both, and this is what I get:
connected to Mesa (onboard card):

joccnc@JocCnc:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
-- snip --
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e8:4e:06:84:dc:c9 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.11/8 brd 10.255.255.255 scope global eth0
-- snip --
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 70:85:c2:6a:f0:3d brd ff:ff:ff:ff:ff:ff
joccnc@JocCnc:~$

and pinging  my router:

joccnc@JocCnc:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sending packet: Network is unreachable



connected to WEB:

joccnc@JocCnc:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
-- snip --
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e8:4e:06:84:dc:c9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.245/24 brd 192.168.1.255 scope global dynamic eth0
-- snip --
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 70:85:c2:6a:f0:3d brd ff:ff:ff:ff:ff:ff
joccnc@JocCnc:~$

and pinging my router:

joccnc@JocCnc:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.651 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.488 ms

[\quote]

 

Going by your most recent answer I interpret the above:

It appears to me you have two network configurations "Web" and "Mesa 7i76e" In both configurations you appear to have the first network port selected. This means, when you click on the "Mesa 7i76e" network, the pc tries to connect to the Mesa card via the network port that is connected to your LAN.

To fix, right-click on the network icon, click "edit connections", click on "Mesa 7i76e", click on the little gear at bottom "edit the selected connection", click on the "Device" dropdown, and select the correct device, click on "IPv4 Settings" tab, make sure the "Gateway" field is empty. click "Save", close the network edit window, and try reconnecting to both networks. On my system, I have both networks connected at the same time.

Don't change settings for the "Web" connection, from what I see, that one is likely configured correctly.

Sounds like you forgot to enable ethercat service and it didn't start at boot.
Some 30 lines down in this post
forum.linuxcnc.org/ethercat/45336-etherc...step-by-step?start=0
tells you how to check status of the ethercat service and, if needed, enable it for automatic start at boot.

...when Beckhoff EK1100 is connected terminal give such information 

Hallo, a litle explanation and  update. Altough LCNC is starting but ethercat connection is not activated.Normaly when I work with Beckhoff EK1100 i see small icon ethercat up on the screen and also i can write terminal command Ethercat Slaves it showing me active participiants.
 
Also when I try   ...ip link set dev ... down / up   it doesnt work to.It looks like driver dont try to start at all when I try to connect oriental motor.
 
What can I do more ,how to test why eth driver dont start/trying to run.
Thanks.

Ich würde ja wirklich gerne auf mein eigenes Thema antworten, doch das Forum meint, es gäbe einen internen Fehler.  
 

Thank you for the reply.

Hi and so much thanks to the people made all the work with the linuxcnc for raspberry pi 5 ,its a great job.
I have downloaded 4.8.9 and it's a great distro working so fine from beguining and today after a week or two the program stop and freze after 5-10 min. I can still run the stepper from the keyboard and the speedometer on the spindle is i ok and run but the rest of the program stop . the only way to go on is a hard rebot and then it start fine and then the problem starts again . Are there people who can help me in the right direction 
I use the byte2bot board in Lathe config. /krister

Hi guys, 

Created this simple, but effective profile editor for myself. 
It is a lightweight Tk-based conversational editor for lathe profiles, designed for LinuxCNC / PathPilot style workflows.It lets you sketch, edit, and preview turning profiles interactively, then generates a G71 or G72 roughing cycle with a G70 finish pass. All core functionality uses only the Python standard library (Tk), so it can be dropped directly into a AXIS environment.Optional DXF / 3MF import is supported via external libraries.

For example you can: 
 

1. import an STL as a background reference
2. Auto create segment points or (recommended) tracing the rotational outline with profile points 
3. Adding chamfers and radii for finishing details
4. Adjusting geometry for optimal cutting
5. Setting machining parameters
6. Generating G-code
7. Sending to LinuxCNC/AXIS

 You can find it here:  Repository


 

I will add, though, that when I started using my ATC I mixed the old and new ways, and it was a disaster
 

I suspect ALL cnc's apply offsets the same way. And as long as the offsets add up to the right tool location, it doesn't matter if you change G54 or T1 when you manually change tools. If you're using a trim router with a collet and change tools all the time but never issue a T command, you just have to know how to change the G54 so that it does the right thing.

So external measurement, toolsetters, manual tool touch off, part touch off, they're all just ways of making those offsets add up to the right thing.