Jump to content

This VI does not want to unlock!


Recommended Posts

Hello folks,

I'm quite anxious here, because a strange thing happened here. I was working on my VI and closed, so appeared a message asking if I want to save. I clicked on OK and a message with the button "revert appeared". So I cancelled the Save, to close the VI.

When I reopened this VI, it is blocked! I cannot see anymore my block diagram! The funny thing is that I did not clicked on VI Properties -> Protection -> Locked (no password). When I try to unblock here, the dialog is disabled, so I can't click on Unblocked! :(

What I do? And any ideas of the cause of this "mysterious" blocking?

Link to comment

QUOTE (crelf @ Apr 8 2008, 02:19 PM)

Show us your code.

I would like to show the code, but what to do if only the front panel appears? Well, anyway, I'm sending below the file VI. Don't mind if LabVIEW asks for subVIs (I would like to send the subvis, but I cannot and is not important for now).

I also tried to unblock programatically, using the method Lock State: Set, setting to Unblocked, but don't works too :(

Link to comment

QUOTE (Giseli Ramos @ Apr 8 2008, 03:15 PM)

I was afraid of this... but hopefully I have a backup copy here (it is a older version, but to recreate the new things....). I'm recreating and for now, I will backup every day.

Loosing stuff is a great motivator :)

It *might* be some simple file corruption that NI could help you with - if you're really in a difficult place and can't recreate it without pain, contact them directly.

Link to comment

I have seen this situation once before. I have no idea how exactly to recreate it, but it goes something like this:

  1. Assume you have the following VI hierarchy:
    Alpha calls subVI Beta calls subVI Gamma.
  2. Open VI Alpha. This of course loads Beta and Gamma into memory. But LabVIEW doesn't load the block diagrams for these VIs because it doesn't need them right now. So those are still on disk.
  3. Now, while you have Alpha open, copy another Beta.vi over the file on disk.
  4. Now open Gamma and change its connector pane. Because Beta calls Gamma, changing the connector pane of Gamma will force a change on Beta. So LabVIEW will now try to load Beta's block diagram. But wait! The VI on disk is not the same as the VI in memory. We *can't* load the block diagram. At this point, LV throws up a dialog that asks if you want to revert the Beta in memory to match what is on disk. If you choose "no", then you keep the version in memory -- the one that has no block diagram. Now you save Beta. Congratulations, you just saved your VI without a block diagram.

I have no idea if you actually did these things, but you may have done something similar. The big no-no is changing a the file of a VI on disk while that VI is in memory. That's the only time I've heard of this situation coming up.

Link to comment

QUOTE (Aristos Queue @ Apr 8 2008, 05:07 PM)

I have no idea how exactly to recreate it, but it goes something like this:

Yeah - I can see how that'd occur. Answer = Don't manually screw around with files that are open (and that means in any application - not just LabVIEW).

Link to comment

QUOTE (Aristos Queue @ Apr 8 2008, 11:07 PM)

QUOTE (Justin Goeres @ Apr 8 2008, 11:49 PM)

May I suggest a
?

We actually filed a bug report about this a while back (2003?), but found out that it was the way some users used ClearCase that caused the removal of the block diagrams (on VIs as well as controls/typedefs).

In our case some users had a lot of code opened in LabVIEW, then when a VI was modified they tried to save the VI, but to do so they had to first CheckOut the VI in ClearCase.

The CheckOut could then in some cases (e.g. if the cs-file was changed after the VI was loaded, so that a later version was selected), cause the change on disk AQ is mentioning.

My point is that even with a Version Control system, you have to be careful. You could still lose a BlockDiagram and be forced to do the work all over again.

/J

Link to comment

I agree with you, about the control version. I will implement it NOW! :D I was thinking about it, but, at the beginning, the project was small, and after, growed a few... I don't have excuses to don't implement it now.

Aristos, well, I think that your explanations about the conditions to lose a block diagram makes sense. Because I was with some VIs opened, and appeared that message to revert. Duh, I was dumb and clicked on "no".

I have a backup copy, so, no great pain to recreate it, hopefully. But good to know that NI can help if the things really goes hard!

It was important to learn that have much ways to lose VIs....

Many thanks!

PS: Sorry for my english...

Link to comment

QUOTE (Aristos Queue @ Apr 8 2008, 02:07 PM)

4. Now open Gamma and change its connector pane. Because Beta calls Gamma, changing the connector pane of Gamma will force a change on Beta. So LabVIEW will now try to load Beta's block diagram. But wait! The VI on disk is not the same as the VI in memory. We *can't* load the block diagram. At this point, LV throws up a dialog that asks if you want to revert the Beta in memory to match what is on disk. If you choose "no", then you keep the version in memory -- the one that has no block diagram. Now you save Beta. Congratulations, you just saved your VI without a block diagram.

Personally, I think the above behavior is evil. Sorry, but I don't care if it makes sense that it happens procedurally... can someone tell me why in Pete's sake I would ever want to select "no" in this situation...? Am I missing something or is this situation programatically detectable/avoidable? If so, why can't we just get rid of the evil dialog that corrupts our VI?

Like Chris, I am still pre-caf at this point... so perhaps there is something I'm not thinking of. :blink:

Link to comment

QUOTE (jpdrolet @ Apr 9 2008, 08:20 AM)

I think a solution to avoid this would be that LabVIEW keeps VI files opened (deny write) while they are in memory. That effectively locks the file in the filesystem. Many applications do that.

Are there better reasons for not doing so in LabVIEW?

Yes. But I can't remember what they are. :-) This was very seriously discussed. If you use LV 8.5, you'll notice that there's a lot more file monitoring going on when you have a project open -- we know if you change a VI listed in the project even if that VI isn't itself open. We took that route instead of locking, but I don't recall why.
Link to comment

QUOTE (crelf @ Apr 9 2008, 03:38 PM)

Nothing like a hijacked thread before first cup of coffee...

I agree with you, in the end it is up to the user to understand how to use the tools.

QUOTE (orko @ Apr 9 2008, 04:19 PM)

Personally, I think the above behavior is
evil
. Sorry, but I don't care if it makes sense that it happens procedurally... can someone tell me why in Pete's sake I would
ever
want to select "no" in this situation...?

What really bugs me is that there is no information that you might loose your block diagram if you select no.

The choice of Yes or No is like to ask if you want to keep your orange or get an apple, but there is no information telling you that if you select the orange the only thing you'll get left is the peel.

/J

Link to comment

QUOTE (Giseli Ramos @ Apr 9 2008, 06:52 AM)

I agree with you, about the control version. I will implement it NOW! :D I was thinking about it, but, at the beginning, the project was small, and after, growed a few... I don't have excuses to don't implement it now.

Aristos, well, I think that your explanations about the conditions to lose a block diagram makes sense. Because I was with some VIs opened, and appeared that message to revert. Duh, I was dumb and clicked on "no".

I have a backup copy, so, no great pain to recreate it, hopefully. But good to know that NI can help if the things really goes hard!

Well NI could theoreticaly help, but for various reasons will only do so in very rare circumstances nowadays, IF and ONLY IF the VI is only corrupted. If the VI is saved without diagram resource however, they can't do anything about that anymore. Something that has been gone can't be recreated.

It's like compiling a program and then throwing away your source code. With the difference that there are readily available tools to disassemble a compiled program and at least see the assembly code, while for LabVIEW disassembly is basically a no no.

The only people that might still be able to do something here are those guys like from Seagate where you send in your harddrive to recover lost data from. Chances would be dim though, since the rewriting of the file has a high chance to destroy the actual data of the previous VI version on harddisk.

Rolf Kalbermatter

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.