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


-- 
Nicklas Karlsson <[email protected]>

------------------------------------------------------------------------------
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to