RSlogix - Drinks Machine

[yasirkhi]

JSR must be in the last of the main program rung, in order to jump to subroutine, unless you don't want to scan rungs underneath JSR instruction.

 

[Lancie1]

I don't think you need all the debounce logic. I tested the 4D version, and I could not make this LogixPro version (using each flavor bit to lock out the others) dispense more than 1 drink for each coin, even if all 4 buttons were held ON at the exact same time. In that case, as you can see in the second attached pictue (where all flavors were selected with maintained-contact buttons BEFORE IP0 was pressed), the first flavor in the ladder logic (cola) is the only one activated and the others are locked out until the timer gets DONE. That makes sense, because if more than one flavor is selected, the PLC scan will arrive at the cola rung first, causing the other flavors to be locked out

If I were a sneaky underhanded marketing agent for the vending company, I would make sure to put the most expensive item first in the logic. If the customer accidently pressed 2 buttons at the same time, the higher-priced item always gets selected provided enough money was inserted! (Wait, I think they already do it like that)!

For the drinks sold counter, you do need to add a Preset value in your version. With a Preset of "0", it will not work very well as you have found.

If you do the drink counter as in this LogixPro file, I don't see how it could fail. When it hits 32767, it needs to be reset, otherwise it will roll over to -32767, then count back up to 0. One way is to add a 2nd counter that is triggered by the first counter, so that it counts batches of 32767 drinks (if that number is ever reached between refills). That number can then be recorded and reset by the machine operator when he refills the machine.

 

[mitureg]

OK Lancie, thank you for your input on the debouncing logic. I was looking into it for the wrong reason. I just wanted to have the counter to increment only when a drink is sold. It was either increment for a flavor bit if it was pressed several time or if several flavor were chosen in a sequence before the timer went down. I hooked up the TR1/DN with the counter instead of a bit, and also the same TR1/DN with the BIT_COIN_HOLD instead of the solenoid output.

Thank you for the security tip and for the profit based decision in regards to the solenoid priority.

I also had a look at that number 32767 (OHRRPGCE).

New version attached.
Cheers

 

[mitureg]

JSR must be in the last of the main program rung, in order to jump to subroutine, unless you don't want to scan rungs underneath JSR instruction.

Thank you for you input on JSR. I didn't know that, and it's quite important.
Cheers.

 

[Anirban Hazra]

JSR must be in the last of the main program rung, in order to jump to subroutine, unless you don't want to scan rungs underneath JSR instruction.

As far as I know, that is incorrectly stated. The rungs which come after JSR are definitely scanned but they are scanned after the scanning of the subroutine has been completed.Placing JSR in the last rung will ensure that the subroutine gets scanned after all the rungs in the main routine have been scanned.

 

[mitureg]

Thank you, that's what I assumed already anyway...

 

[Lancie1]

OK Lancie, thank you for your input on the debouncing logic. I was looking into it for the wrong reason.

Alex, about your logic in your 4D and 4E versions: carefully compare your logic in Rung 0002 with my last version. Do you see a major difference?

You are locking out the buttons, when really you should not care how many times the customer presses a button. The only thing you want to lock out is the effect of the button (the relays that the buttons control) You only want one Flavor-bit relay to be capable of being turned on for each Coin_Accept_Solenoid ON. One way will work, the other will allow multiple selections for the same price. You choose.

I will put your version in LogixPro and see if I am correct.

I tested it, and your method doesn't work at all. If two buttons happens to be pressed at the exact same time, the customer gets nothing! On the other hand, if within the 2-second period, the customer manages to push from 1 to 4 buttons in series, he gets 4 drinks for the price of one.

Please quit screwing around with this and fix it so it works. Use the Flavor bits, not the buttons, to do the interlocks on Rung 0002.

You don't need a subroutine for this short program. But if you did, a subroutine is called on the very rung where you place the JSR, and the PLC scan goes to the subroutine, runs through it, then returns to the rung below the JSR rung.

 

[mitureg]

According to my log you instigated a modification at rung 0002 with your 4D revision. I just followed what you did there : see snippet

 

[Lancie1]

If you check back, you will see that I have been using first the solenoids, then the Flavor Bits as the Rung 0002 interlocks from the time I proposed the solution way back in Post #10. It is YOU that incorrectly interpreted that rung and instead used the buttons. You are locking out the buttons for one instant, allowing the customer, as soon as one flavor solenoid has been activated, to immediately press another flavor. That sounds like a money-losing proposition to me.

 

[mitureg]

Beyond that, I did a modification at rung 0008 because if a user press a flavor bit button several time it will falsly trigger a drink count at CT1.
See snippet

Everything else looks the same.

What should I do with rung 0002 ?

Much appreciated,
Cheers

 

[Lancie1]

What should I do with rung 0002 ?

Fix it to look like my version 4D in Post #17. The timer bit is not the main problem, although you should use either the solenoids or the flavor bits to trigger the counter. I chose to use the flavor bits to avoid the need for another rung because the timer and counter can be combined on the same rung with the same inputs.

It is the stuff on the right side of Rung 0002, the interlocks that prevent more than one of the B3 Flavor Bits from being energized, that is causing your program to fail. If you fix those 4 rung branches on Rung 0002, then the counter will also work.

 

[mitureg]

OK you meant the 3 XIO on each of the 4 branch of rung 0002. I got it fixed, in attachment.

Please quit screwing around with this and fix it so it works.

I'll stop screwing around, no worries... I understand why you keep your own copy safe. LMAO Good trick not to get screwed up by others on a workplace.

Sorry for the confusion.

Cheers

 

[Lancie1]

I understand why you keep your own copy safe. LMAO Good trick not to get screwed up by others on a workplace.

If you mean a RSLogix copy, actualy I never made a version, only a LogixPro version 4D where I changed Rung002. I should have renamed it, though. I think it is your responsibility to make the final correct copy. I believe you are the student and I am acting as your tutor here.

 

[mitureg]

OK I finally got it. I rolled back to the double branch output with the CTU at rung 0003 and deleted rung 0008. It works great with the locking flavor bits.

Cheers

 

[Lancie1]

Congratulations. I think you have learned a few things along the way.

A very small thing is that your symbol for Timer T4:0 is "TR1". You probably meant that to mean the 1st available timer, but that might be a no-no for some people (picky instructors!). Many think it has to be Timer 0 or TR0 or something like that. You can call a symbol almost anything you desire, but it does help if everyone else can see the relationship.