Re: [Emc-developers] Moving backlash comp to HAL module

[andy pugh]

On 28 July 2015 at 00:19, EBo  wrote:
> I am not so
> sure about the tool-offsets, but then again you mention that it doesn't
> necessarily obey axis limits of length, velocity and accel, so a revisit
> might be in order.

My statement was about the HAL "offset" component, not about the tool offsets.


-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[EBo]

On Jul 27 2015 1:07 PM, andy pugh wrote:
> On 27 July 2015 at 19:57, Chris Morley  
> wrote:
>
>> How about adding two pins to motion for each axis.
>> forward comp and reverse comp.
>> These would be summed with the compensation that
>> already comes from the comp file.
>
> This ties in with something that I have been thinking of for quite a
> while, that it would sometimes be handy to be able to apply an
> external offset to an axis.
> (You can sort-of do this with the offset component, but that doesn't
> necessarily obey axis limits of length, velocity and accel)
>
> If you don't need it to be bidirectional then you would just wire 
> both
> inputs to the same source.

this would be a great place to add a tool-wear component.  I am not so 
sure about the tool-offsets, but then again you mention that it doesn't 
necessarily obey axis limits of length, velocity and accel, so a revisit 
might be in order.

   EBo --


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Brian]

On Mon, Jul 27, 2015 at 2:57 PM, Chris Morley 
wrote:

>
>
> > From: bodge...@gmail.com
> > Date: Mon, 27 Jul 2015 17:48:47 +0200
> > To: emc-developers@lists.sourceforge.net
>
> > I think that in this case the backlash feature is where it belongs.
> >
> > motion is a loadable HAL module. It is entirely possible to have
> > configurations that don't use it (I sometimes do exactly that). There
> > probably are things that are in the motion module and shouldn't be,
> > but I don't think that this is one.
> >
> > --
> > atp
>
> How about adding two pins to motion for each axis.
> forward comp and reverse comp.
> These would be summed with the compensation that
> already comes from the comp file.
> Then anyone can tack on any kind of compensation, and it
> doesn't break configs.
>
> Chris M
>
> This is probably where this is headed.  I think a single compensation
input would make the most sense in this case, as what we are trying to do
is translate from joint position to motor position.  This translation
should be the same forward and backward.

Brian
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[andy pugh]

On 27 July 2015 at 19:57, Chris Morley  wrote:

> How about adding two pins to motion for each axis.
> forward comp and reverse comp.
> These would be summed with the compensation that
> already comes from the comp file.

This ties in with something that I have been thinking of for quite a
while, that it would sometimes be handy to be able to apply an
external offset to an axis.
(You can sort-of do this with the offset component, but that doesn't
necessarily obey axis limits of length, velocity and accel)

If you don't need it to be bidirectional then you would just wire both
inputs to the same source.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Chris Morley]

> From: bodge...@gmail.com
> Date: Mon, 27 Jul 2015 17:48:47 +0200
> To: emc-developers@lists.sourceforge.net

> I think that in this case the backlash feature is where it belongs.
> 
> motion is a loadable HAL module. It is entirely possible to have
> configurations that don't use it (I sometimes do exactly that). There
> probably are things that are in the motion module and shouldn't be,
> but I don't think that this is one.
> 
> -- 
> atp

How about adding two pins to motion for each axis.
forward comp and reverse comp.
These would be summed with the compensation that 
already comes from the comp file.
Then anyone can tack on any kind of compensation, and it
doesn't break configs.

Chris M
  
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[EBo]

