Timer Trouble for ML1200

Good day all, I am writing a project in RSL500 that will actuate timers for 8 plating tanks. Currently there are prox switches that, when the basket is lowered into the tank, it turns-on a timer in the PLC and continues to time until the preset is reached. After the first timer times-out, a second timer will begin timing-up until the basket is removed and the prox switch opens. These prox switches are not lasting very long and they sometimes move out of position, so this has been a very reliable way to run these timers. When the hoist is over a certain tank there is a prox switch up on the I-beam which lets the plc know that the basket is over the tank properly and will permit the hoist to lift or drop. I have written instruction so that the hoist position is "known" by the PLC. There are cold and hot water rinse tanks in-between the process tanks (very similar to our acid strip system that you folks have helped me with in the past) and they don't need to be timed. The challenge I have is this; when the basket is dropped into the tank the down-timer begins. When that timer expires the up-timer begins. I need a way to write this so that the timer will continue until the down prox (I:0/15) breaks (lifting the basket out of the tank). I only have one basket represented with my project for obvious reasons. Thank you.

I can't open your program. Would you print it to a PDF file and post the PDF here?

I need a way to write this so that the [Down] timer will continue until the down prox (I:0/15) breaks, (lifting the basket out of the tank).

Click to expand...

To get any timer to "continue" longer than it presently does, just increase its Preset value. For example, if you were to add the Preset setting of your UP time to the current setting of the DOWN timer, then the DOWN timer should run until the UP timer is DONE.

But I am not sure why that is necessary, or how it would be better than some other method.

I was able to get it to open in RSL500. I kind of see what you are trying to do but I could use some more info on the whole process.

It might be helpful to know what these timers are for? What happens when the timers are done?
Are you trying to automate the "dip" process? If so I understand the purpose for the down timer but I am not sure what the up timer would do for you. Unless you are looking for an alarm if the basket doesn't hit the up LS within a certain amount of time.

If you can get us a little more info I am sure we can help.

here's a printout of his program ... I'm swamped right now - but maybe someone else can lend a hand ...

.

Thanks, Ron!

The challenge I have is this; when the basket is dropped into the tank the down-timer begins. When that timer expires the up-timer begins.

Click to expand...

Ceilingwalker,
That may be the way it is supposed to work, but looking at Rung 008, the UP timer T4:0 HAS to start FIRST, then the DOWN timer T4:1 can only run when the UP timer is finished! It seems that the DN bit should be moved to be in front of T4:0, and changed to T4:1/DN (to match what you said, and to make sense if the Basket FIRST moves DOWN, then UP)!

I was able to get it to do what I wanted with the bottom rung. I have tested it and it is working but I would sure appreciate some constructive criticism, as in how I could have done it a better way. Thank you

Sorry, I didn't attach it to the previous reply as I intended

I am having trouble uploading my screen shot so here is the project. Thank you.

Lancie1 said:

Thanks, Ron!

Ceilingwalker,
That may be the way it is supposed to work, but looking at Rung 008, the UP timer T4:0 HAS to start FIRST, then the DOWN timer T4:1 can only run when the UP timer is finished! It seems that the DN bit should be moved to be in front of T4:0, and changed to T4:1/DN (to match what you said, and to make sense if the Basket FIRST moves DOWN, then UP)!

Click to expand...

I had something similar to that but it wouldn't work when the hoist was at another station, say station 3 for example. When the conditions went true for those addresses, it would turn on and off the timers at undesired times.

I was able to get it to do what I wanted with the bottom rung.

Click to expand...

You are starting the first timer when B3/3 Hoist DOWN goes on, which means the first timer to run is going to be starting when the hoist is already DOWN and starting to move UP. It seems to me if the DOWN limit is failing, it would be best to start the DOWN timer with the hoist UP, then use the DOWN timer DN bit to trigger the hoist UP travel.

Using the TT bits as you are is risky, because T4:0/TT can go OFF 1 scan before T4:1/TT will go ON, causing both timers to drop out, ready or not.

I had something similar to that but it wouldn't work when the hoist was at another station, say station 3 for example. When the conditions went true for those addresses, it would turn on and off the timers at undesired times.

Click to expand...

That is probably due to using "C5:0.ACC = 5" to trigger UP Timer T4:0. Why do you care which station the hoist is at to trigger the UP or DONW hoist timer? Should not you use your "Hoist Lifting" B3/2 to start T4:0 Process UP timer? (Unless you are fibbing and T4:0 is really not supposed to measure how long it takes the hoist to go UP.)

Does each station have different UP and DOWN times, and you are trying to determine those station times in order to replace the failing Limit Switches? If so, you might consider using the Timer DN bits in parallel with the Limit Switches, so whichever on goes on first (limit switch or timer DN bit) will start the hoist travel UP or DOWN. That way if any LS fails, the timer can take over and keep the process running.

Lood at these 2 LogixPro simulations of your Rung 0008. Version 1 has problems. Simply reversing the position of the timers causes T4:1 never to run. Version 2 will run both timers in either rung position, due to using something other than T4:1/TT to get T4:1 started.

Lancie1 said:

Using the TT bits as you are is risky, because T4:0/TT can go OFF 1 scan before T4:1/TT will go ON, causing both timers to drop out, ready or not.

Click to expand...

