Data saving at differnet speeds on different computers

[labview212]

I have a data acquisition (over serial) display and record vi set up that reocrds one sample every .05 seconds (20Hz) on my laptop running labview 13. If i pass the vi on to another laptop with labview 15on it i suddenly do not get regular data samples. they are haphazard. some are every .01 sec some every .03, etc. there are still 20 samples per second though, but some are duplicate samples meaning the timestamp on them is the same as so is the data. Any ideas why this woul dhappen?

[Bob_Schor]

It depends, in part, what your code (which you are keeping secret from us) tells it to so.  We could probably answer your question if you posted your code (by attaching the VI -- we need to be able to examine all of the code, and even run it, something we cannot do with a picture of part of the Block Diagram).

Bob Schor

[crossrulz]

---

@labview212 wrote:

but some are duplicate samples meaning the timestamp on them is the same as so is the data.

---

That tells me you are using the wrong type of communication scheme between parts of your code.  Of course, impossible to say for sure without some code to analyze.

[labview212]

---

@crossrulz wrote:

---

@labview212 wrote:

but some are duplicate samples meaning the timestamp on them is the same as so is the data.

---

That tells me you are using the wrong type of communication scheme between parts of your code.  Of course, impossible to say for sure without some code to analyze.

---

Here is the code.

[Gregory]

It is very hard to interpret this code, so I will first say what I think might be the issue, and then give a couple of general pieces of advice.

The part of your code in the middle loop that puts the timestamp on the cluster has no data dependencies. This mean as soon as that middle loop starts rolling, it grabs the time. However, the loop won't complete its iteration until it gets an element off the queue shared by the middle and bottom loop. Once an element is dequeued, it isn't long before the loop finished iterating and the (premature) timestamp is grabbed again.

Some general advice:

Make your clusters type definitions

Keep wires free of unnecessary bends

Create SubVIs to make functions more compact

Use shift registers more to store data, and use property nodes / local variables less

[labview212]

---

@Gregory wrote:

It is very hard to interpret this code, so I will first say what I think might be the issue, and then give a couple of general pieces of advice.

The part of your code in the middle loop that puts the timestamp on the cluster has no data dependencies. Would I be better served in the interim to place the time in the same loop as the visa read? So it reads the timestamp and adds it to the queue at the time of reading?  This mean as soon as that middle loop starts rolling, it grabs the time. However, the loop won't complete its iteration until it gets an element off the queue shared by the middle and bottom loop. Once an element is dequeued, it isn't long before the loop finished iterating and the (premature) timestamp is grabbed again.

Some general advice:

Make your clusters type definitions

What does this mean?

Keep wires free of unnecessary bends

How do you do this, aren't wire connections automatic when you hit CTRL+B?

Create SubVIs to make functions more compact

Where would you recommend I create subVis? for the graphing maybe?

Use shift registers more to store data, and use property nodes / local variables less

---

Some questions above in Red

[Gregory]

• Yes, you can add the timestamp in the loop where you read the data if the intent of your timestamp is to mark when the data is read.
• A type definition is like a custom data type. You can right click the cluster and press "make type def..." Then you can open the type def and edit/save it. Now, whenever you need that custom data, you can use the .ctl file you just made and drop it on the block diagram. If you edit the type def, the edit will propagate to all instances of that type def!
• Wires may seem like a superfluous concern, but with LabVIEW programming it is essential to keep your wires neat if you want to be able to read your code! This is done by using standard connection terminal on your SubVI (references on top terminal, error on bottom terminal), storing related data in clusters to minimize the wires, using good architecture to make your program scalable. Take a look at the "simple state machine" to see how you can use shift register/clusters to store data, and use a case a structure to separate different tasks in your code. 
• Whenever you find yourself copy and pasting code that might be nice to re-use, that is a good cue to make a SubVI. Or if you are making some complicated calculation or data manipulation that takes up a lot of space on the block diagram, it is nice to tuck that away into a SubVI.

[labview212]

Along the same line as putting the timestamps in the data write consumer loop, if I want to change the run speed of the VI, should I use a wait like I have now? basically to get 20Hz I put in a 50ms wait in the visa read/write loop, (then to display on all the graphs once per second update rate I divide their scales by that rate) should this go somewhere else? Like have it read at CPU speed and put the wait in the tdms write loop?

[Gregory]

I don't have too much experience with really tight timing requirements. You definitely want some kind of timing control function in there, otherwise the loop will just take up as much processor as possible, which will slow everything on your computer down.

The Wait function is basically a piece of code that says whatever structure it is in is going to take at least this long to run. So if you put your Wait with 50ms next to code that takes 30ms in a loop, each iteration will take 50ms. If you put it next to code that takes 70ms to run, the Wait will no effect, it is the code that takes longer to run that will determine the loop speed.

There is hardware available for real-time systems, which can handle the timing much better than the Windows OS. But if you know your code runs more quickly than your Wait time, and you don't care too much about jitter in the measurement time (you have to define what too much is) then your Wait function will be fine.

You can even enforce it so that the timestamp that goes with your data is grabbed immediately after your VISA read. How do you do this? You put your timestamp code inside a SubVI with 3 terminals: Timestamp Out, Error In, and Error Out. You simply are using the error terminals to enforce data flow in your program.