Lost in a loop

Any thoughts about this would be appreciated!! I'm in the mist of a project in which thee specs have changed. basically I have a conveyor that feeds a pipe through two pre-heat coils into a furnace for heat treat. I have set up an aray of 12 sensors to detect pipe movement along the line. lets say that there are two groups of sensors. In the first group #1 is located before the entry, #2 is at the entry of the coils and #3,#4 are between each coil #5 is at the exit of the coils and #6 is mid ways between the last coil and the furnace. the goal is to detect a pipe hanging up entering the coils and furnace. To accomplish this I start a timer at each sensor and load the acc. at the next sensor. the distance between each sensor is known so I divide the distance by the time to get mm. per .o1 sec. and use that calc to determine the estimated time of travel to the next sensor. If the pipe is not there in that amount of time (I have a adder for error) then an alarm is set. I than add time to this value for a shutdown of the coil to prevent overheating of the pipe. After this was accomplished the end user decide we should monitor the trailing edge in case the pipe hangs up in the oven, thus the other 6 sensors. The idea in general is to move the time to travel each time so as the speed of the pipe changes so does the time needed between each sensor. OK thats a start not sure if I'm clear in my description so fire away if you have questions!! Thanks in advance!!

Okay... question...

Does each pipe only block one sensor at a time? IOW, is the distance between sensors > pipe length?

Just trying to picture the setup...



-Eric

No the pipe covers all the sensors at once around 40 ft with the sensors spaced around 3ft apart except the ones between the coils they about 6 in apart and the coils are about 3 ft long all the distances are fixed as to their location however they are not evenly spaced due to mounting restrictions . Oh and I'm using an micro logic 1100

what I am wondering is there an easier way to get the same results using less code. I am currently loading the time dividing it comparing it to the next length to get estimated time of arrival at the next prox. for each zone. Is there a way to sequence this leading edge and trailing edge in a simpler way? like loading the time and distance from a variable to one set math functions. I don't do much tracking stuff so I am kinda lost here. how would one handle the trailing and leading edge detection to shift the different times between proxes and lengths to the floats used in the math functions to an alarm set point?

I'm sure someone here will have an elegant solution, but IMO, your approach is fine.

Here's one idea to 'use less code'...

For the speed reference calculation, you could use just 2 timers for the leading edge.

Timer 1 for sensor 1 to 2, 3 to 4, 5 to 6, etc.
Timer 2 for sensor 2 to 3, 4 to 5, 6 to 7, etc.

Then reuse these same timers for the trailing edge in the same manner. The speed reference will automatically update at each sensor edge with the current speed.

Along the same approach... You can use a single alarm timer for each location that has the same sensor spacing.

This assumes that there will only be one pipe in the system from start to finish. If another pipe will enter before the first finishes, then scrap my idea...



-Eric

There is a chance that two pipes could be in the system however they should never be both in the same zone(between two sensors at the same time. As I know the maximum length of the pipe never over 45 ft. I can alarm if for some reason two pipes do happen to be in the same zone.

bce123 said:

I'm in the mist of a project...

Click to expand...

Is that what you call it when working on the hardest part of a project? Is that like being in a fog?

The mist of a project is similar to what happens in the fog of war - mistakes do happen.

Is there a way to sequence this leading edge and trailing edge in a simpler way? [Such as] loading the time and distance from a variable to one set of math functions?

Click to expand...

You could set up indirect addressing to use one computation for all sensor positions, but the gain would be only in reducing a few rungs, an the resulting difficulty of understanding the logic seems to negate the small reduction.

The mist of a project is similar to what happens in the fog of war - mistakes do happen.

Click to expand...

Yes it seems that reserving 20% spare floats and intergers was not enough to keep things in sequencence. good thing I used bits instead of real I/O at least that part in order.just think if this was a relay panel like the old days!

This would seem to be an ideal application for a shift register. I'm not sure of the specific capabilities of the ML1100 (haven't messed with AB for a while), but I would imagine it would have the ability to do this.

Here is a link to a similar problem that a shift register was implemented for. The discussion of the problem and program doesn't start until the 4th or 5th post. Milldrone might be able to help convert that program to AB format. He might also be able to post a screenshot of the ladder. I don't have DS installed on this laptop yet, or I would do it.

You would need to generate some sort of clock pulse. This could be a prox on a sprocket, or a calculation from your drive system, or pretty much anything that pulses a bit when the conveyor has moved a specified distance. You will also need to use your first photosensor to load the shift register. The subsequent photosensors can then compare the status of a particular bit (located x bits away from the start, where x = photosensor inches from first photo sensor/ inches per clock pulse). The code in that thread uses counters to give an adjustable error range, but you can use many different approaches for that.

The nice thing about a shift register is that it will automatically compensate for changes in conveyor speed. No need to calculate timer values on the fly. It does this as it is based on distance traveled, not time.

Anyway, that is how I would tackle the problem.

Brian

I prefer to keep things simple. What I'd do is
Sensor1 AND NOT Sensor2 starts Timer1
Sensor2 AND NOT Sensor3 starts Timer2
...
Sensor is ON when the pipe blocks it, alter as needed.

This supposes there's more than two sensors worth of separation between the pipes. Calculate the PRE values from distance and speed, can be done on the fly if speed is variable and measured.

If you XOR rather than AND you'll also have trailing edge detection.

This would seem to be an ideal application for a shift register. I'm not sure of the specific capabilities of the ML1100 (haven't messed with AB for a while), but I would imagine it would have the ability to do this.

