Forms not communicating besides MainForm on 399r

[Archie]

Some debugging code was left behind that should have been removed.

- Open EthernetIPforSLCMicroCom.vb
- Go to line 263 and remove or comment out these 3 lines of code:

Code: [Select]

            If e.Values(0) Is Nothing Then
                Dim dbg = 0
            End If


[kay_gsr13]

I did see this error before but currently I am unable to replicate it just by disconnecting the physical plc (or stopping Modbus and RSEmulate 500 simulators).

Could be some quirk in VS or possibly some control that you have on that form.

Godra, thanks for the insight.

Some debugging code was left behind that should have been removed.

- Open EthernetIPforSLCMicroCom.vb
- Go to line 263 and remove or comment out these 3 lines of code:

Code: [Select]

            If e.Values(0) Is Nothing Then
                Dim dbg = 0
            End If


Archie,

(1) I commented the debug code and is no longer getting the unhandled exception!

(2) Were you able to mimic the REAL array issue I was having earlier?

Thanks,

K

[Archie]

(2) Were you able to mimic the REAL array issue I was having earlier?

I created an array of 50 reals, then created an app with 4 BasicLabels pointing to various elements of the array. I changed the values multiple times and it all worked normal. Have you found any particular scenario that makes the problem happen?

[kay_gsr13]

I created an array of 50 reals, then created an app with 4 BasicLabels pointing to various elements of the array. I changed the values multiple times and it all worked normal. Have you found any particular scenario that makes the problem happen?
[/quote]

Archie,

After additional testing, I have found that the data freeze is only apparent when I use a certain a converted data type with the other REALs within the array.

For instance, I have a periodic task (1000ms)  that increment an up counter (CTU), the CTU accumulated value is then MOV into element 7 of my REAL[50] array. Once the CTU reached the preset value of 60, calculations are made and the CTU is reset. When pointing to a combination of element excluding element 7, the basiclabel on the HMI syncs continuously, but if element 7 is used, all of the basiclabels from the same REAL arrays does not refresh.

Another thing is that if I point directly to the CTU.ACC value, everything works, that why I think there maybe an issue with how the data conversion are handled.


Thanks

K



 

[Archie]

I still may not be duplicating exactly what you have. I added a program with a counter and timer. The timer increments the counter and the ACC value is put in element 7 of a real array. In AdvancedHMI I put 3 BasicLabels on the form to show RealArray[7], CounterTag.ACC, and DINTTag

I attached a picture of the PLC program I have running. The AdvancedHMI application is just a form with 3 BasicLabels. I watched it count up to 59 and reset several times, but still unable to replicate a freezing.

[kay_gsr13]

I still may not be duplicating exactly what you have. I added a program with a counter and timer. The timer increments the counter and the ACC value is put in element 7 of a real array. In AdvancedHMI I put 3 BasicLabels on the form to show RealArray[7], CounterTag.ACC, and DINTTag

I attached a picture of the PLC program I have running. The AdvancedHMI application is just a form with 3 BasicLabels. I watched it count up to 59 and reset several times, but still unable to replicate a freezing.

Archie,

The only difference I see in your logic and mine is that my Counter is also in a form of an array where as your your is a single.

Also this is a very minor issue as I can change my logic or point to a different address and get the desired result.

Thanks

K

[Archie]

The only difference I see in your logic and mine is that my Counter is also in a form of an array where as your your is a single.

That was the key difference. I am now able to replicate the problem. I will dig into this to see what I can find.

[Archie]

Correction.... I changed the counter to an array and it still works the same. The first time I did not update the BasicLabel PLCAddress

Any other ideas what could be different? I would like to find this because it could lead to uncovering a bigger problem.

[pal]

Hi kay_gsr13 ,

Would you be able to post the part of your PLC program with this timer in it and the logic that loads it to the array - I'm just wondering - since you mentioned the timer is in an array - whether converting to real may be causing the problem ?
If you are not able to post the code , perhaps you could add a rung and check that the conversion to a new real gives the value you are expecting . ( if the timer is in an array , then it takes 3 words )
Paul

[kay_gsr13]

Correction.... I changed the counter to an array and it still works the same. The first time I did not update the BasicLabel PLCAddress

Any other ideas what could be different? I would like to find this because it could lead to uncovering a bigger problem.

Archie,

The only other thing that I can think of is that the form has multiple PLC connections, uing both the CLX and SLC drivers. I will do more testing and see what I come up with.

Thanks

K

[kay_gsr13]

Hi kay_gsr13 ,

Would you be able to post the part of your PLC program with this timer in it and the logic that loads it to the array - I'm just wondering - since you mentioned the timer is in an array - whether converting to real may be causing the problem ?
If you are not able to post the code , perhaps you could add a rung and check that the conversion to a new real gives the value you are expecting . ( if the timer is in an array , then it takes 3 words )
Paul

Pal,

Attached is a portion of my program. Background: This routing is on a 1000ms periodic task, that increments my counter. Once the pre. value is met, counter is reset and a compute bit is latched for computing my flow totalizer, then unlatches the compute bit and repeat.

The only reason for the data conversion from counter.ACC to Float is that I'm grouping and sending these REALs value to another PLC through explicit messaging to minimizing the overall MSG connections.

Thanks

K

[pal]

Hi kay_gsr13 ,

Unfortunately I have an earlier version of rs5000 , so I was unable to open it .

Paul

[kay_gsr13]

Hi kay_gsr13 ,

Unfortunately I have an earlier version of rs5000 , so I was unable to open it .

Paul

Paul,

I still trying to debug myself, thanks again for the effort.

K

[kay_gsr13]

Correction.... I changed the counter to an array and it still works the same. The first time I did not update the BasicLabel PLCAddress

Any other ideas what could be different? I would like to find this because it could lead to uncovering a bigger problem.

Archie,

I tested some more, and here's what I found:

1) I was having freezing issue with element 7 of a REAL[50]. Further testing revealed that using any one of the 0-8 element caused this issue. Once I used element 9-49, the issue went away.

2) Test 2: Copying the CLXethernet driver and the two BasicLabels from that REAL[50] array to another empty page, the data updated accordingly.

3) Test 3 & Back to the original page: In addition those BasicLabels, I have 5 other BasicLabels. These 5 BasicLabel that are sync to a couple of large String Arrays. The first BasicLabel is synced to the last element of String[500] array or 499, the second BasicLabel is synced to 498, and the third is synced to 497. The fourth BasicLabel is synced to the last element of another large String Array[520] or 519. The fifth BasicLabel is synced to the last element of a 120 element long String Array or 119.

4) Results: By using an element (NOT 0-8) of the REAL[50] or by deleting one of the larger BasicLabel pointing to the large string array, my element 7 of a REAL[50] will update fine.

I hope this this help reveal something, also if you need me to perform additional testing let me know. Thanks.

K

[dmroeder]

Hi kay_gsr13 ,

Unfortunately I have an earlier version of rs5000 , so I was unable to open it .

Paul

The program is in the dreaded 20.03