Hi Rita

Now that you are retired, I thought you might be interested in this email.  The 
group is heavily involved with open source machining.  As this posting 
indicates, they are doing serious work.  This isn't exactly the kind of 
woodworking that you have expressed an interest in, but it isn't too far afield.

Best

Dave


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday, June 14th, 2021 at 9:15 AM, Nicklas SB Karlsson <n...@nksb.eu> wrote:

> Den 2021-06-14 kl. 14:48, skrev andy pugh:
>
> > On Sat, 12 Jun 2021 at 12:15, Nicklas SB Karlsson n...@nksb.eu wrote:
> >
> > > Do not find any modulo arithmetic in hal, it is very useful then waiting
> > >
> > > for a particular angle both if value overflow or just accumulate. May be
> > >
> > > solved by loop and modulo operator in g-code but maybe adding to
> > >
> > > carousel component would be a better option.
> > >
> > > One solution (though an untidy one) would be to scale the encoder
> > >
> > > counter so that it gives the correct position as a float.
> > >
> > > Then convert that float to a u32 with conv_float_u32
> > >
> > > Then convert the bottom set of bits of that u32 to signals with "bitslice"
> > >
> > > Then connect each relevant bit to the carousel comp. For a power-of-2
> > >
> > > carousel that will automatically do the modulo calc.
>
> It would probably work if position is scaled down to correct number of
>
> pockets first adding an offset to get angle of the pockets correct.
>
> Thinking about it a while I added a difference with modulo component to
>
> hal and sequential .ngc program waiting on angle then to stop, if in the
>
> half furthest away waiting for carousel to reach other half before
>
> waiting to reach position. First stop with pocket 13 at correct position
>
> and others counted in wrong direction but that should be easy to change.
>
> .ngc program is running in a slower thread so I guess some more jitter
>
> then waiting for input before turning off? Or it's just the interpreter
>
> running in slower thread and commands are executed in faster thread?
>
> I found then running servo-thread at 1kHz carousel stopped within 1/360
>
> of at turn or so and guess slower g-code thread will be more than good
>
> enough, think locking of carousel correct the last few degrees but have
>
> not checked yet. Think it is good either to add support for angle sensor
>
> in current carousel component or simply forking of a different variant
>
> using an angle sensor. At some point I want to add a check if carousel
>
> is rotating as supposed to because I am pretty it will brake down quite
>
> fast if for some reason locked then running from the noise it make in
>
> this case.
>
> Regards Nicklas SB Karlsson
>
> Emc-users mailing list
>
> Emc-users@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/emc-users


_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to