LoisLbs

Thank you for your answer. So, I tried check/uncheck different build option and it seens that checking the "Disconnect type definitions" works in my case..

Hi, I post again because I finish my project and wanted to create an executable but I have a LabVIEW error saying "This Vi is not in memory". It concerns my VI with the VIs "Create DVR Buffer". When I delete "Create DVR Buffer" VI, the compilation works. Then I made some tests of build with my own malleable buffer test vi and it really really weird. At the beginning it works well and when I delete some part of code, it refuses to build anymore even if the part of code I deleted do not concerned the malleable buffer (on the video, you see that with openG vi). Attached a screen record showing that. Any idea of the problem? Thank you. 0bdbd340-47c4-4bff-a9b2-ef384a796478.webm

Hi everyone, First thank you for your work, I recently downloaded "Malleable Buffer" for a project and I think it's very useful and easy to use! It will certainly be a part of my tools from now However, i have encountered a bug who cost me some times of debugging. I have found a correction even if I still don't really understand why it behaved like that... So I would like to share this with you to improve futur versions I had an application with 2 processes (threads), a writer and a reader with differents frequencies. The type of my data is : I explain my bug. My reader has a frequency lower than the writer. So the reader has to read several points (i used a for loop with the "Read Element by Index of Count" function) and I increment my own readIndex. I noticed that when the reader try to read data at the end of the buffer, I mean if my buffer has a size of 10 elements and I tried to read elements index (8 then 9 then 0), the elements read was not 8,9,0 but something like 4,5,6 : For instance, here, element 4 is read instead of element 9. To debug, I used "Convert instance Vi to Standard VI" on my function and I finally discovered that the problem was a wrong type conversion in the function. The output of a substract was converted from I32 (in the malleable VI) to U32 (in my cas with my type). If you know why, I am interested by the explanation.... To correct this force the substract to generate a I32 in output and now it is ok ! NB : To improve this library, I would suggest to add a function to read several data (index from/to) with one function. It will used one index array instead of calling the same function several time with a for loop as I did.