Help with ladder logic determining direction with quadrature

[a70duster]

Hello all,

I am trying to program a PLC (Idec) to determine direction from two impulse proxs arranged in a quadrature formation. Searching around on the net has shown that a D-latch device can be used to determine direction, but the PLC doesn't have a D-latch device, just contacts, timers, counters and coils. I guess I could program a D-latch with contacts in an "and" formation, but it would be a messy design.

Any help out there?

Thanks

 

[Skogsgurra]

I would use a PLC with "Logic Block Programming" it will be done in no time at all. Even a lowly programmable relay like the LOGO does it.

Question: you may need to look at timing. Can your PLC handle the pulses at highest speed? Also, if your proximity switches are arranged so that they do not overlap, you will have a problem telling direction when movement starts after power on. If that is not a problem, then go ahead.



Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[richs]

Hiya-

You might want to look at set/reset or latching coils
in programming. The quadrature leading lagging can
determine the direction.

Alternatively, if the quadrature is spaced correctly,
one of the prox is the data input to the D latch, the
other is the clock.

Hope this helps!

Cheers,

Rich S.

 

[a70duster]

At max speed, the scan time for the PLC is greater than an impulse transition (lo->hi then hi->lo) so the quadrature events will be missed. I am looking for a rollback and that can only happens at a stop or low speeds. So I would only look at the "quadrature" at a minimum speed.

The PLC is fast enough to catch each rising edge of a pulse so I can precisely determine speed. I've thought the logic through and here is what the logic should be doing.

Definition
A - First rising edge pulse in the forward direction
B - Second rising edge pulse in the forward direction shifted 90° after the rising edge pulse in A.

If the rising edge of B is after the rising edge of A and before the falling edge of A, that is a "forward".

If the rising edge of A is after the rising edge of B and before the falling edge of B, that is a "reverse".

 

[Skogsgurra]

Yes. That's how to do it. You can, of course use all four combinations fwd and the other four bwd. But if you are satisfied to pick one of the combinations, you should be fine.

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[a70duster]

I was side-tracked at work but I finally sat down and figured it out. Instead of looking at both A and B's rising edges, I looked at a high on A and a rising edge on B for a forward. For reverse I looked at a high on B and a rising edge on A.

I further added ladder logic to look at every rising and falling event on A and B for greater rollback detection.

Thanks for all the help/hints!

Mike

 

[xyzz]

Are you using a high-speed counter?
If yes, it must be a bit in the PLC for counting direction indication.

 

[a70duster]

No I am not using a high speed counter, just digital inputs. The time between AB events is greater than the scan time of the program.

 

[bgood1]

I have done this in a winch drum application, determining direction, distance, and a derivative speed. The linear sensing is accurate to the spacing of the prox sensors. One transition of each prox in either direction will set direction indication. The time span of "on" vs "off" should be made approximately equal and over two scans in duration. The prox switches two states should be offset to overlap equally in both directions (with manipulation of prox targets and slight offset of mounting).

My application had a 10'circumference drum with 6 steel plate prox targets. These were arranged to provide equal on/off time to the prox switches. (22.5 degrees on, 22.5 off) The sensors were offset about 11 degrees, or 1/2 the pulse duration to set up the directional detection. Since the drum max speed was only just over 3 linear FPS, scans consideration was not a problem as the program scan maxed at 30 ms and the pulse duration was 200 plus ms max.

If you would like a copy of the logic I will be glad to forward. Notify me at bgoodwin@pinnoakresources.com. I will send an RSLogix file which contains it.

 

[nbucska]

What is the RPM and the pulse/rev on each phase?



----------------------------
Please read FAQ240-1032
My WEB: <

http://geocities.com/nbucska/>

 

[a70duster]

bgood1 Thanks for the offer and good advice. I have figured out the logic to determine direction.