On Jul 27 2015 10:35 AM, Brian wrote:
> On Mon, Jul 27, 2015 at 12:29 PM, John Kasunich 
> 
> wrote:
>
>>
>>
>> On Mon, Jul 27, 2015, at 12:25 PM, EBo wrote:
>>
>> >
>> > Doesn't HAL have a way to load drivers and other data?  I have not
>> > mucked with things at this level for awhile.
>> >
>>
>> Loading the code of drivers (or any other realtime component), yes.
>>
>> Loading configuration specific data into a driver or other 
>> component, not
>> really.
>>
>> The normal way of passing configuration specific data to a component 
>> is
>> arguments tacked onto the loadrt command.  That works if all you are 
>> trying
>> to do is tell the parport driver to use the port at 0x378, or tell 
>> the
>> step generator
>> to give you three velocity mode stepgens.  It doesn't scale well to 
>> larger
>> amounts
>> of data (like a 256 point screw compensation curve).
>>
>> I wonder if we could leverage the fact that the data only needs to 
>> be
> loaded once, and not randomly accessed.  Maybe something could pass 
> it at
> init, or something?

That is exactly where I was going with my follow on question.  I had 
assumed that loading the compensation curve is a once only operation.

   EBo --


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Brian]

On Mon, Jul 27, 2015 at 1:26 PM, Sebastian Kuzminsky 
wrote:

> On 7/27/15 11:16 AM, Brian wrote:
> > Does Classic Ladder run in HAL?  I'm sure it has a large config, if it
> runs
> > as a HAL component, how does it do it?
>
> ClassicLadder runs in HAL and has a large config, and it manages this by
> having part of it run in Realtime (which doesn't have filesystem access)
> and part run in Userspace (aka non-realtime) which *does* have
> filesystem access, and it passes the config info from userspace to
> realtime at startup.
>
> This information-passing is done "by hand", using shm.  See
> Classicladder_AllocAll() for details.
>
>
Well, if that's the case, then it may be best to leave the screw comp where
it is.  If that becomes the eventual consensus, we should then consider
adding a few HAL pins to motion to better enable more sophisticated
compensation and feedback.

Brian
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Sebastian Kuzminsky]

On 7/27/15 11:16 AM, Brian wrote:
> Does Classic Ladder run in HAL?  I'm sure it has a large config, if it runs
> as a HAL component, how does it do it?

ClassicLadder runs in HAL and has a large config, and it manages this by 
having part of it run in Realtime (which doesn't have filesystem access) 
and part run in Userspace (aka non-realtime) which *does* have 
filesystem access, and it passes the config info from userspace to 
realtime at startup.

This information-passing is done "by hand", using shm.  See 
Classicladder_AllocAll() for details.


-- 
Sebastian Kuzminsky

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Brian]

Does Classic Ladder run in HAL?  I'm sure it has a large config, if it runs
as a HAL component, how does it do it?

Brian
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Brian]

On Mon, Jul 27, 2015 at 11:48 AM, andy pugh  wrote:

> On 27 July 2015 at 17:29, Brian  wrote:
> > Regardless, the point I would like to address right now is whether it
> would
> > be a welcome change or not.  Its technical feasibility can be determined
> > during its implementation.  Obviously we want everything to work
> correctly
> > and logically.
>
> I think that in this case the backlash feature is where it belongs.
>
> motion is a loadable HAL module. It is entirely possible to have
> configurations that don't use it (I sometimes do exactly that). There
> probably are things that are in the motion module and shouldn't be,
> but I don't think that this is one.
>
> For other types of backlash comp there are other ways to do it. For
> example I believe that non-compensated positions are available on
> other HAL pins, if needed.
> If you want to create a parallel method of compensation for specific
> circumstances then feel free, my only objection is that there might be
> more useful uses for your time.
> (Removing compensation from motion would break existing configs, and
> that might be unwelcome)
>
> In the event that backlash comp stays, then a few HAL pins should be
created to make available the information and functionality I am trying to
achieve.  This shouldn't break anyone's setup (not irreparably anyway).

In your particular situation it might be possible to close the loop
> properly with velocity-mode stepgens and PID, but that is a discussion
> for a different thread.
>
> My goal is not to close any control loops, and moreover,  this would
likely suffer from the same underlying limitation:  Currently, there is no
provision for position feedback that is not subject to backlash comp.
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Brian]

On Mon, Jul 27, 2015 at 12:29 PM, John Kasunich 
wrote:

