Citadel Issue - write numbers and then read back slightly different numbers???

[Mattjk]

I have been working on a project that writes data to the database in a timed loop.  Later in time I need to be able to change data and the only way to do this is to delete the trace and re-create it with the changes in place.  I have created a VI called backfill that does just that.  The problem is that when I write values to the database (after deleting the trace and re-creating it) the values turn out to be written slightly off as shown below.  Attached is three screen shots.  The first "Original Data.jpg" is the original data read back from the database.  The second screen shot "Saving Changed Data.jpg" shows the three values being saved via write trace using a probe.  At this point, I used MAX as explained below to see the actual values being written.  The third screen shot "Data read back.jpg" shows the data after it has been read back.  

I tried turning off the compression option when deleting traces but this has no effect.  I have made sure that I use doubles as numeric representations everywhere.  I just don't get it.

Please Help.

Matt

I used MAX to export the saved data to a text file.  This was taken before the read occurred.  You can clearly see that during the write trace, the input numeric values going in were 1, 2 and 3.  After that, looking in the database directly yields 1.00481, 1.99481 and 2.99481 as seen on lines 3, 4 and 5.

1 10:01:02.924 AM 12.6848

2 10:01:03.024 AM 2.21481

3 10:01:03.124 AM 1.00481

4 10:01:03.224 AM 1.99481

5 10:01:03.324 AM 2.99481

6 10:01:03.424 AM 73.5848

7 10:01:03.524 AM 45.3048

8 10:01:03.624 AM 90.5548

9 10:01:03.724 AM 49.4748

10 10:01:03.824 AM 28.3348

[Mattjk]

Here is the program.  What I do is wait until the start of a minute on the clock to run it.  It creates the database and process and starts recording.  Then stop it and open up the backfill program and put a time range in there that you started collecting data.  Click the display data button to view and try changing data then click the save data button and then display data button again.  So you are basically reading, then changing data, then writing data, then reading back the data.

Thanks for looking into it.

Matt

[Mattjk]

I forgot to mention that main.vi is the first program to run.

[BTreece]

Hi Matty, 

While you have done a very good job of using subVIs in your application, I cannot find where you are actually getting the data to write back to the trace, so therefore having a hard time finding the problem.  Is there any way that you can cut this code down so that it is easier to look through and so we can narrow down the cause of this error?  That would make troubleshooting much easier.

Brandon Treece

Applications Engineer

National Instruments

[Mattjk]

Hey B Treece,

I have been working on my code and it is a little better than what it was.  Before you begin, make sure that the CEM Database is deleted from MAX (if it exists from before. Every time you run this program you should delete the CEM Database to simplify debugging).  If you run the main.vi it will begin saving data to a trace (timed Loop).  If you go to edit --> backfill  this will bring up the backfill VI.  Then click on the From "set time date" and select the "set time to now" and OK.  Then Click on the To "set time date" and select the "set time to now"  and OK.  Now if you click on the "Display Records" it will get the time range you just specified from the database and display it in the cluster array.  At this point try to change a few values in the cluster array (only the numeric data, not the time).  Then click "Save Changes" which will save the changes you made.  Now click the "Display Records" again.  This will read back the same data you just saved.  Notice how it read back slightly different numbers than what you saved?

The backfill.vi is an event structure and the actual Vis that write traces is the "Write Changed Data.vi" which runs when you click "Save Changes" button.  The vi that reads traces is the "Read Selected Data.vi"  and this runs when you click "Display Records" button.

At this point it would take too much time to minimize the code.  To help you figure out this one I should tell you that I have ran it on multiple computers with the same result.  I think that it has to do with deleting a trace and re-creating the same trace with slightly changed element values.

Hope this helps.

Thanks

Mattyk

[Mattjk]

OK OK OK,

I have re-created the problem.  When you run it the first time it generates an error:

Citadel:  (Hex 0x8ABC1003) The operation cannot be completed because the resource is in use by another client.

I could debug this but if you stop it and re-run it it will work this time.  If you notice, it tacks a 56 on to the end of all elements.  This is defiantly a Labview bug.

Let me know what you think.

Thanks

Mattyk

[Elizabeth_K. · Accepted solution]

Hi Matty,

Thank you for those demo programs, it really helps with the debugging.  First, the Hex 0x8ABC1003 error occurs because at the end of the program you do not have the error wires from Get Trace List.vi wired to Read Trace.vi, so they try to execute at the same time.

Secondly, the reason you are seeing different values than the ones you are writing has to do with the precision of the database. If you notice the Open Trace VI has an input titled "value precision", which if nothing is wired to it, defaults to 0.01. If you want to store uncompressed values, wire in a value of 0. You will then notice that the read data is exactly what you input, as in the modified debug.vi attached.

Regards,

Elizabeth K. 

National Instruments | Applications Engineer | www.ni.com/support 

[Mattjk]

Thanks a lot.  I assumed that the default precision was based on the precision of the value you write.  Problem solved.