Increase/decrease count to reach a certain value and then stop

[H2lloTh3r3]

Hello, I am working on a program to control an actuator attached to a load cell and need the user to be able to position the actuator such that the load cell is just touching a sample prior to a bending test. To do this, I want to have it so the user enters a voltage value and the actuator extends/retracts by increasing/decreasing the initial value by an increment (in order to control the speed) until it reaches the entered value then stops. 

I've had a couple of problems:

1) Getting it to stop. Whenever I set the loop to end when the count is equal to the input it never does. I have used a probe when running and the value will reach the input but will then pass it without terminating the loop.

Ex. Input = 3 the count will count up to 3 and then continue to 3.01 without stopping.

I can get around this by using a ≥/≤ but then the final value jumps between the desired value and +/- 0.01

2) Finding a way to set up the case structures so they can trigger different cases depending on which Boolean is true.

Ex. If Input > Count Value = TRUE execute case that increases the count, and if Input < Count Value = TRUE execute case that decreases count

The pictures attached show my most recent attempt to solve the problem and it works except that it doesn't stop. Upon reaching the desired value the count continuously fluctuates between the desired value and values +/- 0.01 causing the actuator to move in and out by a very small amount.

I'd very much appreciate any tips to solve my problem or make my code more efficient.

 (All done on LabVIEW 2014)

[altenbach]

---

@H2lloTh3r3 wrote:

 (All done on LabVIEW 2014)

---

If you only show pictures, the LabVIEW version is not important. It is always better to attach the actual VI. Nobody here want to look at code pictures. We cannot test, run, or debug a picture.

This has been solved many times in previous discussions. Did you do a forum search?

[H2lloTh3r3]

There was a notice saying to use PNG files so I thought applied to all files. I tried a search but I couldn't find a way to phrase my problem in a way that yielded useful results (too many words).

There is the code if that helps. 

[altenbach]

---

@H2lloTh3r3 wrote:

There was a notice saying to use PNG files so I thought applied to all files 

---

PNGs (if done right!) can contain LabVIEW code, yours don't 😄 Have a look at LabVIEW snippets. 😄

I'll have a look at your VI later.

[Minions]

For starters, I would change the properties of the Set Actuator Position.  At a minimum, change the Data Entry of Increment to COERCE to nearest rather than IGNORE.  Next, I would ensure that the Display Format for your starting (0), increment and decrement values (0.01) are set to Floating point with 2 Digits of Precision.  This should help make the comparison work.

[altenbach · Accepted solution]

---

@Minions wrote:

 are set to Floating point with 2 Digits of Precision.  This should help make the comparison work.

---

No that is just a cosmetic property of front panel objects and has no bearing on the data in the orange wire. It will NOT help any comparisons. Things like 0.1 cannot be expressed with a finite number of bits.

One option would be to do the ramp using integers and divide by 100 where needed.

[Minions]

---

@altenbach wrote:

---

@Minions wrote:

 are set to Floating point with 2 Digits of Precision.  This should help make the comparison work.

---

No that is just a cosmetic property of front panel objects and has no bearing on the data in the orange wire. It will NOT help any comparisons. Things like 0.1 cannot be expressed with a finite number of bits.

---

I understand the IEEE-754 conventions.   The 2-Digits of Precision was for the Block Diagram objects and not the Front Panel as there is no coercion properties.  However, maybe all orange wires regardless of origin have this.  Could have these wires treated more like BCD when coercion/precision is used. 

[H2lloTh3r3]

Changing the doubles to integers and dividing by 100 has prevented the fluctuations. The rest of the code now works properly. Thanks!

[altenbach]

---

@H2lloTh3r3 wrote:

Changing the doubles to integers and dividing by 100 has prevented the fluctuations. The rest of the code now works properly. Thanks!

---

You are still doing this way too complicated. There is no need for inner loops and complicated structures. Here's one possible simplification doing basically the same using 10% of the code. (see also my signature :D)