LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

subvi in loop not working

Hallo everyone,

 

I just experienced a weird problem. (For demonstration, I attached a minimal configuration):

If I run the min_demo_example.vi, it should tell me if the terminal is connected or not. It works great, when I just put the subvi “test_terminalconnected.vi” as it comes.

The problems begins, when I put this subvi in a loop (don’t matter which, can be for, while, case, event,…).

I really have no idea why. Either there is something very obvious or I’m just too dump.

 

Would be very nice if someone could help me.

 

Regards

0 Kudos
Message 1 of 7
(3,612 Views)

Your zip file is empty.

0 Kudos
Message 2 of 7
(3,593 Views)

You're right and I have to appologize. Attached is the not empty one. thanks

0 Kudos
Message 3 of 7
(3,583 Views)

I ran your VI's with highlight execution on to verify they were executing.  Thje Terminal Checker gave me an error 1026 for invalid reference.  I also saw error 1 in the execution and an error 1055 for invalid object reference.

0 Kudos
Message 4 of 7
(3,531 Views)

it worked (or, rather, it mis-worked) for me.  The problem is the convoluted way you are testing to see if a terminal is connected to a specific VI on a sub-VI on the Top Level Diagram using LabVIEW Scripting.  When you wrap the sub-VI in a Structure, it is no longer a Sub-VI on the Top Level Diagram, and when you try to access a member of an empty array, you get an error.

 

Another way to test if anything is wired to the input is to set a Default Value that is "completely unreasonable" and to test for it.  One of the inputs of your Cluster is a string -- you could set the default value to "XYZZY" --you would test your string for XYZZY and, if different, would conclude that something was wired to the input.  Note that if they were the same, then either (a) nothing was wired, or (b) the user, unfortunately, loved playing Adventure ("A cheerful little bird is here, singing ...").

 

Bob Schor 

0 Kudos
Message 5 of 7
(3,451 Views)

@RavenFan: Sorry to hear that. Maybe you should rebuild the reference for the control of the front panel object in the subvi.

 

@Bob: Thanks. I can accept this as an explanation. Nevertheless it seems quite unintuitivley that a vi is no subvi anymore if I put it in a structure. Can someone please give me an explanation why?

I know about the method you proposed, and it might surely work, but I think it is a quick and dirty way to solve the problem. i wanted to stick more to a general solution, but it seams there is no other way. do you know if i can change the scripting in a way it works in general?

 

Julian

0 Kudos
Message 6 of 7
(3,318 Views)

No.  I'm not going to rebuild any reference.  I think the VI basically worked the way it was programmed, and the problem is with the programming just like Bob was talking about.  I was seeing one or more errors related to your program, not to the structural integrity of the VI itself.

 

To clarify Bob's point, the subVI is still a subVI.  If the subVI is on the main block diagram, then you can find it within the array of nodes that are on the block diagram.  If you have the subVI in a structure, then the structure is a node on the main block diagram, the subVI is a node within the block diagram of the structure.  You aren't going to find the subVI referenced in the array of main block diagram objects.  Your block diagram is actuall a tree of objects with items on different branches depending on whether they belong to higher level structures or not.

 

There is a VI called Traverse for GObjects with iterates through all the branches of the tree and returns references to the objects.  You may find that useful to use.  You can find the Traverse if you search or start typing it into the Quick Drop window.

0 Kudos
Message 7 of 7
(3,310 Views)