04-02-2015 12:37 PM
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?
Solved! Go to Solution.
04-02-2015 12:41 PM
The global variable should be overwritten each time you do a read. Are you sure you are getting different messages?
04-02-2015 12:52 PM
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)?