10-18-2015 08:52 AM
Hello
I am creating a vi of a vending machine and I got to the point where I have to return the change.
I want to display the change in 1$ dollar bills, quarters, dimes, and nickels but I have no idea how.
I have already done that in another programming language where I substracted the integer from the double (ex assuming amount =2.45 ---> double(2.45)-int(2.45)=2.45-2=0.45) so int(2.45) which is 2 goes into the 1$ bills and the rest which is 0.45 into the rest and so on.
In LabView however it seems that int(2.45) is = 3 not 2 so I cant use that method.
How can I proceed?
(the following should be done when both case structures are false)
Solved! Go to Solution.
10-18-2015 09:03 AM
Instead of using the conversion, look at Round to - Infinity. This will always truncate the value. You can convert it to an integer type if you'd like.I'm not sure if that's part of your requirements or not. Once you use the rounding operation, you should get back to the truncating you're used to and be able to figure out the rest from there.
10-18-2015 09:09 AM - edited 10-18-2015 09:10 AM
You can use the "Quotient and Remainder" function, part of the numeric pallet. It works similar to modulus in a text-based language.
10-18-2015 10:01 AM - edited 10-18-2015 10:03 AM
I used round to - infinity and everything went perfect thought I feel like the code is a bit complicated and can be done in a simpler way.
There is a small problem however.
In some cases even if the price and the amount inserted are equal, it says not enough money and displays a very small amount of money remaining.
Do you have any idea why?
For instance if the user's inputs are 4, 2 and 6 respectiverly and the amount inserted in 6.8 which equals the price, it says not enough.
10-18-2015 10:15 AM
I did not look at your VI but almost certainly the effect you are seeing is due to the way fractional values are stored in binary. Many values which are exactly represented in decimal notation are infinitely repeating in binary. Such values will always have a small error compared to the exact value.
For currency calculations it is often better to use integers and work in cents rather than dollars.
Lynn
10-18-2015 10:51 AM
Johnsold and I are "ancient" enough to remember old-fashioned Cash Registers (which did not compute the change) and how cashiers (who did not do subtraction in their heads) used to make change. Suppose they had a Price, P, and you gave them Money, M, with M > P. The object is to return Change, C, such that M - C = P.
However, that's a "subtraction" problem, which is "difficult". Cashiers converted it to a simpler "addition" problem by returning C such that M = P + C. For example, you buy $5.36 worth of stuff and pay with a $20 bill. Here's what the cashier would do:
Note that the cashier has given you $10 + $4 + $0.50 + $0.10 + $0.04 = $14.64, which is the correct change, but has never mentioned (nor computed!) that number. Similarly, the customer doesn't really know how much change has been returned, but because he (or she) can add, too, knows the amount matches what was tendered, so must be correct.
You can use the same algorithm in your Change Machine. For a step-wise algorithm such as this, a State Machine might be the way to do (have states "Add Pennies", "Add Nickels", "Add Dimes", etc. Note that you are dispensing coins and (possibly) bills, so the output from your machine will be an array of "Money", where "Money" might be represented as an Enum of "Penny, Nickel, Dime, Quarter", etc., so the above example "solution" would be the array "Penny, Penny, Penny, Penny, Dime, Quarter, Dollar, Dollar, Dollar, Dollar, Ten" (for example).
Bob Schor
10-18-2015 11:05 AM
The simpler solution is to use the remainder Will suggested - divide the total number of cents by 1000 to know how many 10$ bills, then divide the remainder by 500 to know how many 5$ bills and so on until you get to the lowest value coin. Since it's a process you repeat and a value you keep changing, a for loop and shift register should do the trick.
10-18-2015 11:13 AM
I would agree with Lynn that your problem with price and amount inserted not being equal is due to binary rounding.
You amount inserted is probably something like 6.7777777779 and price 6.8000000001. So use integers and cents.
10-18-2015 12:01 PM
Of course you really don't want to do all that duplicate code, especially since it continues with "etc".
A single Q&R and a FOR loop with a shift register is all that's needed. 😉 Make it scalable!
10-18-2015 12:32 PM
Final version absolutely, always optimize, but to show the concept of using quotient remainder, to break down cents into coins, I opted for the cascaded approach for clarity.