TI plc

Hello,

I am new to the TI world having mostly worked with AB and was wondering about setting up a plc to measure log length in a sawmill, using an encoder and a Photo eye. Can someone help me with the logic on this.

What kind of a TI do you have?

Try this link:
http://www.plctalk.net/qanda/showthread.php?s=&threadid=11355&highlight=board+length

Here's the link to the 505 programming reference manual.
505 MANUAL
Link to 505 homepage: 505 Homepage


Which plc are you using, 545, 555, 565, 575 ?
What software Tisoft, Softshop?

At the very least you are going to need a high speed pulse card, either a 505-7002 or 7003, and discrete I/O cards.
CTI also makes a lot of I/O cards for the 505: LINK
and if used/refurbed is an option try here: REFURB LINK

The high speed cards in the 505 work basically the same as the AB ones. You write a control word to the card every scan, used for resets and such. You read the count from the card. It is more like the SLC than the PLC-5's. There are no BTW & BTR type instructions in the TI. The I/O cards read and write directly to memory (Like SLC's).


The manual listed above should be a good start, it explains TI memory and addressing.

Follow up:
One of the major differences between TI and AB is how bits are adressed:

In AB bits are: 15,14,13....2,1,0 with bit 15 being the MSB.

In TI bits are: 1,2,3,...15,16 with bit 1 being the MSB.

Wow, I just experienced a flashback. I haven't touched a TI product since the early 80s, the 6MT series, and was surprised to find them at plccenter.com.

Info is sketchy, but the issue is the same. Start counting when the eye goes dark and stop counting when the eye goes light. Then convert the count into whatever units.. The linked thread above dosnt really provide info on the code or math for this. It only debates the method, vision or encoder.

borbob,

