LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Separate Complied Code bug

Highlighted

I have found a situation where the source code of a calling VI should be updated and saved after editing a type def, but the calling VI does not get a dirty dot or prompt for save on close.  Worse yet, the cached compiled code seems to get updated, so re-opening the calling VI seems to work correctly... Until the compiled cache is cleared or the source code is moved to another machine!

 

The situation involves a case structure driven by a type-def'd enum.  Follow the steps below with the attached VI and CTL to observe the behavior:

 

Start with a clear cache:
 - Open LV and Tools>Advanced>Clear Compiled Object Cache... Delete

Open Case.vi and Enum.vi
 - Verify Run arrow

On Enum.vi
 - Edit Items
 - Change "K" to "Gamma" (K is the end of a range in the Case structure)
 - Note that Case.vi gets a broken Run arrow.
 - Save, then Close Enum.ctl
 - Note that Case.vi has a solid run arrow, but no "dirty dot"
 - Close Case.vi
 - Note that there is no prompt for save.


Open Case.vi and Enum.vi
 - Verify Run arrow

On Enum.vi
 - Remove items "G", "H", and "I"
 - Note that Case.vi gets a broken Run arrow.
 - Save, then Close Enum.ctl
 - Note that Case.vi has a solid run arrow, but no "dirty dot"
 - Close Case.vi
 - Note that there is no prompt for save.

Open Case.vi and Enum.vi
 - Verify Run arrow

Close Case.vi and Enum.vi

Clear cache:
 - Tools>Advanced>Clear Compiled Object Cache... Delete

Open Case.vi and Enum.vi
 - Verify Broken Run arrow


My belief is that if separate compiled code works properly, you should never have a condition where you can open a VI with a good run arrow, close it, clear cache and re-open it and get a broken run arrow.  To me, this implies that the source code and the compiled code are out of sync.

This may seem like an esoteric case, but it is a case we often have in an application we have been using and updating for years.  We have always been able to rename and insert/remove enum items following the above process without a problem, until we separated source and compiled code.  We know that it is important to save calling VI's after renaming items, before deleting or inserting items.  It seems when a calling VI's case structure cannot find an enum item by name, it will use the correspoonding item number.  By saving after renaming, we avoid the situation where a named item is not found.

In the past, if the calling VIs were in memory when the enum items were edited, the calling VIs would get a dirty dot and be saved when the hierarchy was closed.  I always though the source code was getting updated, but given the behavior after separating the compiled code, I now believe only the compiled code was being updated.

You might think that enums shouldn't be used or edited this way, and you might convince me of that.  Nevertheless, it is definitely a bug that a VI that works before clearing compiled cache doesn't work after clearing compiled cache.

I suspect the calling VI with the case structure has stored enum strings in the source code, but that these strings aren't getting updated when editing the enum items in the typedef.  As a result, the calling VI isn't getting a dirty dot and the source code doesn't get saved.  (or perhaps the strings are getting updated in the source code in memory, but still no dirty dot and so no prompt for save).  Somehow, the calling VI's compiled code is getting updated when the enum typedef control gets closed.  Reopening the calling VI opens the cached compiled code and everything works fine, until the compiled cache is cleared or the source code gets distributed through source code control to a machine without the compiled cache.  The result is code that appears fine during development, but breaks later without any editing.

Download All
0 Kudos
Message 1 of 8
(1,170 Views)
Highlighted

Is there an official route to submit a bug report?

0 Kudos
Message 2 of 8
(1,143 Views)
Highlighted

Hello Matt,

 

We really do appreciate the time you spent identifying and reporting this bug. I was able to reproduce this behavior on my PC.I will be creating a corrective action request on this, and will be posting te CAR# when I have it, this way you can check the release notes of future LabVIEW versions to check if this has been fixed

 

Regards

 

Mart G

AE NIC

Message 3 of 8
(1,123 Views)
Highlighted

Mart,

 

Thanks for the follow-up!

 

-- Matt

0 Kudos
Message 4 of 8
(1,115 Views)
Highlighted

Hello Matt,

 

The corrective action request has been created, the number is #355966. You can check the release notes of future versions of LabVIEW to find out if this is fixed.

 

Regards

 

Mart G

0 Kudos
Message 5 of 8
(1,099 Views)
Highlighted

I don't see any mention of the specific version of LabVIEW used for catching this problem. Judging by the date, I'd assume LV2011?

 

Any word if it still happens in LV2012? I know there had been problems with enums and separating compiled code in LV2010...that was the dealbreaker that made us turn OFF that feature (after some frantic troubleshooting to un-break our code!), and we were really hoping to give it another shot after upgrading to LV2012. But if this is still happening, it sounds like that feature is not yet ready for primetime. That's a bummer.

0 Kudos
Message 6 of 8
(1,046 Views)
Highlighted

I just tried following the steps posted above and it seems to be fixed in LabVIEW 2012.

Tarek B
Applications Engineer
National Instruments
0 Kudos
Message 7 of 8
(1,015 Views)
Highlighted

Thanks!  That is good news.  -- Matt

0 Kudos
Message 8 of 8
(991 Views)