RSlogix - Drinks Machine

Hi Everyone, thank you for reading this post. Please have a look at this program in attachment if you have a minute to share...

I would like to simplify this program as much as possible and eradicate all mistakes or wrong proceedings in order to bring this project as close as it gets to industrial standards.

All comments and advice most welcomed.

Cheers!

Not very smart! You have used an OTE for O:0/1, 4 times in 4 rungs.
Would you be surprised to learn that the only place that O:0/1 will have any effect is Rung 0007, the last case?

That is because the PLC tries to do exactly what you instruct in each rung. Therefore, the last duplicate (or double, as in "double-coil syndrome) is the one that it will use to set the value of the OTE, ignoring all the other OTE versions of O:0/1. Then your Rungs 0001, 0003, and 0005 could be deleted and your program would work exactly the same as it does now (not very well, I imagine)! If you can't believe that, then run your program With and Without 1, 3, and 5, and see how it operates.

You need to combine all cases of OTE O:0/1 into 1 rung. If you cannot, then you have to use intermediate or flag relays that in turn control O:0/1.

Duplicated output many times. And too many rungs. Simplified version is attached.

Thank you Lancie and Yasirkhi. I have another version ready. I did a few modification based on Yasirkhi. The lime drink button was swapped with another input, I corrected that.

Since the list of inputs are as follow, I replaced "FINISH_POURING" input by a B3.

IP0 Coin slot sensor OP0 Coin hold solenoid
IP1 Cola drink button OP1 Coin accept solenoid
IP2 Lemon drink button OP2 Dispense cola drink solenoid
IP3 Cherry drink button OP3 Dispense lemon drink solenoid
IP4 Lime drink button OP4 Dispense cherry drink solenoid
IP5 Reject coin button OP5 Dispense Lime drink solenoid

Does my version still contains double-coil syndrome like rungs? I use OTE as input at rung 2 and 3.

Much appreciated. File in attachment.
Cheers.

RUNG 3 seems not practical, because this won't make sure that fluid has poured or not.
Ofcourse pouring is from one nozzle, that has a sensor verify fluid is passed through for certain amount of time. So only one input is required.

Try to avoid OTL for physical outputs - Not recommended.

The drinks are dispensed in the form of metal can. Does that change anything for your logic reasoning yasirkhi?

Any thoughts on that one Lancie?

If it is a CAN, you still need an input at the gate or at the point where it will pass through. Just to make sure order is completed.

I would use more neutral descriptions and comments. What I mean is this.

You have outputs labeled things like "dispense cola drink solenoid." I assume this is at a particular position in the machine. So what happens down the road when someone rearranges the product and that position no longer dispenses cola? That's not going to be very helpful for someone who has to get online with it and try to figure out exactly which solenoid is supposed to be firing in a machine where all the labels have been moved. In my experience it's not uncommon for the offerings of a vending machine to be moved around and rearranged.

So I would use comments and descriptions that describe the physical aspects of the MACHINE, not the product it dispenses. If there's a mechanical drawing of the dispenser it should have some nomenclature on it like "Spout 1", "Spout 2" or something similar. Now if the Mechanical drawing DOES label the dispensers based on the product then I would leave it alone. It may be confusing in the future, but at least it would be consistent.

Any thoughts on that one Lancie?

Click to expand...

Yes, I love your Rung 0002. All vending machines should be built to dispense 4 for the price of 1! Probably the fellow collecting the money for the drinks would like you to make a few program changes, as in the attached picture.

As as been said on this site many times, getting a machine to do what you want is the easier part. Keeping it from doing the infinite number of things that you don't want is the hard part.

When a Drink Dispense Solenoid goes on, how long will it need to stay on to dispense a drink and then unlatch the Bit Coin hold? Maybe you need a timer or a seal-in to make sure that one of the solenoids is still ON to unlatch B3:0/0. In the real world (as opposed to the ideal student world), machines usually require more than 0 time to finish a step.

Maybe you were going to depend on the guy holding his finger on the button long enough to dispense the drink AND also reset the Coin Hold? I am sure you know how quickly word will spread that if you just hit the selector a half-second, that you can get as many extra drinks as you want!

You might need an intermediate relay that seals in when any drink selector is pressed. When sealed in, this new relay turns a light on for that button, telling the customer that his selection is made (but also locking out all other buttons until the Coin Hold is unlatched), and also enabling the Dispense Solenoids.

Hi Lancie, thank you for you reply. I added a substantial amount of logic with timers and B3 for the security aspect of the drink machine. I don't know if this could be a bit more tidy than what it is at the moment.

I have chosen more neutral descriptions for the timers and other contacts following the sound advice of brstilson.

Here is the explanation I added in comment for this version:

!! These rungs control the security aspect of the drink machine. It ensures that no more than one drink can be obtain with one coin. This is done in 2 differents steps. First we have N/C contacts to exclude all other possibility of output coil activation with the exception of the one being pressed. Second, there is a B3 inner logic corresponding to the chosen drink that activates an assigned timer for each drink solenoid. This timer takes in charge the energizing time for the output solenoid contact for each drink. This has the purpose of preventing a "funny" operator button trick that would, within a certain time frame, allow the machine to dispense more than one drink. At the end of the timer sequence, the "drink bit" is reseted by the timer /DN contact. This activates as well the unlatching of the "bit coin hold" output. !!

File attached.
Cheers

Alex,

I think that last round now covers the subject. If you want to refine it some more, I think that you could probably use one timer in place of the four. A timer can be used for more than one purpose at different times.

Because only one drink should be dispensed at a time, you could (just for laughs) use only T4:0, and on Rung 0003, put all 4 drink-flavor bits in parallel, B3:0/2 through B3:0/5, to start T4:0. Then any ONE of them would start T4:0 running. Then use a T4:0/DN at the end of each branch of Rung 0000 to time the flavor bits. Probably then you only need to use B3:0/2 to B3:0/5 to also activate each flavor dispense solenoid in Rungs 4, 6, 8, and 10, which will now automaticaly go off after 2 seconds. That would reduce the number of rungs considerly while still only allowing a 2-second window to seal in the drink selection AND dispense the drink. After 2 seconds, the Bit_Coin_Hold will get unlatched, preventing any tinkering with the buttons.

OK I followed your advice and made the modification Lancie. The new version is the file "DRINKS_MACHINE_4D.RSS".

I also have an alternate version ""DRINKS_MACHINE_4E.RSS" with a debounce logic for let's say, if the customer change his mind about the drink he wants to get.

Plus I wanted to add a counter for the number of drink sold. That's one of the reason I needed the debounce logic because I was getting wrong counts trigger. There is probably a simpler way to fix this, but I thought the debounce logic for the first reason mentioned would be a real world application on a modern drink machine.

Have a look,
Cheers

All those things labeled "Debounce" look impressive, but will they prevent 2 signals from the same drink selector pushbutton? If your DID get two signals from the same button, would that be catastrophic? What would happen, since your logic already immediately locked out the OTHER drink buttons, why do you care it a guy hits the same button 2 or 3 or 10 times within the 2-second window? He would still get only 1 drink even with the original interlocked circuit.

Bouncing is the tendency of any two metal contacts in an electronic device to generate multiple signals as the contacts close or open; debouncing is any kind of hardware device or software that ensures that only a single signal will be acted upon for a single opening or closing of a contact.

Click to expand...

Later I will enter your program into LogixPro and test to see if all the "debounce" stuff is doing any good, or just looks impressive.

Thanks. I still have a few problems with the JSR, maybe you'll be able to see why.