LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2018 crashes a lot!


@10Degree wrote:

Is there a way to decouple the source from the compiled code? How ddi I set that up to test?


First, Under the Tools->Options->Environment options you can set the default to separate compiled code from new files. This will separate it from all new VIs you create.

 

In a project, you can mark all code within the project to separate the compiled from the source via the project options. There is a check box to separate the compiled code for all new files. There is a button under that check box you can use to set that option on all the files currently in the project. This also helps quite a bit with source code control since only files with actual changes will be committed rather than everything that simply gets recompiled because of some minor change such as a subVI change or update to a typedef.

 

Another benefit is that you can open a VI in different version of LabVIEW without having to save the code. This won't work if you open it in an earlier version and the source contains a new feature that does not exist in that earlier version. Project files will always get saved since they contain the LabVIEW version used within them. However if you don't actually add/delete anything from the project there is no need to save it.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 11 of 23
(1,311 Views)

And add  *.Allias to th SCC ignore list.

 

MyComputer isn't the same on YourComputer.


"Should be" isn't "Is" -Jay
0 Kudos
Message 12 of 23
(1,306 Views)

I've  got some time and feel like... speaking 

 

 

Fortunately the original poster is familiar with an upgrade process ... he she has rigorously been careful about it for over a  decade. 

 

Note: at no time were upgrade reports offered.. they just religiously addressed any issues...whatever those might have been. 

 

 

Questions about following upgrade notes...should have those outputs ready... unless my cynicism has been accidentally replaced with reality.   

 

You upgraded.  Your code base... but you and your group are diligent....without anything from you but " we are diligent .... statements 

Evidence or not?  

 

Frankly, If you show me the upgrade process outputs... I will be less cynical. 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 23
(1,272 Views)

@JÞB wrote:

I've  got some time and feel like... speaking 

 

 

Fortunately the original poster is familiar with an upgrade process ... he she has rigorously been careful about it for over a  decade. 

 

Note: at no time were upgrade reports offered.. they just religiously addressed any issues...whatever those might have been. 

 

 

Questions about following upgrade notes...should have those outputs ready... unless my cynicism has been accidentally replaced with reality.   

 

You upgraded.  Your code base... but you and your group are diligent....without anything from you but " we are diligent .... statements 

Evidence or not?  

 

Frankly, If you show me the upgrade process outputs... I will be less cynical. 

 


We upgraded and found out that our code crashes more often 

 

Needs specific evidence.   But,  your group has been winging it for so long that all you can provide is a rant without any examples 

 

Answer if NIER service is on.  Heck. Attach that specific output from a crash you observed... again,  I don't have your code base ... it doesn't crash my PC. 

 If you really were diligent and disciplined with the upgrade... your post would have specific details. 

 

After upgrade vi y runs and LabVIEW crash dump said specific zzz happened that we do not understand...  NI service request  ppp has the following additional information. 

 

Nope,  nothing but a statement about how your group is diligent and expert.  Says you.

 

Would you like to keep whining or would you like to give us details to help you?

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 14 of 23
(1,269 Views)

Thank you!  This level of insight is very helpful.

0 Kudos
Message 15 of 23
(1,204 Views)

Thank you  

0 Kudos
Message 16 of 23
(1,200 Views)

LV2108 crashes regularly on my machine. Mainly when building applications or closing LV.

 

0 Kudos
Message 17 of 23
(1,181 Views)

@Mark_Yedinak wrote:

Another benefit is that you can open a VI in different version of LabVIEW without having to save the code. This won't work if you open it in an earlier version and the source contains a new feature that does not exist in that earlier version. 


Do you mean that a 2017 VI without compiled code will open in e.g. 2013 if no new features where used? That's new to me. Or does it only work from\until 20xx?

0 Kudos
Message 18 of 23
(1,177 Views)

Dear all,

 

Just circling back on this topic to share what we did here to work around these crash issues.  We opened several tickets with NI since this original post.  They were able to re-create some of the problems on their end, but not everything.  CAR 709208 was opened for the file dialog express vi.  They could not solve our problems and their only advice was to clear the object cache.  The process I have started using as a means of producing crash-free development and builds:

 

  1. Open LabVIEW
  2. Clear compiled object cache (Tools...Advanced)
  3. Open my project
  4. Clear compiled object cache again (probably just paranoia)
  5. Build crash-free EXE

It's clunky but it is the only thing we have found that seems to work.

Cheers!

-cb

0 Kudos
Message 19 of 23
(1,088 Views)

I also have LabVIEW 2018 SP0 Crashing hard on my machine, i9 intel Win10.

Having used LabVIEW since 1.1.0...I am pretty familiar with LabVIEW development behavior.

 

What I am seeing is a hard Win10 blue-screen crash. I've not had this machine ever crash, except when I am using LabVIEW 2018, typically, accessing Type defs...

0 Kudos
Message 20 of 23
(871 Views)