> > On Mon, 25 May 2020 at 00:17, R C <[email protected]> wrote: > > > I have been following this thread. I wrote some code that runs on an > > RPI that can read a quadrature encoder, I have a few of them, with > > different resolutions. > > Is this something different to the normal LinuxCNC software encoder > that reads GPIO? > Is there some dedicated encoder counter hardware on the Pi? > > --
The Pi doesn’t have QEI hardware. In fact the PIC32 I've ported my ELS code to doesn't have a QEI so it too is limited to whatever BASE rate that could set up. With the PIC32 it can be much higher than 50uS. In the old days, when the biggest processor available for embedded systems was the 16 bit MC68000 most stuff was done with 8 bit micro's and external hardware. One system I designed for measuring rig heave on drilling platforms tracked encoders on a cable attached to the ocean floor and to the drill ship. The other was on the cable that held the drill string. As the tide or ocean swell lifted the boat the encoder reported how much the ship moved upwards and signaled the servo on the drill string cable to lower the drill string by a corresponding amount. This kept the same load on the drill bit a few thousand feet down. Otherwise it could pick up and slam down damaging the cutter. Since we didn't have the fancy Digital Signal Processors we used LSI Computer Systems LS7066 and LS7266R devices. They had an bit parallel bus interface to two 24 bit quadrature counters. At something equivalent to the LinuxCNC base rate the code would read the counters. Now that's all done with programmable logic inside FPGA devices and the counters are larger. With a 10MHz clock rate they can even debounce edges if need be. Access to these is done on some products with SPI bus also running 10 MBPS which the Raspberry Pi can do very easily. That math works out like this: 32 bits is requested with say a command and an address byte for a total of 6 bytes transferred(48 bits). So READ from ADDRESS X for 4 bytes incrementing the address after each read requires 4.8 micro-seconds. Now let's do the math on the other side. A spindle turning 6000 RPM with a 2500 line encoder generates 10,000 edges per rev at a rate of 1MHz or one edge every 1 microsecond. That means roughly 4 or 5 edges will be counted every 4.8 microseconds. But you'd use the BASE thread running 50uS to actually get this data and probably use it in the SERVO thread once every 1mS. What do you get then at 50 uS? Theoretically 50 edges at 6000 RPM. That's 50 out 10,000 or 1.8 degrees. Drop the RPM by 10 to 600 RPM and you'd now get 5 pulses every 50 uS or 0.18 degrees. What does all that mean? Well, if tapping 20 TPI (0.05" pitch) at 600 RPM that 0.18 degrees works out to 0.000025" every 50 uS. So if you are threading or tapping at 600 RPM then every 50uS the Z axis has to move 0.000025". My mill has a 4TPI screw turned 1:3 with a Gecko driven stepper motor. That's 6000 steps per 0.25" or 0.000041667" per step. So really the Z axis will only get a step pulse every 2 BASE Periods or so. Back to the original question then. Can the Pi do this? As Andy has said, unless you have a RTOS of sort running on the Pi you can't get a deterministic 50uS BASE Thread or for that matter even a SERVO thread. And then getting smooth motion linked to the spindle can be difficult. So if your encoder is limited to 100 PPR and you have an accurate 50uS BASE thread period then you can count encoder pulses. Otherwise it's easiest, and best just to use hardware. John Dammeyer _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