>
>
> On Mon, Jul 27, 2015, at 12:25 PM, EBo wrote:
>
> >
> > Doesn't HAL have a way to load drivers and other data?  I have not
> > mucked with things at this level for awhile.
> >
>
> Loading the code of drivers (or any other realtime component), yes.
>
> Loading configuration specific data into a driver or other component, not
> really.
>
> The normal way of passing configuration specific data to a component is
> arguments tacked onto the loadrt command.  That works if all you are trying
> to do is tell the parport driver to use the port at 0x378, or tell the
> step generator
> to give you three velocity mode stepgens.  It doesn't scale well to larger
> amounts
> of data (like a 256 point screw compensation curve).
>
> I wonder if we could leverage the fact that the data only needs to be
loaded once, and not randomly accessed.  Maybe something could pass it at
init, or something?
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[EBo]

On Jul 27 2015 10:29 AM, John Kasunich wrote:
> On Mon, Jul 27, 2015, at 12:25 PM, EBo wrote:
>
>>
>> Doesn't HAL have a way to load drivers and other data?  I have not
>> mucked with things at this level for awhile.
>>
>
> Loading the code of drivers (or any other realtime component), yes.
>
> Loading configuration specific data into a driver or other component,
> not really.
>
> The normal way of passing configuration specific data to a component 
> is
> arguments tacked onto the loadrt command.  That works if all you are 
> trying
> to do is tell the parport driver to use the port at 0x378, or tell
> the step generator
> to give you three velocity mode stepgens.  It doesn't scale well to
> larger amounts
> of data (like a 256 point screw compensation curve).


Could it be set up to accept an argument 
"comp=/opt/LCNC/config/axis.comp" and let the driver handle the load as 
part of it's initialization?

   EBo --


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[John Kasunich]

On Mon, Jul 27, 2015, at 12:25 PM, EBo wrote:

> 
> Doesn't HAL have a way to load drivers and other data?  I have not 
> mucked with things at this level for awhile.
> 

Loading the code of drivers (or any other realtime component), yes.

Loading configuration specific data into a driver or other component, not 
really.

The normal way of passing configuration specific data to a component is
arguments tacked onto the loadrt command.  That works if all you are trying
to do is tell the parport driver to use the port at 0x378, or tell the step 
generator
to give you three velocity mode stepgens.  It doesn't scale well to larger 
amounts
of data (like a 256 point screw compensation curve).

-- 
  John Kasunich
  jmkasun...@fastmail.fm

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[John Kasunich]

On Mon, Jul 27, 2015, at 12:08 PM, Brian wrote:
> On Mon, Jul 27, 2015 at 11:54 AM, John Kasunich 
> wrote:

> 
> > Another implementation detail is how to get the screw comp data to the
> > compensation component.  Realtime HAL components don't have a clean
> > way to access files (such as a file that contains a screw compensation
> > curve).
> > Motion gets a variety of data from user-space already, and the screw comp
> > data piggybacks on the same data structures and user/realtime communication
> > link.  A stand-alone screw comp component would have to solve that problem
> > another way.
> 
> 
> 
> This could be a major issue.  I haven't looked at any of that yet, and I
> don't know much about it.  Does anyone else have any thoughts to add about
> this?

Actually, this conversation reminded me of something that went by a few
days ago.  Look back in your emc-dev archives for a thread called:
jepler/hal-streams: an API for streaming data to/from realtime

If I understand that correctly, Jeff is cleaning up and generalizing the 
user/realtime mechanism used by halstreamer and halsampler.  It doesn't
completely solve the problem - the screw comp component would still need
both a realtime part and a user-space part, which would be a nuisance.
But at least you wouldn't have to invent it from scratch.


-- 
  John Kasunich
  jmkasun...@fastmail.fm

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[EBo]

