04-02-2012 01:55 AM
I am in the process of migrating my large application from LV10 to LV 11 and Stepped on this Barkers Nest.
Not O.K. Code
O.K. Code
I tried to isolate this error into a VI on it's own and the bug went away.
Has anyone else seen anything else like this
04-02-2012 04:45 PM
Hi Timmar,
I have found a few people that have ran into that error like: sjunge and this forum post goes into detail on what the error is and some possible solutions.
DylanC
Applications Engineer
National Instruments
04-02-2012 09:33 PM
Sounds a lot like a workaround to me.
Is there an open bugfix case for it?
iTm
04-03-2012 10:02 AM
Timmar,
I am seeing some cases on this issue but not any involving the timeout from network shared variables. If you can attach the VI that is causing this error I will see if I can reproduce it on my machine and then submit it to a Corrective Action Report. I see you tried to isolate the issue and it went away, but if you are still recieving that error I would like to take a look at the VI that is causing it.
DylanC
Applications Engineer
National Instruments
04-03-2012 07:57 PM
Dylan
It is part of a 7,000 vi large application that is in the order of 100 MB when zipped.
It is of proprietry nature and I cannot post it to a forum.
I will spend 20 minutes on it to day to see if I can isolate it.
As with most Labview bugs that I have encountered (I am up to 10 now with none fixed!), they are time thieves with little or no reward for investment.
I tend to post them on this forum as a warning to others.
Standby for results.
04-03-2012 08:44 PM
I gave up trying to isolate the code .vi.
What I can tell you is that it most likely related to the number of Vi's in the block diagram.
There seemed to be a point where no matter which .vi I removed, the error would go away.
It didn't matter if the .vi was in a diagram disable or not, removing it, fixed the problem.
Maybe get the labview coding team to check the source code for:
#define MAXVISBEFOREANNOYINGCUSTOMER= ???
I can make arrangements for you to get my code, but as I said, it will need to be through official channels and not on the forum.
04-03-2012 08:50 PM
Dropping the code into a new .VI didn't work either
04-04-2012 08:39 AM
How far did you get in narrowing it down? Does the error crash LabVIEW allowing you to submit an error report? I agree that in a project with around 7000 VI's it would be counter-productive to send us the whole project. How many subVI's would the one showing the error need to include to be able to run/reproduce that error?
As stated in the previous forum post I linked, "The error GenEA occures when you have a bad VI / corrupt VI. This means, somewhere, the compiler makes a mistake and can't compile the code behind your, for example while-loop, correctly. This can happen when the compiler can't find the vector address.”
DylanC
Applications Engineer
National Instruments
04-04-2012 07:22 PM
As posted,
I wasn't able to reduce it much further because there was no repeatability it seemed to be the number of VI's that is the problem, not the code.
I got to the point where it didn't matter which .VI I removed, diagram disabled or otherwise, it would resolve the problem,
So it appears that the key to the investigation is having a large number of .VI's.
I did a re-count, I think that this section of the project has only 1300 .VI's
I pasted into a new .vi without success ruling out a corruption in the main .VI.