LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unexpected behavior logging with DSC

My application uses the Write Tag (String).vi to write event markers to the historical database for use in extracting data in a report later in the process. In another tag, I store the name and path to a text file used by my application. Later, I query these values using the Read Traces.vi, along with other process data.
Tags are configured as String type with a maximum length of 80 and Text Data Only selected. They are memory tags. Update Engine Value is On Change, events are not logged. Log Data is selected and Log Data when is set to Always.
With the filename, I often get nothing stored in the database. I am pretty sure that it is a write problem because I have used MAX and queried the values between two events down to
.001 seconds with no sign of my value. Other times, the value is stored and works perfectly.
With the string tag I write process events to, I see the following: Given a simple 2-frame sequence structure where each frame contains Write Tag (String).vi wired to the same tagname but each with a different string ('Test Complete" and 'Module Complete' for example). When I query this data, sometimes I get the first value twice and sometimes I get the second value twice, but I never get the two distinct values together.
There appears to be a severe problem with logging of string tags. I have spent months trying to get these values to log (or query) reliably, but no luck. I have even tried writing the tag value, then reading the same tag until the current value matches the written one. The values still don't show up in the log. I have other string tags which are logged exactly as expected all the time.
Can anyone tell me how to reliably write and query string tags with LabVIEW
7.1 DSC?

Thank you,
plaskey
0 Kudos
Message 1 of 13
(4,875 Views)
Hello Peter,
Thanks for contacting National Instruments. As I understand it, your issue can be replicated by doing a Tag Write with a different string every time; and then reading it back immediately in the next frame of a sequence structure. I was able to do this and replicate your issue. If you do not place a time delay between the read and the write, the read may not reflect the correct value. This is because the write function may still be occurring when the read happens, thus reading an older data point.
I have attached 2 files. In one case, I did a read after a write tag without any delay. I used a string memory tag. Notice that in the corrected VI, I placed a 1 ms time delay between the read and the write function. Usually this is enough to all
ow a single tag write to complete. Upon doing so, the values shown were as expected.
Also, if you look at the data in MAX's Historical Data Viewer and export the data to a text file, you will notice that the data is continuous.

Hope this is helpful. Please let me know if this doesn't answer your question. I'd be more than glad to assist you with this.

A Saha
Applications Engineer
National Instruments
Anu Saha
Academic Product Marketing Engineer
National Instruments
Download All
0 Kudos
Message 2 of 13
(4,875 Views)
Hello A Saha,
I may have some insight into what is happening. I write an ampty value to the tag in question to clear it when my LAbVIEW VI starts. Then, at a point in time that is before the range that I query later with Read Trend (String).vi, I write a new value. I also write this value an the end of my process, and this value is within the range I query. SInce the tag is configured to write on change, perhaps I am getting no value because the first write after I set the tag to empty is not being picked up? Or maybe the problem is related to the way string tag values are 'interpolated' within a range.

I am working on building an example program to try to replicate the problem. I will send the program when I get it working. IN the mean time, I h
ope this information helps you identify the problem.

Thank you,
Peter Laskey
Software Engineer
JDS Uniphase
0 Kudos
Message 3 of 13
(4,875 Views)
Hi Peter,
I have sent you an email with the following information:
In Citadel, data is only logged to the database when the value changes by a certain amount (log deadband). If the value doesn't change, then nothing gets logged. If the value doesn't change for a certain predefined amount of time (max time between logs), then the same previous value gets relogged. By default this delay is I believe 1 hour and can be set in the Tag Configuration Editor. So if your value doesn't change for 30 minutes, no value is logged during that time. When you try to read a value from that time, you won't get any values. The best way to check if there is any valid data is to use the Historical Data Viewer in MAX.
Use it to view a trace. Once you have the tr
end viewer displaying a certain trace, right-click on the graph and go to properties. Here, change the Line Style to NONE and the Data Point Style to something like Solid Square. This will disable the viewer from drawing an interpolated line between two points and only show the discrete points. Now you can see which points are actually being logged. Furthermore, you can click on Export to Text in MAX and write the data you are viewing to a text file (do not enable interpolation in the Export to Text dialog box). You can then look at the individual datapoint values and timestamps much more explicitly.

Regards,

A Saha
Applications Engineering
National Instruments
Anu Saha
Academic Product Marketing Engineer
National Instruments
0 Kudos
Message 4 of 13
(4,875 Views)
Dear A.S.:
I am attaching an example extracted from my application that illustrates the process I use to log and extract data related to this problem. At this time, I haven't been able to reproduce the problem using this example, but I believe it accurately reproduces the actual process. The main difference is in the number of tags being logged. The production system has about 450 tags. As you can see from the sequence structure, the Gen_Sequence_name tag is written at the beginning and end of my process (both within the timestamp bounds of my process). To operate the VI, click 'Load' and point to any file on the system - the file is never actually opened in this example. Click "Start' and the program will log some random data
simulating a process. Click 'Stop' to end the process. Now the file name selected should be returned in the Result array when you click 'Report'. For subsequent runs, you will need to edit the Run Number field. The program should handle multiple instances of a given run number by asking you to choose the one with the desired start time.
The problem I am trying to reproduce is the 'Report' function returning an empty value from the Gen_Sequence_Name trace. Since this code retrieves a trace instead of a single point, I would expect it to catch the value if it is set at the beginning of a run and doesn't change throughout the run.
In terms of a string tag, what constitutes a change? In a long string value, is a single character change enough? I am just wondering.
I will try adjusting the max time between logs on my production system to see if it gets the data into the database in the right place.

Thank you,
Peter
0 Kudos
Message 5 of 13
(4,875 Views)
Hi Peter,
I ran your extracted code, and it appears to run exactly as you described it. Right off, I cannot see anything obvious that may cause the problems you are seeing. If you are dealing with 450 tags is that reading and writing may take longer to execute. This delay is not too bad if they are all memory tags. But if you have any hardware tags, then you can expect to see some delays during reads/writes. You should make sure that you take this into account when you are designing your application.

Your other question is regarding string tags. String tags don't have a deadband associated with them. Any change in the string, even one character, is considered a change. I used 2 different sequence files, one called hello1.txt and
another called hello2.txt. And your program ran correctly, showing the right file name. Since you are not able to replicate the issue on a smaller scale, this should be a good troubleshooting tool for you. You can go through and keep adding the rest of your application to try to isolate the problem.

Please let me know what else you find out from your investigations, and I will help you out with it.

Thanks!

A Saha
Applications Engineering
National Instruments
Anu Saha
Academic Product Marketing Engineer
National Instruments
0 Kudos
Message 6 of 13
(4,875 Views)
Thank you. I did finally encounter one problem with my extracted code. I do not yet know if it is the same as my actual problem, but it acts like it. After several trials, I encountered a situation where the first event timestamp was before the beginning of the run. This caused my Binary Search (timestamp) routine to bit-shift a negative number resulting in a very large index value. When this value is used to pick the filename from the array, the result is empty. I am attaching a copy of my historical data files that show this problem. Try running my Report code against runs 100 and 101. Run 100 works as expected but run 101 does not. Can you help me understand why this is happening?

Thank you,
Peter La
skey
0 Kudos
Message 7 of 13
(4,876 Views)
Hi Peter,
Perhaps I'm not running my tests the correct way. Here are the steps that I went through:
1. Run VI and keep run# as 100
2. Click on 'Load' button and specify a random file for the Sequence File
3. Click on 'Start' button
4. After a few seconds, click on 'Stop' button
5. Click on 'Report' button
6. Click on 'Exit' button
The Result shows me the file I selected in step 2.

I repeated the above steps except changed the run# to 101 and picked a different random file. And both times, the Result array displayed the file I had selected in step 2 above. Is this not correct? Please let me know if I'm doing something wrong. I ran the tests with the new data that you sent to me. Also, can you elaborate on what you meant by "the first event timestamp was before the beginning of the run" in terms of your specific application?

Thanks!

A.S.
Anu Saha
Academic Product Marketing Engineer
National Instruments
0 Kudos
Message 8 of 13
(4,864 Views)
Generally, you are performing the test in the correct way. For this specific test, run the VI, then simply enter run number 100 and click on the Report button. In this case, I would like you to take a look at the results that I came across during multiple tests on my end. To do this, don't add more data to the Historical Log database, just use what I have provided.

Using this data, you will (hopefully) find that the binary search routine doesn't work as expected for run #100. It will locate a timestamp that is before the timestamp associated with the Start Run string in the Process Events tag. This causes the binary search (timestamp) routine to act unexpectedly.
0 Kudos
Message 9 of 13
(4,849 Views)
Hi,
Sorry about the delay. I didn't receive a notification from your last post (still working out the kinks of the new forum I suppose). Anyway, I deleted all the files you sent to me and redownloaded them from this forum. This was to ensure that I hadn't added anything to the database. Upon doing so, I ran your VI for the first time. I simply opened it, made sure the Run# was 100 and clicked on Report. It then gave me a string in the results array. When I changed the Run# to 101 nothing appeared in the results array.

I guess I don't know what unexpected behavior I am looking for. For your convenience, I have attached a screenshot of my runs below. I'd love to help you out more, so please advice further.

A.S.
Applications Engineer
National Instruments
Anu Saha
Academic Product Marketing Engineer
National Instruments
0 Kudos
Message 10 of 13
(4,829 Views)