Cross Reference is not showing correctly

[lyle894]

I have an issue in Studio 5000 where occasionally a few different tags numbers will change to an -e1.444 for less than a second.
I ran the cross reference on the tag and found that it was used in two rungs. The rung its on and the previous rung.
I go to that rung and it is not being used or set on that rung. Im not sure what is going on and have spent many hours trying to search for this.

I decided to check every tag and they all (except the one on rung 0) are like this. Is this normal or is there something else going on?

 

[drbitboy]

Maybe CPS would be a better choice than COP; see this link, especially this:

 

[lyle894]

I changed them to CPS and they still have the same issue

 

[drbitboy]

I have an issue in Studio 5000 where occasionally a few different tags numbers will change to an -e1.444 for less than a second.

1) what does -e1.444 mean? Is that a typo?
2) where are you seeing that it is that value? HMI? Studio 5000 online monitoring? Something else?

 

[lyle894]

While online monitoring, it will display 2.45647621e-041 then go back to the actual number of 1000.0

 

[drbitboy]

What data types are .Firmware_version and .Mass_Units?

What is the layout in Data_In (I assume Data_In is a UDT)?

Which tag is normally 1000.0? Is it a REAL or LREAL?

How often does the problem happen?

Can you get the actual values for the TC20.I.Data and the other pieces (I assume 2.45637621e-041 is random keystrokes representative of what you see)? You may want to set it up, press PrintScreen when it happens, paste into a PNG, and post the PNG here.

 

[lyle894]

Data_In is a UDT. It consists of 183 different parameters that I am reading from an EIP device (TC20)
One tag that is normally 1000.0 is called LIW_Target_Rate. It is a REAL

The problem seems to happen randomly. I waited for it to happen to grab the screenshot and it happened once within 2 seconds of it and then it took almost a minute for it to happen again.

 

[drbitboy]

is it possible the .LIW_Target_Rate is an LREAL instead?


What about everything else?


Where is .Firmware_Version in the UDT?


What precedes it and what follows it?


Where is .LIW_Target_Rate in the UDT?


What precedes it and what follows it?


Where is .Mass_Units in the UDT>


What precedes it and what follows it?


Better to just dump the entire layout to a PDF and post it here.


Can you monitor those values in hexadecimal?

 

[lyle894]

They are attached

 

[drbitboy]

Take note of my .signature below. Cf. here.


Also, if you define the UDT correctly, I am pretty sure you should be able to load every attribute of the Data_In UDT with one COP instruction.






So how many bytes does the following COP instruction copy, when Data_In.Firmware_Version is the Dest parameter, and where does it put them?

 

[ASF]

Is this causing any actual issues, or is it just the visual aspect?

The tag monitor is not realtime. I don't know what update rate it has, but let's call it 250ms for the sake of argument.

It may be that occasionally the tag monitor reaches 250ms and updates the tags partway through the COP instruction, and so for the next 250ms, you will see scrambled data. Of course, in the background, the tag has actually gone right back to being 1000.0, and all of your code is executed with it being 1000.0, and there are no problems except the fact that it's annoying.

If it were me, the first thing I'd do is to place a few error traps in various places around my code to latch a bit if the value of the tag is ever anything other than 1000.0 (or possibly NEQ Suspect_Tag 1000 MOV Suspect_Tag Diagnostic_REAL, to catch the actual value). I would be surprised if any of your "traps" are ever sprung.

Side note: the above would not apply if you had not already addressed the COP vs CPS issue mentioned by drbitboy. It's entirely possible to get scrambled data if you're COP-ing data from asynchronous I/O, as opposed to CPS-ing it.

 

[lyle894]

I did place a latching bit if it wasn't equal to 1000 and it never latched. I guess it is a more visual thing than anything. It just seemed odd that it also stated that it was being used on other lines when it wasn't.

Thank you for your help!

 

[drbitboy]

If OP has not figured it out by now, the solution is to replace the value of every Length parameter in those COPy instructions with a value of 1.

Or replace them all with one COPy statement:

COP TC20:I.Data[0] Data_In 1

​

which assumes the UDT's bytes are ordered identically to the source TC20:I.Data's bytes.

 

[ASF]

I did place a latching bit if it wasn't equal to 1000 and it never latched. I guess it is a more visual thing than anything. It just seemed odd that it also stated that it was being used on other lines when it wasn't.

Thank you for your help!

What exactly were you cross referencing in your initial screenshot? It's been cut out of the picture, but I suspect you were cross referencing an individual element of your UDT.

The AB cross reference is extremely exhaustive, sometimes to the extent that it could be described as too all-encompassing.

For example, if I cross reference Some_Array[5], it will find not only references to Some_Array[5], but also references to Some_Array[Pointer], which could conceivably be writing to Some_Array[5] if the value of Pointer is 5. It will also find a COP instruction writing to Some_Array[0], because if the length of that COP instruction is 6 or more, it could also write to Some_Array[5].

Doesn't mean when I get to that rung I'll find any trace of Some_Array[5], nor that the rung will ever do anything involving Some_Array[5], only that it could.

It works the same with UDT's. When you're doing a lot of stuff with UDT's, you can wind up with a lot of entries in your cross reference list when cross referencing a UDT member, even if the specific member you're interested in doesn't get involved on that rung. Sometimes it gets annoying, but for my money, I'd rather have too much detail than not enough. In this instance, look at the "Reference" column of your cross reference list.

Here, both entries in the list show that it's the base UDT being referenced. If you're looking for places that your specific UDT member is being individually addressed, you can look in that column for entries that show MyUDT.ElementOfUDT instead of just MyUDT - but as mentioned, RA will show you not only your specific element, but also anywhere that your whole UDT is being referenced.

 

[janner_10]

Sit and view the tag in a trend for a few minutes to see what is actually going on.