Host Engineering Forum

General Category => General Discussion => Topic started by: rawbutta on May 09, 2024, 10:25:10 PM

Title: Remote IO & Power Outages
Post by: rawbutta on May 09, 2024, 10:25:10 PM
Hi Everyone,

I've got a site with multiple BX-DMIO PLC's Peerlinking, and each PLC has at least 1 or more Ethernet Remote IO Controllers (BX-EBC's).

The main issue I'm having is when we have power outages (which has become a regular occurance of late), The network switch (Ubiquiti) seems to take longer to boot up and get going than the PLC's. So all the PLC's can't find their nodes and get upset.... as they should.

Is there a way to reset the PLC's back to 'RUN' mode automatically once the network is up and it can see the remote IO controllers?

Cheers
Title: Re: Remote IO & Power Outages
Post by: BobO on May 10, 2024, 03:21:58 PM
Hi Everyone,

I've got a site with multiple BX-DMIO PLC's Peerlinking, and each PLC has at least 1 or more Ethernet Remote IO Controllers (BX-EBC's).

The main issue I'm having is when we have power outages (which has become a regular occurance of late), The network switch (Ubiquiti) seems to take longer to boot up and get going than the PLC's. So all the PLC's can't find their nodes and get upset.... as they should.

Is there a way to reset the PLC's back to 'RUN' mode automatically once the network is up and it can see the remote IO controllers?

Cheers

No, sorry. There is a way to stay in run mode even during failure and a way to monitor the remotes health, so you could craft your logic to stay in a dormant state until all slaves reported in.
Title: Re: Remote IO & Power Outages
Post by: rawbutta on May 10, 2024, 03:41:22 PM
Any chance you would be able to give me some advice on how to "craft the logic" to do such a thing?  :)
Title: Re: Remote IO & Power Outages
Post by: BobO on May 10, 2024, 06:43:37 PM
Any chance you would be able to give me some advice on how to "craft the logic" to do such a thing?  :)

Kinda hard to say without seeing your program. The key thing is that $EthIOMaster.Error will be on any time there is an error in a remote I/O slave. When the error resolves, that bit will clear.

One way to handle this would be to drive all physical outputs into intermediate locations rather than drive the Ys directly. Use a MAPIO instruction to drive the physical I/O with the intermediate value. When there is an I/O error, disable the MAPIO instruction and use a second rung to drive your outputs off, essentially mimicing program mode. Indirection between the outputs the program drives and the physical I/O point also provides other benefits like allowing you to bypass a point, or easily move a point to a different physical location, or to easily force a point, so it's not a bad method to use regardless.

Another approach would be to use an ENDC (a conditional END) instruction at the top of each code block to easily bypass all logic that you don't want to run.

A complete implementation would probably use a combination of the two approaches.