Most efficient to combine arrays

[RavensFan]

Are you clearing the elements out of your "buffer subVI"?

[pjr1121]

Question: for the 2D array are you using InsertIntoArray or ReplaceArraySubset?? I can't tell on my screen.

In terms of the 1D data, your code is taking a 1D array from iteration 1 and pre-pending it to the data in iteration 2.  Then, this data is pre-prended to the data in iteration 3.  Your code is DESIGNED to do what you are observing.

Please describe what you want it to do in more detail.

[altenbach]

---

@kevin_khan wrote:

I am not sure how I can accomplish this, and was wondering if anyone would have an idea.  I can try and include a picture of my code, if it might help (I do have some custom made subVIs within this section of code).

---

The code picture shows several shift registers, one with a 2D array where you seems to replace one row at a time and a 1D array where you keep appending new data to the previous data, then splitting it, keeping a part in the shift register while placing the other part into the 2D array.

Your picture is really insufficient to troubleshoot, because we cannot know what values are coming from the sequence locals. What is the index value going into "split array"? How big is the array coming out of the subVI? How big is the 2D array?

(Overall, you should avoid stacked sequences and sequence locals. Also the value property is probably not needed). 

[kevin_khan]

For the 2D array I am using the replace array subset function, sorry for the small picture. 

Basically I am trying to set up a circular buffer, which will serve as a pre-trigger buffer, and it will store data read back from the USB module (FTDI's UM232H).  The block size within the pre-trigger buffer is a specific size, smaller than the amount of data read back from the USB module, thus I need to split the array of data that is read from the USB module.  The block size is set to a specific size such that the last value in the block would be a sync word (a special character to separate each sampled package).  Now the USB module is a high speed module and thus sends data in packets that are multiples of 512 bytes.  Because of this, the usb can not send the exact number of bytes back such that it will coincide with the block size.  Thus I read more data and have to split the array to match the size of the block size. 

I am currently reading 65280 bytes from the USB and the block size is set at 57134 bytes.  The 2D array (in the image I posted) is my circular buffer and the read buffer is the function to read the data back from the USB (this a slightly modified version of the D2XX functions provide by FTDI).  When I split the array I am splitting it such that it will match the block size.   

I am not sure if this is very clear, please let me know if you need more detail information. 

[kevin_khan]

I should add, that when I place the array size function to look at the size of the concatenated arrays (the output of the build array function), I see the size is constantly growing.  However I thought that size in this particular case should have a relatively stable value, in other words it should not constantly be growing like this.  I know that the data from the read buffer is indeed being cleared.

[kevin_khan]

So I think pjr1121 was right about the operation of my shift registers.  They work the way they are suppose to work, such that they transfer data from each iteration.

What I would really like is to simply access the most recent set of data transferred into the shift register.  In other words, not all the elements within the shift register but just a portion. 

The code I have now is suppose to do this such that it will delete the unwanted portion of the shift register.  However I think that there is still a mistake in my code because even though I am deleting the unwanted elements within the shift register, the shift register still contains all the elements from before (in other words nothing was really deleted).  This might be a simple mistake on my end, but perhaps someone might be able to help me out.

[RavensFan]

Attach the Read Buffer subVI so we can see what it going on in there.  You haven't answered the question I asked in message 11.

Quote:

"Are you clearing the elements out of your "buffer subVI"?"

[kevin_khan]

The elements are being cleared in the read buffer subVI.  I will attach the subVI, however this VI will require some other VIs from the FTDI website (D2XX driver is required).

I attached the read buffer VI, as well as two others (Get_Queue_Status and Read_Byte_Data(U16)), which help make up the read buffer VI.

[RavensFan]

So you are using an RS-232 to USB converter?  Is there a reason why you are using a .dll to communicate with this rather than using normal VISA functions on a serial port?  Most USB/232 converters come with a driver that makes them appear like a normal serial port in Windows device manager.

Do you know what is going on inside the .dll?  How do you know that it isn't buffering data?

If you are going to continue using this .dll (which is already more trouble than it is worth), you are going to have to use the debugging tools that LabVIEW provides you to figure out why you are maintaining old data in your buffer.  Use highlight execution, probes, conditional breakpoints, extra indicators dropped into subVI's that you have open while running, so that you can track the data and see where it is coming from.

You have a wire going into the split array function that determines where to split it.  It comes from outside the loop, so its value never changes.  What is its value?  Perhaps your reading in data faster than the point that is allowing you to break the data.  For example, if you read in 10 bytes of data every iteration, but only break it after 5 data points, your array is going to keep growing.

[pjr1121]

---

@RavensFan wrote:

Do you know what is going on inside the .dll?  How do you know that it isn't buffering data?

---

As a test, try this.  Delete the "build array vi" block and probe the data comming directly from the Read Buffer subvi.  if this array data is increasing in size, then you have problems.  From looking at your pictures though, I am inclined to beleive that it is your shift-register array that is increasing in size, and not the data comming from the buffer.

I'm still confused on the purpose of your shift register and build array.  In my eyes, it doesn't seem to have any purpose other than augment the data being fed into the 2D array.  Is this correct?