On Jul 27 2015 10:08 AM, Brian wrote:
> On Mon, Jul 27, 2015 at 11:54 AM, John Kasunich 
> 
> wrote:
> ...
>> Another implementation detail is how to get the screw comp data to 
>> the
>> compensation component.  Realtime HAL components don't have a clean
>> way to access files (such as a file that contains a screw 
>> compensation
>> curve).
>> Motion gets a variety of data from user-space already, and the screw 
>> comp
>> data piggybacks on the same data structures and user/realtime 
>> communication
>> link.  A stand-alone screw comp component would have to solve that 
>> problem
>> another way.
>
>
> This could be a major issue.  I haven't looked at any of that yet, 
> and I
> don't know much about it.  Does anyone else have any thoughts to add 
> about
> this?

Doesn't HAL have a way to load drivers and other data?  I have not 
mucked with things at this level for awhile.

   EBo --

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Brian]

On Mon, Jul 27, 2015 at 11:54 AM, John Kasunich 
wrote:
>
> In principle, making things more modular is always good and welcome.
> But in practice, the technical feasibilty does come into play.  If the only
> way to pull screw comp out of motion is to add several more HAL pins
> to motion so that the screw comp module can be aware of motion
> internals, then perhaps it shouldn't be pulled out.
>
> Agreed.  If it become a spaghetti mess, then it probably doesn't make
sense to do.  I would be willing to go down the rabbit hole without know
for certain everything will work out.  If turns out to be a dead end, then
its only my loss.


> Referring back to the block diagram, I can see one specific issue that
> would
> need to be resolved:
>
> See the box labeled "motor offset", which is summed with the screw comp
> output?  That value is determined during homing and stuffed into that box
> by the homing routine.  It needs to be added to output (and subtracted from
> feedback) on the motor side of the screw comp block, so that screw comp
> knows the absolute axis position, not the more-or-less "random" motor
> position.
> (Motor position varies depending on where the axis was when the power was
> turned on.)
>
> Couldn't that be left alone?  Unless there is a finer technical detail
here I'm missing (I haven't studied it too much yet), I think motor offset
addition could be left in place.

Another implementation detail is how to get the screw comp data to the
> compensation component.  Realtime HAL components don't have a clean
> way to access files (such as a file that contains a screw compensation
> curve).
> Motion gets a variety of data from user-space already, and the screw comp
> data piggybacks on the same data structures and user/realtime communication
> link.  A stand-alone screw comp component would have to solve that problem
> another way.


>
This could be a major issue.  I haven't looked at any of that yet, and I
don't know much about it.  Does anyone else have any thoughts to add about
this?

Brian
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[John Kasunich]

On Mon, Jul 27, 2015, at 11:29 AM, Brian wrote:
> On Mon, Jul 27, 2015 at 10:34 AM, Sebastian Kuzminsky 
> wrote:
> 
> > I agree with Andy, backlash compensation belongs in Motion, since that's
> > where the trajectory is planned.
> >
> > Motion can insert a backlash compensation "move" when a joint changes
> > direction, and compensate for the time that the backlash move takes by
> > not moving the other joints (except that possible backlash moves on
> > other joints may happen at the same time).
> 
> 
> >
> An external hal component that tried to do that would have to capture
> > and buffer all the joint waypoints that Motion was generating during the
> > backlash move, then when the backlash move is finished either try to
> > catch up to Motion (which would violate the accel & vel that Motion had
> > planned), or stay behind Motion from then on out (which would introduce
> > lag on things that immediately affect the trajectory, like Feed Override).
> >
> >
> Looking at the code, this does not appear to be the case.  As it appears,
> backlash is ramped in and added to the joints position target without
> affecting the movement of any other joints.  See "control.c" line 1871.
> Yes, this means a joint executing a backlash move will lag behind its
> target position until the backlash move is complete.  Can anyone else
> confirm this?

I believe you are correct.  Look at the diagram here:
http://linuxcnc.org/docs/html/code/Code_Notes.html#_block_diagrams_and_data_flow

In particular, note that the screw comp module is computing velocity
using a d/dT calculation.

I cannot vouch for the accuracy of that drawing.  I drew it, and I wrote the
corresponding code - so it was accurate at that time.  But the code was
written about a decade ago, and it is quite possible that other folks have
improved it since then.

