LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

going polymorphic switches inputs

Assume:

  • you have plain.vi, with the current default 12 input;/output connector, all used,
  • some of those inputs are of the type double,
  • those inputs are not required and have default values,
  • you call that VI from a LARGE number of other VIs,
  • not all of those calls connect to all of the double inputs, when calling plain.vi.

Now:

  • close LabVIEW.
  • rename plain.vi to plain-old.vi,
  • copy plain-old.vi to plain-new.vi,
  • open LabVIEW (2012 in this case)
  • change plain-new and replace one of the double inputs with a structure of two doubles (thus gaining one input),
  • change plain-old to call plain-new, filling in the one of the new structure inputs with the corresponding old input and defaulting the other double,
  • create a polymorphic plain.vi and add in plain-old.vi and plain-new.vi,
  • open a main.vi that causes (most of) the LARGE number of VIs that used to call plain to be loaded in memory.

With automatic polymorphic choice I would expect LabVIEW to chose plain-old.vi for all the places where the old plain.vi was called, and it does so.

 

What I wasn't expecting was, that in places where not all double inputs to the old plain.vi are wired, that LabVIEW would REARRANGE the wires and connect  a double carrying wire to a different input of plain-old.vi, which has the same old connector type as before!?

 

Is that to be expected?  Is there a way around it?  Would it make a difference if I had all the calling VIs in memory? (though in my case that is not possible, as I can't have all of them in memory simultaneously...)  Some of the calling VIs have constants in the diagram and I can't really tell which ones were changed or not (as I didn't write most of them)

 

 

 

 

 

0 Kudos
Message 1 of 5
(2,614 Views)

instrumento,

 

I think that I have an understanding of your set up, until you describe the unexpected behavior. When you say rearrange wires, do you mean that the wires are being connected to the wrong inputs? Where is the the "double carrying wire" that you mention coming from? 

Can you please attach a screenshot of the unexpected behavior and the behavior that you were orginially seeing so that I can see how it changed?

 

Regards

Carli S.
Troubleshooting & Maintenance Digital Business Manager - NI
0 Kudos
Message 2 of 5
(2,563 Views)

A lesson to learn:  Design the interface before you use the construct.  Doing it backwards can be painful!  I would say Of course it is expected behavior!  LabVIEW can't read your requirements spec and some errors are likely introduced when you automatically replace objects.

 

Next tip:  Find all the callers and bookmark them maybe even with a snip (not snipett, a plain olf jpg) of "as is" on the BDs Then replace the vi with the poly.  use the Bookmark manager to go back and see that every implementation was correct (clear the bookmarks as you go)


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 5
(2,556 Views)

I think that I have an understanding of your set up, until you describe the unexpected behavior. When you say rearrange wires, do you mean that the wires are being connected to the wrong inputs? Where is the the "double carrying wire" that you mention coming from? 

The before and after pictures are the same, as the original VI is called and it's icon is the same.

The only difference is that some of double inputs end up connected to different inputs, of the same type.

I would expect that maybe it would make a mistake if the input that is moved was previously connected to the input that changed type, but not any others.

Whatever input match algorithm that is used to automatic decide where connect the wires,  probably only looks at plain-new and plain-old and not at what the old diagram looks like.

 

 

0 Kudos
Message 4 of 5
(2,375 Views)

A lesson to learn:  Design the interface before you use the construct.  Doing it backwards can be painful!  I would say Of course it is expected behavior!  LabVIEW can't read your requirements spec and some errors are likely introduced when you automatically replace objects.

 

Next tip:  Find all the callers and bookmark them maybe even with a snip (not snipett, a plain olf jpg) of "as is" on the BDs Then replace the vi with the poly.  use the Bookmark manager to go back and see that every implementation was correct (clear the bookmarks as you go)


Lesson learned?  Unless the lesson is when you come into a job, don't reuse any old code.  Just rewrite all the 10000 to 20000 VIs from scratch:-), maybe in another language.

 

And LabVIEW can read my requirements as it knows what the old diagram looks like.  We now have to put a poly in its place.  Does it, by any chance, have one of the components that matches exactly the old cone?

Yup, reuse it.

No, go ahead and do your best matching job.

 

I had found all callers and fixed all callers before posting.  However, I had to open all our "top level" projects to make sure I didn't miss any of the uses.   Not that hard, just incredibly laborious.

0 Kudos
Message 5 of 5
(2,368 Views)