Do tunnels retain historic or live data?

[therealkilkenny]

Hi RER and Ben,

Thanks for your comments.

@RER - I am not under any illusions about the fact that this code is badly written and that there are better ways of doing it (It's not mine - I routinely use large state diagrams for complex data acquisition from dll's). My question is not how to do it better. I know how to do that. My question is how is it working and is there a good reason to do it this way (e.g. speed).

@Ben - "If that wire was branched and checked after the dll ran, you could actually see non-zero data in the array" - do you mean that "buffer 2" should have non-zero data after passing though the dll? If so I'm afraid to inform you that "buffer 2" never shows anything but zeros. If not, then I don't know what you mean.

My questions:

• Is the overhead on getting the data in the while loop smaller doing it this way rather than calling the dll every iteration of the while loop? Would it make for super fast collection of data into LabVIEW?
• Does the dll have to be written in a very special way for this to work or could any dll where you collect data by making repeated calls to the dll be done this way?

Best regards,

Dr Phil

[JÞB]

• Is the overhead on getting the data in the while loop smaller doing it this way rather than calling the dll every iteration of the while loop? Would it make for super fast collection of data into LabVIEW?
• Does the dll have to be written in a very special way for this to work or could any dll where you collect data by making repeated calls to the dll be done this way?

Best regards,

Dr Phil

---

Some answers

• vastly smaller overhead.  the dll is called once and remains active at its task of updating a defined memory buffer until it is told to stop.  LabVIEW is merely copying that dynamic buffer to the indicator each time the indicator node is reached (each while loop iteration.)
• Yes - and I was surprised at the dll's construction.  I think that with LabVIEW's dynamic memory allocation scheme, that there is a risk of the buffer being moved without notifying the dll.  For most text based languages this would not be an issue but I would be very cautious of depending on LabVIEW memory management to keep the buffer it passed to the dll in place.  This dll functions behavior totally breaks a data-flow paradigm.  If this is used in a large program with large memory growth after this dll function is called you are going to have even more "interesting" moments.

[therealkilkenny]

Hi Jeff,

Thanks - exactly the answers I was looking for. 

• is there any other way to implement this much smaller overhead as i have another application where i'm running into problems with the overhead of making repeated calls to the dll?
• why doesn't LabVIEW implement a variation on this that handles the memory management so that the data flow paradigm is not broken.

Best Regards,

Dr Phil

[JÞB]

---

therealkilkenny wrote:

Hi Jeff,

Thanks - exactly the answers I was looking for. 

• is there any other way to implement this much smaller overhead as i have another application where i'm running into problems with the overhead of making repeated calls to the dll?
• why doesn't LabVIEW implement a variation on this that handles the memory management so that the data flow paradigm is not broken.

Best Regards,

Dr Phil

---

The problem is not with LabVIEW breaking the data-flow paradigm.  The dll is.  You've started a function in the dll that keeps going until you tell it to stop.  That function keeps overwriting a bunch of memory that LabVIEW looks at from time to time.   However, LabView is free to re-assign that block of memory at its discresion.  And LabVIEW will reassign that memory block if the memory needs of another buffer grow to the point where LabVIEW assigns a new block of memory for an unrelated variable (call it Var_Y) and "moves" the memory space for "buffer" .  However, (comma - pause for effect!) the dynamically reassingd memory location for "buffer" is not passed to the dll which is still updating the same space in memory.  So the dll now updates Var_Y and "buffer" stops changing.  UGLY!  

I think (KNIGHTS and CHAMPIONS help on this) you might make this dll function safe by using the In-place functions when you read the data- Does that preserve the memory location a variable uses?  I just don't have enough visability into the LabVIEW data management guts to give you a firm answer.