LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reload VI Memory Space


@James.Morriƽ wrote:

I'm making a service request now. Do you know of a way to load a VI completely separate from the previous run which could maybe bypass this issue? Since it's an iteration crash, I assume it has something to do with memory, so maybe reloading completely will fix the issue for now.


James,

 

I do not have and answer for you.  A few questions though...  I assume the target is a Windows OS, If not the *emf file type is your likely problem but, I can't see it working a hundred times.

 

I Do see that the VI Properties for "Print Options" are "Default"  You may consider messing with some of them to test a theory

Capture.PNG

But, That is a "Long-Shot"

 

101.... that bugs me! why 101? and is it reproducable?

 

 

EDIT- when do you empty the clipboard?


"Should be" isn't "Is" -Jay
Message 11 of 15
(1,358 Views)

Jeff, thanks for the response.

 

101 iterations work, yup. 102, nope. Every time at i=101, crash repeatable.

 

I messed around with the print options, but to no avail.

 

I paste the clipboard immediately following this VI using the report gen toolkit to replace text with the image. This can be seen here. I don't "clear" the clipboard per se, just overwrite at each iteration, but I've tried writing an empty string using an invoke node and that didn't help.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 12 of 15
(1,334 Views)

@James.Morriƽ wrote:

Jeff, thanks for the response.

 

101 iterations work, yup. 102, nope. Every time at i=101, crash repeatable.

 

I messed around with the print options, but to no avail.

 

I paste the clipboard immediately following this VI using the report gen toolkit to replace text with the image. This can be seen here. I don't "clear" the clipboard per se, just overwrite at each iteration, but I've tried writing an empty string using an invoke node and that didn't help.


101,  that SUCKS!  Print options were a stab in the dark.... What does DETT tell you about unclosed references etc....(Yup, time to pull out he big gun) and, do you have a service request in yet?  I "Guess" this might be OS related but, offer no proof.

 

Merry Christmas Mr. Morris! I wish I had more cheer.


"Should be" isn't "Is" -Jay
Message 13 of 15
(1,290 Views)

I have a service request in and the Apps engineer escalated it after they were able to reproduce the crash with my code. We'll see if they come up with anything.

 

I can't seem to get the DETT to see the executable for the trace... I have debugging enabled and all that, I can see the VI and project as options, but no executable. I can also use Debug Application to manipulate the executable.

Interesting story, using remote debugging to control the executable causes the exe to crash and LabVIEW to crash. But not at 102 anymore... it crashes inconsistently between the 110 and 130ish iteration each time.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 14 of 15
(1,277 Views)

This issue has been reported as CAR 564223. My suspicion is that it's related to the issue with Get Image not working in the Runtime Engine

Zach P.

Staff Software Engineer | LabVIEW R&D | National Instruments
Message 15 of 15
(1,142 Views)