The synchronization further down is the hard problem. > It may be useful to consider what hostmot2 does, before deciding whether > to do it the same way or differently.
I currently use the hostmot2 Ethernet protocol but for stepper generator it would make sense with UART if fast enough. USB might also be an option. There are cheap power supplies for mains power readily available so I sometimes use USB port as power supply even though port is not used for communication at all. > The command to the step generator is a velocity or frequency command > (e.g., in units of 20ns is convenient for a DDS-type generator running > at 50MHz and can express step rates down to around 1/minute in a 32-bit > register), and the feedback is cumulative position (mod 2^32 or other > convenient width that doesn't overflow too often). > > In the hostmot2 hal component, the narrow position feedback register is > extended to a larger width such as 2^64, and divided by the scale to > give a position in inches, degrees, mm, or whatever. +-2^63 counts is > enough that you can ignore "roll over" for approximately the length of > written human history -- at 25MHz step rate you have over 116 centuries > before the values overflow around. I think I got it correct speed out and position back. > Add to that the necessary HAL configuration to take linuxcnc's commanded > position and the stepgen feedback position to produce a frequency > command. This can be done e.g., by a PID loop. I think he recommends > FF1=1, P=1e9/servo_period_ns (so 1000 for a 1ms servo period), other > terms 0 as a starting point. (I think this is only documented by word of > mouth, unfortunately) There is no PID for stepper. I have to read source to figure out. > This already produces very good position following despite some jitter > in the PC. Peter does a few additional tricks in his FPGA, like > actually sampling the position a bit before it expects the request for > position feedback to arrive, eliminating jitter of the time the position > feedback is taken. (this involves a PLL in the FPGA that tracks the PC's > servo thread frequency, plus a negative offset so that it can sample the > position early enough) This time synchronization is the hard problem. Jitter in the position feedback will be a problem if Linuxcnc assume there is no jitter. There will also be some delay which is may cause problem if Linuxcnc assume there are no delay. In average there should only be a small clock skew between them. It make sense to allow jitter within the full period because in such case dead line will be equal to period and this fit with real time scheduling theories. Timer registers in micro controllers usually have shadow registers which are written to real registers at hardware controlled update event and then jitter within period will not matter at all. If servo period is averaged and tracked it is possible to correct errors about assumptions period is without jitter even including the execution of the servo period itself. Delay is possible to compensate because micro controller know it will generate pulses which have not yet been generated. Ideally I think Linuxcnc should send a stream of stepper positions to micro controller. Then micro controller interpolate between the steps and motion get smother. With this method it would also be possible to send several values at once and have a receive buffer. > (hostmot2 the hal component also offers a mode where its input is > position command, but it uses a different algorithm and empirically PCW > says that the PID solution gives better following. A good small project > in linuxcnc would be to move this pre-tuned PID loop into hostmot2 so > that the position mode gives following that is as good as with external > PID; a slightly less small project might be to pull out PID into a > library that could be used by PID the component but also by various > smart step generators such as hostmot2 that would benefit from a > pre-tuned PID) > > Jeff Nicklas Karlsson ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
