Networking feature request

[ATU]

I would like to see a feature that would work like peerlink, broadcasting to all PLC's that subscribe, except have an update on demand or at the end of the scan.
Publishing would be limited to at minimum one 16 bit register (perhaps more if practical). You would have a subscribe function that is at the top of the scan. That would select which register(s) the PLC was publishing and like peerlink, put the unit on the subscription service. Maybe limit the total number of PLC's allowed in the service to 8 or 16. Then you would have a publish instruction, that would copy the register(s) to the network service register and either send it out then and there or wait until the end of the scan.  I have been working with a 4 plc system on a project and I find that when I need to send non-time critical data between units, the Peerlink function is great at a 100ms update. Sending large chunks of data, the Modbus functions require more coding, but are fast. However, trying to send a time critical trigger or synchronization pulse between PLC's  is too slow using Peerlink the application. Wiring I/O for this function is messy and prone to noise. I ended up using the MWX functions, but it's a lot of code to send 1 bit and trying to get all the PLC's to receive the triggers close together is another challenge when the number of PLC's increase.  The feature might also be quite useful in motion applications.  OR, add another function that  publishes the data for the Peerlink node on demand or at the end of the scan.

[franji1]

Broadcast a Report-By-Exception.  The exception data can consist of 2 or 4 or 16 WORDs?

Keep it simple.  Call it FASTLINK or PEERRBE (or whatever).  Like PEERLINK, have FASTLINK support up to 16 blocks of 2/4/16 WORDs.  Have a FL structure and an FL block of 32 or 64 or 256 WORDs (2x or 4x or 16x 16 WORDs).  Have all the Inhibit functionality of PEERLINK.  Instead of a BYTE representing the data rate, have it just be a modulus 256 counter such that whenever a subscriber receives that block, it increments that BYTE (simple Delta contact can determine when an "exception" occurred).  But there can also be an event bit in the FL structure.

When the FASTLINK Publisher specifies the block that it is publishing, it also specifies a BIT to TRIGGER.  This is simple scan based, edge trigger monitor (so it will utilize an edge bit).  FASTLINK instruction monitors the Trigger bit - FASTLINK instruction could also auto-reset it (or force ladder logic to reset it).  However, FASTLINK needs to breathe.  You can't do it EVERY scan (auto-reset could cause it to possibly want to publish EVERY scan - that's why I was thinking have ladder logic do it - the FASTLINK must see the OFF to ON transition? ? ?).

Doesn't sound too bad, and would be a great "global" RBE mechanism.  Like PEERLINK, up to 16 PUBLISHING PLCs with 1 trigger each, but literally hundreds of SUBSCRIBERs LISTENING/RESPONDING to the TRIGGERs.  All with a simple FASTLINK instruction in $Main.  Every little to set up (like PEERLINK).

Possibly a HeartBeat mechanism of once per minute would help with failure detection? ? ?

When you say motion - that probably needs to be hardwired?  How fast do you believe FASTLINK needs to be?  PEERLINK is ~100ms.  FASTLINK would be PLC scan/comm based - not HSIO speeds.  1 to 4 ms latency is typical case?

[BobO]

Can you not do exactly what you want with PACKETOUT and PACKETIN. Use the global or subnet broadcast address.

[ATU]

I would be happy if I could send a trigger under 10ms for the current application, but get it to all the PLC's  at the same time.

So I could setup each PLC with a different UDP port, use PacketOut and send it to IP address 255.255.255.0 ? Then in the each of the PLC's, run PacketIn and  keep track of which port the data came in on and store it accordingly. Would that be faster than Modbus?

I know it wouldn't be fast enough for coordinated motion, but it you had several axis on multiple PLC's, you could initiate motion and get the in-position signal back much faster than Peerlink.
 

[BobO]

I would be happy if I could send a trigger under 10ms for the current application, but get it to all the PLC's  at the same time.

So I could setup each PLC with a different UDP port, use PacketOut and send it to IP address 255.255.255.0 ? Then in the each of the PLC's, run PacketIn and  keep track of which port the data came in on and store it accordingly. Would that be faster than Modbus?

I know it wouldn't be fast enough for coordinated motion, but it you had several axis on multiple PLC's, you could initiate motion and get the in-position signal back much faster than Peerlink.

If you are broadcasting to a group, they would all use the same port number. The broadcast address is the (sub)network address with 1s for the node. If you were using 192.168.0.x (netmask 255.255.255.0), the subnet broadcast is 192.168.0.255. The global broadcast is 255.255.255.255.

Use PACKETOUT to send, and monitor UdpPort.InQueue on the listening side(s). When it is true, call PACKETIN to get the data. I would use a simple stage program to do it. In the first stage monitor .InQueue, then jump to the next stage when true. In the next stage call PACKETIN, jump to the next stage to process the result, and jump back to the first. It seems like overkill, but it works cleanly...every time.

Performance of this will smoke Modbus. You can do multiple PACKETOUTs every scan.

[Controls Guy]

Ooh, very cool!   Didn't realize we had that capability.   

[BobO]

Ooh, very cool!   Didn't realize we had that capability.   

That's a common theme.

[ATU]

Thanks, sounds pretty straightforward and easy. I will give it a try.

[ATU]

That is freaky fast. Without going to a bunch of work to measure it, what used to take about 35ms is now around 11ms. Not sure how much of that is transmission time.  I just have to be careful about overrunning the buffer on the receiving end. I could get away with just executing a MWX over again because it would take a few scans to execute and no harm done if it keeps writing the same data. But the packetOut instruction looks like its done on one scan, so I have to delay sending again to allow time for the response to come back before I send it again. With Modbus you have some assurance that the data got there or didn't . With this you don't unless you put it in the protocol. Its a tradeoff, but I will take the speed gain.