10-13-2023 05:34 AM
It seems to be you're saying I should just use separate buffers each time I use the MemoryMove. I was thinking I could reuse the same buffer space via the DVR. Scratch that idea.
10-13-2023 05:51 AM
How about this? The indicator on the output of the MemoryMove eats memory by showing me the contents of the destination block that got the copy of the source block.
Memory can be reused by using the same destination block, array, over and over.
10-13-2023 06:45 AM
@*3d0g wrote:
Memory can be reused by using the same destination block, array, over and over.
It CAN, but the compiler has to weight many things, and overzealous memory reuse can cause many problems in a multi-threaded environment. So the compiler has to weight many different indications to decide if it is safe to do memory reuse. Being to conservative means unnecessary memory duplication, which can be unwanted but being to overzealous means wrong calculations or even crashes, which has to be avoided at ALL costs.
10-13-2023 09:00 AM
Sorry, late to the party so most has been said already so I won't repeat. 😄
Just a few quick comments:
10-13-2023 05:59 PM
This present thread is associated with this linked thread.
The resonant theme is how do I work with a large amount of data (16-bit) stored in memory in a way that LabVIEW does not run out of memory? What is the algorithm?
Can it be done without accessing C:\? (I recently received the suggestion of writing to TDMS file.)
Please do not suggest changing to 64-bit LabVIEW. Please. That is not an option.
10-13-2023 06:11 PM
"It CAN, but" ...
I say it must, or there is no solution. The question is am I correct?
I hope I am not and that there is a solution. I have to get large amounts of data out of memory, process it, and do it without LabVIEW running out of memory before conclusions can be drawn about the data, about the waveforms captured by the oscilloscope and stored in memory. I have the data. It's there just sitting in memory. Now what? Please do not say change to 64-bit LabVIEW. Please avoid going to the disk. Please do not say don't use indicators. 🙂
Please do say how I can reclaim memory that must be used during the data processing.
10-13-2023 06:14 PM
The DVR didn't work like I wanted. I'm not going to use it. I thought I had a pointer to already used memory. I don't.
10-20-2023 02:50 AM
"
What's the point of creating the DVR?
You init an array, put that into the DVR, then you read the array from the DVR, then you dispose the DVR. There is no place where you actually use the DVR to manipulate data inside the InPlaceElement structure…
The main usage of a DVR is to provide a "pointer" (aka reference) to a data structure so you move that small reference instead of large data structures along the DATAFLOW. You manipulate the data referenced by the DVR inside an IPE structure.
"
Actually, that was the most helpful post, to me. It showed me I couldn't use the DVR to solve my problem. Also, I appreciate your explaining what was wrong; your prompt introduced me to new tools. Thank you.
10-20-2023 02:57 AM
"
Hi 3d0g,
"knot" is "Knoten" in German, which also is the translation of "node"…
So Martin was talking about nodes in your block diagram…
@*3d0g wrote:
What's a knot, as you used the term?
When you ask someone named "you" then you should also provide a citation so we know who is referenced by "you"…
"
This also was a dynamite post. You heard my question. You answered it, well. (The bonus is you caught on to the fact that I'm unfamiliar with the workings of the software behind this forum. I have to actually direct my posts in my text entry; otherwise, it is unknown to whom I am speaking. Thank you.)
10-20-2023 03:02 AM
"You can delete all the DVR stuff in your VI and it will work the same…"
I proved that to myself, later, but not with this vi. 😉
"You keep rewriting the buffer behind the wire (which sounds dangerous to me)…"
If you wouldn't mind, I would appreciate, please, a little more detail on that idea if you get a chance.