09-27-2018 04:41 PM
@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.
09-27-2018 05:45 PM
And add *.Allias to th SCC ignore list.
MyComputer isn't the same on YourComputer.
09-29-2018 06:32 PM
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.
09-29-2018 06:49 PM - edited 09-29-2018 07:11 PM
@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?
10-01-2018 07:33 PM
Thank you! This level of insight is very helpful.
10-01-2018 08:23 PM
Thank you Mark_Yedinak. Insightful help.
10-02-2018 02:53 AM
LV2108 crashes regularly on my machine. Mainly when building applications or closing LV.
10-02-2018 03:03 AM
@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?
01-18-2019 11:00 AM
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:
It's clunky but it is the only thing we have found that seems to work.
Cheers!
-cb
06-04-2019 01:11 PM
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...