Printable View
All,
I have a magazine setup that has 2 switches that act as a quasi encoder. What I am looking for is a starting place to build a C program that will increment and decrement a counter variable. I have 30 stations so my total count should be 30. mIt is driven via hydraulic motor and latches mechanically once triggered in position. I can do the delta for direction control. But, making a counter can be tricky.
Any help is appreciated.
Sir,
I thinks that speed is a beginning factor. Once you know the speed, of your mechanical system... then you can design your code to work within that speed... not to exceed.
Here is an article: Link: Where the beginning discussion... and arguments, as well as "Pit Falls", related to, the reading of a quad encoder. All four states need tracked in your code.
Decode a quadrature encoder in software | EDN
Using a timer to track the state of your inputs, every so many ms. Then filtering each input, to not get false signals, can be a challenge.
__________________________________________________ __________________________________________________ ________
Reading the inputs directly and trying to "debounce" your code could be a source of errors in your operation.
Alternative approach could be, and maybe should be... Using a Up/Dn counter chip, that has this covered, and puts out the digital position, would give your application an advantage.
So run your two inputs into a Up/Dn counter chip, made for this... and that chip, or logic can give you a count, up or down, and the filtering of the input can be a simple RC circuit... and may be built into a chip for that purpose.
So your little circuit board, could give you a position, 0-? (depends on chip) and based on that, track your mechanical position.
__________________________________________________ __________________________________________________ ________
I would dig further into the chip option... then once you have that... your C code will be only the ready of the digital position of you counter chip.
Note: If only using 2 inputs, this way... you may need a homing switch... so to home that mechanical system. Otherwise when you start, your computer and system will not know where it is.
_______________________________________
That brings up the final solution.... Absolute Encoder... and using 4 inputs and not 2. This is how Brother for instance, tracks there tool positions... absolute encoder logic, there is no calculations what so ever... you read the state of the 4 inputs... and you know where you are. They have a small disk, that has holes in it... and four through sensors, that read the position of the whole mechanism.
Abosolute gives you the piece of mind, that you know without a doubt, where it is.
This would be a top notch solution... less chance for errors. No homing needed. Tool 1 is always tool one.... it is "Absolute"!
It is roughly 2 -3 PPS which is not a lot considering. I would think one could catch that in a 100ms loop. Just needed to see how to decode it. One AB cycle = 1 count plus. One BA cycle = 1 count minus.
Advice: When you think something is simple... therein is your first mistake.
Two signals, what is so hard about that??? Read the article I linked you to... and go down to the comments, and you will see... just how complicated it can be. Of course that is reading encoder with 100's maybe thousands of lines, per rotation.
When your sensor is on the knife edge... what will happen? Jitter, spikes, and so forth... that is the filtering. You can get false signals... and that will increment your counter up and down... even when the device is setting there idle.
How to eliminate that from happening... see below.
_______________________________________________
One way to avoid all that, is to build the cog's or cams, mechanically, so that they only read, or send signals between moves. Then once they show the right location coming up.
Go past, stop decoding the position, thus your count is set and locked.
Then write the logic to use one of the prox's as a homing sensor, maybe by a separate cam or tab, then home to that position. Now you are in that tools home postion.
Mechanically and progamically make it, so that you are only counting with those sensors, when you are in motion. Leaving a position, you may need to block the encoder till you clear that position.
For reading from either direction... you could do that with code... then the code could go either direction... the quickest, determined by your logic.
All in all, I think it could be done that way. You don't want your counter counting, when not in motion. Then all the filtering issues go away.
I am wondering if the simplest way is to utilize a single ended encoder input for the last acis channel with no output. Then scale the count accordingly. Read the position and act on that. Since the count hapens about 5 degrees ahead of the physical location I should have time to read the position and set the lock in place output and release the forward motion.
I did this single ended on a wire mess machine... I used standard AC 3 phase motors, with a VFD, and I used two speed... I went at high speed... and counted up, when within 100 counts of the desired position, I set it to go to preset speed 2, which was a crawl... then when it hit the sensor, stopped based on a timer... I could hit within 1 encoder count every time.
So no Servo motor, no stepper motor, just a standard AC Industrial motor, and hitting very accurate, via the single ended encoder count.
As with anything, you can think it to death... but giving it a whirl, testing... you will find what works. If you don't mind going only one direction... then this get way more simple.
Hi Don,
Here is a software example that should work. It is a bit complicated because it debounces the switches and is state driven. As you state you could also use a KFLOP Hardware Encoder Counter but that wouldn't do debouncing. It wouldn't ever loose count but might dither between positions when transitioning. It would of course use up an encoder input as well.
As shown in the example you must call ServiceQuadCount(); continuously and then the global variable quadcount will be the current position.
I've attached it as a txt file as well. Let me know if you have questions.
Regards
TK
Code:#include "KMotionDef.h"
// Example counting quadrature transitions
#define QUADPHASEA 46
#define QUADPHASEB 47
// function prototypes for compiler
int Debounce(int n, int *cnt, int *last, int *lastsolid);
void ServiceQuadCount(void);
// state variables for switch debouncing
int alast=0,alastsolid=-1,acount=0;
int blast=0,blastsolid=-1,bcount=0;
int quadcount=0; // the counted position
main()
{
for (;;) // loop forever
{
WaitNextTimeSlice();
ServiceQuadCount();
// for testing put as Position 7 for viewing on Axis Screen
ch7->Position = quadcount;
}
}
void ServiceQuadCount(void)
{
int bita,bitb,resulta,resultb;
bita=ReadBit(QUADPHASEA); // Read Phases
bitb=ReadBit(QUADPHASEB);
// Debounce Phases and detect any transition
resulta = Debounce(bita,&acount,&alast,&alastsolid);
resultb = Debounce(bitb,&bcount,&blast,&blastsolid);
if (resulta != -1) // a transition?
{
// when moving forward phases are different after a transition
if (resulta != blastsolid) quadcount++;
else quadcount--;
}
if (resultb != -1) // b transition?
{
// when moving forward phases are same after b transition
if (resultb == alastsolid) quadcount++;
else quadcount--;
}
}
// Debounce a bit
//
// return 1 one time when first debounced high
// return 0 one time when first debounced low
// return -1 otherwise
#define DBTIME 300
int Debounce(int n, int *cnt, int *last, int *lastsolid)
{
int v = -1;
if (n == *last) // same as last time?
{
if (*cnt == DBTIME-1)
{
if (n != *lastsolid)
{
v = *lastsolid = n; // return debounced value
}
}
if (*cnt < DBTIME) (*cnt)++;
}
else
{
*cnt = 0; // reset count
}
*last = n;
return v;
}
Fantastic. Just hat I was looking for. Thanks Tom and Jeffserv.
Once I have the final I will send it to you. It should work with most Taiwanese ATC's. Almost all including Toyoda (FH Series to 1993), Mori (Green Body), and several others. The logic for them all is practically identical in nature. I will do my best to include random slot tracking as well as most do that. And a reset that will reset the slot array to consecutive numbers which is vital as they get pretty screwed up at times. Especially when the ATC is reset during the arm rotation before the tool data is transfered from Arm to Spindle to Magazine.