Reads and Writes?

[amezam]

Hello Jeffin CA,

It would be better if you post on another forum since this is a new issue. When you attempt to use that option to save your files, do you get an error or message? Or is the option not appearing at all or grayed out?

Best Regards,

Alina M

Applications Engineering

National Instruments

[JeffinCA]

Yes, you are right; I should have posted in another thread.

When I use that option, it is not grayed out.

When I select the destination folder, only the top level VI is saved there.

This may be related to the method in which the top level VI was created (I used the DAQ Assistant and expanded the code).

I have noticed that, even though I edit and save the individual sub VIs with the top level VI closed (the only way they can be edited after the top level VI has been saved for the first time), they still show up as as if they are from a library if the top level VI is open (e.g. they are marked as cloned copies in the window header).

As an experiment, I replaced the 4 subVIs with re-named copies and 3 of those 4 copies still show up as cloned (oops... I checked again and now all 4 subVIs are marked as clones).

Regards,

Jeff

[nathand]

---

@JeffinCA wrote:

I have noticed that, even though I edit and save the individual sub VIs with the top level VI closed (the only way they can be edited after the top level VI has been saved for the first time), they still show up as as if they are from a library if the top level VI is open (e.g. they are marked as cloned copies in the window header).

As an experiment, I replaced the 4 subVIs with re-named copies and 3 of those 4 copies still show up as cloned (oops... I checked again and now all 4 subVIs are marked as clones).

---

This has nothing to do with whether the VIs are in a library; the clones indicate that those are instances of a re-entrant VI.  I remember noticing that when I opened the VIs you uploaded.  There's no reason for those to be reentrant, though, and you can change this in VI Properties under the Execution category.  Also, to edit the master copy of a reentrant clone, open the VI and then hit control-m.

[JeffinCA]

I removed the 're-entrant' tag on each VI and verified they opened normally in the top level VI, but the Duplicate Hierarchy function still failed.

Jeff

[nathand]

I can duplicate this with your VIs on my machine, but I've never seen this with other VIs, so I think it's a problem with your VIs.  How did you create them?  Did you start with a VI that was part of vi.lib and then modify it?  What happens if you recreate those VIs by creating blank VIs, then copy then entire contents from the existing VI into the new blank VI and configuring the connector pane?

[JeffinCA]

This is odd.  I copied and pasted each of the subVIs to blank VIs and saved them with unique names.

I then opened the top level VI to replace each of the subVIs, but the original subVIs were already being displayed properly (not as uneditable clones).

I waited awhile (because, after I turned off the 're-entrant' flag earlier, one of the subVIs that seemed to be fixed switched back to 'clone' behavior when I checked again a few minutes later), but that didn't change anything.

I edited the Top Level VI, saved, closed and re-opened it, but still with no change; all the subVIs display as they should (not as clones).

However, the original subVIs are still not being copied with the Duplicate Hierarchy option.  I say 'original' because I created a VI in 8.2 and loaded it as a new function into the Top Level VI; when I tried the Duplicate Hierarchy command, only the Top Level and new subVI were copied.

So... your supposition that there is something wrong with the VIs may, or may not, be correct.  It could be a problem with LabVIEW 2010.

Jeff

[nathand]

Sorry, I can't follow what you're saying here.  This is a guess, but my sense is that whether or not the VI is reentrant has nothing to do with whether it saves properly.  So the comments about "displayed properly (not uneditable clones)" aren't helping me understand what you did.  I'm still not clear whether you did what I suggested, which is: for each subVI, create a new, blank VI.  Copy the contents of the existing subVI into that blank VI and configure the connector pane.  In the top-level VI, replace the existing subVI with the new subVI you just created.  Close all the old subVIs.  Then, from the top-level VI, see if you can save the entire hierarchy properly.

A cloned instance of a reentrant VI is not incorrect or bad, it's doing exactly what's expected when the VI is marked reentrant.  Whether or not you need the VI to be reentrant is a matter of system design - in your case, reentrancy is not needed since you only have a single instance of each VI.

[JeffinCA]

---

@nathand wrote:

I'm still not clear whether you did what I suggested, which is: for each subVI, create a new, blank VI.  Copy the contents of the existing subVI into that blank VI and configure the connector pane.  In the top-level VI, replace the existing subVI with the new subVI you just created.  Close all the old subVIs.  Then, from the top-level VI, see if you can save the entire hierarchy properly.

---

I did precisely that (the second time) and "Duplicate Hierarchy" finally worked, so yes, you were correct in directing attention to the VIs.

As to how the the subVIs were created, I used the DAQ Assistant, expanded the code and edited each of the three subVIs ("NI-DAQ Configuration", "Sine Wave Data" and "Configure DAQ Input") to what you see.  "Sine Wave Prep" is a modified copy of "Sine Wave Data", so the fault propagates that way, but not via Copy and Paste.

Jeff