> Regardless, the point I would like to address right now is whether it would
> be a welcome change or not.  Its technical feasibility can be determined
> during its implementation.  Obviously we want everything to work correctly
> and logically.

In principle, making things more modular is always good and welcome.
But in practice, the technical feasibilty does come into play.  If the only
way to pull screw comp out of motion is to add several more HAL pins
to motion so that the screw comp module can be aware of motion 
internals, then perhaps it shouldn't be pulled out.

Referring back to the block diagram, I can see one specific issue that would
need to be resolved:

See the box labeled "motor offset", which is summed with the screw comp
output?  That value is determined during homing and stuffed into that box
by the homing routine.  It needs to be added to output (and subtracted from
feedback) on the motor side of the screw comp block, so that screw comp
knows the absolute axis position, not the more-or-less "random" motor position.
(Motor position varies depending on where the axis was when the power was
turned on.)

Another implementation detail is how to get the screw comp data to the 
compensation component.  Realtime HAL components don't have a clean
way to access files (such as a file that contains a screw compensation curve).
Motion gets a variety of data from user-space already, and the screw comp
data piggybacks on the same data structures and user/realtime communication
link.  A stand-alone screw comp component would have to solve that problem
another way.



> 
> Brian
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


-- 
  John Kasunich
  jmkasun...@fastmail.fm

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[andy pugh]

On 27 July 2015 at 17:29, Brian  wrote:
> Regardless, the point I would like to address right now is whether it would
> be a welcome change or not.  Its technical feasibility can be determined
> during its implementation.  Obviously we want everything to work correctly
> and logically.

I think that in this case the backlash feature is where it belongs.

motion is a loadable HAL module. It is entirely possible to have
configurations that don't use it (I sometimes do exactly that). There
probably are things that are in the motion module and shouldn't be,
but I don't think that this is one.

For other types of backlash comp there are other ways to do it. For
example I believe that non-compensated positions are available on
other HAL pins, if needed.
If you want to create a parallel method of compensation for specific
circumstances then feel free, my only objection is that there might be
more useful uses for your time.
(Removing compensation from motion would break existing configs, and
that might be unwelcome)

In your particular situation it might be possible to close the loop
properly with velocity-mode stepgens and PID, but that is a discussion
for a different thread.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Brian]

On Mon, Jul 27, 2015 at 10:34 AM, Sebastian Kuzminsky 
wrote:

> I agree with Andy, backlash compensation belongs in Motion, since that's
> where the trajectory is planned.
>
> Motion can insert a backlash compensation "move" when a joint changes
> direction, and compensate for the time that the backlash move takes by
> not moving the other joints (except that possible backlash moves on
> other joints may happen at the same time).


>
An external hal component that tried to do that would have to capture
> and buffer all the joint waypoints that Motion was generating during the
> backlash move, then when the backlash move is finished either try to
> catch up to Motion (which would violate the accel & vel that Motion had
> planned), or stay behind Motion from then on out (which would introduce
> lag on things that immediately affect the trajectory, like Feed Override).
>
>
Looking at the code, this does not appear to be the case.  As it appears,
backlash is ramped in and added to the joints position target without
affecting the movement of any other joints.  See "control.c" line 1871.
Yes, this means a joint executing a backlash move will lag behind its
target position until the backlash move is complete.  Can anyone else
confirm this?

Regardless, the point I would like to address right now is whether it would
be a welcome change or not.  Its technical feasibility can be determined
during its implementation.  Obviously we want everything to work correctly
and logically.

Brian
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Brian]

>
> I think that motion knows things about the required path that are
> unavailable to HAL. For one, it knows the direction of travel whereas
> HAL would need to compare subsequent position commands, introducing
> lag at best and possibly worse problems at very low speed.
>
> This may be true, and serious technical issues may arise. With respect to
direction not being available, that could simply be output to HAL via a pin
if that is the only issue.

