Advanced Search

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 wrote:

Thanks for the detailed explanation — that is a very interesting architecture and I appreciate you taking the time to describe it.Thanks for the clarification regarding Beckhoff I/O. 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

Sorry i had no time to watch this, will do very soon.
Thank you.
OK, watched it, left a comment, nicely done and very detailed.

Magnificent or wunderbar in German, danke schon.
For context this is using a touchscreen to move the machine and watch the video from a camera, as MPG with vision.
Anyone have a better tittle, feel free to chime in, i feel this tittle does not do it justice.
Thank you.

Savaal teshekyr (if i recall correctly, been 30 years since i learned that).
One small complaint, turn the camera on it's side, it is hard to watch vertical video on a ultra wide monitor!

What pins are you monitoring?

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 

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

And here is the short video of the build process of that same PC above:

Sorry PCW, i keep advising boards that are usually in stock.
-
For this use case, Mesa 7i95T should also be considered as it is a step/dir board with encoders for all axis/joins, for if you ever want to also include LinuxCNC in the loop.

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.