Now I think algorithm is perfect! Then measuring stepper pulse by oscilloscope while running an arc spiral I could see pulse width grow and shrink while machine take the turns. There are some jitter for frequency below servo period because stepper could chose to generate one pulse or not. By using the decimal for the "phase" to place pulses within servo period all jitter could removed including below servo period.
Algorithm: 1. Send positions to stepper generator each servo period. 2. Synchronize to average of receive times or other sync source. 3. Generate the difference in pulses from next period to period two steps forward to allow for a full period of jitter. Possible extension: 2.1 Use decimal to place pulses within period. 3.1 Extend (3.) from one position forward to n steps FIFO to allow missed dead lines. To place periods one steps forward and allow a full period of jitter will make algorithm agree with theories for real time scheduling, dead line equal to period. To use decimal for placement of pulses within servo period will remove all jitter including below servo period if correctly implemented of course. A FIFO would allow for missed dead lines without degraded performance except possible synchronization jitter provided value arrive before FIFO is empty of course. Algorithm allow for essentially perfect stepper pulse generation and I think it deserve a place in the documentation. Stepper algorithm could not just generate the correct number of pulses but it could also use decimal point of number steps to place steps at correct position in time. It should work equally well for servo drives. Improvements? Regards Nicklas Karlsson On Mon, 11 Apr 2016 14:18:33 -0500 bari <[email protected]> wrote: > Just wondering what the point or goal is here. > > If you move the synchronized motion from a PC to a uC and then run the > GUI with what a PC or an ARM SOC with GPU? > > Or is this for headless applications? > > Trying to save $10 on Spartan 6 with a $1 uC? > > Just asking, not judging :) > > On 04/06/2016 11:07 AM, Nicklas Karlsson wrote: > > Got machine up and running, there will probably be at least a week or two > > before I finnish of the last steps of the software. > > > > > >> I would say that the first critical thing to determine and accomplish is > >> the lowest jitter data transfers as possible via Ethernet. Since you are > >> using one of the STM32 processors I would thing that DMA would be the best > >> method to process the packet data. > >> > >> What stack are you planning to use? > >> > >> On Tue, Apr 5, 2016 at 2:05 AM, Nicklas Karlsson < > >> [email protected]> wrote: > >> > >>> 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 > >>> > >> ------------------------------------------------------------------------------ > >> _______________________________________________ > >> Emc-users mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
