Advanced Search

LinuxCNC does support index only homing and seems a
reasonable option on a linear scale with only one index at the end of motion.
 
You would need to guarantee that the axis was not past the index mark
when homing starts...

Looks like the recommended solution is to add physical homing switches.

The Ursviken press brake I'm working on has one index near top of travel for both left and right ram. Then it has a prox sensor near the bottom of travel, only reachable if the tooling is removed, with limited documentation. It appears these might be for bottom limits to avoid over-extending the hydraulic cylinders.

If I were to try homing to only the index signal... has anyone done this successfully? I searched around a bit and did not find much hope.

I'm thinking of maybe trying to add a home-switch-out-pin to each of the two encoders in the Mesa firmware, on index this pin would always go high during positive counting/ negative during negative counting.

Just bringing this up in case anyone has a better solution. I could always add more sensors/switches. I'd like to complete this retrofit without adding additional sensors to the various axis.

Yes that was what I meant. 
Tips is to check what ethercat master writes in the syslog.

I see in the last screenshot it mentions MDI and MDI-X.
Can it be the cable, straight or crossed?

Hello forum

I've set up a new control PC and switched to EtherCAT. I'm using Leadshine EL8 components. Everything works perfectly except for the missing Tool cone.

If I have no tools loaded, the tool cone is displayed correctly.
 

When I have loaded a tool, the tool cone is missing..
 

Despite reviewing the installation instructions multiple times, I cannot find the error. 

 

I try to install an old serial 3m touchscreen but the cursor jumps randomly and the calibrator gives false clicks and is impossible to calibrate. I tried this in a debian 12.
Any help would be appreciated.

Geht mir genauso.
Nur dass das Forum fast einen 1/2 Tag nicht erreichbar ist. Und das jeden tag

Hallo Hakan I supose that You are talking about this commands :sudo systemctl enable ethercat.service
sudo systemctl start ethercat.service
sudo systemctl status ethercat.service
sudo chmod 666 /dev/EtherCAT0
I try them before and also today but with no lack.
But I see that Oriental Motor unit catch a fault whenever I plug rj45 eth.
That situation never happen under twincat.
After summarize everything I wonder what do TwinCat that works properly .
I will try watch history fault in the driver ,maybe it can help.

Jocman wrote:

After restarting the system 5 times (yes, 5), finally linuxcnc "sees" the mesa card, and axys is revived.
 

That is a sure sign something is still not set correctly, it only requires reseting the network from the network manager by clicking on the icon and clicking on the active network from the list.
I set networks for Mesa at least once a week, and it never ever fails to work correctly, but that howto has to be followed to a tee, especially when using two or more network interfaces.

I decided to remove the PCI LAN card, leaving only the MB LAN card, then deleted all the connections and remade a new setup as suggested by tommylight.
After restarting the system 5 times (yes, 5), finally linuxcnc "sees" the mesa card, and axys is revived.
I'll do some test in the next days, and see what happen.
If needed, I could try to reinstall the PCI card and re-connect to my LAN.
 

Strange because in the attached parameter file the P3-18 is also set to 0x1000h.

Of course, the first thing I did was upload your *.par file to the servo. But there was a problem: the firmware versions didn't match. Your file was 01.645, and my drive was 01.644. ASDA software did the conversion, but the DI didn't work.

I found a solution: parameter P3-18 must be set to 0x1000, then the inputs start working from linuxcnc. This works for me, perhaps this will also help someone with the problem of non-functioning DI.

@NWE
Thanks for the clarification — that helps a lot, and I appreciate you explicitly calling out the difference in perspective.Your comments are very helpful in terms of transport robustness (discrete I/O vs EtherCAT vs Modbus), and that’s valuable input for narrowing down implementation options.Just to make sure the discussion is clear for readers: when we talk about a PLC supervising LinuxCNC, we’re referring to logical authority over machine state, sequencing, and operator workflow, rather than mastership of the physical communication layer.As you noted, with EtherCAT today LinuxCNC often ends up as the technical bus master, even in architectures where the PLC is the higher-level controller issuing commands and consuming status. These two roles tend to get conflated, but they’re separate concerns in industrial systems.Your insight on which transports have proven more or less fragile in practice is very useful, even though the PLC→LinuxCNC authority model itself is something we’ll have to implement largely on our side.

My system is running beautifully. My goal is to make "Running LinuxCNC on a Raspbery Pi5 using the Byte2Bot daughter board" simpler, more successful with fewer "Gotchas" than other options.

Marcos wrote:

@NWE
In your experience, when LinuxCNC is treated as a subordinate motion controller,
 
 

I can see potentially doing it this way, and I agree, for your use case, this must be necessary, however, I have not used LinuxCNC as subordinate to a PLC in any project. I have used LinuxCNC controlling 6 PLCs via mqtt messaging on a larger project. Above all that in the chain of command I have the safety system, and due to the nature of the system, we have one single discrete signal wired from an output in the safety system to an input on one of the PLC's, through which LinuxCNC reads whether the safety system has disabled the entire plant. During most abnormalities, the program running in LinuxCNC initiates a controlled shutdown of the plant. If the safety system has tripped, it is a foregone conclusion, the plant is already shut down.

Most of the machines on that project are interdependent in various ways, so we have not included the capability to disable part of the system while other parts are in operation, except for the fact that each machine has individual lockout switches. However, It is not possible to complete the automatic startup sequence programmed in LinuxCNC when the locked-out machine fails to start. It does have a service mode where the repair tech has start/stop control of each individual machine during down time.

I can see doing it the other way, where the PLC commands LinuxCNC, but I have not done it that way yet.

Marcos wrote:

@NWE
Following up on the interface question above:Given that LinuxCNC does not currently provide a standardized, PLC-facing external API, 

Sorry, I was misunderstanding you in this respect. I was on a different page, thinking low level I/O.