Marcos DC wrote:

This is similar to how many industrial robotic cells are structured, where a dedicated motion controller handles paths, and a PLC controls the cell logic and operator interaction.

So the question is not whether LinuxCNC can do everything, but how others have structured a clean responsibility boundary between a real PLC and LinuxCNC in production machines.

Any practical examples along those lines would be appreciated.

I think of this: LinuxCNC has capability to be operated by the user, entirely using keyboard+mouse+monitor, at opposite extreme it can have external I/O wired to physical buttons, switches and dials for operator control without any keyboard+mouse+monitor if you wish.

I'm thinking wire connections from your PLC I/O to LinuxCNC I/O to "drive by wire"? Cycle start, Feed hold, etc. maybe also jogging, whatever you need can be brought out on a wire and connected to your PLC.

The Fanuc 6-axis robot bag palletizer I've been reprogramming lately is connected to an Allen Bradley PLC via ethernet/IP. I have never heard the words "LinuxCNC" and "ethernet/IP" in the same sentence, but I've been meaning to explore the possibilities. I have about $1500 usd worth of new Beckhoff ethernet/IP remote I/O hardware on the shelf for nearly a year now, that I plan to connect with LinuxCNC. My big hurdle has been my nil experience with ethernet/IP. Now on this Fanuc I got an idea what ethernet/IP configuration looks like...

spumco wrote:

Admittedly, the Click PLCs are fairly 'low-end', so higher-end PLC's likely have more sophisticated onboard motion control features.

I've always had good results with AutomationDirect's Click PLC's. But I've been disappointed with the reliability of their Productivity 2000 and also their BRX models. Maybe it was just bad luck. I've finally retrofitted most of my higher end AutomationDirect PLC's but those Clicks sure don't seem to make much trouble. Still I don't care for ladder logic.

The very first project I sold containing a Productivity 2000 quit about a week after it was out the door. I tried reprogramming it, also tried updating its firmware, no go. I was able to read out some error logs. Automation tech support told me it is bricked, and that they have been having that trouble with that one firmware version. I have to return it for warranty. They gave me a choice of sending back the bricked plc then after they have it back, they send me a replacement. Or I can buy a new plc and they refund me when they get the broken one back. So I bought the new one and got the refund later because the customer was in a hurry. This was a $1200 USD PLC about 7yr. ago. (CPU + base + PSU + motion I/O) Even the base was bricked, that contained a CPLD on its motherboard.

Marcos DC wrote:

Just to be clear, in your setup you are using Beckhoff EtherCAT I/O as remote I/O, but without a Beckhoff PLC runtime (e.g. TwinCAT PLC), correct?

 

Yes, I'm using Beckhoff I/O strictly as remote I/O, all my logic exists in the pc running LinuxCNC

I've totally rewritten it anyway. I was able to move the state machine into a seperate procedure which has substantially streamlined the code. Now I just have to get it to compile image missing /media/kunena/emoticons/shocked.png

A lot of that does not need to be in the component because you are setting the pin externally. But we may need to scale or otherwise calculate data for them in which case they need to pass through the component. Get the basics first....

write all becomes something like  
homing feedback is in the read command

Thanks for the replies — I think it may help to clarify one architectural point.

We are not evaluating a PLC + LinuxCNC setup because LinuxCNC lacks sequencing, ladder logic, or HMI capabilities.
The decision is driven by industrial architecture requirements.

In our case, the PLC is not intended to replace motion control.
The process is trajectory/raster-based (laser cleaning and spray overlap), where motion quality, lookahead, and path execution are critical — this is why LinuxCNC remains responsible for motion.

The PLC acts as the machine controller:
• machine state and sequencing
• safety and interlocks
• operator workflow and recipes
• maintaining a safe and known state independently of the PC

This is similar to how many industrial robotic cells are structured, where a dedicated motion controller handles paths, and a PLC controls the cell logic and operator interaction.

So the question is not whether LinuxCNC can do everything, but how others have structured a clean responsibility boundary between a real PLC and LinuxCNC in production machines.

Any practical examples along those lines would be appreciated.

The current state focuses on contour machining and the related LinuxCNC cycles.Contour (CONTOUR) is defined purely as geometry (lines, chamfers, radii, inner/outer).
Different operations can then be derived from this geometry, independent of their order in the workflow.Currently implemented:

• Drilling using LinuxCNC cycles G81–G84 (including G82 with dwell, G83/G73 peck drilling, G84 tapping)
  • cycle-specific parameters are shown dynamically
  • internal correct switching to
    Code:

    G17
    , followed by
    Code:

    G80
    and back to
    Code:

    G18
• Roughing of contours
  • use of G71/G72 if the contour is monotonic
  • automatic fallback to move-based machining for non-suitable contours
• Finishing of the same contour as a separate step

All operations reference the same contour geometry but are processed as logically separate steps.G-code generation (current logic):

• Before every tool change, the machine always moves to a defined G53 tool change position
• Definition of an explicit safe area (
  Code:

  X_safe
  ,
  Code:

  Z_safe
  ) derived from stock geometry and retract planes
• After each cutting step:
  • retract in X first
  • then retract in Z (no combined retract moves)
• Approach from the safe area may be diagonal
• Coolant (
  Code:

  M7/M8/M9
  ) is set explicitly per operation
• Comments are sanitized (no nested parentheses)

The preview is directly based on the geometry:

• true arcs for radii
• separate visualization of contour, stock, toolpaths, retract planes, and safety limits
• visual highlighting when machining or safety limits are exceeded

A reworked README describes the current feature set, safety logic, and G-code strategies in detail.
Screenshots will follow in the next few days.
The current state will also be published on GitHub in the coming days.Additionally, a test file ( ) is attached, reflecting the current state of the generated G-code.

The RPi 5 + Mesa 7i96s is fantastic for LinuxCNC.

I haven't been on the Forum for ages but today I noticed that someone asked if I could post my RPi 5 ethernet settings on this thread.

I think they have been posted a few pages back by someone else, nevertheless the following wider context may be helpful.

As an aside, my RPi 5 and Mesa setup has worked perfectly since the ethernet issue (below) was fixed.

================================================================
The following is copied from another thread.
================================================================

I ran my RPi 5 and 7i96s overnight and completed 40 million pings with zero errors.

sudo chrt 99 ping -i .001 10.10.10.10 -c 40000000

At the same time in the background, I ran Latency Histogram and two Glxgears. I have attached photos in case anybody is interested in seeing the results.

I’m not sure what to make of the maximum ping time of just over 10 ms.

It seems that "hardware-irq-coalesce-rx-usecs 0" has fixed the issues I was having (aside from the 10 ms issue) at least on RPi 5 * GB with LinuxCNC 2.9.2.

======================================

What is this "coalesce" thing?

Interrupt coalesce settings ( access.redhat.com/documentation/en-us/re...ing_networking/index )

"By using interrupt coalescing, the system collects network packets and generates a single interrupt for multiple packets. This increases the amount of data sent to the kernel with one hardware interrupt, which reduces the interrupt load, and maximizes the throughput."

=====================================
My /etc/network/interfaces looks like this:
=====================================

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.10.10.11
hardware-irq-coalesce-rx-usecs 0

=========================== 

I understand that for Orient to work, you need two PIDs and a MUX to switch the PID output from Velocity to Position.
I think some of it works for instance the Spindle will fire up with and M3 command and in HalShow the MUX2 light goes from red to yellow, and back to RED with M5.
However M19 R90 registers in the pid.so.angle but doesn't move the spindle. 

Could another pair of eyes look at the attached please.
Thanks