Host Engineering Forum

General Category => Do-more CPUs and Do-more Designer Software => Topic started by: EDurako on July 31, 2019, 11:27:27 AM

Title: Multiple Remote I/O's
Post by: EDurako 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.

Title: Re: Multiple Remote I/O's
Post by: EDurako 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?
Title: Re: Multiple Remote I/O's
Post by: RBPLC 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.   
Title: Re: Multiple Remote I/O's
Post by: franji1 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!
Title: Re: Multiple Remote I/O's
Post by: EDurako on July 31, 2019, 01:27:02 PM
Two thumbs up!
Title: Re: Multiple Remote I/O's
Post by: EDurako 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?
Title: Re: Multiple Remote I/O's
Post by: BobO 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.
Title: Re: Multiple Remote I/O's
Post by: EDurako 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?
Title: Re: Multiple Remote I/O's
Post by: BobO 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.
Title: Re: Multiple Remote I/O's
Post by: RBPLC 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.
Title: Re: Multiple Remote I/O's
Post by: EDurako 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.
Title: Re: Multiple Remote I/O's
Post by: BobO 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.
Title: Re: Multiple Remote I/O's
Post by: RBPLC 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?
Title: Re: Multiple Remote I/O's
Post by: EDurako 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.
Title: Re: Multiple Remote I/O's
Post by: EDurako 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
Title: Re: Multiple Remote I/O's
Post by: BobO on July 31, 2019, 05:53:05 PM
Did it go to Run mode? Then it worked...otherwise it wouldn't have. The master continues to report errors as long as the slave doesn't talk. It scans at a significantly reduced rate while failed.
Title: Re: Multiple Remote I/O's
Post by: RBPLC on August 01, 2019, 12:08:28 AM
I've attached the section from the user manual indicating how slave errors can be cleared (or this is how I read this section of the manual). Unfortunately I cannot get errors to clear by the method shown in the user manual. It would be nice for someone from Host to verify that this is functioning correctly. In my case (as in yours) I tried to clear the #4 communication error by the method shown in the user manual and cannot get the command to reset the $EthIOMaster.Slave0Error from 4 to 0.

