10-06-2012 12:05 AM
Here is some LV2012 weird behaviour when clearing the compiled cache and having a project with source code separated from the binaries.
Steps to reproduce:
1. Open a VI in a fairly large LV project
2. With the VI open, clear the compiled cache:
3. Close the VI.
4. Open the VI
5. Watch the broken arrow and the LV Out of Memory bogus.
Br,
/Roger
Solved! Go to Solution.
10-06-2012 12:34 AM
And then the internal error reporter runs when I exit LV.
Br,
/Roger
10-08-2012 10:13 AM
So this is reproducable?
Do you have some figures about number of VIs/minimum memory requirements of the project for reproduction?
Norbert
10-08-2012 10:22 AM
@Norbert_B wrote:
So this is reproducable?
Do you have some figures about number of VIs/minimum memory requirements of the project for reproduction?
Norbert
Yes, it always behaves the same. So it's easy to reproduce.
I didn't try to reduce it down to the limit. This computer is busy building an .rtexe (for the past 6h). I'll see if I can attach a project, from my home machine, where this happens and which is below the (nuts!) 10MB attachment limit.
Br,
/Roger
10-08-2012 01:26 PM - edited 10-08-2012 01:27 PM
Steps to reproduce modification:
1. Open the Benchmark VI (broken arrow?)
1.1 Try running the VI. (Otherwise it won't be out of memory)
2 .. Same as before
Br,
/Roger
10-09-2012 04:01 AM
Roger,
i tracked down the issue to "ExecutionBenchmark1.lvclass:Load Core.vi" and "ExecutionBenchmark2.lvclass:Load Core.vi". If removing both VIs from the main, it is compilable.
Since those VIs have their blockdiagram removed, they have to include their compilation in order to be executable. I expect this to be the source of the issue.
Can you please check if using the default VI "Load Core" for both classes work as long as LV is able to recompile those while creating the object file for the main?
thanks,
Norbert
10-09-2012 04:28 AM
@Norbert_B wrote:
Roger,
i tracked down the issue to "ExecutionBenchmark1.lvclass:Load Core.vi" and "ExecutionBenchmark2.lvclass:Load Core.vi". If removing both VIs from the main, it is compilable.
Since those VIs have their blockdiagram removed, they have to include their compilation in order to be executable. I expect this to be the source of the issue.
Can you please check if using the default VI "Load Core" for both classes work as long as LV is able to recompile those while creating the object file for the main?
thanks,
Norbert
Perhaps it's another bug when trying to "Save As" in the project "File" menu when the compiler is in out of memory state, which is what I did and possibly caused it to be saved without the block diagram? Those VI's should have their block diagram included in any case.
Okay, I couldn't reproduce it now. It seems like a random issue from time to time. I'll try it out on my computer at home. However, I get internal errors when I exit LV.
Br,
/Roger
10-09-2012 05:03 AM
@Norbert_B wrote:
Roger,
i tracked down the issue to "ExecutionBenchmark1.lvclass:Load Core.vi" and "ExecutionBenchmark2.lvclass:Load Core.vi". If removing both VIs from the main, it is compilable.
Since those VIs have their blockdiagram removed, they have to include their compilation in order to be executable. I expect this to be the source of the issue.
Can you please check if using the default VI "Load Core" for both classes work as long as LV is able to recompile those while creating the object file for the main?
thanks,
Norbert
Yep, still reproducible on my 32 bit Windows 7 home machine. Attached is the fixed code.
Also, my suspicion was right. If you try to save a project in a out of memory condition, the saved project will always display an out of memory error due to a missing block diagram.
Br,
/Roger
10-09-2012 06:20 AM - edited 10-09-2012 06:28 AM
Roger,
your attachments somehow irritate me.
Missing_BD.zip seems to have the very same content as the original Execution.zip. All class VIs have their BD removed and do contain code (even if option seperate source code is checked, but the option itself is greyed out).
Execution_Fixed.zip does contain all BDs for all VIs, but the issue with the broken error is not reproducable on my machine. I checked some of the subvis, but it seems all have the option to seperate the source code set.
EDIT: Ok, following you initial description i can reproduce the issue.
EDIT 2: I can reproduce the issue only if i opened one of the Load Core.vis before purging the cache. Please confirm.
Norbert
10-09-2012 06:34 AM
@Norbert_B wrote:
Roger,
your attachments somehow irritate me.
Missing_BD.zip seems to have the very same content as the original Execution.zip. All class VIs have their BD removed and do contain code (even if option seperate source code is checked, but the option itself is greyed out).
Execution_Fixed.zip does contain all BDs for all VIs, but the issue with the broken error is not reproducable on my machine. I checked some of the subvis, but it seems all have the option to seperate the source code set.
So how can i make the project to display the error?
Norbert
Norbert, dont be grumpy, you just gotta try a little harder. In any case, thanks for the efforts!
The bug is there when I run it in my 32 bit Windows 7 machine and not on my 64 bit Windows 7 machine at work.
What type of machine are you running the code on?
Separating the source code from the compiled binary isn't the same as removing the block diagrams from the VI's.
Please elaborate what you mean?
Br,
/Roger