News:

  • October 02, 2026, 04:20:24 PM

Login with username, password and session length

Author Topic: Multiple Remote I/O's  (Read 35244 times)

EDurako

  • Sr. Member
  • ****
  • Posts: 52
Multiple Remote I/O's
« on: July 31, 2019, 11:27:27 AM »
Hi everybody! I'm still working through the power failure modes of a new installation.

I'm working on a Master to 3 Slave units setup. Master is BX-DM1E-M and each Slave will be a BX-DMIO-M-D.

I know there is a "Slave must be online to enter RUN mode" option when setting up the ethernet Master/Slave relationship.

My question is in regards to multiple Slaves in different areas of the plant.

For example, lets say the Slaves are all controlling utilities that are sensitive to massive current inrushes. There is a timer in the Master logic to stage the utilities turning on out over several seconds. If the power grid goes down and comes back up, I am assuming that all Slave units will have to boot up before the Master will enter Run mode. But, if one Slave unit happened to get fried during the power outage, I still need the others to execute the Master's logic (better to loose a section of the plant than the whole thing).

I have played with the idea of locally connecting an Output directly to an Input but this is 2019 and that seems like a waste of I/O.

Maybe I have overlooked a group of system bits that specifically address each Remote I/O's Run/Error status?

Is there a way to tie individual programs in the Master to each Slave?

I'll gladly expand more if there are questions.


EDurako

  • Sr. Member
  • ****
  • Posts: 52
Re: Multiple Remote I/O's
« Reply #1 on: July 31, 2019, 11:36:21 AM »
AAAAAAANNNNNNDDDDD>>>>>>

I found the I/O Error section in the help file. So again, this forum has allowed me to look silly. I'm assuming I can do a compare between $EthIOMaster.Slave0Error and the number 0 to allow each utility timer in each program to advance or stay stationary until the slave is online.

I would have to disable the "Slave must be online to enter RUN mode" option for each Slave but this would still work?

RBPLC

  • Hero Member
  • *****
  • Posts: 586
Re: Multiple Remote I/O's
« Reply #2 on: July 31, 2019, 12:36:41 PM »
Yes. What you are saying will work. If you look in the section of documentation that contains the $EthIOMaster.Slave0Error instruction, there are a whole host of other status bits that indicate faults on the slave or on modules of the slave. You can use any of these bits in your programming to stage the machine in whatever manner is necessary. You are correct about the "Slave must be online to enter run mode". If this is enabled the Master will not run if a particular slave is not communicating with the Master which would not allow operation of any section of the machine. 

I was recently working through a similar problem and I would recommend that you add some form of power status monitoring to indicate whether power is actually present at the section of the machine of interest if that same power is powering the remote slave. In my case I was working with 8 remote slaves installed on different sections of the machine. Each of these sections had their own power supplied through disconnect at these locations. In my case I needed to ensure that if the section of machine had power (which was also powering the remote slave) and if I lost communication to the slave, then the machine needed to shut down. I also had the scenario where sometimes these sections of the machine would be disconnected from power to perform maintenance, repair etc. If these were intentionally disconnected then there is not necessarily a problem and the rest of the machine can continue running. However, this would generate the same communication errors with the slave because it is no longer powered. One solution to cover this scenario (what I did) is I have a hardwired relay (aux relay would work as well) back to the master indicating power to the section of machine. I can then use logic bits to say that if I have power to the section of machine and get a communication fault then shut the entire machine down. Otherwise, if I get a communication error and there is no power to that section of machine then the rest of the machine can continue to run without switching the master to stop. This was specific to my machine but is something to think about.   

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3847
    • Host Engineering
Re: Multiple Remote I/O's
« Reply #3 on: July 31, 2019, 12:50:26 PM »
One solution to cover this scenario (what I did) is I have a hardwired relay (aux relay would work as well) back to the master indicating power to the section of machine. I can then use logic bits to say that if I have power to the section of machine and get a communication fault then shut the entire machine down. Otherwise, if I get a communication error and there is no power to that section of machine then the rest of the machine can continue to run without switching the master to stop. This was specific to my machine but is something to think about.

GREAT idea!

EDurako

  • Sr. Member
  • ****
  • Posts: 52
Re: Multiple Remote I/O's
« Reply #4 on: July 31, 2019, 01:27:02 PM »
Two thumbs up!

EDurako

  • Sr. Member
  • ****
  • Posts: 52
Re: Multiple Remote I/O's
« Reply #5 on: July 31, 2019, 02:13:52 PM »
What is the startup timeout value?

I keep getting error code 4 when attempting to boot the slave 30 seconds after the master is booted and running.

I have the slave setting as pictured below (10000ms timeout 6 retries)

Any ideas?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6176
  • Yes Pinky, Do-more will control the world!
Re: Multiple Remote I/O's
« Reply #6 on: July 31, 2019, 03:21:26 PM »
What is the startup timeout value?

I keep getting error code 4 when attempting to boot the slave 30 seconds after the master is booted and running.

I have the slave setting as pictured below (10000ms timeout 6 retries)

Any ideas?

If memory serves, it's 15 seconds.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

EDurako

  • Sr. Member
  • ****
  • Posts: 52
Re: Multiple Remote I/O's
« Reply #7 on: July 31, 2019, 03:22:51 PM »

If memory serves, it's 15 seconds.

Can I configure that? Why would it be different than the values I have typed in?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6176
  • Yes Pinky, Do-more will control the world!
