Misuse of Polymorphic VIs

[RTSLVU]

Newer <> better

Yokogawa decided to get all fancy and use the new Polymorphic feature on a lot of their VIs.

I get it Polymorphic VIs can be a nice feature but there is a point where they are actually worse than the old VI's.

Example creating a measurement list for any Yokogawa power analyzer like the WT-500 I could do this:

But with the fancy new polymorphic VIs that came with our fancy new WT-1800 power analyzer I have to do this to obtain the same results:

OH, yeah that is soooo much better... NOT!

[santo_13]

Haha, you're right, OVERUSE

Use polymorphic only when the VI supports more than one connector pane format and/or change in input data type. Datatype handling was improvised with the introduction of malleable VIs.

In your case, neither the connector pane nor the data type seems to change, then it should be a single VI with case structure handling.

[altenbach]

---

@RTSLVU wrote:

Yokogawa decided to get all fancy and use the new Polymorphic feature on a lot of their VIs.

---

Polymorphic VIs are a very old feature. Malleable Vis are relatively recent. (Cannot tell from the picture what you have there)

[RTSLVU]

---

@altenbach wrote:

---

@RTSLVU wrote:

Yokogawa decided to get all fancy and use the new Polymorphic feature on a lot of their VIs.

---

Polymorphic VIs are a very old feature. Malleable Vis are relatively recent. (Cannot tell from the picture what you have there)

---

I am not sure if I even know the difference between polymorphic and mailable VIs. 

But LabVIEW 2018 is the most recent version Yokogawa has VIs for, maybe it's not so new.

[crossrulz]

From what I can see, it looks like they decided to break up a single VI with A LOT of cases into separate VIs/methods.  I would say this is an improvement in readability.

Otherwise, it looks like they were trying to copy DAQmx.

[RTSLVU]

---

@crossrulz wrote:

From what I can see, it looks like they decided to break up a single VI with A LOT of cases into separate VIs/methods.  I would say this is an improvement in readability.

---

I don't agree. The "old way" took one single instance of one VI that looked like this inside:

The "Function" ring contained every measurement possible. This VI actually had more functionality than the "new" ones because it could also call up the Preset and it handled building the entire string and writing it to the instrument.

The "new way" requires one of the Polys and a second VI just to complete the string and write it to the instrument

[tyk007]

A great rule of thumb is to implement your own wrapper around any external dependencies whose API you don't control. That way you can limit the scope of change in your application.

In your case, a wrapper VI using an enum (for the calls you need) plus any common parameters. That internally calls the correct polymorphic VI instance (either the specific VI or the polymorphic VI).

[billko]

---

@tyk007 wrote:

A great rule of thumb is to implement your own wrapper around any external dependencies whose API you don't control. That way you can limit the scope of change in your application.

In your case, a wrapper VI using an enum (for the calls you need) plus any common parameters. That internally calls the correct polymorphic VI instance (either the specific VI or the polymorphic VI).

---

So you create a VI to recombine all the code that was originally separated from a single VI.  That takes Rube-ish code to a new level!  😄  However, yes, that is how I might implement this as well.

[crossrulz]

---

@RTSLVU wrote:

The "new way" requires one of the Polys and a second VI just to complete the string and write it to the instrument

---

Well, the extra VI is kind of silly.  I think I would have just had the ability to add to the list in the previous VI.

[tyk007]

---

@billko wrote:

---

@tyk007 wrote:

A great rule of thumb is to implement your own wrapper around any external dependencies whose API you don't control. That way you can limit the scope of change in your application.

In your case, a wrapper VI using an enum (for the calls you need) plus any common parameters. That internally calls the correct polymorphic VI instance (either the specific VI or the polymorphic VI).

---

So you create a VI to recombine all the code that was originally separated from a single VI.  That takes Rube-ish code to a new level!  😄  However, yes, that is how I might implement this as well.

---

Haha yes, that's probably how I would have started, and then be amused how it ended. I've been bitten many times with vendor API changes that the extra work involved in providing my own abstraction up front was worth doing.