I'm trying to understand some example code from the SDK of an instrument (a Picotech oscilloscope, link to SDK). If I look at one of the example routines, such as the snippet below, my immediate expectation is that the I16 array going into the inner loop would have its values update once per iteration of the outer loop and would stay constant while the inner loop executes. In fact, when you hook up the hardware and run it, the array updates every time the inner loop executes. What's going on is that those subVIs are essentially just wrappers around some calls to external routines linked in through DLLs, and the routine just before the inner loop (PS4000 Start Stream) sets up a fixed-size buffer (the I16 array) and the routine inside the inner loop (PS4000 Get Stream Values) does an in-place overwriting of some part of that chunk of memory associated with that buffer array, so that when the array subset command executes, it extracts the latest measurements from the buffer into a dedicated array for display or further processing. My question is essentially what are the rules associated with this sort of thing? In my own code, I can just slavishly copy the structure of this example, but I'd prefer to understand exactly what are the constraints in terms of what can I do with that buffer array that won't break the behind-the-scenes updating and also if there's any straightforward way of telling that this is going on in general code (since it does essentially break the dataflow paradigm). What I've been doing in the early versions of my own code is to take each chunk as it's spat out by the Array Subset operation, stick it into a queue, and then use a separate consumer loop to dequeue and process as needed; so just treat the initial source of the data as a bit of a black box. I'm nervous about using (or writing!) code that I don't fully understand, so that's not really ideal... Thanks, Daniel

LabVIEW

In-place overwriting of memory chunk by external libraries

Author

So I got manual memory management to work (crashing LabView a few times before I figured out the exact right format for creating and reading memory blocks...). Code works much better now; besides the memory issues, I can now use some sane wire (and data) management. Instead of anywhere up to 11 (!) output terminals emanating from the setup routine, I only have four (1 or 2 buffers per channel, 4 channels, originally separate terminals for each but now a single array of clusters; also an error cluster and a couple of control/config lines).

Looking in more depth at the SDK code, I realized it was a near miracle that it worked at all. The snippet here is from the setup routine supplied by the SDK.

(broken wire coming in from the left comes from a control setting the buffer size) Notice that there are two buffers associated with this channel; one is used internally by the driver routines (presumably to hold the data streaming off the device) and one is exposed to the application (data copied from the internal buffer as needed). In particular, note that from a LabView perspective the array emanating from the first DLL going into the second is entirely internal to this subVI, which means that a memory manager would be entirely justified in saying to itself "well, we're done with that chunk of memory, guess I can reuse it" as soon as the 2nd DLL call completes or at the end of the subVI execution. Of course, the rest of the library would cheerfully go on reading and writing to that block of memory that's being used for something else....

(Annoying software aside, the scope hardware is very nice. I'm working with the Picoscope 4262, which does 16 bit sampling with fairly low noise at up to 10 MS/sec on each of two channels (simultaneous sampling) and will stream one channel at full speed over a USB2 link for hours and hours at a time without any dropouts that I could see)

Message 11 of 11

(541 Views)

LabVIEW

In-place overwriting of memory chunk by external libraries

Re: In-place overwriting of memory chunk by external libraries