I think there might be an argument for having backlash compensation in
> motion, and addign secondary corrections such as these with the
> "offset" component.
>
> I am actively soliciting feedback as to the usefulness and desire for this
change, so, if there is something to add, please do.  It would seem though
as the intention of HAL was to make LinuxCNC modular and flexable with as
little or as much functionality as your machine needs.  Having concepts
like this hardcoded and forcing everyone to use the same model seems
against the point of having such a great framework like the HAL.


> >  Second, it would set the stage to be more friendly for dual scale/motor
> feedback, because it would give control over where the compensation is
> added in the feedback loop.
>
> This sounds good in principle, but I would need to think about it
> rather longer to work out whether it is important in practice.
>
> The dual feedback issue it helps solve is this.  I have a Bridgeport mill
with a DRO.  Nothing unusual or fancy.  I adder stepper motors to the X and
Y handles to drive the table.  Then I thought it would be great to use the
DRO scales as positive feedback, so I wired those in as well.  Once I got
everything working, I used the DRO scales to create a screwmap of both X
and Y to minimize lead error.  So far, my story seems pretty typical and
logical for the average LinuxCNC user.  Here is where the problem occurs.
I wanted to use the scale feedback as an input to motion so LinuxCNC would
track the table position when the stepper drives were disabled.  The only
place to feed that information into motion is motor-pos-fb and it has the
backlash/screw comp subtracted from it before it get to the kinematics.
Because those compensations were subtracted from the scale position, the
information going to the kinematics was never correct, and there is no
current way to accommodate this with the way motion is written.

Brian

> --
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[sam sokolik]

I also use hal to do temp compensation using the offset component.

https://www.youtube.com/watch?v=h-CdFd2Zakc

sam

On 7/27/2015 9:34 AM, Sebastian Kuzminsky wrote:
> On 07/26/2015 09:31 PM, Brian wrote:
>> I have had an idea lingering in my head for quite some time now.  How about 
>> moving the screw/backlash comp out of motion and implement it with a HAL 
>> module.  The purpose would be for two goals.  One it would make it more 
>> logical to implement more sophisticated joint compensation, such as thermal 
>> expansion, deflection, and belt stretch.  Second, it would set the stage to 
>> be more friendly for dual scale/motor feedback, because it would give 
>> control over where the compensation is added in the feedback loop.
> I agree with Andy, backlash compensation belongs in Motion, since that's
> where the trajectory is planned.
>
> Motion can insert a backlash compensation "move" when a joint changes
> direction, and compensate for the time that the backlash move takes by
> not moving the other joints (except that possible backlash moves on
> other joints may happen at the same time).
>
> An external hal component that tried to do that would have to capture
> and buffer all the joint waypoints that Motion was generating during the
> backlash move, then when the backlash move is finished either try to
> catch up to Motion (which would violate the accel & vel that Motion had
> planned), or stay behind Motion from then on out (which would introduce
> lag on things that immediately affect the trajectory, like Feed Override).
>
> While backlash compensation surely belongs in Motion, slow,
> small-magnitude, long-term offset changes like thermal compensation can
> probably be implemented safely as a HAL modification to the waypoints
> commanded by Motion.  See Dewey's "moveoff" demo for an example of how
> this can be implemented (sim/axis/moveoff), with some video here:
>
>  https://www.youtube.com/watch?v=KY6hx7WBkO8
>  https://www.youtube.com/watch?v=XGDq6620fPQ
>
>


--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Sebastian Kuzminsky]

On 07/26/2015 09:31 PM, Brian wrote:
> I have had an idea lingering in my head for quite some time now.  How about 
> moving the screw/backlash comp out of motion and implement it with a HAL 
> module.  The purpose would be for two goals.  One it would make it more 
> logical to implement more sophisticated joint compensation, such as thermal 
> expansion, deflection, and belt stretch.  Second, it would set the stage to 
> be more friendly for dual scale/motor feedback, because it would give control 
> over where the compensation is added in the feedback loop.

I agree with Andy, backlash compensation belongs in Motion, since that's
where the trajectory is planned.

