Malleable Buffer (seeing what VIMs can do)

[hooovahh]

In 2020 SP1 I've found that an Always Copy will fix these broken wires.  That obviously comes with a performance cost and isn't ideal.  I hope 2021 SP1 fixes this.

[dannyt]

A very minor comment, the Read Buffer context Help is incorrect and a duplication of the Read Element By Index Contents Help.

[dannyt]

Another minor comment for next release.

I had an issue building a executable using the package as it introduces a missing Item within Malleable Buffer.lvproj

It is looking for 

C:\Program Files (x86)\National Instruments\LabVIEW 2021\vi.lib\addons\functions_JDP_Science_lib_Malleable_Buffer.mnu and cannot find it.

There is a functions_JDP_Science_Malleable_Buffer.mnu in the addons folder.

I simply removed the functions_JDP_Science_lib_Malleable_Buffer.mnu from the project and builds OK now.

I realize I have not said THANK YOU 🙂 🍺 another great community toolkit.

 

 

 

 

[drjdpowell]

1 hour ago, dannyt said:

I had an issue building a executable using the package as it introduces a missing Item within Malleable Buffer.lvproj

That is the Project I use to develop the library; it isn't meant to be used after install (and doesn't update the various paths, such as to teh examples).   I should probably not include it in the VIPM.    If you'd like to fork the package and develop it, I'd recommend forking the Git repo. 

That menu should have been installed by VIPM, though.  

[drjdpowell]

On 5/16/2022 at 3:38 PM, dannyt said:

A very minor comment, the Read Buffer context Help is incorrect and a duplication of the Read Element By Index Contents Help.

Fixed, thanks.

[drjdpowell]

6 minutes ago, drjdpowell said:

That menu should have been installed by VIPM, though. 

Ah, it's because I added submenus in last release, and this added '_1' onto teh menu name.  I'll fix that.

[LoisLbs]

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.

[drjdpowell]

In the actual VIM "Read Element by Index of Count" it is an I32, but I think when you connected a U32, and LabVIEW did type propagation through the code of the VIM.  Note sure why this caused your specific issue, but this needs fixing regardless, perhaps just by a convert-to-I32 node.  Thanks.

[LoisLbs]

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.

[LogMAN]

It appears to be working when unchecking the "Remove unused polymorphic VI instances" option in the build specification. Not sure why because the library does not seem to include any polymorphic VIs 🤔

[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..