Advanced Search

UART and Smart-Serial are different. If it says "ua" rather than "ss" in the filename then they are standard UARTS.

try again, found a bug

and now you can try to set the Error_Values to
6 0 112 0 0

this should switch all outputs to off on connection errors (PC<->FPGA)

doh.. yeah, that can happen...

I just pushed some changes that allow sequential loading correctly that captures hal loading for all ui's at startup for registration. this should allow the use of hal widgets in all user ui files. should be up and live by 8am EST.

ok, i have order one, than i can fix and test it the right way
maybe next monday

@meister I tested your last dev commit, and the N4D3E16 template only works with the outputs; the inputs don't work.
Thank you so much for your work!

Billy wrote:

The issue is that my ESTOP-out is no-longer tracking either the GUI ESTOP or the hardware ESTOP-in.  It just stays asserted all the time with no change of state.
 

I don't have a 7i96s, but out of curiosity I checked it on my 7i92...

You can make two types of mistakes:
1. Electric.
2. Logical.
It looks like you did both.
First, about the electric one. It is true that there are inputs that detect all possible states (high, low and high impedance), but I have only seen such inputs in logic states analyzers. Typically, the input detects only one state or no this state. For example, shorting the input to ground causes the output to change to the opposite state, but it does not matter whether we short the input to Vcc or leave it unconnected anywhere. In this case, if the output of the previous gate is high, closing or opening the serial switch does not change anything because the high state and the high impedance state are interpreted the same.
Now about the logical one. By pressing the serial switch we do not change the input state, we only cut off the signal. And this is not the same as what I explained above.

Your configuration either doesn't work at all, or works in such a way that it cuts off the iocontrol.0.user-enable-out signal. This means that the serial switch does not turn off the machine, it only prevents it from being turned on/off via an icon in the GUI, which is definitely not what you wanted.

Can this be fixed?
Probably yes, but it makes no sense because you have a ready-made and 100% reliable solution - the estop-latch component. A switch between the input and ground is connected there, so that each time it is switched, the input status changes.

This is from my config:
And now a few words about the emergency stop switch. As the name suggests, it is used in an emergency situation when we want to stop the machine immediately to prevent it from causing damage.
Sometimes the emergency switch must also disconnect or enable something (for example, turn off the motors and apply the brakes), so simply connecting it to the control program may be insufficient or unreliable (the program may hang or respond with a delay).
You have to remember this, and the bigger the machine, the more seriously that should be treated...

Rod, I agree with Tommy, the Linuxcnc E-stop Latch component isn't necessary for estop compliance. Linuxcnc doesn't even need to know about the hard E-stop loop for a machine to be compliant. The soft E-stops in Linuxcnc really have nothing to do with it, and shouldn't (I'm not even sure that it even can) be counted on if you want a compliant E-stop system. It is how the hard E-stop is implemented that makes a machine's E-stop system compliant.

Add W5500 spi Ethernet, and setting up main Ethernet port to ethercat master and connect to linuxcnc-ethercat

In Portugal in stock, prices should be without VAT, but do check that.
eusurplus.com/index.php?route=product/pr...ct_id=51&search=7i77
Welectron in Germany does not have any in stock, nor 7i97/T, nor a complete combo of 7i96S/7i85/7i83

Hi,

If anyone over this side of the pond wants to sell one of these please let me know. I am collecting parts for a passible project.
Thanks,

John

I’m attaching the files.

GennadijSpb wrote:

... but if you also move the X axis, the machine goes into error mode due to exceeding the Z limit.

That does not seem right, and may be caused by errors in the hal/ini files, so upload the config files here.

rodw wrote:

I'm sorry Tommy, but none of those 20 machines you retrofitted are compliant in today's safety concious world.

Oh hell....
YES, they are Rod, and you know that for sure as you have read everything i did here, but still you have to protect your convoluted ways by demeaning me and my work.
Yet, you did not read what STO actually does and the explicit warnings that go with it.
-
Rod, i will not continue this discussion any further, please refrain from tainting topics and only reply with actual helpful posts, as you often and for a long time did. Thank you.

It wasn’t fully fixed, but there’s some progress. Now the machine finds metal and passes the test normally in the home position and if you only move the Y axis, but if you also move the X axis, the machine goes into error mode due to exceeding the Z limit. What information should be attached? I have a PC with an AMD Athlon 3000G, 8 GB of RAM, an LPT‑PCI‑e board, and an LPT‑mach3 board; it’s powered via USB from the same PC and from an external 24 V power supply. All the sensors are inductive, except for the metal detection sensor; there, an NPN inductive sensor is used, which activates a relay, and the signal is then sent to the board via the relay. The metal detection sensor does not touch the metal directly; it is mounted on a movable, spring‑loaded plastic platform, and when it shifts, the sensor is triggered.

Actually, to be compliant for safety, a machine cannot depend on LinuxCNC to manage the estop. The compliant external safety circuit should be advising LinuxCNC when the an environment is safe via the iocontrol pins. That's how I have set up my last few machines.

And yes, your 15 tonne machine is a perfect case to adopt modern hardware. The servo drive needs to have a Safe Torque Off  (STO) input triggered by the redundant safety circuit so the servos are safely brought to a halt. In an ethercat environment, there is specific modules to manage this. To your Beckhoff EK1100 coupler you need to add a EL6900 safety PLC and a EL1904 that contains 4 compliant safe inputs. In the absence of STO, You can place two force guided relays in series to trigger the normal servo enable/disable. Siemens make  a 5 pole force guided relay and two of these would allow compliant shutdown of 5 servos (4 axis plus spindle) But you  would also need 2 more single pole force guided relays to fire the signal back to LinuxCNC's iocontrol to tell the controller an estop situation existed.

I'm sorry Tommy, but none of those 20 machines you retrofitted are compliant in today's safety concious world.