USC estop chain problem

Hi,

I started setting up a PyVCP and wanted to display the estop chain status from my Pico Systems USC. I found a message online somewhere that I can't actually read Input15 and that a solution was to connect the chain to both inputs 15 and 14 and just read off input 14. I did this but then all sorts of problems happened and now I'm trying to figure out what I've done/messed up. I don't want to waste everyone's time because I may have now caused a wiring problem but here's the issue I ran into:

Basically the machine won't come out of estop with the fault chain connected to more than one input (15 + 14, also tried 12 or 13). The estop led on the USC is green and during the testing when I would press F1 the Relay8 light on the USC would flash. With only Input15 connected I can power up and jog the machine.

When my machine comes out of estop a signal from Relay 8 goes to a second box ("aux box") that will turn on my motor power supply which closes a relay sending a signal to the USC ("ps on" - input 13). The motor power supply can take a few seconds to power off and release the signal because of the large caps. During this time I couldn't come out of estop until the "ps on" signal is released. So the fault chain is ok and In14 and In15 are true, I'd press F1, R8 would briefly go on but enough to cause my motor ps to come on, Input13 ("ps on") would become true but the system is now in estop, I can't press F1 to repeat until the ps "times out" and Input13 goes false.

I tried disconnecting the "ps on" Input 13 but at some point during all this testing I burned out a relay in the aux box so my problems have spread out. I mention all this in case it turns out to be something I've done with my wiring or PyVCP config. Still, even now as long as I have the fault chain only connected to Input 15 things seem to work including the PyVCP and the "ps on" input.

thanks,
John

johntrevick wrote:

Hi,

I started setting up a PyVCP and wanted to display the estop chain status from my Pico Systems USC. I found a message online somewhere that I can't actually read Input15 and that a solution was to connect the chain to both inputs 15 and 14 and just read off input 14. I did this but then all sorts of problems happened and now I'm trying to figure out what I've done/messed up. I don't want to waste everyone's time because I may have now caused a wiring problem but here's the issue I ran into:

Basically the machine won't come out of estop with the fault chain connected to more than one input (15 + 14, also tried 12 or 13). The estop led on the USC is green and during the testing when I would press F1 the Relay8 light on the USC would flash. With only Input15 connected I can power up and jog the machine.

Hmm, that's very odd, as we used to do this all the time in the EMC(1) days. Maybe there is
too much resistance in your E-stop chain to supply sufficient current to two inputs.
You might measure the voltage between EG and 15 when it is working OK, and then
when it is not (with input 14 also connected). When the estop chain is closed, there should
be nearly zero volts across the chain. If the voltage is significantly more, then
that indicates the resistance may be too high. It is possible the logic thresholds of
the FPGA and the CMOS gate that drives the green LED are different enough that
the LED lights but the FPGA is not considering it as the "OK" signal.

One way to be sure is to connect inputs 14 and 15 with a wire to EG and see if you can
come out of estop that way.

Also, the chain of logic in univstep_io.hal that handles the E-stop functions is very
tricky, depending on the delay between writing the "come out of estop" command on
one invocation of the servo thread, and the reading of the status of estop on
the next invocation. This allows the USC to come out of estop if all the conditions
are OK, and then LinuxCNC sees it as "out of estop" next time it checks. This
tricky scheme requires that the logic in that file, and the scheduling of
those HAL functions in the file univstep_load.hal not be changed. So, if you
have changed the logic there or altered the order of addf's in univstep_load.hal,
that could be causing the problem.

But, back to the first point, indeed you CANNOT read the status of input 15, what
you read instead is the condition of the E-stop FF on the USC. If the command
to come out of estop is successful, then the next time you read the estop
registers, you will see input 15 is true, and it will stay that way until some
event causes it to go false. That could be a disconnection of input 15,
a timeout of the watchdog, a command from the PC to go to estop, or
a power-on reset of the USC.

Jon

Thanks Jon, I will do some testing tonight and report back.

I didn't modify the estop code in univstep_io.hal at all and I did try at one point to remove my pyvcp hal code (there are no name conflicts that I saw).

Ok, did some testing and it appears that my fault chain was too long. I've now reduced it down to just the big red estop button and things are working again. I'll reroute the non essential elements (motor overheated, AC power fail from UPS) to separate inputs. Down the road when I get wiring done I'll figure out how to use the signal to trigger an estop.

thanks for the help,
-John