Advanced Search

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

    G17

    , followed by

    G80

    and back to

    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 (

  X_safe

  ,

  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 (

  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

 

This toolpath is at centerpoint, so don't forget cuttercompensation. If G41/ / G42 makes trouble, whats not unusual, it can be solved like that. Parameter #5410 is tooldiameter of loaded tool. 
 

Yes, helix milling was the end goal. But I was trying to build the program as simple as possible to start with, because I have little experience with anything else than G0/G1. But I got stuck because the preview did not show what I expected for an in-plane (XY) circle.

Thank you for the explanation and test you provided!

Cam -> Raspberry PI3 -> 7Inch Touchscreen -> TCP -> WIFI -> LinuxCNC

www.youtube.com/shorts/sAEmJ-vLgHY
 

The output of the command "lcec_configgen" is usually a good starting point.

Just in case you want helix milling, you need to set z value for start and end. P is the amount of turns, if z-10 P5, it could look like that, pitch 2


 


 

The complete code was visible in the screenshot, but for clarity I include it here:
I made a new test with the code you used, and for that the preview is working properly. But if I comment out the G0 move, then the preview is again strange. See the two situations below.
 
 

The complete code, with G0 commented out is below:
Maybe this is expected behavior? It certainly wasn't what I expected, but that doesn't mean much. I use LinuxCNC 2.9.2 by the way.

Thank you for having a look. With that the issue is now pinpointed.

I am pretty sure I didn't make any changes to the .coreDC file.  What troubles are you running into? Ill post it anyway in case I did.

For step/dir, Mesa 7i96S is the right choice, and if you do need more IO add Mesa 7i84 with 32 inputs and 16 outputs and wires to 7i96S with a simple cut down LAN cable.

If need more I/O than a 7I96S can provide, a 7I76EU is a one card solution (basically a 7I96S+7I84U on one card)

I would like the same functionality.
I would like the setup page in gmoccapy to toggle the execution of MDI commands either by enter key, double click, button (like now) or by HAL signal.
But I did not have time yet.

This functionality cannot be simply implemented using the HAL pin in HALUI, because the EMC_MDIHistory widget is in Gmoccapy. So a new gmoccapy HAL pin should be created.

EMC_MDIHistory widget is here:
github.com/LinuxCNC/linuxcnc/blob/master...cp/hal_mdihistory.py

The function to confirm the command is here:
github.com/LinuxCNC/linuxcnc/blob/bf71ba...history.py#L151-L200

In gmoccapy.py:
github.com/LinuxCNC/linuxcnc/blob/bf71ba...py/gmoccapy.py#L3444

You can create new HAL pin in Gmoccapy for self.widgets.hal_mdihistory.submit()
linuxcnc.org/docs/devel/html/config/python-hal-interface.html

FWIW, I thought is was nice that pins are named stat_* in Donomik's version.

My mind was into naming pins after the mode they are used in. Problem being there are overlaps.
For example there are many velocities: Homing velocity fast, homing velocity slow, PV velocity,
CSP velocity, CSV velocity, PP velocity, all using different PDOs, except CSP and CSV velocity which is the same PDO.
I would guess also Probe velocity, probably several versions.

On the other hand, it would be a bit convoluted for the user to use .csp-commanded-velocity when they already selected csp mode and see it as natural to use .commanded-velocity.