EthernetIPforCLX Subscribe vs Read and best practices

[leovailati]

Hello all,

First and foremost, I want to thank the authors of this amazing project. I appreciate the effort they are putting on and how they decided to make it mostly open-source and free to use! I am working on a small project to transfer data from a PLC into a SQL server and generate excel reports. I like to think of it as a smaller version of the Rockwell Transaction Manager solution.

I have a few questions that I could not find direct answers to regarding the internal workings of the Ethernet/IP communication driver for CLX controllers. I am using the latest version of AdvancedHMI, released just a few days ago, I believe. And VS Community 2015.

Here are my questions:

1. I know that I should use the Subscribe method to perform periodic readings, and then handle the returned data with a callback, that is fine. However, I noticed that the arguments PollRate and CallBack of that method don't seem to work. I have read (I) that the PollRate argument hasn't been implemented yet, is that the case for CallBack as well? I can still configure and receive data using the attribute PollRateOverride and the event SubscriptionDataReceived, but it would be easier to have one callback per subscription and perhaps different PollRates.

2. I have been thinking of creating my own subscription system, that would use threads and call the simple Read function to grab data each time. I know that the Subscribe method that the driver provides has the advantage of combining multiple read operations into a single message. I want to know if going down this path makes sense or if the lost in efficiency would be too bad. Would it be possible to reimplement these block read operations myself?

3. If I want to subscribe to tags on the same controller but with different PollRates, should I create more EthernetIPforCLX objects pointing to the same controller? I am thinking of creating groups of tags that have the same PollRate, and create EthernetIPforCLX objects accordingly. Is that the way to go?

I will greatly appreciate any help and advices that this community might have! Thank you all,

Leo

(I) http://advancedhmi.com/forum/index.php?topic=839.0

[Archie]

The pollRate in the subscription parameter list is not used. It was a feature that was going to be implemented, but a change in driver architecture essentially did away with it.

If you are finding the callback parameter not working, does this mean no subscriptions work for you?

The subscription system is a rather complex bit of code that highly optimizes communication. It also runs on it's own background thread. Although you can create your own subscription system, but meeting or exceeding the performance of the current system will be very difficult. If you want to see how efficient it really if, add 5 BasicLabels to a form then set the driver PollRateOverride to 0. Your labels will typically all refresh at about a 5ms rate.

To use different poll rate, you do need to use multiple driver instances. One thing to note is that read optimization is done on a per driver instance basis. For instance, let's say you have 5 tags on one driver instance updating at 50ms. Then you have a second driver instance with 5 more tags, but at a 100ms rate. You will likely lose efficiency because always read the data with 2 separate packets. A single driver with 10 tags at 50ms will read all ten tags with a single packet. So there is a tricky balance if you are trying to use extreme levels of optimization.

[leovailati]

Thank you for your reply.

I can get subscriptions to work with the event SubscriptionDataReceived, but then I get all the callbacks in one place rather than being able to use different functions for different read subscriptions. It is working fine though.

Yes, I noticed that the driver is indeed very efficient - I have observed that 5 ms average myself. Very impressive! And I will not try to reinvent the wheel, I will just write some glue code to use the current subscription system.

I am not sure of what I should do to have different poll rates for different tags. I see your point and I agree that there is a tricky balance to it. For now I think I prefer the idea of using different drivers. Will the drivers optimize their packet size for just the tags that I want or do you think I would be creating overlaps? I don't want to read data just to throw it away, and I wouldn't like to read duplicate data either.

On a separate question: does the BeginReadMultiple method combine requests into a single packet as well?

Leo

[Archie]

I can get subscriptions to work with the event SubscriptionDataReceived, but then I get all the callbacks in one place rather than being able to use different functions for different read subscriptions. It is working fine though.

You can use and specify separate callbacks for each subscription. This is an example if using the Modbus driver:

Code: [Select]

   Private SubScriptionID(1) As Integer
    Private Sub MainForm_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        SubScriptionID(0) = ModbusTCPCom1.Subscribe("40001", 1, 500, AddressOf Subscription1CallBack)
        SubScriptionID(1) = ModbusTCPCom1.Subscribe("40002", 1, 500, AddressOf Subscription2CallBack)
    End Sub

    Private Sub Subscription1Callback(sender As Object, e As Drivers.Common.PlcComEventArgs)
        '* Data from 40001
    End Sub

    Private Sub Subscription2Callback(sender As Object, e As Drivers.Common.PlcComEventArgs)
        '* Data from 40002
    End Sub


On a separate question: does the BeginReadMultiple method combine requests into a single packet as well?

Yes, the BeginReadMultiple does combine multiple requests into a single packet. However caution must be exercised because it does not valid the length of the packet. Once too many tags are packed into a single BeginReadMultiple, it will just stop working. The total packet length is determined by the CIPConnectionSize property of  the driver, which is 508 bytes by default.

[leovailati]

Yes, the BeginReadMultiple does combine multiple requests into a single packet. However caution must be exercised because it does not valid the length of the packet. Once too many tags are packed into a single BeginReadMultiple, it will just stop working. The total packet length is determined by the CIPConnectionSize property of  the driver, which is 508 bytes by default.

Thank you!

So does that mean I can read up to 508 bytes of randomly-positioned memory or does it have to be 508 bytes of sequential memory? Other than not validating the packet size, does it have all the capabilities that the subscription system has, as far as driver optimizations go?

[Archie]

You can read groups of random tags as long as the header length + tag name lengths + a few other support data does not exceed 508 bytes. The subscription systems final read is done using the BeginReadMultiple function.

[leovailati]

You can use and specify separate callbacks for each subscription. This is an example if using the Modbus driver:

So that is pretty much what I tried to do. The three main differences are
1. I am using C#
2. It is a console application
3. I was using the same callback function for the three tags I subscribed to
4. I am using the MfgControl.AdvancedHMI.Drivers library
5. I am also using the SubscriptionDataReceived event

Here is the code: I noticed that On1 was never called, but On2 was called every time (once for each combination of transaction and subscription)

Code: [Select]

        private static int id1 = 0;
        private static int id2 = 0;
        private static int id3 = 0;
        private static EthernetIPforCLX b = new EthernetIPforCLX();

        static void Main(string[] args)
        {
            b.IPAddress = "192.168.1.220";
            b.ProcessorSlot = 0;

            var t = 500;

            b.PollRateOverride = t;
            id1 = b.Subscribe("TestNum1", 1, t, new EventHandler<PlcComEventArgs>(Program.On1));
            id2 = b.Subscribe("TestNum2", 1, t, new EventHandler<PlcComEventArgs>(Program.On1));
            id3 = b.Subscribe("TestNum3", 1, t, new EventHandler<PlcComEventArgs>(Program.On1));
            b.SubscriptionDataReceived += On2;

            ...
        }


[leovailati]

You can read groups of random tags as long as the header length + tag name lengths + a few other support data does not exceed 508 bytes. The subscription systems final read is done using the BeginReadMultiple function.

Great! Thanks Archie!

So the 508 bytes maximum is for outgoing or incoming packets?

[Archie]

Yes, it is an outgoing limit. If an incoming packet exceeds the limit, the PLC will break it up and the driver will reassemble it.

[leovailati]

Yes, it is an outgoing limit. If an incoming packet exceeds the limit, the PLC will break it up and the driver will reassemble it.

Perfect. Thank you!