LabVIEW
Request Deallocation LV 8 Bug
I can't figure out what's going here. It' seems to be some sort of memory allocation issue.
The first time I run the "Smaller Version.vi" attached VI, the Time Stamp converts correctly to a LabVIEW Time Stamp. Subsequent runs without closing the VI result in the Match Pattern function not finding the colon and not converting the time correctly.
If you run it with Highlight Execution on, you'll see the Match Pattern function does not find the first colon and outputs a -1 on the Offset Past Match terminal which stops the loop, as it should after it finds the last colon on a good run.
If I close and reopen the VI, it runs correctly the first time, but again incorrectly after that.
We've managed to find two things that will make it run correctly without closing.
If you make either of the array index controls larger, as in able to display a larger number (stretch it to the left) it will again convert correctly once.
What seems to fix it for good is to either remove the "Request Deallocation" function or change it's flag to a False. So this seems to be the root cause of the problem.
The "Samllest Version.vi" attachment shows the same problem but without any arrays, so the problem seems to be with the Request Deallocation function. And in case you're wondering why I'm using this function, the full version of this VI has a lot more going on and usually reads in a data file with several hundred thousand data points for processing and I wanted to clean the memory after this was done.
We've verified this on two WinXP Pro SP2 PCs running the downloaded version of 8 activated as the Pro version. I saved it back to 7.1 and it works fine there.
I've already talked to NI support about this and will post the feedback.
Ed
The first time I run the "Smaller Version.vi" attached VI, the Time Stamp converts correctly to a LabVIEW Time Stamp. Subsequent runs without closing the VI result in the Match Pattern function not finding the colon and not converting the time correctly.
If you run it with Highlight Execution on, you'll see the Match Pattern function does not find the first colon and outputs a -1 on the Offset Past Match terminal which stops the loop, as it should after it finds the last colon on a good run.
If I close and reopen the VI, it runs correctly the first time, but again incorrectly after that.
We've managed to find two things that will make it run correctly without closing.
If you make either of the array index controls larger, as in able to display a larger number (stretch it to the left) it will again convert correctly once.
What seems to fix it for good is to either remove the "Request Deallocation" function or change it's flag to a False. So this seems to be the root cause of the problem.
The "Samllest Version.vi" attachment shows the same problem but without any arrays, so the problem seems to be with the Request Deallocation function. And in case you're wondering why I'm using this function, the full version of this VI has a lot more going on and usually reads in a data file with several hundred thousand data points for processing and I wanted to clean the memory after this was done.
We've verified this on two WinXP Pro SP2 PCs running the downloaded version of 8 activated as the Pro version. I saved it back to 7.1 and it works fine there.
I've already talked to NI support about this and will post the feedback.
Ed
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Very curious find, Ed. Seems reproducible. 😞
In any case, if you substitute "scan strings for tokens", the problem does not occur, see attached. 🙂
Hi Ed,
Good catch indeed! I will file a corrective action request to the LabVIEW developers about this issue. I have already talked to some of them, and they are very interested in looking into the reason for this.
I'll post any updates to this thread - until that it seems that Ben's solution will do as a workaround.
Thanks again!
Good catch indeed! I will file a corrective action request to the LabVIEW developers about this issue. I have already talked to some of them, and they are very interested in looking into the reason for this.
I'll post any updates to this thread - until that it seems that Ben's solution will do as a workaround.
Thanks again!
