AB 1756-EWEB - Able to read multicast or not?

Hello my fellow PLC fanatics..

Question for those of you playing with the 1756-EWEB modules - have you been able to successfully read a Multicast using these modules? I don't even know how to subscribe the socket to the multicast group, since I don't see an option for it anywhere in the socket object. It would be most helpful for my current project, but is it even possible? Rockwell TechConnect is working the issue right now, since I apparently "asked the right question, we'll have to look more into it and get back to you."

-B.K.

I know you got the answer already , but for all other forum readers:

"NO", EWEB sockets can't accept UDP multicast, it can only send it out.

Other options?

Ha, how'd you know, was it you I spoke with on the phone? That was a very quick response, btw.

I guess then, what are my other options? I need 272 bytes of data, 10 times a second, shared between 4 PLCs (3 sending, one receiving). The problem is, which three are sending and which one is receiving can change very quickly, due to failover logic. A multicast would've been nice, since I could just "float" the message out on the network, and not worry about making connections, reading headers, sending ACKs, etc..

Ideas?

What's wrong with produced/consumed tags?
You will need ENBT for it.

Or some PLCs are not AB?

Contr_Conn said:

What's wrong with produced/consumed tags?
You will need ENBT for it.

Or some PLCs are not AB?

Click to expand...

I'm already using ENBTs and produced/consumed tags, but the EWEB is for operator panel communication and backup data transfer.

All PLCs are AB, there are 4 17-slot racks, each one with an ENBT and an EWEB module, and an L63 CPU. I'm consuming the Input data from the other three PLCs in each controller (through the ENBT), but I also want to send out a packaged Input-state structure from each controller, for a "master" PLC to read and process. The slave PLCs would consume (and read the master's output struct broadcast), and set its local outputs based on the structure. The operator panels in the system will read the multicast sent out by the master PLC. I know this is a large amount of redundancy (and failure modes), but those are the requirements put in front of me. Sick, eh?

The only problem I'm seeing with this is even if you could get the broadcast packets to work, it would not be deterministic at all. I think a secondary ENBT would be better than a EWEB. What other functions do you have the EWEB doing?

I thought about using another ENBT, but I think that just adds one more layer of failure modes..besides, the ENBTs seem to be less powerful(?) than EWEBs (I'm using 50% CPU for the ENBTs, and every now and then my diagnostic connected/cached CIP messages fail, whereas the EWEB is currently sending two high-load, high-frequency Multicasts and using only 4%). I would deal with the non-deterministic case by including timestamps with the packets, throwing out the out-of-order packets (also, during failover, the new Master sets its Wallclocktime to the last master's final good timestamp, making sure the operator panels don't get confused). The other reason I want to use the EWEB is for its Multicast to the operator panels (don't need to worry about using the proprietary EML interface, multicast is much cleaner/simpler).

whereas the EWEB is currently sending two high-load, high-frequency Multicasts

Click to expand...

So how are you doing the multicast currently?

I don't think the ENBT is more capable than the EWEB. I think they have two different purposes. You will see the ENBT CPU usage higher with more produced and consumed tags in the ENBT. What your will not see is a lot of additional load on the LXX processor.

With the EWEB you are using MSG instructions. Messages are almost completely processed in the LXX processor. That is why your are seeing practically no load on the EWEB. The only time I see hard processor usage in the EWEB is when loading large XML files embedded in web pages. Go to the Logix 5000 Task Monitor and see how many backplane buffers your are using. These are used to process messages and are extremely hard to manage. By Default 10 is the limit and it can supposedly be adjusted to 40. From personal experience I like to keep the below 6 and 12 is the absolute max. This is one of the weaker points of the Controllogix processor when it comes to networking. This is where you are going to run into problems

Contr_Conn may correct me on this and if he does then listen to him, he has much more experience than me with both modules, but I'm going to say you need a second ENBT for this instead of the EWEB.

And trust me if I could think of a way to do it with the EWEB I would argue using the EWEB all the way, it is by far my favorite Controllogix module.

By the way are you using the web portion of the EWEB module?

Currently, I'm sending out the multicasts (output data multicast on the master PLC at 10 Hz and input data on all the slave PLCs at 5 Hz) from the EWEB module, just not receiving any in the other PLCs. I think I will just have to use directed unicast from each slave to the master and vice versa for inter-comms.

Thanks for the MSG handling explanation, now I understand why my EWEBs have so little load compared to the ENBTs. I'd like to explore this a little further, too. I did set the unconnected buffers limit up to 40 (from the default 10), but I'm not too sure how that is used. Where is this Logix 5000 Task Monitor you speak of? When I monitor any of the tasks running on the controller, I only get the Scan, Interval Times and the Task Overlap Count. I'm using v15, if that matters.

I agree about the EWEBs, they're fun to work with I'm not using any of the web services (yet), but that may become a preferred method of diagnostic display (limiting what diag data I send out on the multicast).

Thanks for the thoughtful replies, guys, I appreciate the comments!

-B.K.

The Task Monitor is downloadable HERE along with several other utilties. They are also on your RsLogix 5000 CD