Is thre any DRO encoders that connects to PC

Alex wrote in news:bIAlh.22081$ snipped-for-privacy@newssvr22.news.prodigy.net:

Not that I'm aware of. Most will require at the minimum a counter card.

Not really. If you do have a RT-OS, you could try to count quadrature-encoder signals. But you won't have a RT-OS on your PC.

Nick

Here is a link to how to hook encoders to your computer's printer port with free software. It does require two transistors per channel....

Charles

Because if a Mouse loses acount or two, it does not matter. If an encoder loses a count or two, it is a bigger deal. Any scheme that relies on a software loop to count the pulses is doomed for long term reliability. The only solution I would personally trust would be a dedicated counter circuit. And that is based on two things, 25 years experience as a digital logic engineer, and today relying on my machines every day for my living.

Alex,

I've seen several other software/hardware solutions for your project, but don't remember a web link. I'm sure I would have seen them on yahoo's CAD_CAM_DRO newsgroup or on CNCzone.com newsgroup. Both groups are searchable. IIRC, they all use the parallel port on a PC.

I also still have a DRO PCI card from Dan Mauch

that i will never use. See if Dan still supports it, especially what software program it uses. I'll sell you mine for $20 - NIB still just parts to solder. Or get a new one from Dan - I see he no longer lists it on his web site.

I suggested this in another thread about a year ago. Never had the chance to try it. The other issue is figuring out how to do two axis and not have it interfere with your normal mouse.

Doug White

What makes you say that?

There have been several RTOSs made available for desktop PC's. Often, they run the "normal" operating system (linux, windows, etc) as a low-priority non-realtime task.

But I don't think this is a good way to do an encoder - the I/O latency in and out of modern PC's is just too long.

Today I'd do it with a little microcontroller eval board hanging off the USB port.

The high probability that he has Windoze running.

ACK. That's why I wrote "you could try". Some tried it (like Mach3) and come up to about 30kHz. But no guarantee that they don't lose a step.

A dedicated counter that is communicated with with some kind of interface is the way to go. Not a uC alone, a _real_ counter that is hooked to a uC for communication and managing the counter. Note, that we are talking about QEs.

Nick

Nick, most uC's contain at least one and often several "real" 8 and 16 bit counters that can count asynchronous external events. The minimum pulse input durations of the 16-bit counter in the PICF87 is 30 ns (Tlo and Thi) so its max counting frequency would be 16.67 MHz. Atmel has one that will do 60 MHz. The max output frequency of a typical QE (BEI model H25) is 100 KHz.

That's nice, but doesn't help. We were talking about QE signals. I'm not aware of a uC with QE-input. But if you know one, let me hear!

Nick

Yes, but how many of those take quadrature?

Without that, you need a little 8-pin quadrature to step up/step down chip. And even then, you'd need either a micro with an up/down input, or to count up pulses and down pulses in seperate counters. If doing the later, you have to be careful that when you reset the counters (to prevent overflow) you don't risk loosing a count in the process.

I was thinking that a modern microcontroller tasked with little else could probably decode quadrate in software with a poling frequency around a mhz.

Forget it. There are nice intelligent QE-counters available that work in the

40MHz range, do digital filtering, handle reference signals and communicate over SPI or the like.

Nick

I don't know of a uC with inputs specifically labelled "QE" -- or one with outputs labeled "LED" for that matter though they're often used to drive LED displays. The various pins aren't even explicitly ins or outs until so configured in software.

There are a number of ways that a uC could increment or decrement an internal counter or register in response to a pair of quadrature signals, one on each of two input pins. One approach might be to have each of these pins increment an internal "hardware" counter on each rising edge. The contents of the two counters could then be subtracted to differentiate up counts from down counts, and the result used to increment or decrement a cumulative count register or set of registers.

A purely hardware solution would require more chips, if that matters. uC's are just chips that can do many different things depending upon how they are programmed. If just doing a one-off, it'd probably be easier to design it with logic chips but a low-end $2 uC running a simple program can certainly do it too.

Well Don, then you should know what "QE" means: Quadrature-Encoder signal. A phase-shifted two wire signal with Gray code*). Now you show me a uC with a single input that handles 2 lines and detects by some magic in which direction to count. :-))

You _can_ simulate a quadrature counter in a uC, but I wouldn't waste my time with that if I intend to have a solid relayable metrology instrument.

Have a happy new year!

*) Gray-like. Only one line switches state, not two at the same time.

Nick

One of the chips on this page:

do waht you want. They go between the encoder and whatever you want the encoder to cennect to. ERS

That won't work.

Quadrature differentiates up and down by the relative timing of the edges on the two channels, not by the total number of pulses on each.

You need something that looks at the state of one channel to determine what a transition on the other means.

However, if you get the 8-pin quadrature to up clock and down clock chip, then you could count those two clocks with seperate counters and subtract that result.

And with a mere 1mhz and a standard DRO 2540 counts per inch, you could operate up to 23,622 inches per minute. A counter chip can count faster but that isn't needed for this type of application. A microcontroller could count using an interrupt and have a foreground task of reading buttons, calculating count to inches and mm, and displaying the results. Of course as you approached 23000 inches per minute, the display updates would lag :-) But then you could use the Scenix chip that's PIC compatible and operates at

50MIPS.

The subtraction events would need to be triggered by one channel (counter) incrementing. The algorithm could then determine whether counter A is leading counter B (up counts) or lagging B (down counts).

That could be done too. Or,without the extra chip, the channel A input could trigger an interrupt: if B is low when A rises, increment a counter, else if B is high when A rises decrement a counter. This whole routine would take only a microsecond or so.

My point was not to propose an algorithm; there are plenty of them to be found. The point is merely that a uC can indeed deal with quadrature inputs in an number of ways up to the programmer to devise. It has been done plenty of times.

Hard-wired hardware solutions are always more bulletproof than uC's. They also cost more to make. An FPGA would be another possibility here but it'd cost more than a commodity uC. Pick yer pony, take yer ride. I definitely do not advocate uC's as the answer to everything.