Bit shift or something easier

[kekrahulik]

I would look to use a FIFO- a bit shift would also work since you are 13 places away.

To me, the big question is whether you need to blow off the 13th product or the product that is some fixed distance away (maybe its both). I'm guessing that the distance from detection to blow off is fixed. So tracking distance makes good sense.

Counting products can also work. However, if a product can be missing (ie you have 12 products and an empty space) then counting products can fail. On solution for this is to place an additional "new" sensor at the 13th location and then count up the products at the original sensor location and count down the products at the 13th location with your new sensor . ie, you can track the number of products between the two locations. You need to also work out a way to know if your count is off and a means to get it back on track.

Regardless of what you do, take Okie's advice and error proof you sensor signals.

Making it work is easy. Making it work robustly is where you spend your time.

 

[Lancie1]

That trigger, along with N:7 at 0, then sets of the first delay timer and moves a 1 into N:7. So on and so forth for the next 13 rungs.

Do you then have 13 rungs, 13 delay timers, and N7:0 = 13 for the last product? If so, your method is depending on the conveyor belt speed being always constant. How do you handle start-ups and shut-downs, when the belt goes from 0 to full speed, or full speed to 0?

 

[rrparker07]

Anirban, Yes I read your post and you were correct in me wanting to do this without more hardware. The code you posted is very similair to what I have except I used a move instructions vs. a timer. (and yours looks a lot more compact.)

Lancie, I do have the last rung moving a zero to N7:0. The ansewr to your other question I think answered mine. I was testing my program out online while the process was in operation. The conveying is constant. We don't start the process until the conveying is at speed so the logic isn't called unless it recieves the at speed signal from the VFD. The sensor is already in place and is running a speed calculation. In My code, I was going to use the speed calculation multiplied by a constant and write that to the preset on my delay timers. I hadn't figured out exactly what the constant should be so I just ballparked it. If that delay didn't fall in the correct gap, is that what is causing my logic to "trip on itself"??

 

[rrparker07]

Anirban, Yes I read your post and you were correct in me wanting to do this without more hardware. The code you posted is very similair to what I have except I used a move instructions vs. a timer. (and yours looks a lot more compact.)

"move instructions vs. a counter."

sorry

 

[Anirban Hazra]

In My code, I was going to use the speed calculation multiplied by a constant and write that to the preset on my delay timers. I hadn't figured out exactly what the constant should be so I just ballparked it.

If you know the speed, then just measure the distance from your sensor to blast point, divide this distance by your speed and move the value to the Timer Presets. Remember to take care of the units as well.

If that delay didn't fall in the correct gap, is that what is causing my logic to "trip on itself"??

Can you elaborate this statement a bit more?
Also, can you provide an estimate of the time it takes each product to traverse from sensor to blast point?

A certain thing that I wanted to point out that without any additional hardware, the shown logic's effectiveness and accuracy will be entirely dependent on the constancy of your conveyor speed. If your conveyor speed jumps around to much then adding extra hardware is the only way to go.

 

[rrparker07]

Originally Posted by rrparker07
If that delay didn't fall in the correct gap, is that what is causing my logic to "trip on itself"??

Can you elaborate this statement a bit more?
Also, can you provide an estimate of the time it takes each product to traverse from sensor to blast point?

What I mean by that is if the delay was set too long, when the first product came back around, the delay timer would still be timing so it would miss being started again by the sensor.

About 4.5 seconds from sensor to blast point.

 

[Anirban Hazra]

What I mean by that is if the delay was set too long, when the first product came back around, the delay timer would still be timing so it would miss being started again by the sensor.

I think you mean to say that there is a problem if the 14th product (assuming 13 timers are being used) reaches the sensor before the first product has reached blast point.

That is why the correct calculation of the maximum number of products possible between the sensor and blast point at any given time is very important.Suppose it is 15, then just use fifteen timers and you will not face any problem with that logic.

 

[rrparker07]

I think you mean to say that there is a problem if the 14th product (assuming 13 timers are being used) reaches the sensor before the first product has reached blast point

.

Yes that is what I meant. I was so anxious to see if what I had would work, I looked past the importance of the timer accuracy. I will work on that and post back.

Thanks to all that responded.

 

[HJTRBO]

You know your conveyor speed! You can create a virtual encoder based off a known speed and time.
Create a virtual encoder that ticks over every 100ms for example.
When the sensor triggers read the current value of the virtual encoder and add with the amount of virtual encoder pulses to the blast position.
Use fifo.
If you are close to working with the current program you described above then you will be extremely accurate with a virtual encoder program.
You will be able to reduce your air blast window as well due to the accuracy. Saves on energy.

 

[Lancie1]

You know your conveyor speed!

Well, not exactly. What Roy knows is a "calculated conveyor speed" based on the time between trips of the product sensor. There are going to be several errors in the calculated speed using this method, including math rounding, variances in the product size and product placement on the conveyor, product slippage, and varying sensor detection time depending on the package size, shape, and orientation.

An analog input from the VFD speed indicator parameter would be nice...

The speed is fairly constant...

Depending on the product we are running, there is anywhere between 340 and 500 msec.

The sensor is already in place and is running a speed calculation. In my code, I was going to use the speed calculation multiplied by a constant and write that to the preset on my delay timers.

We don't start the process until the conveying is at speed, so the logic isn't called unless it recieves the "At Speed" signal from the VFD.

How long does it take each product (once placed on the conveyor) to accelerate and reach the same speed as the conveyor? In other words, where you detect the products with a sensor, have they been on the conveyor for a while, or just dropped on immediately before? Is each package oriented the same way, or turned at random? How much do the packages vary in size, weight, and reflectivity (that might affect the calculated speed)? What type of sensor do you have to detect each package?

Roy, If you are calculating an instantenous speed-between-products, it might be best to use an average speed over the past 13 or 26 products. A speed average would tend to smooth out any variations due to the other factors, and might give you better accuracy.

 

[HJTRBO]

Well, not exactly. What Roy knows is a "calculated conveyor speed" based on the time between trips of the product sensor.

Sorry, my intention was that Roy use the actual conveyor speed in my method, since he mentioned it will not change. (I think he said that?) i agree with you that trying to calculate the speed using the time between products method will be inaccurate.

An analog input from the VFD speed indicator parameter would be nice...

+1

 

[OkiePC]

Yes.
I like to use a handheld tach for belts. Cut the bull, measure and compare with command, no need to know or calculate all the drive train geometry as a programmer, sure use it if its there for you, but measure anyway.

the more precisely you can measure this the better.

 

[Lancie1]

Sorry, my intention was that Roy use the actual conveyor speed in my method, since he mentioned it will not change.

I understand that. What I really do not understand is why there is a need to calculate speed if it is constant? Is it really? I know Roy said the speed changes as the product type changes, so maybe that is why he needs to calculate the speed for each product type.

The distances between the products are constant. Depending on the product we are running, there is anywhere between 340 and 500 msec,[] between the leading edge of the products.

If the product distance (leading edge to leading edge, so size does not count) is constant, but the time between products varies from 340 to 500 msec, then there is a lot of slop, or the conveyor speed is varying.