LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Amount of money to bills and coins

Solved!
Go to solution

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)

0 Kudos
Message 1 of 14
(9,359 Views)

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.

Message 2 of 14
(9,344 Views)

You can use the "Quotient and Remainder" function, part of the numeric pallet.  It works similar to modulus in a text-based language.

bg.pngfp.PNG



I saw my father do some work on a car once as a kid and I asked him "How did you know how to do that?" He responded "I didn't, I had to figure it out."
Message 3 of 14
(9,333 Views)

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.

0 Kudos
Message 4 of 14
(9,314 Views)

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

Message 5 of 14
(9,303 Views)

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:

  1. Start giving you pennies, adding one to the amount you paid, until it was a "rounder" number.  For example, give you four pennies and say "$5.40".
  2. Give you nickels and dimes to get to multiples of a quarter.  So give you a dime and say "$5.40".
  3. Give you quarters to get to a dollar -- two quarters and say "$6".
  4. Give you dollar bills to get to a multiple of $5 -- give you four dollars and say "$10".
  5. Give you fives and tens to get to the amount you paid -- give you a ten and say "20".

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

Message 6 of 14
(9,284 Views)

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.


___________________
Try to take over the world!
0 Kudos
Message 7 of 14
(9,268 Views)
Solution
Accepted by topic author patomated

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.

 

bd.png



I saw my father do some work on a car once as a kid and I asked him "How did you know how to do that?" He responded "I didn't, I had to figure it out."
Message 8 of 14
(9,259 Views)

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!

Message 9 of 14
(9,239 Views)

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.



I saw my father do some work on a car once as a kid and I asked him "How did you know how to do that?" He responded "I didn't, I had to figure it out."
Message 10 of 14
(9,224 Views)