Thank you. This is exactly the kind of advice I was looking for. This part of the ladder has been running a couple of years now. For this particular process it isn't that critical but I can think of some others that it would be. Is there "make-before-break" sort of instruction available?

[/quote] Why do you care which station the hoist is at to trigger the UP or DONW hoist timer?[/quote]
Because there are rinse tanks in-between the process tanks that do not have timers associated with them and each of the tanks has their own up and down timer. I wrote this logic just to get one of the tanks operating properly, however, there are a total of 8 so the C5:0.acc could be 1,2,3....8 and each timer has its own display.[/quote]
[/quote]Should not you use your "Hoist Lifting" B3/2 to start T4:0 Process UP timer? (Unless you are fibbing and T4:0 is really not supposed to measure how long it takes the hoist to go UP.)[/quote]
Not "fibbing", I accidentally left out a vital piece of information. These are process timers, it is not timing the hoist, it is timing how long a basket has been in the plating tank. On top of that, I mistakenly labeled the up-timer the down-timer. What it does is first, times-down to whatever sp the operator enters (N7:0) from HMI. When that timer expires the up-timer begins and has a large red slave display that lets half the plant know the basket has been in the tank too long and how much additional time has elapsed.

Oh. Okay. If you are timing the process, then you will not be able to use these process timers to help with the failing limit switches. You would need another set of timers for the hoist travel UP and DOWN times, to use as a check against the limit switches.

Lancie1 said:

Oh. Okay. If you are timing the process, then you will not be able to use these process timers to help with the failing limit switches. You would need another set of timers for the hoist travel UP and DOWN times, to use as a check against the limit switches.

Click to expand...

Sorry Lancie1, it was my inability to properly describe what exactly I was hoping to accomplish. I will try again;
1. Operator pushes fwd pb or rev pb for crane to move basket over plating tank. Crane uses input from prox switch mounted on its mounting rail to pass-by dogs. Each time it passes by a dog, it takes a counter value and adds one if fwd pb is pressed or subtracts one if rev pb is pressed. C5:0.acc is how the system knows which tank the crane is at. The actual name for that prox switch is "crane in position". Its main job is to let the control know it is ok (if energized) to drop the basket as it is in position over the tank.
2. Operator then pushes drop pb to drop basket into tank
3. Then there is a second prox switch located at the bottom of the crane and when the flight-bar crosses that switch it stops the drop process as it is now in the down position. I am now using all of these conditions (crane is at appropriate tank number and the flight-bar is down) to begin the process timer, which is timing-down.
4. The operator then takes the crane back to the loading station to pick-up the next basket, and the process is repeated (basket is moved over appropriate tank, flight-bar drops basket into the tank, timer begins timing) over-and-over....
5. When the down-timer expires, it will begin to time-up. Now, the main reason for the up-timer is for data collection. If too much alloy is removed it scraps the parts and there are times the operator's will swear up-and-down the basket wasn't in the tank but maybe an extra 5 minutes but we had no way to know if what they said was fact. So, when this up-timer begins there is a large serial device that displays the up-timers accumulator so that it can be viewed by the appropriate management team members. It also stores that value in the SCADA for later reference.
6. When the operator pushes the lift pb, as soon as PLC recognizes the crane is in a certain position and the operator pushes the lift pb, it will stop the timers and, again, that data is collected and stored and it also resets the timers for for the up and down-timers.
I have a couple of bugs with my project and I will bet you spot them immediately. When the conditions are right, and the hoist is passing-by the process tanks, sometimes it will reset the timers. I have some other goofy things that happen seemingly at random (timers will start without a basket actually being dropped into the tank for example)that I can not find a solution to. The problem is I have to quickly get in and get out as I can not stop production. I have a PLC at my desk that has a series of switches so that I am able to simulate this however, it works fine at my desk but after loading it into the processor and testing it, these other undesirable issues surface. I am attaching the latest version of my project. I really appreciate the help.

When the down-timer expires, it will begin to time-up. Now, the main reason for the up-timer is for data collection. If too much alloy is removed it scraps the parts and there are times the operator's will swear up-and-down the basket wasn't in the tank but maybe an extra 5 minutes but we had no way to know if what they said was fact. So, when this up-timer begins there is a large serial device that displays the up-timers accumulator so that it can be viewed by the appropriate management team members. It also stores that value in the SCADA for later reference.

Click to expand...

Hmmmm...It seems that with a little work, the UP timers could be used to start the UP hoist, and not have to wait on an operator to press a button, saving everyone grief and embarrassment!

Lancie1 said:

Hmmmm...It seems that with a little work, the UP timers could be used to start the UP hoist, and not have to wait on an operator to press a button, saving everyone grief and embarrassment!

Click to expand...

This would cause a new set of problems. I would then have to automate the crane to pick the baskets up. Most of the time all process tanks are being used at the same time, with different parts in each tank. This would automate the entire system which is what it was, at one time. Because different parts require different amounts of time and then like parts that are in a better or worse state than another, require a little more or a little less time. I have offered to return the system to automation but no one wants to pay for it. They continually had problems with the automation because the crane would lose track of its position, was the biggest complaint. I gave the operators an input option that, should the crane lose position, it was a simple input on the HMI to change it. So, I told them I could purchase a servo motor and pulse-coder so that it will be better able to know where it is but that is the money they don't want to spend. They will spend thousands of dollars on new office chairs but wont give a couple thousand dollars to automate this line.