LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

string buffer

Solved!
Go to solution

There's probably a very simple answer to this; just not simple enough for me to figure it out.  I'm running LV 2012.  Attached dump shows vi used to program a part, on a production tester.  On this tester, hundreds of boards will be processed daily, and I don't have any apparent problems with this particular vi.

The 'Segger read buffer' is a global string indicator.  My question relates to this buffer.

If this was C code, I would reset the pointer into this buffer each time this vi runs.  Since I don't have a way to do that, I can only assume that, as I continue to run this vi, that each response from the Segger programmer is tacked on at the end of the previous response.  This implies that the buffer continues to grow in size.  So, is that what happens?  I don't get any fatal errors, so I 'assume' nothing bad is happening.  If I look at the global indicator for this buffer, I do not see it being updated with new messages, as the testing continues.  This supports my belief that messages are being appended.

If these buffers operate as I've postulated, there must be some limit to their size; maybe it will try to use all available RAM?

Is there a way to 'reset the pointer', so that I overwrite the buffer every time I use it?

0 Kudos
Message 1 of 3
(3,399 Views)
Solution
Accepted by topic author seawollf

The global variable should be overwritten each time you do a read.  Are you sure you are getting different messages?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 3
(3,393 Views)

You're correct.  The reply message from the programmer shows thing like erase time, programming time, etc.  When I looked at it previously, it appeared to me that nothing was changing in the response, which I found to be unlikely.  So, I just looked at it again, and, indeed, the message does change.  So it might have been that the reply message was unchanged, when I looked at it before; or, it could have been cockpit problems.

Thanks for the quick response.  Where is it documented that the buffers work like this (I would have assumed that they HAD to work like this)?

0 Kudos
Message 3 of 3
(3,382 Views)