In Range and Coerce

[LAVA 1.0 Content]

I use the In Range and Coerce Function to coerce the N terminal of a for loop but the output is never coerced.

Also if the N terminal is in the range for the In Range and Coerce Function, the In range output need two run to turn on.

Anybody can explain this strange behavior? :headbang:

See the attached code.

[gleichman]

You're VI worked for me (WinXP, LV8.2.1). What results were you expecting?

QUOTE(pdc @ Dec 14 2007, 01:11 PM)

I use the In Range and Coerce Function to coerce the N terminal of a for loop but the output is never coerced.

Also if the N terminal is in the range for the In Range and Coerce Function, the In range output need two run to turn on.

Anybody can explain this strange behavior? :headbang:

See the attached code.

[LAVA 1.0 Content]

QUOTE(gleichman @ Dec 14 2007, 01:33 PM)

You're VI worked for me (WinXP, LV8.2.1). What results were you expecting?

uhm... This is what I get for the first run:

And this is what I get for the second run:

I use WinXP and LV8.2

Can it be a LabVIEW setting?

[Justin Goeres]

QUOTE(pdc @ Dec 14 2007, 12:23 PM)

I use WinXP and LV8.2

Can it be a LabVIEW setting?

That's rather bizarre. I get the same results as gleichman (that is, the behavior is correct) in both LV8.2.1 and LV8.5, under WinXP. Maybe it's an issue in LV8.2.0 -- I don't have that on my machine.

I'm not aware of any LabVIEW.ini setting such as MakeInRangeCoerceNotWork=TRUE .

[crelf]

QUOTE(Justin Goeres @ Dec 15 2007, 05:38 AM)

I'm not aware of any LabVIEW.ini setting such as MakeInRangeCoerceNotWork=TRUE

It must be MakeInRangeCoerceWork=FALSE

[LAVA 1.0 Content]

QUOTE(crelf @ Dec 14 2007, 02:43 PM)

It must be MakeInRangeCoerceWork=FALSE

Was there a bug in the N terminal with constant folding?

TO many bugs, so few brain cells....

Ben

[LAVA 1.0 Content]

I try it on two other computers:

1st with LV8.2.1 : the vi work fine

2nd with LV 8.2 : The vi does'nt work fine

Ouf, I don't need to add the key MakeTheProgrammerCrazy=False

Somebody with LV8.2 can confirm that is related to LV8.2?

Thanks to all, I will upgrade!

[Norm Kirchner]

QUOTE(pdc @ Dec 14 2007, 02:23 PM)

I try it on two other computers:

1st with LV8.2.1 : the vi work fine

2nd with LV 8.2 : The vi does'nt work fine

Ouf, I don't need to add the key MakeTheProgrammerCrazy=False

Somebody with LV8.2 can confirm that is related to LV8.2?

Thanks to all, I will upgrade!

I specifically remember there being a note in the 82 ->821 upgrade notes about in-range and coerce.

Make it so first mate

[AnalogKid2DigitalMan]

I have ran it on my 8.2 machine, it does behave odd.

1st run does not work, successive runs work.

[eaolson]

QUOTE(pdc @ Dec 14 2007, 12:11 PM)

I use the In Range and Coerce Function to coerce the N terminal of a for loop but the output is never coerced.

Also if the N terminal is in the range for the In Range and Coerce Function, the In range output need two run to turn on.

It gets even freakier. For me, in 8.20, the first run has the In Range? output in the bottom loop coming out as (incorrect) False for the first run, and True for the subsequent runs. Now, toggle the value of "Include upper limit" for the In Range and Coerce node in the top loop, and the next run gives False again for the bottom loop. Subsequent runs give True.

Wish I could upgrade. Grump.

[Justin Goeres]

QUOTE(eaolson @ Dec 14 2007, 03:11 PM)

It gets even freakier. For me, in 8.20, the first run has the In Range? output in the bottom loop coming out as (incorrect) False for the first run, and True for the subsequent runs. Now, toggle the value of "Include upper limit" for the In Range and Coerce node in the top loop, and the next run gives False again for the bottom loop. Subsequent runs give True.

Wish I could upgrade. Grump.

The 8.2.1 upgrade is free. I'd say that a critical bug in a basic comparison function would be a pretty good argument for applying that update . While you're at it (if it's a political issue) just tell the person holding the purse strings that it's only really fixed in 8.5 -- 8.2.1 was just a patch .

[Ton Plomp]

QUOTE(Justin Goeres @ Dec 15 2007, 01:18 AM)

The 8.2.1 upgrade is free.

Not if your SSP expired between 8.2.0 and 8.2.1

Ton

[Justin Goeres]

QUOTE(tcplomp @ Dec 15 2007, 12:30 AM)

Not if your SSP expired between 8.2.0 and 8.2.1

Yikes! I didn't know that. That's crappy. :thumbdown:

[Rolf Kalbermatter]

QUOTE(tcplomp @ Dec 15 2007, 02:30 AM)

Not if your SSP expired between 8.2.0 and 8.2.1

Ton

Well, not entirely true. You could download the LabVIEW evaluation version at that time and install it over the old one, preserving your license file, and everything was fine. The only difference between the upgrade and a full install was in fact preservation of already set things such as the license file.

Also installing theat version and activating it with the LabVIEW 8.2 serial number worked too, since they were both in terms of the license manager 8.2.

Unfortunately they pulled the 8.2.1 evaluation download and replaced it with the most recent one for 8.5 and here a non active SSP will render your 8.2 serial number invalid for this installation. Also 8.5 is in quite a few things more like a regression to 8.2.1 than anything else. But 8.5.1 is coming out somewhere next year. So if you upgrade now with SSP you get that upgrade automatically.

Rolf Kalbermatter

[eaolson]

QUOTE(Justin Goeres @ Dec 14 2007, 06:18 PM)

The 8.2.1 upgrade is free. I'd say that a critical bug in a basic comparison function would be a pretty good argument for applying that update . While you're at it (if it's a political issue) just tell the person holding the purse strings that it's only really fixed in 8.5 -- 8.2.1 was just a patch .

My inability to upgrade is not technical or financial, but political. Alas.