On Tuesday 05 April 2016 03:05:00 Nicklas Karlsson 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)

Interesting tidbit of info above, Nicklas.  Having that in dead tree 
format in the pdf documentaion, as a recomendation would be most 
helpfull.

My present setup (determined by the try & cry & cuss method) on the mill, 
using a 5i25 interface, does have PID's for each axis, and of note the P 
setting hasn't been set above 1000 because it seemed non-critical, but 
in my case it should be 2000 since the current servo period is .5 
milliseconds.  This was reset from 1 millisecond when I incorporated a 
hal stanza that made the encoders velocity output the summed average of 
the last 4 edges the encoder detected.  This absorbed the edge to edge 
timing noise to a very helpful degree, but at the same time I figured I 
should make the servo loop faster because of the delay in the averager 
paragraph of my .hal.

However I didn't think the cpu could do a .25 millisecond servo loop so 
it wasn't tried. Half a millisecond does not seem to make it at all 
sluggish for other uses.  So next time I am at its keyboard, I will try 
2000 for effects, and just for S&G, a .25 millisecond servo-loop and 
P=4000.

See if I can lock it up. :)

> 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


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
+

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

Reply via email to