LabVIEW 2018

[MikaelH]

The first project I’m trying to open and convert to LV2018 just hangs LabVIEW 2018-64bit.
It looks like it gets stuck when it tries to re-compile all VIs.

I have all compiled code stored outside the VIs.

It’s a very large project, I’ve tried using the mass compile feature of the folders I use before I open the project, but still no luck in opening the project.

Has anybody else seen this?

[hooovahh]

Nope sorry.  All projects previously saved in 2015 through 2017 (all 32-bit) open just fine in 2018 32-bit.  In fact I've been enjoying better IDE responsiveness from larger projects and have moved up some of the projects to be converted that I might normally not until a service pack.

[MikaelH]

I’m happy it works for you. Some projects I’ve tested works, but one of the very large ones just refuses to re-compile everything.
It’s frustrating since I’m the one pushing all LV developers to get ready to migrate to 2018

[ShaunR]

I think you are going to need NIs input on this one.

[MikaelH]

2 hours ago, ShaunR said:

I think you are going to need NIs input on this one.

I've reported it to my local NI office, but they have not found any records in the database about other people having this issue.
And I can't send them the code to test it themselves due to IP.

I guess I just have to slowly open small parts of the code to see what VIs are freezing LV.

[ShaunR]

35 minutes ago, MikaelH said:

And I can't send them the code to test it themselves due to IP.

Isn't that what non-disclosure agreements are for?

[shoneill]

Does LV freeze or crash? I often see "freezes" of more than one hour when LV starts compiling our entire project when just moving the files to a new path on disk.

If I wait long enough, it does eventually recover, but at that point it's hard to differentiate between this and "normal" LV crashes where it just sits there and does nothing and will never recover.  I say "normal" because it happens quite a lot.

LV 2015 SP1.

[JKSH]

1 hour ago, shoneill said:

If I wait long enough, it does eventually recover, but at that point it's hard to differentiate between this and "normal" LV crashes where it just sits there and does nothing and will never recover.  I say "normal" because it happens quite a lot.

One way to tell is to look at the Disk Activity under Resource Monitor in Windows.

If LabVIEW is working on files, Resource Monitor will show you exactly which files are being touched. If LabVIEW has frozen, There will be no disk activity.

[shoneill]

I'm pretty sure that's a good indicator, but not foolproof.  I've had LabVIEW "idling" for nearly an hour, frozen, and come "back from the dead" afterwards. I've also had LabVIEW be "active" and not recover even after leaving it carry on for a whole weekend.  Maybe if I had let is continue for just 5 minutes more, it would have completed......

I've grown to expect all kinds of weird behaviour from LV over the years.  That's not meant as a compliment.

I suppose we need considerably more feedback regarding what LabVIEW is actually doing so that we can better judge whether stopping the process or just waiting is the best option.

[0_o]

Just a thought... try running LV as admin after first upgrading to 2017. Check to see if there are no file permission issues or password protected vis.

[gb119]

I've seen variants of 'Vi Failed to Compile' with projects involving complicated class hierarchies and class instances as data members of other classes etc. Nothing particularly new - I've seen this in versions of LabVIEW from 8.6 onwards - usually simply opening the offending Vi 'standalone' is enough to get it to compile then everything is ok until the next time that LabVIEW decides it needs to compile all my code. Now in 2018 64bit I've got a slightly odd one where when I open my top level Vi, LabVIEW decides that the Actor Framework isn't compiling, but if you open that first and then load the top level Vi everything is fine...

I find it incredibly hard to debug the issuse as it only happens when one has a sufficiently large project. Keeping compiled code separate seems to make it more likely, as does having very large class hierarchies or classes with private data containing classes. Actor Framework also seems to be a contributing factor. The error message is almost as helpful as the old MacOS installer error "There was a problem with the hard disc, please use a different one....."

[MikaelH]

On 07/06/2018 at 7:38 PM, 0_o said:

Just a thought... try running LV as admin after first upgrading to 2017. Check to see if there are no file permission issues or password protected vis.

I tried running as Admin, no changes, it still freezes

On 07/06/2018 at 5:03 PM, shoneill said:

Does LV freeze or crash?

In some instances it really freezes, but after mass compiling sub components I could get the project window to open up, but it still doesn’t become responsive, but I can see that the CPU usages goes from 0% to 0.1% from time to time.
So I left it over this long weekend(3-days) but still frozen when I got back to work.

My next step could be to re-compile/save everything in LV2017, and then try 2018.
But it shouldn’t make too much of a difference since we have all compiled code saved outside the VIs.

I could also try to add the compiled code into the VIs and see if that does the trick before opening the code in 2018.

[0_o]

Another thought: LV doesn't allow you to compile code from program files.

You could take the hard drive/ssd out of that computer, connect it to a different computer with LV and compile there.

This way all the files will be accessible since program files is just a name now.

[MikaelH]

15 hours ago, 0_o said:

Another thought: LV doesn't allow you to compile code from program files.

I've now done a source distribution of all the code and the code open in LV2016, but not LV2018.
I'll zip this up and send it to NI for investigations.
(I'll just remove all sensitive IP stuff, even with missing VIs LV2018 should freeze but it does)
I'll keep you posted about the progress.

[AutoMeasure]

Hey, guys, along the lines of this topic, I'm setting up to move my company forward in its Labview and Teststand versions.  We're standardized on Labview 2015 SP1 f10 and Teststand 2016 f2, both 32-bit and both behaving well including running on Windows 10 64-bit.  I'm thinking to move to Labview 2018 fn and Teststand 2017 fn.  Should I do it now, and if so, should I try the 64-bit versions or is that still too risky?  Also, although Teststand 2017 doesn't "officially" support Labview 2018 (http://www.ni.com/teststand/product_lifecycle/), it should work OK I'm guessing.

Thanks.   -Joe

 

[crossrulz]

I would stick with 32-bit.  I have yet to see a reason to go 64-bit unless you are doing massive amounts of memory intensive processing (Vision immediately comes to mind).

[Benoit]

For the original post,

Instead of doing a mass compile on the huge project, try to do object by object. I have a feeling that only one object is causing issue for you.

Also, are you trying to do that on a new PC or on the upgraded PC that still have the old LabVIEW version?

In my case, It happened to me because of a .dll. External code some times creates problem.

Benoit

[MikaelH]

I've done lots of small mass compiling to see if that solves the issue.
But no luck yet, but I'm getting closer it looks like it freezes when it load projects using the Vision module.
We need to use 64 bit on quite a few test system when we use lots of vision stuff and/or testing multiple units at the same time (capturing heaps of data, maybe more than we need)
And some larger project can't even build an exe, LV runs out of memory during the build process.

 

 

[Benoit]

I don't know if it's applying to you project, but in my case, I have different .exe with different responsibility that talk with each other trough VI server.

This allow me to be very modular and when I have an update, only the required module is recompiled.

Some process that are used for multiple other .exe, I load them as service in Windows.

Just saying... that could be useful 

 

Benoit

[MikaelH]

Just an update, NI has found and fixed my issue, it's just a matter of time when we'll get a patch for this, maybe I have to wait for the Service pack before I can migrate to 2018.