Programmatically detect if inputs are wired

[adriaanrijllart]

Hi LAVA people,

A quick question. Is there a way to detect inside a vi if an input was connected from the caller vi?

I don't want to make the inputs "required" so they have to be wired.

I could put some funny default value that *almost surely* will not be supplied by the caller, but there's maybe a better way?

Thanks

Adriaan.

[Tomi Maila]

QUOTE(adriaanrijllart @ Oct 26 2007, 10:57 AM)

I could put some funny default value that *almost surely* will not be supplied by the caller, but there's maybe a better way?

Actually comparing the control value with control default value is, I think, the best way. It's rather quick and doesn't include slow performance scripting. It also works always whereas scripting can break when you build application.

Tomi

[Yair]

At the moment, there is no other way to do this. You can see some more details here.

[crelf]

QUOTE(Tomi Maila @ Oct 26 2007, 09:34 PM)

Actually comparing the control value with control default value is, I think, the best way. It's rather quick and doesn't include slow performance scripting.

That's not really going to work, especially if you have float inputs. The real answer is no. That said, I'd like to see this a future feature of LabVIEW...

[Yair]

QUOTE(crelf @ Oct 26 2007, 03:53 PM)

That's not really going to work, especially if you have float inputs.

Why not?

You just set the default value to be an invalid value (e.g. NaN) and test for it. Checking for equality works perfectly well if it's a predetermined value.

[Ton Plomp]

QUOTE(Yen @ Oct 27 2007, 08:05 PM)

Why not?

You just set the default value to be an invalid value (e.g. NaN) and test for it. Checking for equality works perfectly well if it's a predetermined value.

I'm not sure what Chris is referring to but NaN can be composed in numerous ways.

That's the reason of the 'Is NaN?' primitive

Ton

[crelf]

QUOTE(Yen @ Oct 28 2007, 04:05 AM)

Checking for equality works perfectly well if it's a predetermined value.

Well, I suppose that will work, but it means that you need to keep track of what's valid and invalid for each subVI that the checking algorithm is in, so keep it tracable.

[Rolf Kalbermatter]

QUOTE(crelf @ Oct 27 2007, 03:18 PM)

Well, I suppose that will work, but it means that you need to keep track of what's valid and invalid for each subVI that the checking algorithm is in, so keep it tracable.

Standardized works too, and for floating points NaN is probably the best approach, at least I do it that way if I do it at all. Of course it could fail if there is an actual calculation that is invalid and its result is wired to that input. But!! then having tested for NaN (and probably doing some default action) is still most probably the best course of action.

In terms of subVIs I have not yet come across situations were I wanted really to know if a value was unwired, but quite often if it was valid at all, wired or not!

Rolf Kalbermatter

[Aristos Queue]

The reason for the "Is Nan?" prim is that testing for equality of NaN is tricky. According to the IEEE standard for floating point calculations (which LV follows), if I have a value A that is NaN and I compare it to a value B that is NaN, then I should get FALSE for tests of both equality and inequality. In other words, A!=B and A==B are both false. That's how you detect NaN. This makes it hard to build generic code for checking "is the input wired?" because anytime you want to use NaN as your magic value, you have to do different work than any other data type.

Your best bet would simply be to create two VIs, one that has the input marked as Required and one that doesn't have that input at all. The user could then drop whichever one they needed.

You might be able to do something clever involving a polyVI used to select between instances, too, but all the ideas I can think of along these lines have some drawback.

[crelf]

QUOTE(Aristos Queue @ Nov 5 2007, 07:03 AM)

According to the IEEE standard for floating point calculations (which LV follows), if I have a value A that is NaN and I compare it to a value B that is NaN, then I should get FALSE for tests of both equality and inequality. In other words, A!=B and A==B are both false.

Thank you Aristos, for putting eloquently what I was struggling with to verbalise. :thumbup:

[jpdrolet]

QUOTE(Aristos Queue @ Nov 4 2007, 04:03 PM)

In other words, A!=B and A==B are both false.

I'm nitpicking here but NaN!=NaN is actually True.

One trick uses the fact that NaNs generated by LabVIEW are always represented as 0xFFFFFFFF (-NaN). However NaN has many representations and 0x7FFFFFFF(+NaN) is another one. If you put +NaN as the default value of your control, you can still detect if the subVI is wired and receives a generic NaN (-NaN) or if it was unwired (+NaN). You detect which NaN using the flattened string. The trick still have its limitations since if the connection is made using "Create a constant/control", that constant/control will take the deafault value which is the one used for wire detection.

[adriaanrijllart]

Hi Everyone,

Thanks for all the comments. Good points have been made I hadn't thought about. The NaN can be a trap!

I will carefully choose an "invalid" number as default to detect wired inputs.

A colleague of mine came up with this: Add an extra boolean input saying: I wired the inputs!

I also like the suggestion with two different vi's: one required inputs, the other not. The programmer should know what he is doing.

Thanks all.

Adriaan.

[crelf]

QUOTE(jpdrolet @ Nov 6 2007, 12:25 AM)

One trick uses the fact that NaNs generated by LabVIEW are always represented as 0xFFFFFFFF (-NaN). However NaN has many representations and 0x7FFFFFFF(+NaN) is another one. If you put +NaN as the default value of your control, you can still detect if the subVI is wired and receives a generic NaN (-NaN) or if it was unwired (+NaN). You detect which NaN using the flattened string. The trick still have its limitations since if the connection is made using "Create a constant/control", that constant/control will take the deafault value which is the one used for wire detection.

This all confirms that there is no generic method to detect if an input is wired. What you're suggesting is a hack that just checks if a number is valid for a particular instance (you might as well just use In Range and Coerce). Sure, it's a work around, but I'd need to be pretty desparate to label such a sub VI as "Is Input Wired?"

QUOTE(adriaanrijllart @ Nov 6 2007, 04:25 AM)

I also like the suggestion with two different vi's: one required inputs, the other not. The programmer should know what he is doing.

You probably want to wrap the two of them in a polymorphic VI so it's easy (and obvious) to switch between them, just as Aristos suggested.

[silmaril]

QUOTE(Aristos Queue @ Nov 4 2007, 10:03 PM)

According to the IEEE standard for floating point calculations (which LV follows), if I have a value A that is NaN and I compare it to a value B that is NaN, then I should get FALSE for tests of both equality and inequality. In other words, A!=B and A==B are both false. That's how you detect NaN.

If A!=B and A==B are both false for NaN values, how do you explain this behaviour of LabVIEW 8.5?

http://lavag.org/old_files/monthly_11_2007/post-7932-1194603753.png' target="_blank">

[Aristos Queue]

QUOTE(silmaril @ Nov 9 2007, 04:25 AM)

If A!=B and A==B are both false for NaN values, how do you explain this behaviour of LabVIEW 8.5?

http://lavag.org/old_files/monthly_11_2007/post-7932-1194603753.png' target="_blank">

I got it wrong... it's the == that's false and != that is true. It's the <, > and == that are false. I knew there was some logical impossibility that you could find -- ie a two numbers that are neither greater, lesser nor equal to each other -- but I got it wrong in my memory which logical impossibility it was. (I should learn to double-check the documentation before posting details like this...)