AdvancedHMI Software
General Category => Support Questions => Topic started by: kay_gsr13 on November 15, 2016, 11:26:50 AM
-
I'm rebuilding my project from 3.61 to 3.99r. I've got three pages so far and is now testing the connection. What I'm seeing is that the MainForm works well but when I switch to any of the other two pages while hide the Mainform, I don't see any of my PLCAddressValue being updated on the other forms, all values are at the default "0." I don't have any error.
Has anyone else experienced this or is there something different from the older release?
-
See this topic:
http://advancedhmi.com/forum/index.php?topic=1470.0
-
Godra,
Thank you for the update, I will try the patch.
K
-
So I added the v399r patch with the same labels and components as with the original v399r
Setup: Multiple forms (connecting to a MicroLogix1400 with the EthernetIPforSLCMicroCom driver)
Here's what I've seen:
1) Any PLCAddressValue with "timer address such as T4:XX or T4:XX.XXX" will not allow connection to the any Forms. Soon as I remove those timer addresses, the MainForm will run fine.
2) My other pages are still not connecting.
3) Tested using a fresh copy of v399r with and without the driver patch and just 1 button per page. The result are the same: page2 fails to communicate. Any other ideas?
Thanks,
K
-
I'm going to take a look at this over the weekend to see if I can figure where the issue is.
-
Thank you Archie.
For you information, I tested the same configuration on v399p and all of my forms are communicating and working fine.
Another thing on v399r and v399p that I'm seeing is that my Boolean Tags (array is 128 long), such as on a CompactLogix, KB[100] for example and using the EthernetIPforCLXCom driver, is that it's returning an error of "General Error: Offset plus Number of Elements extends beyond the end of the requested tag."
Thanks for the awesome software.
-
I created a new patch to address the problems with the SLCMicro driver.
https://sourceforge.net/projects/advancedhmi/files/advancedhmi/3.5/Patches
- Download and extract Patch 4 V399r
- Replace the file found in AdvancedHMIDrivers\support
- Rebuild the solution
-
Archie, thanks for the prompt update!
I tested the configuration on v399r with patch4 and all of my forms are communicating correctly now.
The Boolean tag reference on a CompactLogix, using the EthernetIPforCLXCom driver, works now as well, albeit when the form first load, the error of "General Error: Offset plus Number of Elements extends beyond the end of the requested tag" still exist. Once the push button is toggled, the error is automatically resolved and the PB functions as intended. Hope fully you see something from this feedback.
Thanks again
-
The Boolean tag reference on a CompactLogix, using the EthernetIPforCLXCom driver, works now as well, albeit when the form first load, the error of "General Error: Offset plus Number of Elements extends beyond the end of the requested tag" still exist. Once the push button is toggled, the error is automatically resolved and the PB functions as intended. Hope fully you see something from this feedback.
I'm not able to replicate this. How big is your BOOL array and how many and which elements are you reading?
-
Archie,
"I'm not able to replicate this. How big is your BOOL array and how many and which elements are you reading?"
My Boolean Array is 128 (KB0[128]) and I'm trying to access just one at a time. Attached shows a screenshot of my data type.
Playing around with a little more, I've notice that the error is mainly apparent when I toggle a BOOL element from my array and using that same tag for both PLCAddressClick and PLCAddressValue (to indicate a change in state).
Older release such as v3.61 (my original build) did not exhibit this type behavior with the same configuration.
Thanks.
-
I was finally able to replicate the problem. My BOOL array had too many elements. Once I reduced it to 128 and used element 100, it gave me the same error. There is now patch 6 that should fix it:
https://sourceforge.net/projects/advancedhmi/files/advancedhmi/3.5/Patches
The problem came about because of the way BOOL array values come back. To the driver they appear as DINTs. If any value was used in the last DINT (elements 96-127) , the driver tried to read 1 more DINT.
-
Archie,
Patch 6 did the trick. BOOLs are responding correctly.
I did experience another issue on v399r, As I'm adding to my project, I've noticed that when I'm reading a couple of elements, from an array of REAL[50], I'm seeing data freeze. The data will initially read, but will not refresh.
Are there limitations as to how long the arrays for floats can be? My other smaller REAL arrays are not showing these symptom.
Thank you again for the support.
-
I did experience another issue on v399r, As I'm adding to my project, I've noticed that when I'm reading a couple of elements, from an array of REAL[50], I'm seeing data freeze. The data will initially read, but will not refresh.
Are there limitations as to how long the arrays for floats can be? My other smaller REAL arrays are not showing these symptom.
There are no limitations on array sizes. I will try to replicate this problem and let you know what I come up with.
-
Hope everyone had a Happy Thanksgiving!
Archie,
Over the weekend, we completely power off certain equipment and I left my HMI program running. I later toggled through my pages and when I got to the page that used the EthernetIPforSLCMicroCom driver and the PLC was shut down, I had an unhandled exception. Please see that Attachments, the images are those that I captured remotely from home. If you need more information, let me know and I will try to replicate this when the machine is not in use.
Thanks,
K
-
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.
-
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:
If e.Values(0) Is Nothing Then
Dim dbg = 0
End If
-
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:
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
-
(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?
-
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
-
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.
-
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
-
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.
-
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.
-
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
-
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
-
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
-
Hi kay_gsr13 ,
Unfortunately I have an earlier version of rs5000 , so I was unable to open it . :(
Paul
-
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
-
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
-
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
-
The program is in the dreaded 20.03
[/quote]
dmroeder,
Dreaded indeed!
This came about when one of our L35E A series failed one day while I was on vacation. The only spare that was available was a fresh B series. The OEM's version was 15.3 and when they remote in, one of the support guys flashed the new PLC to the v20.03, plus had to make drastic changes for their program to run correctly.
Long story short, I went ahead and flashed the remaining L35E PLC and RSLogix 5000 program to the same version so that I wouldn't need a bunch of spare L35E PLCs.
K
-
Now we're getting somewhere. I duplicated your list of variables and was able to replicate the problem. It actually was not related to the REAL, but an effect of using the strings. The driver combines reads into a multi-service request and the string data sizes were calculated incorrectly causing the last item to not fit in the packet. In my test it was a string not updating because it was the last item I added to the form.
Tonight a new version of 3.99s will be released with the fix.
-
Now we're getting somewhere. I duplicated your list of variables and was able to replicate the problem. It actually was not related to the REAL, but an effect of using the strings. The driver combines reads into a multi-service request and the string data sizes were calculated incorrectly causing the last item to not fit in the packet. In my test it was a string not updating because it was the last item I added to the form.
Tonight a new version of 3.99s will be released with the fix.
Great news Archie!
Can't wait to used updated release!
K
-
Now we're getting somewhere. I duplicated your list of variables and was able to replicate the problem. It actually was not related to the REAL, but an effect of using the strings. The driver combines reads into a multi-service request and the string data sizes were calculated incorrectly causing the last item to not fit in the packet. In my test it was a string not updating because it was the last item I added to the form.
Tonight a new version of 3.99s will be released with the fix.
Update: The BasicLabels are currently responding accordingly with the v399s release! Thanks Archie!