Re: Multiple Remote I/O's
« Reply #8 on: July 31, 2019, 03:28:04 PM »
Can I configure that? Why would it be different than the values I have typed in?

You are setting an individual slave's timeout. The 15 second timeout is how long the PLC will wait for a stable I/O system on the initial trip to RUN mode. The trade-off is that the PLC is completely unresponsive while we are waiting. It is not configurable.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

RBPLC

  • Hero Member
  • *****
  • Posts: 586
Re: Multiple Remote I/O's
« Reply #9 on: July 31, 2019, 03:36:21 PM »
Not to confuse the issue and I'm not entirely sure what you're doing (I don't understand what you're attempting to do with the TMR with a Preset of 0s) but...

1) Error code 4 (from documentation) indicates slave timeout. This implies that your master cannot establish communication with your slave within the given time you've specified.

2) Your settings indicate that after a period of approximately 1 minute (there is an equation in documentation that specifies the exact timing), if your master doesn't see your slave then it will return a timeout error. This is obtained (again approximately) by multiplying 10000ms * 6 = 60 seconds before timeout.

3) I would say your problem is that your master can't see your slave. This could be for a number of reasons. You'll need to check that your master and slave are on the same subdomain and that your switch/router can properly route to those addresses. For diagnostic purposes I recommend plugging the master and slave into an unmanaged switch and seeing if they can communicate with one another.

EDurako

  • Sr. Member
  • ****
  • Posts: 52
Re: Multiple Remote I/O's
« Reply #10 on: July 31, 2019, 04:20:33 PM »

You are setting an individual slave's timeout. The 15 second timeout is how long the PLC will wait for a stable I/O system on the initial trip to RUN mode. The trade-off is that the PLC is completely unresponsive while we are waiting. It is not configurable.

BobO, is this an error that can be reset? Would the attached picture logic provide a 75 second boot window?


RBPLC, not all timers are used to output bits based on preset conditions, in this logic, I have multiple different processes that are actuated by comparing a value/calculated value to T1.Acc which starts at the beginning of each scheduled work day. The basic TMR is easily set/reset and I can get by using 1 timer instead of 5 by comparing to the elapsed time in this manner.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6176
  • Yes Pinky, Do-more will control the world!
Re: Multiple Remote I/O's
« Reply #11 on: July 31, 2019, 04:29:32 PM »
BobO, is this an error that can be reset? Would the attached picture logic provide a 75 second boot window?

The 15 second wait time has nothing to do with individual slaves, it is simply the fixed period of time the PLC OS spins waiting for the Ethernet master to get all slaves online before it quits waiting and moves on. If you mark slaves as optional it won't prevent it from going to RUN mode, but it will still wait up to 15 seconds.

If slaves are marked as optional they will eventually mount without any program intervention.

Individual slave status is available from the program, so if a slave is critical at certain points but doesn't have to be there at others and is marked optional, you can write logic to deal with that however you like, including generating a fatal error and stopping the PLC.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

RBPLC

  • Hero Member
  • *****
  • Posts: 586
Re: Multiple Remote I/O's
« Reply #12 on: July 31, 2019, 04:48:14 PM »
Understand concerning the TMR instruction (seems like a good approach to deal with different events at different times based on the same input).

I think two different conversations are happening. One is in regard to how "slave finding" is handled during initial start-up, the other is in regard to loss of communication to slaves.

Have you confirmed that you can communicate from the master to the slave?

EDurako

  • Sr. Member
  • ****
  • Posts: 52
Re: Multiple Remote I/O's
« Reply #13 on: July 31, 2019, 05:04:00 PM »
Understand concerning the TMR instruction (seems like a good approach to deal with different events at different times based on the same input).

I think two different conversations are happening. One is in regard to how "slave finding" is handled during initial start-up, the other is in regard to loss of communication to slaves.

Have you confirmed that you can communicate from the master to the slave?

There are two different conversations happening. I have a functioning Master/slave network that is up and running. I am now trying to debug scenerios that might occur after a power failure to plant in the middle of the day.

EDurako

  • Sr. Member
  • ****
  • Posts: 52
Re: Multiple Remote I/O's
« Reply #14 on: July 31, 2019, 05:06:20 PM »

The 15 second wait time has nothing to do with individual slaves, it is simply the fixed period of time the PLC OS spins waiting for the Ethernet master to get all slaves online before it quits waiting and moves on. If you mark slaves as optional it won't prevent it from going to RUN mode, but it will still wait up to 15 seconds.

If slaves are marked as optional they will eventually mount without any program intervention.

Individual slave status is available from the program, so if a slave is critical at certain points but doesn't have to be there at others and is marked optional, you can write logic to deal with that however you like, including generating a fatal error and stopping the PLC.

I may have to disagree with you! Ohno!?!?!?   ;D

So I have my "Slave must be online to enter RUN mode" box unchecked......which makes it optional? and several minutes later I still showed an error code #4 "TIMEOUT" and my slave was not responding to the Master. Is there more action required on my end to make a slave optional?

I also just ran the logic pictured below (specifically rung 5 disregard the CT0.Acc<=5) and it did not reset the error code #4. Should it?

Are they any programming examples out there of which bits are used to make a Slave critical in certain parts of the code? I'm assuming its all based on the $IOError/$EthMasterError/$EthIOMaster.Slave(x)Error status's and comparison bits?

I really wish I wasn't 7 hours away from this installation. I also really wish the network drop was installed so I could test on it more than 3 times a day.

Thanks for helping me by the way