What does seem to work is what I have shown in the second attachment on line 11. A move command can be issued to change the $EthIOMaster.Slave0Error from a 4 to a 0 as shown. As for your case, your line 5 is not correct. It is saying in the event of a communication fault (#4 error) clear the communication fault. Logically this doesn't make sense, you can't clear the error while there is an error. What I've shown in line 11 does seem to clear the fault as long as there currently is no fault. In the event that you try to clear the fault using this method and there is still a fault, the fault status will change briefly to 0 and then will time out and set $EthIOMaster.Slave0Error back to 4.

If you use the method I've shown on line 11 and the $EthIOMaster.Slave0Error goes back to 4 then there is some type of communication issue between the master and slave that is causing the slave to timeout. This will have to be resolved before you can reset it.

Concerning the issue of another setting that you need to change for the slave, I don't think there is one. I think the problem is that there is an unresolved communication issue between the master and the slave.
Title: Re: Multiple Remote I/O's
Post by: BobO on August 01, 2019, 12:39:44 AM
I need to confirm, but I think .ResetSlaveStatus is to clear I/O warnings and errors in the slave itself...stuff like module failures and broken transmitters in the slave, not comm to the slave. The slave comm error states in the master will automatically clear when the slave starts talking. There isn?t anything required to fix comm errors.
Title: Re: Multiple Remote I/O's
Post by: EDurako on August 01, 2019, 09:05:40 AM
I need to confirm, but I think .ResetSlaveStatus is to clear I/O warnings and errors in the slave itself...stuff like module failures and broken transmitters in the slave, not comm to the slave. The slave comm error states in the master will automatically clear when the slave starts talking. There isn?t anything required to fix comm errors.

Thanks for checking BobO, I patiently await your reply, I have also had no luck just as RBPLC expressed.
Title: Re: Multiple Remote I/O's
Post by: BobO on August 01, 2019, 09:44:32 AM
Thanks for checking BobO, I patiently await your reply, I have also had no luck just as RBPLC expressed.

As I remembered, that triggers a command to the slaves to clear relevant module status. It has nothing to do with clearing errors relating to communicating with the slaves.

I came in to the conversation late, so what exactly isn't working as you expect?
Title: Re: Multiple Remote I/O's
Post by: RBPLC on August 01, 2019, 10:39:07 AM
I need to confirm, but I think .ResetSlaveStatus is to clear I/O warnings and errors in the slave itself...stuff like module failures and broken transmitters in the slave, not comm to the slave. The slave comm error states in the master will automatically clear when the slave starts talking. There isn?t anything required to fix comm errors.

I think part of the confusion (for me anyway) was that when I read the documentation about how to reset errors using the .ResetSlaveStatus method, I was under the impression that it would also reset the $EthIOMaster.Slave0Error error as well. You're indicating that .ResetSlaveStatus is to clear other types of errors and not those associated with comms issues. If $EthIOMaster.Slave0Error is not cleared by using .ResetSlaveStatus  (at least not in the case of a #4 timeout error) what is the preferred method for clearing this error through logic? Is it by moving a 0 to $EthIOMaster.Slave0Error as I had shown in a prior post?
Title: Re: Multiple Remote I/O's
Post by: BobO on August 01, 2019, 10:43:45 AM
I think part of the confusion (for me anyway) was that when I read the documentation about how to reset errors using the .ResetSlaveStatus method, I was under the impression that it would also reset the $EthIOMaster.Slave0Error error as well. You're indicating that .ResetSlaveStatus is to clear other types of errors and not those associated with comms issues. If $EthIOMaster.Slave0Error is not cleared by using .ResetSlaveStatus  (at least not in the case of a #4 timeout error) what is the preferred method for clearing this error through logic? Is it by moving a 0 to $EthIOMaster.Slave0Error as I had shown in a prior post?

It isn't necessary to clear SlaveNError unless you want to. It just stores the last error and has nothing to do with the execution. And yes, just write it to 0.
Title: Re: Multiple Remote I/O's
Post by: RBPLC on August 01, 2019, 11:03:32 AM
Thanks BobO. Maybe I've missed something in the documentation, but how would you get the fault status (0 or 1) of a specific slave using the $EthIOMaster.SlaveErrors without using a bunch of comparisons? What I want to do is something like: $EthIOMaster.SlaveErrors[0] to determine if slave 0 has a fault on it but this does not appear to be correct syntax? What would be the correct way to do this, or is there a way? I'm probably missing something simple here.
Title: Re: Multiple Remote I/O's
Post by: BobO on August 01, 2019, 11:14:38 AM
Thanks BobO. Maybe I've missed something in the documentation, but how would you get the fault status (0 or 1) of a specific slave using the $EthIOMaster.SlaveErrors without using a bunch of comparisons? What I want to do is something like: $EthIOMaster.SlaveErrors[0] to determine if slave 0 has a fault on it but this does not appear to be correct syntax? What would be the correct way to do this, or is there a way? I'm probably missing something simple here.

Do-more cannot index or cast structure fields for reasons I won't bore you with. Just copy it a 16 bit register, then access. And let me add that when I said 16 bit register, that can also be 16 contiguous Cs. Just do a MOVE $EthIOMaster.SlaveErrors to C0:W. Note that the bit location must be on a 16 bit boundary...C0, C16, C32, etc.
Title: Re: Multiple Remote I/O's
Post by: EDurako on August 01, 2019, 02:42:16 PM

As I remembered, that triggers a command to the slaves to clear relevant module status. It has nothing to do with clearing errors relating to communicating with the slaves.

I came in to the conversation late, so what exactly isn't working as you expect?

Based on what I have read in this thread I am expecting the following to be true even though they contradict one another:

-If a slave is marked optional, by unchecking the "Slave must be online to enter RUN mode" then it should auto establish connection with the Master at some point without intervention.

-There is no way to clear a communication error or reset a communication link with a slave short of power cycling/rebooting the Master


I purposefully allowed Master to fully reboot and return a #4 Timeout error, then after the Slave had rebooted, we let it sit overnight. The next day we are now getting a #3 Signature Error. We were also unsuccessful at clearing this error.

I also expected that if the "CPU remains in RUN mode on slave error" is checked and the "Slave must be online to enter RUN mode" is not checked, then the Master would always be trying to reconnect any missing slaves every scan or every other scan from here to oblivion.

Title: Re: Multiple Remote I/O's
Post by: BobO on August 01, 2019, 06:15:53 PM
-If a slave is marked optional, by unchecking the "Slave must be online to enter RUN mode" then it should auto establish connection with the Master at some point without intervention.

-There is no way to clear a communication error or reset a communication link with a slave short of power cycling/rebooting the Master

I purposefully allowed Master to fully reboot and return a #4 Timeout error, then after the Slave had rebooted, we let it sit overnight. The next day we are now getting a #3 Signature Error. We were also unsuccessful at clearing this error.

I also expected that if the "CPU remains in RUN mode on slave error" is checked and the "Slave must be online to enter RUN mode" is not checked, then the Master would always be trying to reconnect any missing slaves every scan or every other scan from here to oblivion.

The first point is correct, the second is not...it will automatically reconnect. Once a base is logged out, the poll rate is reduced to 5 seconds, after the base is logged back in it returns to what you specified. Not sure what I said that led you to the conclusion that the master would not automatically reconnect, but I'm sorry if I confused you.

The signature error is related to a unique code that is assigned to a slave when we bring it online. It prevents two masters from talking to the same slave. Not sure what might be causing that, but let's resolve one thing at a time.
Title: Re: Multiple Remote I/O's
Post by: RBPLC on August 02, 2019, 08:02:30 AM
Thanks BobO. That's exactly what I was after in terms of casting. I tried both the copy and move method you described and they both worked.