Wonderware reading wrong CLX Array Tags

Just sharing an experience with a weird one that had 3 EE's scratching our heads for a bit...

A PLC5 program was converted to CLX, version 20 in an L71 processor. With the conversion, PLC5 Data File N15 (used for HMI display values) was converted to a 250 INT array N15[xx].

The CLX program worked. A panelmate (not a panelview) displayed everything correctly. Wonderware did not display things right and had us rather baffled.

At first, it seemed like Wonderware wasn't talking to the CLX, but when we looked at the diagnostics of the DASABCIP server we could see that tags were actively being read from the CLX. For example, if we looked at the WW Tagname "Servo_Alarm" (read-only) that looks at the bit N15[53].9 we could see in the DASABCIP server that this bit was toggling on and off. However, this bit was not ever changing in the CLX program.

After some stumbling around, we found and proved that even though the DASABCIP server showed it is reading N15[53].9, it was actually reading the CLX tag N15[51].9. In fact, it was reading 2 values off throughout the entire N15[xx] array. So N15[xx] was actually reading N15[xx-2] (we didn't figure out what it was trying to read for N15[0] or N15[1]). Wonderware was sucessfully reading other tagnames in this CLX, but this was the only array that it was trying to read.

Solution: We updated the WonderWare DASABCIP server to the latest version and all was good. (not sure what the old version was).

Just an FYI for anyone it may help.

I had a very similar problem not too long ago, working with a CLX L7 processor.
There was an array of tags where my panelview was reading all the values correctly, but on my WW application that array was being read off by one value.
Example, instead of reading tag HMIR[0], WW was reading HMIR[1] and so on.

What I eventually ended up doing was creating new tags in the controller, and it worked. Also I switched from using DASABCIP 4.0 to RSLinx as a communications server and that seemed to fix the problem as well.

I also realized later that another array of strings was not displaing at all in my WW application. After I switched to RSLinx the problem was fixed.

As you said, maybe DASABCIP 4.0 has some flaws that were corrected in the later versions, I´m not sure, but just FYI.

Its not necessarily a flaw. The firmware version 20 implements a security protocol which involves randomizing offsets. Dasabcip v5 supports this. Anything prior to version 5 will not work.

How is that not a flaw?
Anyways I had a spare RSLinx license around and that's what we decided to use as communications platform, it worked, and a bit faster too.

It's not a flaw because it worked as designed.

By ensuring your proposed setup by reading release notes, you would have discovered that you needed v5.

I've used the RSLinx IO server to WW before, and it became too cumbersome to maintain - went back to DASABCIP driver.

Actually you can use 4.1 with a service pack. I think it's at SP3 now.

EDIT: I should check myself. They had to change things around when the L7x processors came out, I thought it was related to the actual processor not firmware. So, I can vouch for this setup on an L7x processor v19, but maybe v20 throws in a curve ball.

I have looked at the release notes for 4.1 SP3 and although it supports v20 firmware it doesn't mention this flaw.

V5.0 has the following fix
SR 10512070: When advising items from a UDT that is greater than 63k bytes and "Optimize User Defined Types" is checked, the values returned are incorrect with good data quality.

I would be intested to know if 4.1 Sp3 works or not.

mhopley said:

I have looked at the release notes for 4.1 SP3 and although it supports v20 firmware it doesn't mention this flaw.

V5.0 has the following fix
SR 10512070: When advising items from a UDT that is greater than 63k bytes and "Optimize User Defined Types" is checked, the values returned are incorrect with good data quality.

I would be intested to know if 4.1 Sp3 works or not.

Click to expand...

You should definitely use V5.0 of DASABCIP with Logix V20 and above.

This fix you reference from the revision notes is actually something our company found and submitted to Wonderware West. In the previous version 4.1 SP3, they had release notes that were similar stating that a warning message was added to the wonderware SMC log when UDT size exceeds the 63k limit. We use ControlLogix in a pretty unique fashion with many complex nested UDTs so it was pretty obvious for us. The bad thing is that with the DASABCIP failure modes, 95% of your data may read just fine while the other 5% gives intermittent trouble.

PCMusicGuy said:

You should definitely use V5.0 of DASABCIP with Logix V20 and above.

Click to expand...

Only problem with v5 is that it requires a new license and my customer is not under support.
I've not seen any issues with 4.1.3 but we are about to start upgrading the PLC-5s to controllogix, something to watch out for.

Unchecking "Use Persisted Tags" or Deleting .AATDB files

I worked through this issue with WonderWare tech support today and learned that it is due to the temporary database cache DASABCIP.4 uses to load the tag names.

2 methods for resolving this are to un-check "Use Persisted Tags" so the DAServer pulls a fresh tag database from the PLC's each time it is started, or to stop the DAServer, delete the database cache files with file extension .AATDB, and then restart the DAServer. The second option will force the DAServer to pull a fresh tag database from the PLCs as well.

I was also informed that updating to SP3 will resolve this issue and reduce the frequency at which this problem may occur.

This post helped me sort through this problem so I thought I would add my experience. Thanks!