LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

shared variable, missing data, the same timestamp for two consecutively data

Solved!
Go to solution

hello

I have a problem with missing data when I read from a network published shared variable.

 

Host VI:

In a host VI on my Laptop (HP with WinXP Prof.) i'm writing data to the shared Variable "data". Between two consecutively write operations is a minimum of Milliseconds waiting time. I use that because I want to be sure that the timestamp for each new data value is different then the preview one (resolution shared variables is 1 ms)

 

Target VI:

the Target VI on a cRIO-9012 realtime device is reading only new data in the way that it compares the timestamp of a new value with the timestamp from the last value.

 

Problem:

rarely, I'm missing a datapoint (sometimes everything works fine for several hours, transferring thousands of data correctly before suddenly the failure happens). With some workaround I'm able to catch the missing data. I've discovered that the missing data has the exactly same timestamp then the last readed datapoint, therefore is ignored in my "legal" data.

To sum up, the missed value is written to the shared variable in the host, but the target ignores him because his timestamp is wrong, respectively the same as the last value has, despite the host waits every time for a minimum of 10 milliseconds before writing a new value.

 

Note:

The shared Variable is hosted on the Laptop and configured using buffering.

The example is simplified only to show the principle function, in real I use also a handshaking and I secure that there is no over- and underflow.

 

Simplified Example:

sharedVariable_timestamp_problem.html.jpg

sharedVariable_timestamp_problem.html_2.jpg

 

 

Question:

Has someone an idea why two consecutively data can have the same timestamp ?

Where is the (wrong) timestamp finally coming from (system?) ?

What would be a possible solution (at the moment with shared Variables) ?

-> I tried a workaround with clusters where each data gets a  unique ID. It works but it is slower than comparing timestamps and I could get performance problems.

Would it change something when I host the shared Variable on the RT-System ?

 

Thanks for your help

Regards

Reto

 

0 Kudos
Message 1 of 7
(4,516 Views)

 

 Hello Reto,

 

Basically shared variables are like other variables. Meaning you can read/write data on a memory zone, but you can loose data when writing faster than reading.

Within a machine, I always advice to add a synchronization system such as Queue or Notifier. With Network SV, you can define wether you work with a scalar(default) or an array (FIFO).

Try to set your SV using a FIFO of 50 elements for instance (see attachments), so that you won't miss data as you described.

 

I hope this helps,

 

Laurent P.

AE  Switzerland

National Instruments

 

0 Kudos
Message 2 of 7
(4,491 Views)

hello Laurent

 

thanks for your answer, but that's not the problem.

 

I use already buffering and synchronization technics (by the way I think Queues and Notifiers can not be used for different application instances).

 

The problem in fact is simple. I don't really lose data, but I read two consecutively data from the shared Variable which both have the same timestamp, despite I wrote this two data with a minimum of 10 Milliseconds time difference between each write cycle.

According to the LV documents, the time resolution of shared Variables is 1 Millisecond.

 

Who is finally responsible for writing the timestamp to the shared Variable, LabView or the operating system ?

Is there a minimum time difference I have to wait between two write cycles to have a guarantee each data when reading have a different timestamp ?

0 Kudos
Message 3 of 7
(4,483 Views)

Hi Reto,

 

I had a look on your modified Example.

Because the Shared Variables didn`t work like Queues or Notifiers (No Event or Interrupt when a new value has been written. And for sure the´re not possible over a network) you will see the issue, that the code is reading the values more often with the same timestamp (Polling Problematic) if the reader is faster then the writer. And because the timestamp is written with the value you´re able to program like you do. Filter out whats duplicated when you have the same timestamp.

 

Everything is described in here:

http://zone.ni.com/devzone/cda/tut/p/id/4679#toc1

 

Laurent talked about a second depth of buffer. Please have also a look at the link. Somewhere in the middle of the tutorial you see the explanations of Buffer and RT-Buffer.

 

Regarding your question: Would it change something when I host the shared Variable on the RT-System? --> No

In my experiences, you should consider to place the Shared Variable Engine after asking some questions regarding the application.

You will find the Answers to this 3 Questions also in the link:

 

Does the application require datalogging and supervisory functionality?

Does the computing device have adequate processor and memory resources?

Which system is always online?

 

And you`re right the smalles time interval you can see in the timestamp is 1ms.!

What you also can do is working with an enabled "timed out". This might be more performance efficient than reading the timestamp.

 

What I don`t know and not find up to now, is if LabVIEW or the OS adds the timestamp. It´s taken from the system time, this looks like LabVIEW is taking the value and adds it. 

 

I hope this helps

Alex

NI Switzerland

0 Kudos
Message 4 of 7
(4,458 Views)

hey Alex

 

there is still some misunderstanding about the real problem, I'll try to explain it in other words.

 

First of all, I'm not using the RT-FIFO, but that's nonrelevant now.

 

Imagine the Host-VI runs for 1000 iterations. What do we await  on the Target-VI?

Imagine the "my legal values" as an array, collecting all values with different timestamp, filtered out whats duplicated, like you described it. The result should be an array like that [0,1,2,3..999], right?

I tried exactly that, and the result was exactly what I awaited, so far so good.

BUT, not always!

Sometimes my array "my legal values" looked e.g. like that [0..123,125..999] !?

Where was my (index-)value 124 ? I've found the value in my "ignored values" , filtered out, because the value 124 had exactly the same timestamp as the value 123 !

(please have also a look at the simplified example above to understand what I mean with "my legal values" and "ignored values")

 

I hope this helps for a better understanding what the problem is.

Regards

Reto

0 Kudos
Message 5 of 7
(4,445 Views)

Hi Reto,

 

I had a look into our CAR (Corrective Action Request Database) and the issue with the timestamps is in work at R&D. If you would like to foolow up just ask AE´s or DSM´s from NI and give this number: #125640. That´s the ID of the CAR.

 

I would prefer to program a workaround with a array, to catch slower the values (10 times per second a communication) and perhaps implement a kind of ID, to know which packet is arrived. 

 

Best regards

Alex

0 Kudos
Message 6 of 7
(4,437 Views)
Solution
Accepted by reto.wyss@bitster.ch

This issue has been resolved in LabVIEW 2010.  You can check for other bug fixes in the LabVIEW 2010 Readme.

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 7 of 7
(4,071 Views)