LabVIEW
When is dataflow not data flow? Updating LabVIEW Arrays through Call Library Function Nodes?
I recently was tasked with using a PicoScope and ended up as flabbergasted as the rest of you. To further muddy the water, here is another example. I cleaned up the example code which resulted in the following. The buffers are put into a queue where the driver then updates their data. The stacked sequence structure contains a SetDataBuffers for each enabled channel.
This is utterly obscure and only appears to work thanks to LabVIEW's lazy memory reallocation for optimization purposes. It is definitely not valid dataflow and can break by any number of reasons, including future LabVIEW memory allocation changes for reasons like optimization or security improvements.
The proper implementation would export additional functions from the DLL that are specifically written for LabVIEW and work with proper memory allocation schemes with a defined allocation and deallocation routine for the buffers.
Dang... I know this isn't guaranteed to always work, but I have a project right now that uses shared memory to do very high speed data synchronization over SCRAMNet. I might have to actually try to pull this one off; right now, copying all of the data from the SCRAMNet memory location to a LabVIEW wire is taking something like half of my total loop time. Since LV doesn't normally provide ways to write directly to a memory location I have to rely on some looped dll calls anyway... and this MIGHT let me squeeze a bit more performance out of my code.
Of course any old update might break it, but I like to live dangerously. 😉
