Bit shift or something easier

[rrparker07]

Hello all! I'm sure there is a simple solution to this problem but I can't figure it out.

THE GOAL: Using a Micrologix 1400, One sensor, and a Mac valve, I need to pulse an air blast when there is a product in position instead of leaving the air on constantly. The problem I am having is the sensor is about 13 products away from the blast point.

WHAT I HAVE TRIED: (I can't post code right now so I hope you can understand this.) Using a one shot with the sensor is the trigger. 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. The last rung moves a 0 to N:7 to start all over. The timer done bits trigger the blow off. What I have works perfectly as long as the delay is not longer than the gap from product to product. I have never done bit arrays or fifos. I need someone to tell me if it can be done programatically (is that a word?) or i need to come up with a way to get the sensor at the point of attack.

BTW: I did look at the bit shift instruction, but because my one sensor would have to perform the shift, I would essentially be moving all ones and that wouldn't really help. (i didn't think so anyway) The speed is fairly constant so I thought about trying to use some time calculation to pick up the missing products. If I only missed one it would be fine, but the more you miss in a row, the more room for error.

Anyhow, thanks in advance for any ideas.

Roy

 

[chavak]

You will need one more sensor or any other reference signal which turns on tracking for every move of the jig/pallet in the machine regardless of it is having a part or not. You use that signal as the shift signal in the shift register.

There are several examples of shift register in this forum, you may search for it

Regards

 

[Anirban Hazra]

Maybe something like this would work:

1.Count the number of times the sensor is triggered

2. Set the counter's preset to the maximum number of products possible between sensor and air blast.

3. Suppose, as you say, that number is 13.Then make 13 branches with each branch containing a EQU instruction and TON in series. Place Blast Valve OTE at the end of this rung

4.In the first EQU compare counter accumulator to 1, in the second one, to 2 and so on till 13.

5.Set the TON presets to the time it takes for a product to travel from sensor to blast point.

6.In each branch put a parallel branch around the EQU and put a XIC with the timer's corresponding .TT(Timing bit) to act as a latch for the timer.

7.Reset counter on every 13th count.

These 3 rungs should do the trick.

 

[brstilson]

What does the sensor actually sense? What is moving the product?

Sounds like what you're doing is trying to simulate a bit shift using timers as opposed to using a hard sensor.

What I would do (if I'm imagining this correctly), is add a tooth gear and a suitable prox switch to an end of the conveyor. I would then figure out what my minimum distance between products would be in terms of tooth counts. Have the gear tooth counter on a CTU instruction where the preset is that minimum distance in counts I determined earlier. I could then use the counter's DN bit to shift the bits in the reference word. If the sensor senses a product at any time, write a 1 to the first bit in the shifting word. Put your air blast at bit 12 or 13 or wherever the right distance is.

Using the tooth counting prox should help you avoid issues that come with timing and product gaps, because it provides a hard reference for your conveyor's position.

 

[rrparker07]

Thanks for the replies. The distance 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. I understand the concept of the sprocket and prox. But for the speeds and distances we are dealing with I would need to add an encoderfor that resolution.

I know there are a few ways to accomplish this by adding other types of hardware. Is there anyway of doing programatically (there's that word again) .

Once again, thanks for the replies.
Roy

 

[OdinIII]

Without a signal that tells the PLC when an empty or full product position has passed then I don't see how you could make it work without additional hardware unless you don't mind a blast with no product present.

If this isn't a problem then wouldn't it work to just blast a set time after the sensor is made/unmade?

 

[dwoodlock]

I guess I'm wondering what the process is, continuous movement, or indexing? what rate?

As far as reliability, your best bet is to have something directly monitoring movement of the belt, and then the other sensor indicating a physical part.

There are other ways, but they are all indirect and therefore not so reliable. I recently dealt with a very similar situation so its pretty fresh in my mind.

 

[brstilson]

Without a signal that tells the PLC when an empty or full product position has passed then I don't see how you could make it work without additional hardware unless you don't mind a blast with no product present.

If this isn't a problem then wouldn't it work to just blast a set time after the sensor is made/unmade?

That would only work if there was only going to be one part between the sensor and the air blast at any given time.

 

[OkiePC]

THE GOAL: Using a Micrologix 1400, One sensor, and a Mac valve, I need to pulse an air blast when there is a product in position instead of leaving the air on constantly. The problem I am having is the sensor is about 13 products away from the blast point.

I would use a shift register (BSL, FIFO or whatever you prefer) if these 13 product positions are indexing in their motion.

I commonly find that if you are tracking a product with discrete sensors and a more "analog" conveyor, it is more effective to calculate the position of the conveyor and store the entry position of each product in an array.

Then, depending on the geometry, you can use that conveyor position as a pointer that moves through the array of products' data that sits in a data table and doesn't need to be shuffled. If the conveyor is short and the products are few, it is sometimes more efficient to just keep up with an array of values that represent the positions of each product in transit and update them all.

I typically stick the math in an STI so that the time base is tightly controlled.

Tracking based on a calculated position which includes things like belt acceleration or drive speed feedback is always more accurate and easier to modify in my experience. It is a bit more work to set up and can take a lot of explaining and commenting because it isn't just simple "photo eye feed FIFO" logic.

If your conveyance uses an indexing type of motion with 13 discrete positions, then, by all means, use a FIFO/bit shift style, but be sure to at least add timers to restrict the operation to reality...so that the sequence can't get trashed by a bouncing sensor signal, for example.

Is your conveyor an indexing one? What sort of 'proofs' or feedback for velocity do you have from this product mover?

 

[OdinIII]

That would only work if there was only going to be one part between the sensor and the air blast at any given time.

I think with the current inputs available it would be the best he can do. The flaw is that it would fail to blast a part either 13 products before or after a missing part.

 

[Lancie1]

What I have works perfectly as long as the delay is not longer than the gap from product to product.

I think the heart of your problem is that any program method you use (simple, sophisticated, bit-shift registers, or FIFO's), it can only be as accurate as the method to track the product from sensor to air blast. If you have no encoder pulse, and no accurate constant time between the two points, then any program method is going to be facing that same problem. The PLC Ouput can be only as accurate as the Inputs. There is little that can be done to allow a poor or inadequate set of inputs to make an Output more accurate.

The things that might help:

(1) Add a second Sensor #2 just before (upstream of) the air blast.
(2) Use Timer 1 to measure the minimum average time of Sensor #1-to-Sensor #2 blast position. This Timer #1 Preset value can be a variable that is set according to the type of product being run that day.
(3) When Timer #1 is done, start looking for the next product with Sensor #2. When Sensor #2 sees the product, start Timer #2 (time setting to be dependent on the distance from Sensor #2 to blast point) to wait until product is in blast position.
(4) When Timer 2 is done, trigger the blast.

This method only has the advantage of allowing you to have a range of time in which to look for the correct part to arrive. If that varying time range is greater than the time it takes for the conveyor to move 1 part-position distance, then it will not help at all.

If there can be two or more parts to be blasted on the line at the same time, then you need to look some type of shift register that is triggered by the average time to move from part-position to part-position. You can measure this average time (using your sensor and a timer) and constantly adjust the Shift Register Average Time Trigger, as the system runs.

 

[brstilson]

(1) Add a second Sensor #2 just before (upstream of) the air blast.

This got me thinking. Why can't you just move the sensor? Why does it have to be so far away from the air blast? Moving it right next to where the air blast is will reduce your programming to just a few rungs. The shorter the distance, the less affected it will be by conveyor speed.

 

[Peter Nachtwey]

I would consider a FIFO and encoder or pulse counter. The pulse counter only needs to be 16 bits and should NEVER be reset. Every time a new item is detected put the current pulse count PLUS the number of counts into the FIFO. I would also continually check the oldest item in the FIFO to see if the pulse counter has counted up to the value at the output of the FIFO. If it has I would do what ever needs to be done and read the next pulse from the FIFO. This would take only a hand full of rungs. This will work unless the distance from the detector to the trigger point is close to or above 32767.
If so then one must use a long integer or cascade two integers.

 

[Anirban Hazra]

Thanks for the replies. The distance 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. I understand the concept of the sprocket and prox. But for the speeds and distances we are dealing with I would need to add an encoderfor that resolution.

I know there are a few ways to accomplish this by adding other types of hardware. Is there anyway of doing programatically (there's that word again) .

Once again, thanks for the replies.
Roy

There are countless ways of doing your task with additional hardware,which makes it easier to implement and more accurate too.But, I read that you wanted to do it without having to add any hardware, which is why I thought of the best way it could be done and suggested it to you.

Did you read my post?

There were certain things I missed out considering in that and also wrote wrong as I wrote that while imagining the Ladder in my head.So, I am attaching the ladder of the method I was suggesting and which I have tested.It seems to me that it'll work well for your application.

As stated above, this method requires no additional hardware.But as a result of that it is also compromised on the level of accuracy that an extra sensor,an encoder, etc would provide.

Notes on the program:

1.I have made the ladder supposing a maximum of 5 products between the sensor and blast point. Just increase the number of branches and adjust Counter preset value to the actual number.

2.The "Blast_ON" timer preset value has to be adjusted according to your application keeping 3 things in mind:
-> a.It has to be less than the time gap between the products.
-> b.It has to be greater than the time required for the signal to persist to make the valve actuate.
-> c.The air blast has to last long enough to knock off your product.

 

[OkiePC]

Unless there is non-uniform slippage of the product on the conveyor after it is sensed, you don't need additional hardware. You do also need the resolution, processing speed and actuator consistency to get repeatable results.

You must get a detectable false to true transition for each product. You may have as many of these transitions as you want within memory limits, no new hardware required, between the sensor and the final control element.

What Peter said is logically accurate. Be systematic about how you design the code though, so it can't fudge up. (filter out illegal sensor block time durations, etc.).

There are countless ways of doing your task with additional hardware,which makes it easier to implement and more accurate too.But, I read that you wanted to do it without having to add any hardware, which is why I thought of the best way it could be done and suggested it to you.

Did you read my post?

There were certain things I missed out considering in that and also wrote wrong as I wrote that while imagining the Ladder in my head.So, I am attaching the ladder of the method I was suggesting and which I have tested.It seems to me that it'll work well for your application.

As stated above, this method requires no additional hardware.But as a result of that it is also compromised on the level of accuracy that an extra sensor,an encoder, etc would provide.

Notes on the program:

1.I have made the ladder supposing a maximum of 5 products between the sensor and blast point. Just increase the number of branches and adjust Counter preset value to the actual number.

2.The "Blast_ON" timer preset value has to be adjusted according to your application keeping 3 things in mind:
-> a.It has to be less than the time gap between the products.
-> b.It has to be greater than the time required for the signal to persist to make the valve actuate.
-> c.The air blast has to last long enough to knock off your product.

This is basically the same thing as he started with, except it doesn't trip over itself so it appears valid. It avoids high level instruction, and I am all for brute force and loopless-ness, but you are still unraveling a block instruction and turning it into a book.

This can be done in about ten rungs with few branches per rung, fewer timers to handle all the frills.

I am replete of software right now, and exhausted, but if this thread is still open next week, I will try to write an example.

Paul