LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Control Below Range Minimum

I have a standard numeric control which is a "Strict Typedef" because of sizing changes.
It has a represenstation of I32.
 
I programattically change the Minimum and Maximum (using Property Node) to values in ranges of 16 (1-16, 17, 32, etc).
 
When I use the decrement button, it goes one below the programmed minimum (e.g. if I have the minimum at 17, it will decrement to 16).
This is not true when the minimum is 1.
 
Any ideas?
 
All help is appreciated.
 
0 Kudos
Message 1 of 13
(3,866 Views)

More information:

 

There are two controls in this system that relate to each other.

One control is used to select a cart number (this control has a range from 1-6)

The other control (the one that is failing) selects the slot on the cart (each cart has 16 slots).

When the cart number changes, the slot number control is changed to match the slots associated with the cart.

When the cart number increments (e.g. 2-3), the slot control allows the decrement to go below the property minimum (down to 32 instead of 33).

When the cart number decrements (e.g 4-3), the slot control does not allow the decrement to go below the property minimum (limits to 33).

 

The same code is used to calculate slot min/max regardless of whether the control increments or decrements.  All that is determined is a change in cart value.

 

Once again, all ideas are appreciated.

 

0 Kudos
Message 2 of 13
(3,860 Views)
The range on a control only prevents the user from entering a value below the minimum or above the maximum. It doesn't stop your program writing other values to it.

I did a little test on a new VI. I got a 2 frame sequence with a numeric control in the first frame with a range min of 10, and a value of 15. In the second frame I wrote 2 to a local variable for the control and ran the VI. The control displayed 2.

I would use the in range and coerse VI before writing to the indicator.
0 Kudos
Message 3 of 13
(3,856 Views)

That's not the problem.

The control is allowing the user to enter a value lower than the minimum.

I changed the min/max programmatically, but after they are changed, the front panel control allows a value lower than the minimum.

 

0 Kudos
Message 4 of 13
(3,840 Views)

This is definitely a bug in the LabView compiler.

I can put a probe on my write to the minimum property node and see that I am writing a 17.

When I read the minimum property node, it displays a 16.

 

0 Kudos
Message 5 of 13
(3,823 Views)

Before definitively attributing this behavior to a "bug in the LabVIEW compiler", could you perhaps attach a simple VI demonstrating the problem so we can take a look?

-D

0 Kudos
Message 6 of 13
(3,820 Views)

At the moment, I don't have the time to convert this to a simple VI, I will try to simplify it later.

I can post my whole project (including text files that are read in).

 

 

0 Kudos
Message 7 of 13
(3,818 Views)

Ok, in the interest of proving my point, I made a single VI, along with a Custom Control, that I can upload.

At the moment, I am trying to figure out how to upload.

 

0 Kudos
Message 8 of 13
(3,814 Views)
Ok, found it.
 
The VI has two custom controls, titled "Cart" and "Slot".
 
When cart changes, the range and value of slot are changed.
 
Notice that when cart is incremented, the minimum of slot is different than when cart is decremented.
 
 
Edit:  Help is greatly appreciated as I have not been able to find a work-around for this.
 

Message Edited by jspaarg on 03-17-2006 11:55 AM

Download All
0 Kudos
Message 9 of 13
(3,809 Views)
You did not include all of the subVIs and custom controls so we cannot run your VI. Use Save with Options... Development Distribution to create an .llb with all the subVIs.

I would guess that your problem is a race condition. You have many local variables and many independent nodes. You have no idea which part of the code will execute when. Shift registers would probably allow you to eliminate the local variables and some data dependency or an event structure and a state machine would provide a more robust and understandable dataflow.

Lynn
0 Kudos
Message 10 of 13
(3,806 Views)