Timer instructions and crane position for SLC 5/03

[ceilingwalker]

Good day all. I have attached two ladder diagrams. What I'm attempting to do with the one named "lift timers" is to lift a basket out of an acid dip tank. I want it to lift for 3 seconds, then pause for 10 seconds so the push-air is able to send the acid plume to the scrubber. Then have it lift again for another 3 seconds and pause for another 10 seconds. I need to do this 4 times. I wanted to know if there is a more efficient way of doing this so I don't have to use so many timers. I thought this might be a good time to expand my understanding of how to use indirect addressing.
The second attachment named "crane position" I'm using a prox switch and a pushbutton with counters, to identify at which tank the crane is at. I need the above timers to control the lift function only when the counter values are 0, 1, 5, 8, and 9. Thank you much.

 

[OkiePC]

You don't have to zip images, by the way, before I forget.

First off, this is a crane, and you are timing from one known position and trusting timers...

There are no comments and you are using TOFs where they offer no advantage...

Next, you need to consider what happens when there is a problem, the 3 second lift cycle is interrupted. What if the brake shells out and they try it ten times and it overloads ten times?

For a lift, or anything where you are truly just estimating position, you need an input proof as good as you can get, and a retentive timer, plus address comments, and at least one permissive bit...

Don't go for simple, this is a crane, go for bulletproof with what your working with.

I would use RTO timers running based off of real inputs from proof the motor is running, the closer the motor or better yet the drive load you can get this proof the better. Maybe you can settly for a motor starter auxillary, but this is better than a crane that "thinks" its 9 seconds off the ground and is still in the acid bath...

Make this smarter, not simpler...

 

[ceilingwalker]

You don't have to zip images, by the way, before I forget. When I attmepted to upload them it gave me a message that it was to large of a file to upload.

First off, this is a crane, and you are timing from one known position and trusting timers... Yes sir, it is an approximation. Currently the basket is lifted out of the heated tank is filling the room with a plumes of acid. The push-air system does not have enough time to shove the plume into the scrubber. Some of it is captured but the majority is not and it is destroying everything in its path.

There are no comments and you are using TOFs where they offer no advantage... I have never used TOF's before and was experimenting. I do not have nearly the programming experience you folks have. That's why I submitted it. I like to try something first, run it by the folks here, then learn. If I don't try first, I don't usually learn much.

Next, you need to consider what happens when there is a problem, the 3 second lift cycle is interrupted. What if the brake shells out and they try it ten times and it overloads ten times? It has a lift limit switch that will stop it and, if it makes it past that, there is an up overtravel switch. To keep it brief I only attached what I had done recently, not the entire program. I can see where I should have sent the entire program.

For a lift, or anything where you are truly just estimating position, you need an input proof as good as you can get, and a retentive timer, plus address comments, and at least one permissive bit... I don't understand exactly what you are talking about with the "permissive bit".

Don't go for simple, this is a crane, go for bulletproof with what your working with. The system has been running for a couple of years. I have been tasked with editing it so that we can attempt to capture more of the acid plume.

I would use RTO timers running based off of real inputs from proof the motor is running, the closer the motor or better yet the drive load you can get this proof the better. Maybe you can settly for a motor starter auxillary, but this is better than a crane that "thinks" its 9 seconds off the ground and is still in the acid bath... The crane is only able to traverse forward or reverse after the lift or drop prox sensor is made. What I'm trying to do is lift for 3 seconds, allow some of the plume to be captured, lift for another 3 seconds, capture some more plume........ then have it continue on its way upward until the up prox is made. The challenge is, at the rinse tanks, I don't want this timer, that's why I was trying to find a way to identify which tank the crane was at so it would know to use the timer when at one of the process tanks.

Make this smarter, not simpler... I think simplicity wasn't what I meant to say. I think a more clever way, would have been more appropriate. I'm not looking to cut corners on safety or anything like that. I'm using this as a training session. Many of the programmers here, including you, have helped me for the past few years to hone my programming abilities. I'm still wrestling with understanding indirect addressing and thought this might be a good example for me to learn from.

Thank you.

 

[OkiePC]

By permissive bit, I meant some way to interface with the real world to know when to run and when to pause the retentive timers.

If there are interruptions, it may not matter in your case, as long as the stop dwell times are met, then it may satisfy your requirement that the basket takes more time to allow fume capture to occur.

I didn't mean to be too critical, those were my just my quick thoughts. I think the RTO is definitely applicable here though, just takes extra logic to reset them.

Knowing the hardwiring takes care of travel interlocking takes away 90% or my concern. As for TOFs, I avoid them just because it takes me a minute of extra thought to follow them online. There are times when they can make ugly rungs look nice and times when adding a TOF is much simpler, but I only use them if a TON doesn't fir the bill.

 

[Lancie1]

I want it to lift for 3 seconds, then pause for 10 seconds so the push-air is able to send the acid plume to the scrubber. Then have it lift again for another 3 seconds and pause for another 10 seconds. I need to do this 4 times. I wanted to know if there is a more efficient way of doing this so I don't have to use so many timers.

