Subscribe Function Event Triggering

[ozzio]

Hello.
I'm using AdvancedHMI3.98r with VS2013 Community. Using the following simple code my Label1.text should increase its value 2 times per second. But instead it increases 4 times. This n -> n^2 relationship holds true when I have more variables. With 3 subscribe addresses I get 9 RaiseEvent per second. Any idea why does this happen or how to fix it? I've read a similar thread about event firing twice but it did not help me.
Here is the code:

Public Class MainForm
    Dim subsID(1) As String
    Dim count As Integer
    Private Sub subscribe_Click(sender As Object, e As EventArgs) Handles subscribe.Click
        subsID(0) = EthernetIPforCLXCom1.Subscribe("CYCLE_COMPLETE_PSG5", 1, 1000, AddressOf kount)
        subsID(1) = EthernetIPforCLXCom1.Subscribe("CYCLE_COMPLETE_PSG6", 1, 1000, AddressOf kount)
    End Sub

    Private Sub kount(sender As Object, e As Drivers.Common.PlcComEventArgs)
        count = count + 1
        Label1.Text = count
    End Sub

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        EthernetIPforCLXCom1.UnSubscribe(subsID(0))
        EthernetIPforCLXCom1.UnSubscribe(subsID(1))
    End Sub
End Class

[Archie]

What is the PollRateOverride set to on the driver? That is what determines how often a subscription returns a value. The parameter is the subscribe call for update rate is a dummy parameter that has not been implemented.

[ozzio]

Hi. I added EthernetIPforCLXCom1.PollRateOverride = 1000 after your comment at the beginning of the sub subscribe_Click. I also wrote 1000 ms manually at the design view. I still get the same results.

I'm writing a little program which dumps 3 variables from 5 machines into an SQL. I realized that this was happening when I switched from reading each individually to using subscribe functionality. Subscribe greatly improved the freezing of the window especially at higher rates even though I'm getting my events triggered (3*5)^2 times now.

[Archie]

Have you tried to use the DataSubscriber component to see if you get the same results?

[Archie]

Do you have a ChartBySampling in your ToolBox? There was a driver fix to make the ChartBySampling work correctly. If you have the chart, add one to the form and add a PLCAddress then see if a new point is added at the rate of your PollRateOverride.

[ozzio]

I currently don't have a ChartBySampling in the project. Though I'm planning to make an asp.net page with nice graphs using data from SQL and put it on intranet. I currently left my work so I don't have access to a PLC right now. I'll set up the DataSubscriber tomorrow. One question though:
Does DataSubscribers guarantee that I will receive my data in cycles? By that I mean if I subscribed to (1) (2) (3) will i receive the the data in any form like this
(2) (3) (1) / (2) (3) (1) / ... or
(1) (3) (2) / (1) (3) (2) / ... ...
Also I'm planning to read much more data than 15. I think you mentioned that the data subscriber would introduce performance issues after some number of addresses. I'll try it out tomorrow and let you know.
Thanks for the great work Archie!

[Archie]

If you don't have the ChartBySampling, then you do not have the version that has the fix for the double data triggering. Try to download the latest version

After you download and open the latest version , right click the AdvancedHMI project and select Add->Existing, then browse to and select MainForm.vb from your previous project.

See if that resolves your issue.

[ozzio]

Ok. I'll try to import all my classes into a clean new updated AdvancedHMI project. I'll let you know tomorrow. Thanks for the support 

[ozzio]

Yes it's all fixed. Thank you so much

[leovailati]

I currently don't have a ChartBySampling in the project. Though I'm planning to make an asp.net page with nice graphs using data from SQL and put it on intranet. I currently left my work so I don't have access to a PLC right now. I'll set up the DataSubscriber tomorrow. One question though:
Does DataSubscribers guarantee that I will receive my data in cycles? By that I mean if I subscribed to (1) (2) (3) will i receive the the data in any form like this
(2) (3) (1) / (2) (3) (1) / ... or
(1) (3) (2) / (1) (3) (2) / ... ...
Also I'm planning to read much more data than 15. I think you mentioned that the data subscriber would introduce performance issues after some number of addresses. I'll try it out tomorrow and let you know.
Thanks for the great work Archie!

That is something that I would like to know as well. In short, does the driver guarantee ordered delivery of subscription data?

I would also add to ozzio's question, if (t, n) is a data point with TransactionNumber t and SubscriptionID n, is there any guarantee that I will always receive data like this:

(1, 1) (1, 2) (1, 3) ......... (2, 1) (2, 2) (2, 3) ......... (3, 1) (3, 2) (3, 3)

Thanks,
Leo

[Archie]

There is no guarantee in which the order of data will be returned because of the way the driver optimizes its communications. This is why it is important in your DataSubscriber to check which PLC Address the value came from:

If e.PLCAddress="MyTag" then

end if

[leovailati]

Would this be a little more efficient?

Code: [Select]

if (e.SubscriptionId == myId)
{
}

Because the communication driver optimizes reads and combines them into a single packet, can I assume that e.TransactionId will be ordered?

[Archie]

TransactionID will most likely be ordered, but not guaranteed. The driver will send a request to the PLC, then wait for a response before sending the next. If the response is not received after a period of time, another request may be sent. There is a chance the PLC will delay sending a response, sometimes for many seconds later, in which this period of time it could respond to the next request, therefore making the TransactionIDs come back out of order.

Also for reads that are grouped, they will have a single TransactionID. In other words, the TransactionID is not very useful when receiving data from subscriptions.

[leovailati]

If the driver decides not to group reads, would it return different TransactionIDs for tags that were captured at the same "time"?

I put time in quotes because I understand that there would be two or more different packets. But from a subscription standpoint, the values belong to the same point in time.

Would you recommend ignoring the TransactionId and using solely the order of arrival to record the data? Is there any parameter I can change to prevent the driver from sending the next request without having received the previous response? I would rather have it fail on a timeout than receive data out of order.

[Archie]

If the driver decides not to group reads, would it return different TransactionIDs for tags that were captured at the same "time"?

I put time in quotes because I understand that there would be two or more different packets. But from a subscription standpoint, the values belong to the same point in time.

Yes, different TransactionsIDs will be used for each packet, but it is solely up to the driver in how it groups and orders the requests. You can disable the grouping by setting DisableMultipleServiceRequests to False, but it will greatly reduce it's refresh rate.

Would you recommend ignoring the TransactionId and using solely the order of arrival to record the data? Is there any parameter I can change to prevent the driver from sending the next request without having received the previous response? I would rather have it fail on a timeout than receive data out of order.

The TransactionID is no real use when it comes to subscriptions. It is more useful when using asynchronous reads. There is no way to stop the driver from sending the next request because the driver does not know if the PLC will not respond or will have a long delay, so it has to assume the worst of no response. If it assumed the other case, the driver would then completely lock up if the PLC does not respond or a connection dropped.