"Peter C. Wallace" wrote: >>> Finally had a bit of free time to work on this. Still needs testing and >>> more >>> features but here whats there so far: >> >> Is the VHDL for this going to be made available under the GPL? If so, I'm >> interested in writing the HAL driver for it. > > Yes
Great! >> On the step/dir side: some drives require setup and/or hold times for the >> dir line with respect to the step line. Others have minumum step pulse >> lengths. Do the generators support this? Min pulse length isn't that hard, >> but setup and hold time can be a pain. > > The generator is just the DDS at the moment, it could be followed by a state > machine to generate the step pulses (they are just the DDS MSb ATM) Understood... still under construction ;-) > The DDS uses a 32 bit control word, the DDS is just 28 bits so there are 4 > free bits in the FIFO. 3 of the free bits of that word allow presetting the > DDS MSBs (just once at the start of the frame). This allows presetting the > DDS > to a safe location (no immediate step output change) in case you want to > clear > the residue, or change direction. Interesting approach. Normally of course you want to retain any fractional step that is in the accumulator, but stuffing a safe velue in there on a direction change could work. It gets hairy if you are writing the new value at about the same time as a step pulse is due to be sent. Unless the FPGA is the overall timing master (with a FIFO, etc) then you won't know if that last pulse got sent before you stuffed the new value. >>> Step gens are buffered (16 deep x 32 bit wide FIFOs each). This means that >>> real time is not required (at least for step generation), For example at a >>> basic clock of 8 MHz and a frame size (frame size is how many additions are >>> done to step generator DDS per FIFO entry) of 8000, the step gen will >>> consume >>> one FIFO entry per mSec. Since the FIFOs are 16 deep, if we use interrupts >>> or >>> just poll the FIFOhalf full register the interrupt latency or minimum >>> polling >>> time would ge 8 mSec (125 Hz). >> >> For some applications this might be a feature. For EMC its a bug. We >> already have hard realtime code, and the system time base comes from the >> realtime threads in the PC, not from the FPGA. > > hard realtime is a relative term when relating to MHz pulse streams... Understood - we don't have sub-microsecond realtime. But we don't need it - thats the entire reason for hardware stepgen. EMC treats hardware step generators just like DACs. They are part of a servo loop, which is closed in EMC's servo thread at a typical period of 1mS. Tens of microseconds of jitter in the servo thread causes no real problems. The closed loop resolves any ambiguities about whether a step was sent or not. The only requirement is that the feedback from the FPGA and the output of the drive stay in sync. The main risk is a step that is counted by the feedback in the FPGA, but missed by the drive because of setup or hold or whatever. Jon Elson's boards use the servo scheme - his step outputs are sent to an encoder counter as well as to the drive, and the encoder counter feedback is used to close the loop. Your approach is more open-loop - you rely on the step generator doing exactly what it is told to do, and the FIFO is key to making that possible. If the FIFO runs dry you are in trouble, so you make darned sure it doesn't. But then you have pipeline delays because of the FIFO. For example, consider probing. When probing, we move toward an object until the probe touches, then stop as quickly as possible and back off. If several mS of motion are queued in the FIFO, that quick reaction becomes either less quick, or more complex, or both. We could debate the relative merits of the two approaches for a long time, but let's not. Suffice it to say that EMC has sub-millisecond hard realtime code, and it wants to treat the motor control section as if it was an analog servo. At least at present, it is not possible for EMC to use an external interrupt source to trigger the realtime threads, so synchronizing its code to the FPGA's frames would not be straightforward. Even if we did add external interrupt capability, what happens when there are two devices, each with hardware "frames", and each expecting the software to follow its lead? > The buffering means that each frame will have a know number of > additions, so the DDS after each frame is calculable. > > I could easily add a non-buffered mode, but then you would have to > count the output pulses, In this case it would not be possible to > guarantee synchronism down to 1 step between axis, with the buffer > this is possible... It is true that the buffered approach is theoreticaly a tiny bit more accurate. A perfect forward transfer function is more accurate (if less robust) than using feedback to compensate for imperfections. Maybe we (EMC) should investigate the possibilities. If we limit ourselves to a maximum of one "frame" in the buffer, perhaps the delay issue can be avoided. Something to think about. >> does it rely on the fact that each value in the FIFO will >> be added to the DDS accumulator _exactly_ some known number of times? If >> the latter is the case, then you are requiring the software to synchronize >> itself to the hardware. > > The DDS can be read, and yes the rate,is added FRAMESIZE times, this > guarantees that the DDS is in a known state every frame. Heh, you conveniently ignored the part about "requiring the software to synchronize itself to the hardware" ;-) For a dedicated application running on the "raw iron" (DOS or equivalent) it is both easy and natural to use the FPGA interrupt as the timing source for the software. And for a non-realtime application that doesn't care about delays, a long buffer takes care of things. But EMC falls in the middle - we can't let the FPFA control all of the timing in the PC, but at the same time we don't want long pipeline delays because of FIFOs. Regards, John Kasunich ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
