LabVIEW
Insert into Array is not delivering the expected array
Solved!
@Amr95 wrote:
@altenbach wrote:
You did not attach your subVIs, but wouldn't it be more reasonable to append the new data to a file instead of writing all data (mostly redudant) with each iteration?
I am not sure I got what you meant here, I am writing the data and sending it via a Queue to the Data Logging loop like how it is done in the Continuous Data Acquisition and Logging template from LabVIEW.
I propably I misunderstood what you meant.
If I understand your code right, you are collecting all data in shift registers and with each iteration you form a 2D array from all shift register data collected so far that you seem to send somewhere. This means that the first array element gets sent numerous times, with each iteration, over and over. Every time you send, you send all data, most of it has already been sent in the previous iterations. Very wasteful and redundant.
In a better approach, you would only send the new data from the current iteration. You did not attach your subVIs, so we can only guess.
@Amr95 wrote:
Every time you send, you send all data, most of it has already been sent in the previous iterations. Very wasteful and redundant.
In a better approach, you would only send the new data from the current iteration. You did not attach your subVIs, so we can only guess.
Oh ok I get it now. Yeah it would make more sense to send the new data only, not the previous iterations as well. So I could realise that by giving up the shift registers, right?
Yes, the shift registers would be redundant.
Alternatively, collect all data in the shift registers and write all of it one time, when you stop.
Search LabVIEW like a graph!
@Amr95 wrote:
Every time you send, you send all data, most of it has already been sent in the previous iterations. Very wasteful and redundant.
In a better approach, you would only send the new data from the current iteration. You did not attach your subVIs, so we can only guess.
Oh ok I get it now. Yeah it would make more sense to send the new data only, not the previous iterations as well. So I could realise that by giving up the shift registers, right?
I cropped the Data Acquisition and Logging part of my Main program and attached it here so I don't confuse you anymore with guessing.
Don't name your queues! (Well, suit yourself, but be warned.)
You're wiring the queue references, as you should. The names are redundant, and can be harmful. By naming queues, you're making them a global recourse, which is bad.
Give the constant a label. You'll see those labels in the help when you hover above the wire...
On a similar note, why not straighten those wires? The Release Queue of the UI queue is called right after it's allocated. An automatic diagram cleanup made this clear. But if the code was nice and tidy, you wouldn't even made the mistake in the first place. Perhaps this is just because you're still editing...
@Amr95 wrote:
Don't name your queues! (Well, suit yourself, but be warned.)
You're wiring the queue references, as you should. The names are redundant, and can be harmful. By naming queues, you're making them a global recourse, which is bad.
Give the constant a label. You'll see those labels in the help when you hover above the wire...
Hmm I am not sure what global recourse means. Could you elaborate more please?
Should I leave the name terminal unwired then?
The name of a queue makes the queue accessible anywhere. The reference is globally stored by it's name. So you can use Obtain Queue anywhere. If the name already exists, the existing reference is returned. If the queue types match, you'll get an error if they don't.
So for example you have a queue named "main". Now you add some code (a module, library or whatever), that incidentally also has a queue named "main". The two will conflict.
The name of a queue makes it possible to get the queue anywhere. The problem is, you can get the queue anywhere... Like a global.
Yes, leave the name unwired.
I encountered another problem that I would like to add to that thread as I added the SubVIs here and discussed my program here already. When I press the start button so the Acquisiton and logging starts I get all the data since I started the program saved in my measurement file not from the instant I press start. I then checked the loop where the data that is enqueued , generated and sent through queue to the Data Acquisition SubVI and I found out that the data gets enqueued once I start the main program and when I press start they all get sent to my acquisition and Logging loop.
I thought about adding a case structure in that producer loop (let's call it supervisor loop) and add the cases start,stop,Acquire like in my Data Acquisiton and Data Logging subVIs to start enqueuing only when I press start but it stopped other critical operations running in that Loop that are meant to supervise important parameters in my application and send signals to my application to react in case an error occurs. So recieving the start,stop,acquire messages became the priority for the Supervisor loop which could damage my testbench.
To put it briefly, how could I acquire the data starting from the moment I press the start button without affecting my supervisor loop?
