[Agris]

Hi guys,

Please tell if anyone faced a problem, described here.

LinuxCNC 2.5 works with Mesa 7i76 +5i25 boards on a mill machine.
5i25 is powered by +5v from PC.
7i76 is powered by external +12v power source.

When I turn off power of 7i76 (by switching off a whole cabinet, or power failure, or short circut of 12v power source) - LinuxCNC shows error messages from HotMost2 driver that it lost connection to 7i76. That is expected behavior and is good - machine stops, you need to press F2 (or orange switch button on a panel) in LinuxCNC.

When power of 7i76 gets back I press F2 in LinuxCNC - it fires up, and I can move any axis or do any other things - i seems that LinuxCNC works well.

But it doesn't. When I hit any limit switch, or work with probe - no signals go in to LinuxCNC, This causes my machine to run beyond limits, with disaster happens every time (hard mechanical hits may destroy a whole machine!)

The only way to get limit switches back - restart LinuxCNC (what is not an option).


Did anyone see such behavior? Any clues to get LinuxCNC work as it should?

Thanks in advance,
Alexander

[PCW_MESA]

Hi guys,

Please tell if anyone faced a problem, described here.

LinuxCNC 2.5 works with Mesa 7i76 +5i25 boards on a mill machine.
5i25 is powered by +5v from PC.
7i76 is powered by external +12v power source.

When I turn off power of 7i76 (by switching off a whole cabinet, or power failure, or short circut of 12v power source) - LinuxCNC shows error messages from HotMost2 driver that it lost connection to 7i76. That is expected behavior and is good - machine stops, you need to press F2 (or orange switch button on a panel) in LinuxCNC.

When power of 7i76 gets back I press F2 in LinuxCNC - it fires up, and I can move any axis or do any other things - i seems that LinuxCNC works well.

But it doesn't. When I hit any limit switch, or work with probe - no signals go in to LinuxCNC, This causes my machine to run beyond limits, with disaster happens every time (hard mechanical hits may destroy a whole machine!)

The only way to get limit switches back - restart LinuxCNC (what is not an option).


Did anyone see such behavior? Any clues to get LinuxCNC work as it should?

Thanks in advance,
Alexander

This is because of a sserial driver error handling issue

Until this is fixed here are some Workarounds:

1. For safety, make sure motion is enabled by a 7I76 output
how is motion enabled?

2. if you want to recover from power faults without restarting linuxcnc, you can net the sserial run state pin
to machine-on

[Agris]

Dear PCW_MESA,

Thanks for reply!

This issue is common, and I'm not the one facing it, right?

Until this is fixed...

Fixed by who? Mesa deveplopers or LinuxCNC team? Anyway, this gonna happen sometime in future, nobody knows when I suppose...

1. For safety, make sure motion is enabled by a 7I76 output how is motion enabled?

I don't get you, please explain a bit more.

2. if you want to recover from power faults without restarting linuxcnc, you can net the sserial run state pin to machine-on

What pin exactly? I've checked values of pins related to sserial (hm2_5i25.0.sserial) but they stay unchanged after power failure (except hm2_5i25.0.sserial.portr-0.fault-count changes value to somewhat)
Since they stay unchanged, I can't way to "restart" sserial with something like "setp ******* true"

Best regards,
Alexander

[PCW_MESA]

Dear PCW_MESA,

Thanks for reply!

This issue is common, and I'm not the one facing it, right?


Fixed by who? Mesa deveplopers or LinuxCNC team? Anyway, this gonna happen sometime in future, nobody knows when I suppose...


I don't get you, please explain a bit more.


What pin exactly? I've checked values of pins related to sserial (hm2_5i25.0.sserial) but they stay unchanged after power failure (except hm2_5i25.0.sserial.portr-0.fault-count changes value to somewhat)
Since they stay unchanged, I can't way to "restart" sserial with something like "setp ******* true"

Best regards,
Alexander

The issue is not common (this is the first time I have heard of an actual issue)

One reason its not common is that its standard to have drive systems of any significant size to be enabled
by secondary signal. In a 7I76 system this normally would come from a 7I76 output. In this case losing remote
communications would disable motion (as the output will be disabled when communication is lost),
and motion can not be re-enabled until communication is re-established (restoring the input status as well)

Another reason its not common is that losing power to a part of your I/O system is a pretty serious fault
and its really not too unreasonable to have to restart linuxcnc in this case (though this can be avoided as I mentioned)

If you want to restart serial communications after a serious fault, the pin you need to manipulate is the sserial run pin
by setting it false and then setting it true again. one way of accomplishing this is netting it to machine-on.

[Agris]

Dear PCW_MESA

You are fully right - it's a serious fault on a machine, and "partitial" restart of it can cause some unpredictable results.

I've checked your solution - writing 0 to hm2_5i25.0.sserial.portr-0.run and then writing 1 to it - and it worked!
Nice and elegant, thanks!

One reason its not common is that its standard to have drive systems of any significant size to be enabled
by secondary signal. In a 7I76 system this normally would come from a 7I76 output. In this case losing remote
communications would disable motion (as the output will be disabled when communication is lost),
and motion can not be re-enabled until communication is re-established (restoring the input status as well)

Well, again right words. But, LinuxCNC doesn't know when 7i76 loose power. I mean, you need to configure LinuxCNC to stop after such faults, and do some special things to restart - now it just can be switched again - and seem working.

I suggest (to me, first of all) to implement some "powering up" routine, which (among several checks) restarts sserial interface.

Let me thank you again - problem solved and lesson learned.

Best regards,
Alexander.