Jump to content

Programmatically detect if inputs are wired


Recommended Posts

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

Link to comment

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...

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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:

Link to comment

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.

Link to comment

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.

Link to comment

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

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...)
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.