You could probably do the lift-and-pause with only 1 timer. You can use LIM comparison instructions with the "TEST" value set for your lift timer ACC value. How many lifts are ever done at the same time? If only 1, then you only need 1 timer, but look at different intervals on that one timer to do the different tasks.

What happens to the lift if there is a power blink in the middle of the lift? If it needs to continue where it left off, then like Okie said, use RTO timers.

 

[James Mcquade]

ceilingwalker,
if only part of the acid fumes is being captured, where is the remaining fumes going? your comapny will be required to clean up the affected area if the fumes are just allowed to escape into the atmosphere. EPA requirements are a lot more stricter than 40 years ago. you don't need them on your back.

regards,
james

 

[ceilingwalker]

I didn't mean to be too critical, those were my just my quick thoughts. I think the RTO is definitely applicable here though, just takes extra logic to reset them. .

I didn't interpret your reply as critical. I like honesty and straight-forward talk. And I always appreciate your advice. Thank you.

 

[ceilingwalker]

You could probably do the lift-and-pause with only 1 timer. You can use LIM comparison instructions with the "TEST" value set for your lift timer ACC value. How many lifts are ever done at the same time? If only 1, then you only need 1 timer, but look at different intervals on that one timer to do the different tasks.

What happens to the lift if there is a power blink in the middle of the lift? If it needs to continue where it left off, then like Okie said, use RTO timers.

I like your LIM suggestion. It's something new to me. If power is lost, the system requires the crane be placed in bypass mode with a key switch and jogged to safe positions. I still struggle understanding how to use indirect addressing and that is the main reason I wanted to see if this would be a good exercise to understand them.

 

[ceilingwalker]

Thank you for the advice. I attached my project using only one timer and the LIM's you suggested. Working exactly as I wanted.

 

[OkiePC]

The advantage to using a LIM and a single RTO:

You can write a sequence of LIMs that are extremely diverse, understandable, and adjustable.

You can survive power fail with estimated "position" intact.

You can estimate position surprisingly accurately with in the inclusion of measured step response lag time included in the PLC math.

I had one system slwoing feeding to length a sheet of tire material about 16 inches past a photo eye to start a timer in a ML1000 with a horton clutch/brake for feed control. I had to offset my ACC with extra logic to get it to survive as many as three interruptions and still be within 0.10" of spec. I simply timed the worst case difference and back-calculated the offset, then split it into separate engage and disengage time offsets and adjusted by measured results...If the clutch opened, the timer freezes, and then you adjust the accumulator (add 0.81 seconds "Clutch SV1 Release Time", for example) and recheck the dn bit...

This application does not call for indirect addressing in my opinion.

It may call for mapping all the timers for each "step" from a series of HMI addresses, and then in "hard" code enforcing overlap, (so that if you adjust the time for step 6, while the lim for step is is true (that sequence is running), then all the other LIM values automatically get scooted down and retain their present values. I like to only modify timer values on the rungs immediately preceding the timers, and put the timer rungs in reasonable range of rungs before the majority of the field devices or modes they control.

So, have one RTO timer, and it's preset gets adjusted to the total of all the step presets, therefor you must limit check that value (-327.60 or 32767 seconds) to do this with a lonely and elegant RTO running the show...

 

[OkiePC]

Your submission, just get the cursor on top of the TON instruction and type "RTO" <enter> and it'll be clean. Then you can "break" your TT rung to pause the timer at any step, perhaps until motor feedback occured.

You could expand it later have each LIM separate internal bits, so that you could then just pick and choose in the output area of your programs, which lim bits drive which motors/valves, data triggers, etc.

The timer in your example could be held enabled by the reverse button after the timer is don, at which the timer TT bit goes off, resetting the timer. By clearing it via the upper limit switch, don't miss the opportunity to measure how many seconds the cycle took, nor the opportunity to use the maximum presicion timer suitable for the role. Rule of thumb, if the whole timer ranges in less than about five minutes, use the 0.01 second time base. You will thank yourself later.

Your timer is guaranteed to complete, and could hold on the lift enable bit if any of those LIM ranges get set wrong (inadvertent 0 in there). missing more on that enable rung, or a new name "lift request" at least there should be the reverse button on that rung...

With a momentary button, I also like to do anti-tiedown, just the button on a rung with it's own dedicated TON and the maximum allowed time to jog, then use the TT bit from that as my internal jog button else where in code, the DN bit can be tied to a fault...

Also with a TON, if you choose to reset it away from the TON instruction, that EN bit and TT bit could end up changing states midway through the program scan. Putting the reset rung immediately preceding the TON or RTO prevents this potential for an anomoly...

 

[ceilingwalker]

Thank you for all this information. This is the only way I can learn. Try it, have it checked by an experienced programmer, study the feedback. This site and the folks here have saved my arse a number of times. Thank you.