RBE Mixed with Other ECOM Activity

[johnr]

I have an application with a network of four DL260 PLCs, each operating a material handling station.  The four PLCs are operating as ECOM slaves, responding to ECOM RX/WX messages once or twice a second.  Those RX/WX messages originate from a fifth supervisory or master DL05/06 PLC.  This all works just fine.

I would also like for the four ECOM slave PLCs to send periodic, event-driven information to a PC on the network, mostly alarm conditions as they occur.  I've tested RBE and it seems as if it would suit this purpose.  My question regards the mixing of RBE comms with the other ongoing ECOM slave communications. 

All of the traffic (both directions) is relatively small and low-bandwidth, but the incoming ECOM message requests and the outgoing RBE requests would collide regularly.  Of course I would test the SP busy flag before initiating RBE, but is that sufficient to avoid disruptions between the two sets of messages?   Any risk of inducing errors in the established ECOM slave communications is unacceptable, even if it only happens occasionally.  Given that RBE is a bit of a backdoor, I'm not certain how robust it will be with the ECOM constantly changing communication modes.

I see a couple other alternatives to using RBE, but I wanted to see what people here had to say about this before considering other ways of getting the information to the PC.  Thanks for any insight -

[b_carlton]

This is just based on general knowledge of communication commands in the DL and Ethernet in general.

Testing the busy flag is necessary to prevent the DL from initiating a communication while a previous communication THAT THE DL INITIATED is still being processed.  The processing of RX/WX commands received from another DL should in no way affect or be affected by your RBE commands.

Collisions in the Ethernet world are a fact of life and, unless the network was so densely populated as to be collision-bound, should be transparent to this level of communication.

I would not hesitate to try this out.

[MikeS]

As long as you correctly integrate the RBE requests in with your other RX/WX requests (interlocked and using the SPxxx busy bit), there should not be any problems.

The ECOMs are very adept at handling these various roles simultaneously (ECOM slave to DSOFT, RX/WX master & slave, and RBE). We do it all the time and the performance is very good. If you're using ECOM100's you can even add Modbus TCP/IP client & server into the mix and it won't mess up.

The key to all of this is correctly interlocking all of the comm requests and using the SPxxx busy bit. You absolutely positively have to make sure that only one comm request can be active at any given time.

Are you currently using the IBoxes to do the comm (ECRX/ECWX for ECOM100s, or NetRX/NetWX for ECOMs)?

[johnr]

Thanks for the responses.  No, I'm not using the Ibox instructions in this case in the master PLC, just the standard WX/RX.  I assume you mean for the master, not for the RBE or other code that I initiate in the slave PLCs.  Things are running fine and I have a state machine that sequences through the four sets of read/writes, with a configurable time delay in-between so the master isn't continunally blasting communications across the network.  Is there a reason I should consider the Ibox for this case? 

The reason for my caution is that I've managed to latch up the ECOM cards a good bit during development.  It doesn't have to do entirely with my own programmed communications.  I've noticed that with the DL05 in particular, I can regularly create the need for a power-down reset (or worse) when I download new ladder programs from DirectSoft using the ECOM interface.  I minimze occurrences by making sure that all of my own programmed communications in the DL05 (both master and slave) use a delay at ladder program start-up.  Also, the DL05 ECOM behaves much better if I manually place the PLC in program mode whenever downloading new software, rather than letting DS quickly cycle the run mode on and off itself.  Hence my concern that it's possible to get the ECOMs too busy and cause hang-ups. 

[Greg]

The reason for my caution is that I've managed to latch up the ECOM cards a good bit during development.  It doesn't have to do entirely with my own programmed communications.  I've noticed that with the DL05 in particular, I can regularly create the need for a power-down reset (or worse) when I download new ladder programs from DirectSoft using the ECOM interface.  I minimze occurrences by making sure that all of my own programmed communications in the DL05 (both master and slave) use a delay at ladder program start-up.  Also, the DL05 ECOM behaves much better if I manually place the PLC in program mode whenever downloading new software, rather than letting DS quickly cycle the run mode on and off itself.  Hence my concern that it's possible to get the ECOMs too busy and cause hang-ups. 

The DL05-to-ECOM100 communications across the backplane locking up on very rare occasions is a known issue we have discovered. Currently we (Host Engineering)  and Koyo (makers of the DL05) think it is a DL05 firmware issue. It is very rare and only happens when downloading multiple times while DL05 is in RUN mode. Current work-around is, like you said, put the DL05 in the program mode first.

But the communications using regular RX/WX or with the ECOM100 in a "slave" mode, we have not seen. So, there is no reason to fear that.