Motion can insert a backlash compensation "move" when a joint changes
direction, and compensate for the time that the backlash move takes by
not moving the other joints (except that possible backlash moves on
other joints may happen at the same time).

An external hal component that tried to do that would have to capture
and buffer all the joint waypoints that Motion was generating during the
backlash move, then when the backlash move is finished either try to
catch up to Motion (which would violate the accel & vel that Motion had
planned), or stay behind Motion from then on out (which would introduce
lag on things that immediately affect the trajectory, like Feed Override).

While backlash compensation surely belongs in Motion, slow,
small-magnitude, long-term offset changes like thermal compensation can
probably be implemented safely as a HAL modification to the waypoints
commanded by Motion.  See Dewey's "moveoff" demo for an example of how
this can be implemented (sim/axis/moveoff), with some video here:

https://www.youtube.com/watch?v=KY6hx7WBkO8
https://www.youtube.com/watch?v=XGDq6620fPQ


-- 
Sebastian Kuzminsky

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] carousel_demo and duplicate O-word label

[andy pugh]

On 25 July 2015 at 13:35, andy pugh  wrote:
> This sounds like something that Tormach have already found and fixed.
> (spotted in a release note).

Apparently Tormach have found it, but not fixed it.
So a resolution still needs to be found, it seems.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] joints_axes8

[Sebastian Kuzminsky]

On 07/22/2015 07:33 PM, Curtis Dutton wrote:
> I have rebased joints_axes7 onto master and renamed it to joints_axes8.

Were there any conflicts during the rebase?


-- 
Sebastian Kuzminsky

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[andy pugh]

On 27 July 2015 at 05:31, Brian  wrote:
> I have had an idea lingering in my head for quite some time now.  How about 
> moving the screw/backlash comp out of motion and implement it with a HAL 
> module.

I think that motion knows things about the required path that are
unavailable to HAL. For one, it knows the direction of travel whereas
HAL would need to compare subsequent position commands, introducing
lag at best and possibly worse problems at very low speed.

>  The purpose would be for two goals.  One it would make it more logical to 
> implement more sophisticated joint compensation, such as thermal expansion, 
> deflection, and belt stretch.

I think there might be an argument for having backlash compensation in
motion, and addign secondary corrections such as these with the
"offset" component.

>  Second, it would set the stage to be more friendly for dual scale/motor 
> feedback, because it would give control over where the compensation is added 
> in the feedback loop.

This sounds good in principle, but I would need to think about it
rather longer to work out whether it is important in practice.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving backlash comp to HAL module

[Javier Ros]

Just listening.

IMO, this the way to go if one wants a general way to deal with backlash in
general setups.

In some scenarios having access to the kinematics from the module could be
interesting, for example in parallel machines you can have backlash in a
given joint, and the way it plays can be position dependent in a complex
way, it can even be dynamics or kinetostatics dependent.

A fallback behavior for the module so that it offers compatibility with
today's implementation would be nice.

Javier



On Mon, Jul 27, 2015 at 8:29 AM, Gene Heskett  wrote:

>
>
> On Sunday 26 July 2015 23:31:32 Brian wrote:
> > I have had an idea lingering in my head for quite some time now.  How
> > about moving the screw/backlash comp out of motion and implement it
> > with a HAL module.  The purpose would be for two goals.  One it would
> > make it more logical to implement more sophisticated joint
> > compensation, such as thermal expansion, deflection, and belt stretch.
> >  Second, it would set the stage to be more friendly for dual
> > scale/motor feedback, because it would give control over where the
> > compensation is added in the feedback loop.
> >
> > Is this something anybody has thought about?  If it seems like
> > something that would be useful, I'll start a branch and work it out.
> >
> > Brian
>
> It does sound useful, Brian, particularly for thermal expansion as a
> mills z axis heats up.  If a sensor can measure the quill temp, and
> cause a corresponding compensating rise, I could do pcb etching without
> over digging at the end of the job because the spindle has thermally
> grown 3 thousandths.  I can control it now only if I have lots of fans
> blowing on the machine to carry away the heat.
>
> 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 
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers