Encoder - conveyor tracking

0_Einstein

I think I suggested that fantastic suggestion earlier in this same thread.  It was probably surrounded with text attempting to answer the question(s) from the topic poster, and may have gotten lost in the mud.

Kal.A 

 His module is capable of generating hardware interrupts do digital input events, rising and falling.

 

 Thanks Einstein. I did read your suggestion. I am intersted in the theorem Jacek mentioned and though I haven't had achance to read it, I mentioned the interrupt to see if that would make a difference considering the same theorem.  I will have a read later.

Thanks Jacek and Einstein 

jacek d

 To see changes in signal it must be sampled at twice it's highest frequency. It has something to do with Nyquist–Shannon theorem. 

Now THAT is like saying to a child: "Go ask your mother".
I would buy your response if we were busy with resolvers.

I would not recommend a factor of 2 as signal distortion will play a role too. In real term digital is not a perfect wave. Applying mathematical analysis to that would not give 2.

Jacek - you are one clever guy!

LuuxKristensen

Thanks for all of the suggestions.

Usually the conveyor is running all the time, it only stops when you press the stop button.

It is ramping down smoothly.

So when we need to move the parts to another conveyor, the inlet conveyor with the encoder doesn't stop. 

Sometimes this works flawless, other times not.

By calling the hardware interrupt (Not tried yet) so often, is that a good approach to this problem? 

Thanks 

This is what I understand,:

-you have a conveyor that runs all the time while product is placed on it.

-as the product is moving it detected by a sensor as it goes by it.

-the product continues on the conveyor to a certain position where it is then transferred mechanically.

This what I would do for play, not for for real life application that requires any precision. Otherwise I would use a counter module and an encoder with much higher resolution.

-Configure hardware interrupt for rising edge of encoder input. Based on the encoder PPR of 80 you will get one pulse every about 7ms or so. Meaning you will have hardware interrupts triggered every 7ms and you need to keep that hardware interrupt execution to minimum so as to not adversely impact scan time.

-Put a simple Add instruction to increment a Dint tag and use that as your EncoderCounter. The counter tag will increment as long as the encoder is running.

-Measure the distance between the sensor and target position where the product will be transferred and calculate that in encoder pulses and that becomes your DistanceToTarget value.

-Configure a hardware interrupt for your product sensor input (Rising or falling, your choice) and set the "Priority" to a lower number than the encoder input hardware interrupt. Put a Move instruction to copy EncoderCounter value to another tag CurrentCount  (for your application you will need an array of tags and FIFO as describe by Einstein in another post) and this becomes the current counter value for that product as it passed by the sensor. in the same block set a tag GotProduct to indicate that a product has been detected.

-In Main OB or any FB add the two values so that GoToPosition := CurrentCount + DistanceToTarget; . Do that on rising edge of GotProduct and reset the tag afterwards.

-Put another instruction in encoder input OB to compare EncoderCounter >= GoToPosition then SET output immediately with :P as Einstein described.(make sure that output is reset after it had enough time to turn out the device connected to it; somewhere in the cyclic program is good)

Things to watch for:

-As mentioned make sure hardware interrupt priority is set so that encoder interrupt is higher than the sensor.

-set filter time for encoder input appropriate to the expected encoder frequency; high enough to allow all pulses and not too high that you get the so called "noise" or unwanted ONs.

Note: The attached project and a poor example of structure programming and a patched up bits of code to show an idea. Don't send too much time on it if you don't quickly understand it; in a few days I probably won"t.

qwazee

I would not recommend a factor of 2 as signal distortion will play a role too. In real term digital is not a perfect wave. Applying mathematical analysis to that would not give 2.

But this is a good indication that one got into a trouble.