Do tunnels retain historic or live data?

[therealkilkenny]

Hi Dennis,

I was afraid you might say that.......

I've made a screen shot video that will hopefully convince you.

Best regards,

Dr Phil

[JÞB]

Oops- forgot to finish the first example

[therealkilkenny]

Hi Jeff,

The code has been horribly written, no question there. I only have LV8.5 so i can't only look at your code as a picture......

Have you taken a look at the video? I still don't understand why the tunnels are reading the live value and not the initial value supplied when the while loop started.

Best Regards,

Dr Phil

[RavensFan]

I am not a .dll expert, but here is my take.

It has to do with the setup of the dll and the allocation of buffers by LabVIEW.  I think the .dll call is something continually running in the background feeding data into its memory space.  The call to the dll for that array is a pointer to the allocated array space.  The data comes out and goes into buffer 2 then into the inner while loop and buffer 1.  LabVIEW isn't allocating any buffers between the dll call and the two indicators.   So as the while loop runs, you are getting data in the while loop that is continually being updated by the dll running in the background.

I bet if you use the "always copy" primitive after the dll call, you won't see this issue.

The only reason you don't see any changes in buffer 2 is that its indicator only gets update one before the inner while loop starts.

[smercurio_fc]

From what I can tell I would agree with Ravens Fan. What you are seeing is the DLL updating the memory behind LabVIEW's back, so to speak. This is how that DLL is designed to work in the first place. It requires that the parent program allocate a buffer and pass the buffer to the DLL. The DLL then updates the buffer with the new data.

[JÞB]

Exactly

ps2000_get_streaming_values
unsigned long ps2000_get_streaming_values (
short handle,
double *start_time,
short *pbuffer_a_max,
short *pbuffer_a_min,
short *pbuffer_b_max,
short *pbuffer_b_min,
short *pbuffer_c_max,
short *pbuffer_c_min,
short *pbuffer_d_max,
short *pbuffer_d_min,
short *overflow,
unsigned long *triggerAt,
short *triggered,
unsigned long no_of_values,
unsigned long noOfSamplesPerAggregate
)
This function is used after the driver has finished collecting data in fast streaming
mode. It allows you to retrieve data with different aggregation ratios, and thus
zoom in to and out of any region of the data.
Before calling this function, first capture some data in fast streaming mode, stop fast
streaming by calling ps2000_stop(), then allocate sufficient buffer space to receive
the requested data. The function will store the data in your buffer with values in the
range PS2000_MIN_VALUE to PS2000_MAX_VALUE. The special value
PS2000_LOST_DATA is stored in the buffer when data could not

---

smercurio_fc wrote:
From what I can tell I would agree with Ravens Fan. What you are seeing is the DLL updating the memory behind LabVIEW's back, so to speak. This is how that DLL is designed to work in the first place. It requires that the parent program allocate a buffer and pass the buffer to the DLL. The DLL then updates the buffer with the new data.

---

Always helps to read the doc-  I'm surprised

[therealkilkenny]

Hi All,

Thanks for the replies. 

Jeff, as far as i can see ps2000_get_streaming_values is not called in this VI. That is what doesn't make sense to me. I would expect to make repeated calls to the dll as you describe to access the values. That's not what happens though.

I still don't understand what exactly is happening in the VI. It seems like a little bit of LabVIEW Black Magic and I'd like to know if it is evil magic (i.e. don't ever do this) or cunning magic (this is advanced stuff for super efficient operation but only by wizards who know exactly what they are doing).

Has it been done like this to prevent repeated fast calling to the dll that will incur a processing overhead and ultimately slow down the speed that data can be retrieved from the buffers? Is this a function of clever dll writing (and thus can only be done where the dll has been specifically been written to do so) or can this trick be used in more or less any dll (I've got another application in mind where I'm running into problems making superfast repeated calls to a dll to acquire data)?

Best regards,

Dr Phil

[therealkilkenny]

Hi Ravens Fan,

I've just reread your post and this is starting to make sense now. Any answers to the questions in my post above gratefully recieved.

Best regards,

Dr Phil

[RER]

I have to agree with Jeff & Denis here. Use of the statemachine design artictechure will make your code infinitely more readible and easier to maintain.

If you have not encounterred it before, here is a tutorial which discusses their use in more detail.

Application Design Patterns: State Machines

Furthermore, do not forget that a statemachine design template ships with LabVIEW. You can find this by navigating to FILE > NEW, then expanding From Template > Frameworks >Design Patterns. Using the template gives you a bit of a running start.

Thanks guys,

[Ben]

Add me to the list that are backing up Ravens fan.

Passing an array for a dll to play in hilights one of those unusual situations where can travel backwards through a node. In the previous image we could see an array being allocated and passed to the dll. If that wire was branched and checked after the dll ran, you could actually see non-zero data in the array. At least that is what I observed back in LV 5.1 or so.

The alwaysw copy should let you take a snap-shot of what is in the buffer NOW.

 Ben