It seems I was on correct track. I implemented my own softare with my own hardware only to discover ST have both for sale as evaluation board, I actually got to know about it in a newslettert then I already had implemented so it is possible it is brand new.
My software use toggle on compare fed by DMA but I do not know about ST software yet. My software use averaging of received times with allowance for a full period of jitter or more with FIFO while ST set position as soon as received. I use Ethernet while ST use UART port. The most interesting part! UART is fast enough for control of at least a few axis, a few hundred kbit/s should be enough with correct protocol. With my averaging of receival times and receive FIFO demand on computer real time perfomance would be low or actually very low for a large FIFO. I would say a micro controller as stepper generator communicating with Linuxcnc via UART would be a perfect stepper generator, FPGA with same approach would of course work equally well. 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
