LV32 vs. LV64

[CoastalMaineBird]

LV 2016

Started a new project in LV2016 (to match customer's version) last Nov.

I installed LV2016 on a separate machine, and without thinking about it, installed the LV64 version.

I developed his code, built his app, and delivered.  All is well.

Then he wants another project, this one involving a cRIO with FPGA (which I've never used).  He sent me a sample of what they had started, and I couldn't open it without errors.  Come to find out there was a driver that was 32-bit only and his system was LV32. The first project didn't matter as it was generic code - no DAQ.

So, I just now installed LV2016 (32 bit), and the drivers, and I can load his sample project.

I loaded the previous project, and ran it (without saving).  It ran up to a point, and then hangs.  I deliberately didn't save it, not knowing what trouble that might cause. Had to abort LV and start again.

Debugging showed that a given user event was indeed being fired, but not being received.  I chased it and chased it, until I accidentally SAVED the whole project.

The next time it opened, it ran.

So, I moved to the 64 bit version, opened the project and found the same thing: the program, which previously ran fine, hung, at precisely the same point.

CTRL-SHIFT-RUN, which forces a compile of the whole thing, didn't change anything. It reports 184 VIs that needed saving.  But actually SAVING the project, reports 199. and now it will work in LV64, but not LV32.

Anybody know the rules for this? Haven't tried it on LV2018, but it seems odd to me.

Why would SAVING change things that the recompile did not?

[wiebe@CARYA]

---

@CoastalMaineBird wrote:

Why would SAVING change things that the recompile did not?

---

My guess would be the compile cache...

Tools>Advanced>Clear Compiled Object Cache might help. Or not, sometimes it remains a mystery.

[CoastalMaineBird]

My guess would be the compile cache...

Reasonable, but wrong.  CLEAR COMPILE CACHE does not help.  

if I load the project, load the main VI, CLEAR COMPILE CACHE, and RUN, it still fails at the same point in either the LV32 or LV64 IDE, whichever one it was NOT saved in.

[wiebe@CARYA]

Does it crash when you run any VI? If not, perhaps you can pinpoint the VI(s) that cause the crash?

[aptivo]

Create a copy of that project for backup, mass compile the project directory, pay attention to the errors during mass compile and give it again a try.

[CoastalMaineBird]

mass compile the project directory, pay attention to the errors during mass compile 

OK, good thought.  That revealed some lint (broken, uncalled code that died during development).  I cleared all that away, and am left with this:

I have removed the date/time stuff from the MASS COMPILE (MC) logs:

FOUR CASES:  After SAVE ALL, I ran and verified correct operation.

1... SAVED ALL in LV32, MC 32:

Search failed to find "shfolder" previously from "shfolder" +=+ Caller: "Culverson Windows File Path and Name Tools.lvlib:Culverson Get Windows Folder Path.vi"

2... SAVED ALL in LV32, MC 64:

Insane object at FPHP+13D2EBB8, UID 47, in "SGBDA Events.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:\SGB Data Analyzer\SGBDA.llb\SGBDA Events.vi
Insane object at FPHP+13D2EBB8, UID 47, in "SGBDA Events.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:\SGB Data Analyzer\SGBDA.llb\SGBDA Events.vi
Search failed to find "shfolder" previously from "shfolder" +=+ Caller: "Culverson Windows File Path and Name Tools.lvlib:Culverson Get Windows Folder Path.vi"

3... SAVED ALL in LV64, MC 64:

Search failed to find "shfolder" previously from "shfolder" +=+ Caller: "Culverson Windows File Path and Name Tools.lvlib:Culverson Get Windows Folder Path.vi"

4... SAVED ALL in LV64, MC 32:

Insane object at FPHP+D6B84A8, UID 47, in "SGBDA Events.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:\SGB Data Analyzer\SGBDA.llb\SGBDA Events.vi
Insane object at FPHP+D6B84A8, UID 47, in "SGBDA Events.vi": {tdname } (0x4000): Type Definition (DDO )
insanities in FPHP of C:\SGB Data Analyzer\SGBDA.llb\SGBDA Events.vi
Search failed to find "shfolder" previously from "shfolder" +=+ Caller: "Culverson Windows File Path and Name Tools.lvlib:Culverson Get Windows Folder Path.vi"

I don't think "shfolder" is the problem, because the hang is not in this area of the code.

Also, the "shfolder" shows in ALL FOUR cases.

The "shfolder" mentioned is in this VI  - don't recall where I got this code from.

The "insane objects" seems more likely to be the problem.

Remember what debugging showed was that a particular user event was definitely triggered, but the event loop configured to get it, did not receive it.

Here is the VI in question:

The code simply creates a bunch of user events the first time up, and memorizes them.  the FALSE case simply reports the cluster from memory.

The particular event I hung up on was "Need to Process PER".  I don't know if any other events were gorched or not.  That might or might not be the first event triggered (I'd have to look deeper).

So, what makes an object "insane" ?  Back in LabVIEW 2.0, insane objects meant the memory was corrupted somehow - I suppose that's still the case.

Maybe a SAVE ALL sees the insane objects and fixes them?

[wiebe@CARYA]

Insane objects are, for me, mostly wires that don't end on a terminal. Often the terminal of a (type def'd) enum or cluster. I'd also suspect (un)bundlers.

You need Heap Peak or scripting to locate them. Or simply delete and rewire some wires until it goes away. Use the U button to switch between the long numbers and the UID's of the objects.