If your really going to use an encoder and eye, you must know how many PPI (pulses per inch) of travel. The rest is pretty stright forward. I dont know much about the TIs (execpt for the Koyo's), but any PLC with a counter module should be able to handle the job.

Re-read your post. Unless you already have the TI, it sure seems like overkill for such a simple application.
Since you're familiar with the AB line, wouldn't a ML1200 be suitable?

CUTUP

We built a cutup system a few years ago and used AD 405 system
with hi speed dc input card and hsc counter card. This was used to cut saw logs to length. We put a pe at the saw line then our shortest log was 8 ft. so we put a pe at 7 ft. past the saw. This mint we didn`t have to measure the first 7 ft of the log only the last ft. and so on up to 12'6". We also used ac drives on our conveyors so we could ramp down to a control stop. Split the drive up after the saw this way when the cut is complete you can automatically start the out feed from the saw and as the saw retracts you can have a default set so the infeed starts in auto. Everyone wants more logs per hour. After it left the saw we pasted the bay number with pe`s looking through the log truff. This system only had 4 sorts so it wasn`t much trouble. The ac drives worked fine but be sure and use brake resistors. We were cutting hardwood full of knots and when you get a log hungup on a knot they used the cat to push the log down the truff which will cause regen in the drive and tripp it out without some where for it to go. Good luck fun projects.
Tom

Ken,

I get the impression that borbob might be running the logs under an encoder equipped wheel. I suspect he uses the photo-eye to initiate and cease counting. When the log runs out from under the wheel the wheel and encoder continue spinning. If the eye is off then the encoder-counts don't count... as it were.

It actually is a reasonable way to do it, but, only if the wheel can be counted on to provide positive traction for the entire length of the log.

The problem is in how to develop positive traction for the entire length of the log. When the log first encounters the wheel, depending on the speed of the log, sometimes the wheel does a bounce & spin. The number of counts that occur during the bounce & spin is sometimes not so consistent. Sometimes the log enters the measuring area quickly (more bounce) and sometimes it enters slower (less bounce). So you can't "assume" any particular "bounce-count-value".

The scheme shown below works better.

                                          ___

                                         /   \ <---- Wheel

         +-------------------------+     \___/

         |    Big Honkin' Log      |

         |       -------->>>       |

         +-------------------------+

                                           +-+          +-+

                                           | |          | |

                                           | |          | |

                                           +-+          +-+

                                            1            2

                                               Sensors

                                            |<-- X.X" -->|

.
The mistake that a lot of programmers make is in not accepting that sometimes things are not as "positive" as we would like. They would use a single eye aligned with the wheel (Sensor #1 shown above).

When the eye goes on they begin counting encoder pulses. Then, when the eye goes off they stop counting and calculate the length.

However, as I mentioned, there is that damned variation in the bounce & spin.

The better way to do it is to accept that there might be a bounce & spin. Depending on the speed of the logs, there might not be any bounce at all. However, in this day and age of hurry-up, you can bet that the log will be moving as quickly as it can.

Often, length measurements are performed in open areas where there is not a means to impose a positive drive-force to the log's speed. The log simply moves as fast as it can... sometimes fast... sometimes slower. Snags happen.

Because of this, the speed of the log can not be expected to be consistent (unless there is a means of providing a positive drive-force in that area).

So... you either fight it, or you accept that there might be an unexpected bounce... or not.

In the figure above there are two photo-eyes; #1 and #2. The smart programmer won't start counting pulses until eye #2 goes on. He would then continue counting pulses until eye #1 goes off.

Since the distance from Eye #1 to Eye #2 is known (X.X"), it is simply a matter of adding the appropriate number of pulse counts to the total before performing the length calculation. Alternatively, you could calculate the length based on the total pulses counted and then simply add the distance between sensors to the calculated length.

The idea is to give the wheel a chance to bounce, spin, and then settle down into positive traction before beginning the count accumulation.

Whether or not borbob needs to use a high speed counter depends on the greatest number of pulses per second that might occur (which depends on the size of the wheel as well as the speed of the log) and the scan-time of the PLC.

Depending on his particular requirements for accuracy, he might be able to up-size the wheel so as to reduce the number of pulses per second.

BTW, it is better to use a "spiked-tooth-wheel" rather than a "rubber-roller-wheel"... the traction is much more positive. A "spiked-tooth-wheel" will overcome a failing bearing much better than than a "rubber-roller-wheel" will. But, of course, that failing bearing will have to be replaced eventually.

(120)

TI PLC 545

Thank You all for your help on this, it was a first time and was unsure on what to put down. So let me start over existing TI 545, need to measure log length the logs are placed on a sharp chain and speed of this chain can vary, by using an existing P/E and encoder with 2000ppr I need to calculate log length, the encoder is attached to the chain. What I don't get is how to count these pulses and keep them stored long enough to measure because the average distance between logs in only about a foot, and I am not very good with the TI.
There is no slip on logs when they are on the chain so no problem there my biggest problem is this measurement needs to be accurate within an 1 1/2". Thank you again if any one can help.

What is the fastest chain speed? 10 feet per second, 1 foot per second? 25? 50?

What's the current scan time of your PLC?

Let's assume the chain speed is 20 feet per second, and the gap is 1 foot, then our gap time is .05 seconds or 50 milliseconds. Now the PLC scan time comes into play. We have 50 milliseconds to process the previous log, before the next one starts. Depending on your current scan time it may or may not be possible.

So....before you get to involved, you need those two pieces of information, chain speed and scan time. No use waisting time if it can't be done. If you find your scan time is too slow, there are other alternatives.

I would thing that 20 ft per second is a little fast...Are the logs wizzing by at 14 mph?? I kinda dobut it.
However you still need to know how fast the logs travel..just to be sure.

But what your really need to know is Pulses Per Inch of TRAVEL . The gap isnt so important as the number of counts per inch or foot. You need to determine this for your (rather simple) caluculation.

Mike,
Yeah 20's fast, it's probably 2 or less. Just trying to show that the speed could be a factor. Many times these TI plcs are put in to run the "x" system, and then they add "y", then "z", without much thought or planning. You end up with slow scan times, and they live with it. Then when you need something with a fast respone time you're in trouble.
Borbob has already stated that He isn't familiar with the TI line, so he could be next in a long line of people that have added something to the system without considering the overall system performance.

I have one system that is around 200ms because of this, over the years many people "worked" on the system, but no one had "ownership".


Ken