LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Do tunnels retain historic or live data?

Hi All,

 

A rather strange bit of LabVIEW black magic as far as i can see..............

 

In the attached picture the bits of interest are highlighted with red circles. The VI is for streaming data from a Picoscope (see http://downloads.picotech.com/drivers/ps2000sdk_r6_2_14_0.zip for the files - this is ps2000_fast_stream.vi) and is what is provided from Picotech. When i run the vi, "buffer 2" gets loaded up with 1 million zeros (as expected) while the Picoscope is being set up and settings written to it. We then enter the while loop where data is acquired quickly and displayed on a graph. The values from "buffer 2" get passed through the tunnel highlighted in red. What is odd (at least i find it odd - perhaps i just don't know LabVIEW very well) is that each time the while loop iterates "buffer" is updated with live data from the oscilloscope. It is 1 million points long, but the first n data points are the live measurement from the scope.

 

As far as i can see the tunnel is not retaining and passing through the historic data passed to it (as i would expect it to do), but is passing through the live data from the Picoscope. In other words it seems that the bit of memory that retains the value for the tunnel is being over written with the live data from the Picoscop. This seems very sneaky 🙂

 

Any thoughts?

 

Dr Phil

0 Kudos
Message 1 of 24
(4,356 Views)
Based on just the image, there is no way for 'buffer' to change once the while loop starts. It is an indicator and should be the same as what is shown in 'buffer 2'. However, you have not attached the actual VI and you are using a lot of local variables (too many, it seems) so it would be nice to have the actual VI to see what you have in the other frames.
0 Kudos
Message 2 of 24
(4,313 Views)

Hi Dennis,

 

Thanks for replying. VI is in the link. Buffer does change once the while loop starts, so i really don't understand what is happening!

 

Best regards,

 

Dr Phil

0 Kudos
Message 3 of 24
(4,297 Views)
Attach the file HERE!
0 Kudos
Message 4 of 24
(4,294 Views)

Hi Dennis,

 

File attached.

 

Best regards,

 

Dr Phil

0 Kudos
Message 5 of 24
(4,286 Views)
I'd also like to say that this is Picotech's VI and not something I have written!!
0 Kudos
Message 6 of 24
(4,282 Views)
But it's something you have modified. The VI in the zip file does not have the indicators in the image you posted. Your image also shows a broken VI and that does not match what's in the zip file either.
0 Kudos
Message 7 of 24
(4,274 Views)

Hi Dennis,

 

Modified file attached. The only modifications that i am aware of is to insert the two graphs buffer and buffer 2.

 

This VI runs and buffer updates!

 

Dll's and other dependant vi's should be in the zip that i previously attached.

 

Dr Phil

0 Kudos
Message 8 of 24
(4,244 Views)
Since I do not have the hardware, I've had to simulate the acquisition and no matter what I do, I always see the same data in both the buffer and buffer2 graphs. Frankly, I don't see how it's possible to see something different.
0 Kudos
Message 9 of 24
(4,221 Views)

Oh yes something is going on!  I haven't downloaded the code but--- look at the sequence locals- two SL writes and I only see 1 SL out terminal.  Someone has overlaped tunnels and SL nodes from the other frames.

 

Just another reason to stick with a good programming style guide: avoid stacked sequences (use a state machine), avoid local variables. and never never stack tunnels.

 

Attached is a piece of write only code to show what I mean

undefined


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 24
(4,201 Views)