Stop Core vi broken

[wrkcrw00]

I have experienced this same issue numerous times. Crashing is only sometimes associated. From what I can tell, it happens when I override stop core.vi (not always). I have not been able to peice together the exact series of events that causes it to break stop core.vi. I'd be very interested in a solution because this is a bit annoying.

[Ludwig72]

I have the same issue here. I am working on two projects in parallel too and I am overriding the stop core.vi in a child class. Once I run one project, the stop core.vi is broken. I realized, that the stop core.vi is the only file in the folder that has a changed time stamp.

Workaround: Save the stop core.vi before and write it back in the case that it is broken. Everything is working fine again.

[AristosQueue (NI)]

Still waiting for anyone to post code that shows the problem or steps to reproduce. I have not seen it, nor has anyone at NI that I know of, which makes it hard to fix or workaround.

[Ludwig72]

An image of the broken code is included in the main post. It is almost the same here.

Here are my steps to reproduce the error:

•create a new project and include the Actor Framework and the Linked Network Actor

•open the Measurement Utility sample project in parallel

•write code in your own project using the Measurement Utility network communication as template (it is worth)

•insert a LNA child and override the stop core.vi

•open the error window

•the Actor Framework is broken because the defective stop core.vi  

I hope this helps you to find out what is happened. If you have questions feel free to ask me back.

[AristosQueue (NI)]

Ludwit72: Thank you. I'll see what I can do. That's a non-trivial amount of work to set up for the bug, which means there's a fair chance that if I deviate from your setup even a bit, I might not reproduce the bug. So I'm going to start through installing all the pieces... if you think of any small details that might be relevant, please post them.

[AristosQueue (NI)]

Ludwig72: The sample project seems to be missing from the Measurement Utility web page. There are six attachments, but none of them appear to be Eli's main project, and I haven't been able to get ahold of Eli today (he may be traveling). I don't konw what happened to it... can you zip up and post the project you used to replicate this?

[Ludwig72]

I am sorry, there is no standalone sample project because of the complex structure of the Measurement Utility. You have to download and install the complete package Measurement Utility.vipc. It installs several classes in your user.lib folder, which are necessary. To create the sample project just create a new project in LabVIEW from the Measurement System (Demonstrations) template. It builds up the complete sample. 

This are real a lot of steps to reproduce the error and I hope you don't give up.

[AristosQueue (NI)]

Well, good news: I reproduced the bug.

Bad news: I have no idea what could be causing this.

I'll see what I can do.

[AristosQueue (NI)]

And then, after more debugging, I do see the issue.

It goes all the way back to 8.2. If you have a class in two projects (or two targets of the same project), the parent VI will end up in this broken state if you create an override in the child. The only fix is to close the projects and reopen after creating the override. I will not be able to do anything for this in 2015. There's a much larger project code refactoring on the horizon that I would expect to fix this issue, but it is a couple years away still.

I wish I had better news for you.

[Jed394]

AristosQueue wrote:

And then, after more debugging, I do see the issue.

It goes all the way back to 8.2. If you have a class in two projects (or two targets of the same project), the parent VI will end up in this broken state if you create an override in the child. The only fix is to close the projects and reopen after creating the override. I will not be able to do anything for this in 2015. There's a much larger project code refactoring on the horizon that I would expect to fix this issue, but it is a couple years away still.

I wish I had better news for you.

Ughhh

I guess this just strengthens the always keep crio targets in their own project best practice advice.  I guess we'll add only work on one project at a time that shares classes to that advice list. 

Its interesting this didn't really show up till the actor framework, maybe other use cases just worked themselves out faster. 

Also, its not your fault, but its bugs like this, and the fact they can't be fixed for over a year, that makes it hard to encourage new developers to go all in on LVOOP.  Its powerful but it has its quirks.