Here is a link to a similar problem that a shift register was implemented for. The discussion of the problem and program doesn't start until the 4th or 5th post. Milldrone might be able to help convert that program to AB format. He might also be able to post a screenshot of the ladder. I don't have DS installed on this laptop yet, or I would do it.

You would need to generate some sort of clock pulse. This could be a prox on a sprocket, or a calculation from your drive system, or pretty much anything that pulses a bit when the conveyor has moved a specified distance. You will also need to use your first photosensor to load the shift register. The subsequent photosensors can then compare the status of a particular bit (located x bits away from the start, where x = photosensor inches from first photo sensor/ inches per clock pulse). The code in that thread uses counters to give an adjustable error range, but you can use many different approaches for that.

The nice thing about a shift register is that it will automatically compensate for changes in conveyor speed. No need to calculate timer values on the fly. It does this as it is based on distance traveled, not time.

Anyway, that is how I would tackle the problem.

Click to expand...

I will take a look. the problem with using conveyor speed is the pipe is on v rolls and can slip as well as change speeds due to the dia. of the pipe as well as the speed of the drive. even though each v roll is controlled by the same drive you have to look at each roll as being a separate conveyor sorry for not pointing this out sooner

bce123 said:

I will take a look. the problem with using conveyor speed is the pipe is on v rolls and can slip as well as change speeds due to the dia. of the pipe as well as the speed of the drive. even though each v roll is controlled by the same drive you have to look at each roll as being a separate conveyor sorry for not pointing this out sooner

Click to expand...

This is a bit of deja vu for me, although the project Brian 123 mentioned did not have V rolls in the oven, it did have V rolls for conveying the product external to the oven. I understand the problems with speed/product size when using V rolls. I'm presuming the speed of the drive rolls is determined by a combination of diameter (larger diameter rides higher on the V, and the product moves faster for the same conveyor RPM) and the ability of the coils to transmit heat into a larger thermal mass.

bce123 said:

the sensors spaced around 3ft apart except the ones between the coils they about 6 in apart and the coils are about 3 ft long all the distances are fixed as to their location however they are not evenly spaced due to mounting restrictions

Click to expand...

Brian123 said:

This would seem to be an ideal application for a shift register.

Click to expand...

Like Brian I believe a shift register is the proper tool for this problem, but my concept is to use two shift registers (more on this later).

The first issue to solve would be to resolve the difference in sensor spacing. If the first sensors are 36 inches apart and the ones in the coils are 6 inches then the resolution needs to be at the 6 inch resolution. Presuming that the speed would not be changed while product is in the oven you could measure the time between the first 3 foot spaced sensors and divide that by 6 to get the 6 inch resolution. Then use that calculated time pulse to use as the clock pulse for the shift registers.

Now for my concept of using two shift registers. I'm proposing using one shift register with a slightly shorter calculated clock pulse and one with a slightly longer clock pulse. This would be needed to allow for some time measurement errors or minor slippage and not shut down the machine unnecessarily. I'm also presuming your pipe can actually speedup due to warpage and riding higher on the V rolls when in the oven. When I setup the shift register on my project I monitored a normal production run to determine which bits I needed to monitor. Then I artificially setup a "bad" run by stopping (slipping) product, This was needed because my project had an exceptionally large number(over 4000) of bits in my shift register. Then finally compare the bits of the two shift registers. If both shift registers indicate there is no product and the sensor sees product shut down the process. Or the flip side if both shift registers indicate product and the sensor does not detect product shut the process down. If only one shift register bit does not agree with the sensor do nothing.

This would seem to be an ideal application for a shift register.

Click to expand...

Because the speed of the pipe apparently changes continuously, it seems using shift register(s) would be complicated. EDIT:[Because] the speed change is due to slippage, that ...makes it even worse. The only dependable speed indicator would be the time between position sensors. If a shift register memory shift is not triggered by the actual movement of the pipe, errors creep in. In this case that would have to be the position sensors triggering the shift register, maybe not creating a great gain in efficiency.

For tracking positions, I still prefer keeping a queue of the contents with rolling pointer or in this case I might lean toward keeping track of the positions of several objects as a real number in engineering units (feet or inches). If you know or can measure and get pretty close to the drive speed of the conveyors then you can use the delta T (time) of the scan (or stick some logic in a routine with a fixed scan frequency) to determine how far each piece moves. They are "born" via detection and length proofing by the first photocell, and thereafter the length gets continually updated until the trailing end at which time that number gets stored as the length of that piece. The leading edge position is still updated until is has completely left the process. If it gets diverted into selctable lanes/chutes, you can use alter it's position and set up ranges to represent each chute.

On my sausage sorting line I program in inches (short belts), and when it gets kicked into sorting lane #1 I stuff 1000 inches into its position register, lane 2 is 2000 inches, lane 3 is 3000 inches, etc. So a glance at a list of position values can tell you where in the maze of conveyors each item is located at any given moment.

Meanwhile, logic elsewhere verifies this position against detections made by subsequent eyes. You set a upper and lower value (inches past PE1) within which each piece's position (or length) must be to prevent faults.

You can do this brute force without loops but the logic is more wordy in the end than some simple timers and "straight logic" approach. If you want to track more than a dozen or so, then it gets ugly in ladder if you despise looping but it works like a charm and is very adjustable and predictable.

You need to add another sensor or a paint marker? No problem, just figure out how far it is from the "birth" sensor and program accordingly, adjust until it works well.