LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Scripting - replace invoke node

OK - So far so good.  I want to check in with the experts though to see if I'm on the right path here.

 

Thanks for the reminder of the Class Browser... I had seen that before, but of course as always, if you don't use it...

 

Also, Sev, yes, I did get the save working as you'll see in the attached.

 

So, where I'm at is that I decided that I would have a script VI that creates just all of the .NET methods from the class that I'm interested in.  It is the "Create class VIs_Updated.vi" that is attached (I know that you won't have the same classes as what I'm working with but a little manipulation and you could run it). Also attached is the "RSFSUxx_Seed_Method.vi" that provides one of the methods from the class that allows the VI to pull in all of the rest of the methods. What this set of VIs does then is create and save a VI that just has the invoke node for each of the methods. I only have it set to do two right now, but if you remove the Loop Count input to the for loop, it does create the vi for every method in the class - Slick!!.

 

Then I have a VI (attached also - "LV_Interop_Template.vi") that I have set up with all of my standard connections. Either sticking with scripting or the using the Codegen Engine, I would like to build a VI that will take the template VI, replace the method invoke node that is in there with the one called from the previously saved VIs of just methods, make the connections, then re-save with the same name as the VI with just the invoke node in it.

 

Here is where my limited understanding of the scripting capabilities gets me - if I know it's possible, I'll learn it...

 

What I need to do after I have substituted the method into the template VI is then:

1) Ensure that the connections for the references and the error clusters remain connected

2) If the method does not have IO, remove the inputs to and outputs from the template VI - or would I be better here to have as a template that does not have any IO and then do a check to see if there are any inputs and / or outputs required?

3) If the method does have an input and / or output, create the terminals, wire them and connect them to the connector pane.

4) If the method has 2 or more inputs and / or outputs, create the terminals, place them into a cluster (named input and / or output), wire the clusters (knowing that I will have to create a constant for the output one, along with bundle / unbundle for each) and then connect to the connector pane.

 

Another approach would be to have multiple different types of templates... one that would be for methods that do not have IO, one for methods with a single input, one for methods with a single output, one for methods with single input and output, one with multiple inputs, one with multiple outputs, and finally one with multiple Inputs and outputs

 

Comments? Hints? Tips?

 

Thanks for all of the help so far.

 

Dan

 

0 Kudos
Message 11 of 39
(1,647 Views)

Follow-up to the message above.

 

I did have at one point yesterday a VI that inserted each method into the template VI, but all the wired would disconnect when I did that.

 

Dan

 

 

 

0 Kudos
Message 12 of 39
(1,639 Views)

Sorry - this is working out well as a sounding board...

 

This is another update to the previous post.

 

After thinking about it, in the Create Class VIs_Updated.vi, I could within the loop open the LV_Interop_Template (removing the existing invoke node first) and then just drop in the new invoke node, and do the required wiring and connections from there....

 

Dan

 

 

0 Kudos
Message 13 of 39
(1,636 Views)

I do not have LV11 to see what you are doing, but based on fuzzy recollections I would try something along the following lines.

 

1. Start with a Template VI with an Invoke Node of the proper class, with the Reference and Error terminals wired.

2. Create a New VI using this template, select the Invoke Node using the Nodes[] property of the Block Diagram (there should only be one!).  Use To More Specific Class to convert to an Invoke Node (Invoke)

3. Use the Set Method to set the desired Method (I think you know this part)

4. Wire the InputTerms Property of the IN to a For Loop and call Create Control for each one

5. Same for OutputTerms, except that you call Create Indicator

6. Wire the ConPane if you like, do something with the icon as well

7.  Save the VI

0 Kudos
Message 14 of 39
(1,628 Views)

@Darin.K wrote:

I do not have LV11 to see what you are doing, but based on fuzzy recollections I would try something along the following lines.

 

1. Start with a Template VI with an Invoke Node of the proper class, with the Reference and Error terminals wired.

2. Create a New VI using this template, select the Invoke Node using the Nodes[] property of the Block Diagram (there should only be one!).  Use To More Specific Class to convert to an Invoke Node (Invoke)

3. Use the Set Method to set the desired Method (I think you know this part)

4. Wire the InputTerms Property of the IN to a For Loop and call Create Control for each one

5. Same for OutputTerms, except that you call Create Indicator

6. Wire the ConPane if you like, do something with the icon as well

7.  Save the VI


Thanks for the reply Darin.

 

This is pretty much the route that I am pursueing right now.  Thanks for the confirmation that I am probably on the right track

 

Dan


 

0 Kudos
Message 15 of 39
(1,625 Views)

WHOOHOO!!!!!

 

I am now creating a LabVIEW interop VI for every method in the .NET class that I am working with!!!  SO much better than wiring all of those by hand. 

 

It is simple. All that it does is (using a template):

1) gets a listing of all of the methods in the class.

2) Pulls up the template and sets each method (using a for loop)

3) Wires the input and the output terminals

4) Performs a cleanup

5) Saves the VI under the method name.

 

Now to do...

1) connect terminals to the connector pane

2) figure out if there are more than one inputs, or outputs and place them in a cluster (plus all the overhead of working with the cluster) then connect those to the connector pane.

3) Clean it up

4) Add some directory work to automatically open the template, and save the VIs in an appropriate folder structure.

5) Figure out how to place all of the method VIs into a polymorphic VI and create the selection menu so it follows a logical pattern - all via scripting.

 

I will post the script when it's cleaned up a little.

 

Dan

 

 

0 Kudos
Message 16 of 39
(1,620 Views)

ok...  having another issue.  And I thought I had this all worked out.

 

I am able to create a cluster, change it to an indicator, place my indicators in it etc, but whenever I try to move it into the case structure (error case), I get an error 1060 that says the "Object cannot contain (own) the specific object."  I know that I am getting the reference for the case structure because I can read back the name of the case and the case that is active. I am sending that into the move method for "owner". Then I have the reference of the cluster and I know I have the reference for that because I can set it to a terminal. The ref to the cluster I have going into the top ref point for the move method.

 

I have tried SO many different ways, but I CANNOT seem to get the cluster to move inside the case structure.  (Well I can, with the mouse, but that is NOT the point of scripting Smiley Happy ).

 

Help?

 

Dan

 

 

0 Kudos
Message 17 of 39
(1,611 Views)

I could probably figure out what you are doing wrong, but instead let me suggest you leave the cluster terminal on the root diagram.  It is a good habit to have all controls and indicators which are going to appear on the ConPane on the root diagram.  You can search for "Clear as Mud" to read the details but I gave you the Cliff's notes version.

0 Kudos
Message 18 of 39
(1,606 Views)

You can't move to a case structure.  You need to move to a specific frame of a case structure.  You can use either the Diagrams[] or Frames[] property to get a target.  Note that both of these are indexed in the order they were created.

0 Kudos
Message 19 of 39
(1,605 Views)

@ Darin - Yes, I understand that, and normally I do leave controls and indicators that are going to go to the connector pane on the main diagram. Just suffice for now that if I were to do that, I would create many more headaches than it would solve at this point.

 

@DFGray - That is what I had just concluded.  So to double check, I did an indicator off of the Diagrams[] and yes indeed there are two references there. Since I have not figured out a way to determine which is the Error diagram and the No Error diagram, I indexed 0 and fed it to the owner of the Clust:Move method, got the same error. Indexed 1 and again got the same error.  Smiley Mad

 

#1 - It has to be a stupid simple mistake that I am doing... one of those head slappers.

#2 - How do you determine which is the reference to the case that you are interested in?

 

Dan

 

 

0 Kudos
Message 20 of 39
(1,598 Views)