Locked Libraries ( Actor Framework ) but still editable

[Mac671]

I have a peculiar problem, that is hard to trace.

I have a project where we use AF quite extensively.

Upon a run of the project, and shutting down of all the actors, after sending the normal stop to all our actors, many libraries in the project have the locked icon.

All actors are closed. ( we use the Monitored Actor and our actors inherit from it so we can see that the actors are actually down).

The most peculiar thing is that even though the libraries are flagged as locked, you can open the VIs , edit and save as if they weren't locked.

This is happening for us in LV 2013 SP1.

Any advice would be appreciated.

[dnchen]

Hi Mac671,

Is this a problem that started recently and if so, what sort of changes have you made to the project? Does this only happen after you the run the project? Does it persist when you reopen the project? Could you post a snapshot of the project? This is certainly some strange behavior indeed.

Thanks,

Daniel

[Mac671]

Hi Daniel,

The issue doens't happen after you first load the project in to the LabVIEW environment.

If you run the software once, and close all actors, the issue happens; at the moement I'm not 100% sure if it depends on the execution path in the program or if it happens all the time.

I can't really post the project ... the code belongs to our customer of ours, legal issues etc.

With respect of the changes that have been made, we have 4+ people working on the project constantly, adding editing vi's etc ,,

One thing is for certain 😉 someone made  a change somewhere at some point of time :D.

But we're not really sure when this started occuring, hunitng it down would not be 5 minute job so I decided to post in case someone else had encountered this behaviour.

We might end up having to do some forensics to try and undertstand when this started occuring by carefully taking consequent versions of the project and running them.

The problem is that we have a LOT of actors in the project. And the load time of LabVIEW itself to do such experiments is a bit of discourageing.

Maciej

[dnchen]

Maciej,

Unfortunately, we don't have any records of our customers running into this issue in the past. It sounds like it might be a bug that we haven't run into until now. What do you mean by if it is dependent on the execution path of the program? Does this bug happen on every computer you run the project on?

I understand that you can't post the project but unfortunately that also means I can't really file a bug fix request on it since I would need to be able to reproduce it on my end first.

Could you describe your project in a bit more detail?

How many actors do you have?

Is there anything else in the project that could potentially lead to locking a library ie. an XControl?

Is this bug in any way affecting your development of the code or your customer?

[Jed394]

Do you have any other targets in your project such as a crio or something?  Or are you using any Project plugins like the SVN Pluging that might be affecting the display of the project item icons? 

[Mac671]

Hi,

No we do not we only have the Computer Target, there is no RT in this case.

I know that you can lock a library if it is referenced by two targets at the same time but this is not our case.

The plugins idea might be interesting to check out... I'll try to see if I get the same issue on a clean 2013SP1 install.

Thanks,

Maciej

[Mac671]

By execution path I mean the flow of the program from start to finish.

Some execution paths, would for instance not create certain actors and destroy them as they are not needed in the program run ( i.e. some features haven't been called duirng runngin of the software )

The problem happens on multiple developer machines, preety for every developer that works on the project.

In our project preetty much every thing is an actor.

We go from Actor-> Monitored Actor -> and than some of our own inheritance structure.

With respect of how many do we have about 35 different actor types at the moment and growing.

When the program runs there are however multiple instances of certain actor types.

We don't use X-Controls.

With respect to the bug affecting our work or code, no we have not noticed anything other than the actual libraries saying the're locked.

However this is a serious project ... and I don't like to leave things unchecked.

It is not affecting us now but I don't want to find out down the road this is a crippling problem that will cause some drastic rearrangements.

Regards,

Maciej

[dnchen]

When you right click the library, does it give you any of the locked library options such as "Why is library locked?"

I understand how this seemingly harmless glitch is worrying you. It definitely sounds like a bug but it could be very specific to something you are doing in your project. I can try and reproduce the issue on my end, but if we aren't able to recreate the bug, and you can't send us your code, we can't file a bug fix request on it. Aside from those actions, I'm not sure what else I'm able to do for you in this situation.

[Siegmund]

---

@Mac671 wrote:

I have a peculiar problem, that is hard to trace.

I have a project where we use AF quite extensively.

Upon a run of the project, and shutting down of all the actors, after sending the normal stop to all our actors, many libraries in the project have the locked icon.

All actors are closed. ( we use the Monitored Actor and our actors inherit from it so we can see that the actors are actually down).

The most peculiar thing is that even though the libraries are flagged as locked, you can open the VIs , edit and save as if they weren't locked.

This is happening for us in LV 2013 SP1.

Any advice would be appreciated.

---

Hi Mac,

I know this is a rather late reply, but I seem to be experiencing the same thing using LV2012 SP1 (cannot currently upgrade, since the customer uses a great amount of really old NI Hardware).

I believe i tracked down the problem to the "Time-Delayed Send Message Core" which (although it should be stopping - I Call it 4 Times, it pops up 4 times and then all 4 instances close) it still looks  like it is somehow active:

Were you able to track down the problem your team had? Any info would be greatly appreciated.

Siegmund