Daniel Rogge | 11 Jun 2012 23:24

Re: Development question: interpreter's handling of tool changes for lathe

In response to a recent discussion on IRC I wrote a patch that allows for FANUC-style handling of tool
changes in lathe.  I followed the tool change syntax that is outlined by Peter Smid ((CNC Programming
Handbook. 3rd Ed., page 107):

"T01xx - selects the tool mounted in position one and activates geometry offset number one.
Txx01 - selects the wear offset register number one.
Examples:
T0101 for turret station one, applies geometry offset one, applies wear offset one.
T0111 for turret station one, applies geometry offset one, applies wear offset eleven.
The first pair of numbers is always the tool station number and geometry offset, the second pair is the wear
offset register.  For gang tooling, the tool station is irrelevant.  For ATC, the T call must also perform a
tool change request."

With this patch a Txxyy command changes tools, applies the geometry offsets for tool xx, and applies the
wear offsets for tool yy.  Txx just changes tools and applies geometry offsets for tool xx.  The patch is only
being submitted for discussion - to be properly implemented it would require a fundamental change to the
tool table (extra fields for x and z wear offsets.)  For proof of concept I am "borrowing" the U and W fields in
the tool table, something that wouldn't work for lathes with a motorized tailstock or second turret.  I
tried to implement this with minimal change to the code - default functionality is not affected.

To try it out, add the line FEATURES = 64 to the RS274NGC section of your INI file (or modify your FEATURES mask
if you're already using RS274NGC features, documented here: http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_optional_interpreter_features_ini_file_configuration_a_id_sub_ini_features_a)

To answer the question of why you would want to use this feature:

1.       It's a more standard way of calling out tool changes in lathe g code - programs that ran on a
FANUC-controlled lathe require fewer modifications to be compatible with LCNC.

2.       It makes correcting for wear easier (no math on the part of the operator)

(Continue reading)

andy pugh | 21 Jul 2012 21:39
Picon

Re: Development question: interpreter's handling of tool changes for lathe

On 11 June 2012 22:24, Daniel Rogge <DRogge@...> wrote:
> In response to a recent discussion on IRC I wrote a patch that allows for FANUC-style handling of tool
changes in lathe.  I followed the tool change syntax that is outlined by Peter Smid ((CNC Programming
Handbook. 3rd Ed., page 107):

Has anything developed around this? There is a chap on the Forum
wanting the same feature.

--

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Chris Morley | 22 Jul 2012 04:09
Picon
Favicon

Re: Development question: interpreter's handling of tool changes for lathe


I wish for this feature to be added though I have not reviewed the patch.
The 'lathe-style' tool changes / offsets are intuative to me as a cnc lathe is all I ever used.
and it means less editing to use existing files.

Chris M 

> From: bodgesoc@...
> Date: Sat, 21 Jul 2012 20:39:45 +0100
> To: emc-developers@...
> Subject: Re: [Emc-developers] Development question: interpreter's handling of tool changes for lathe
> 
> On 11 June 2012 22:24, Daniel Rogge <DRogge@...> wrote:
> > In response to a recent discussion on IRC I wrote a patch that allows for FANUC-style handling of tool
changes in lathe.  I followed the tool change syntax that is outlined by Peter Smid ((CNC Programming
Handbook. 3rd Ed., page 107):
> 
> Has anything developed around this? There is a chap on the Forum
> wanting the same feature.
> 
> -- 
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
(Continue reading)

Daniel Rogge | 23 Jul 2012 03:35

Re: Development question: interpreter's handling of tool changes for lathe

I submitted a patch that enables Fanuc-style lathe tool change and offset commands to the Sourceforge
tracker feature requests (https://sourceforge.net/tracker/?group_id=6744&atid=356744).  I have
not written the documentation, but if people review and like the patch I will be happy to do so.

Rogge

-----Original Message-----
From: Chris Morley [mailto:chrisinnanaimo@...] 
Sent: Saturday, July 21, 2012 9:09 PM
To: EMC DEV
Subject: Re: [Emc-developers] Development question: interpreter's handling of tool changes for lathe

I wish for this feature to be added though I have not reviewed the patch.
The 'lathe-style' tool changes / offsets are intuative to me as a cnc lathe is all I ever used.
and it means less editing to use existing files.

Chris M 

> From: bodgesoc@...
> Date: Sat, 21 Jul 2012 20:39:45 +0100
> To: emc-developers@...
> Subject: Re: [Emc-developers] Development question: interpreter's handling of tool changes for lathe
> 
> On 11 June 2012 22:24, Daniel Rogge <DRogge@...> wrote:
> > In response to a recent discussion on IRC I wrote a patch that allows for FANUC-style handling of tool
changes in lathe.  I followed the tool change syntax that is outlined by Peter Smid ((CNC Programming
Handbook. 3rd Ed., page 107):
> 
> Has anything developed around this? There is a chap on the Forum
> wanting the same feature.
(Continue reading)

Chris Morley | 29 Oct 2012 09:05
Picon
Favicon

Re: Development question: interpreter's handling of tool changes for lathe


> From: DRogge@...
> To: emc-developers@...
> Date: Sun, 22 Jul 2012 20:35:33 -0500
> Subject: Re: [Emc-developers] Development question: interpreter's handling of tool changes for lathe
> 
> I submitted a patch that enables Fanuc-style lathe tool change and offset commands to the Sourceforge
tracker feature requests (https://sourceforge.net/tracker/?group_id=6744&atid=356744).  I have
not written the documentation, but if people review and like the patch I will be happy to do so.
> 
> Rogge
> 
> 

Daniel

I finally got around to trying this patch.
It doesn't seem to work properly for me.
I tried it on an AXIS lathe sim that I added the feature mask to.
I do understand its a proof of concept.

I had to multiply the tool number by 1000 in the tool file.
eg tool 11 would be 10011
is that by design? seems silly.

It also seems that if the tool is not found that the interpreter forgets
that the original tool is still loaded. I had to reload the last tool to clear things out.

I think an INI switch would be better then the feature mask.
A GUI can easily search for an INI switch keyword.
(Continue reading)

Daniel Rogge | 30 Oct 2012 14:00

Re: Development question: interpreter's handling of tool changes for lathe


>Daniel
>
>I finally got around to trying this patch.
>It doesn't seem to work properly for me.
>I tried it on an AXIS lathe sim that I added the feature mask to.
>I do understand its a proof of concept.
>
>I had to multiply the tool number by 1000 in the tool file.
>eg tool 11 would be 10011
>is that by design? seems silly.
>
>It also seems that if the tool is not found that the interpreter 
>forgets that the original tool is still loaded. I had to reload the last tool to clear things out.
>
>I think an INI switch would be better then the feature mask.
>A GUI can easily search for an INI switch keyword.
>
>I think this could be an excellent feature for lathes.
>
>Chris M
 		 	   		  

Chris,

Yes - the tool table entry for the geometry offset is in (Tool Number) + 10,000.  I agree that it's odd, but it's
the way Fanuc designed it.  Because I was trying to make the interpreter behave the way a Fanuc lathe
interpreter behaves, I figured I'd duplicate the whole enchilada.  It doesn't play too well with
tooledit.tcl - a revision to tooledit.tcl that supported this patch would make this patch easier to use -
perhaps with your GUI expertise this is something you could easily handle.
(Continue reading)

Chris Morley | 31 Oct 2012 07:30
Picon
Favicon

Re: Development question: interpreter's handling of tool changes for lathe


> 
> Yes - the tool table entry for the geometry offset is in (Tool Number) + 10,000.  I agree that it's odd, but
it's the way Fanuc designed it.  Because I was trying to make the interpreter behave the way a Fanuc lathe
interpreter behaves, I figured I'd duplicate the whole enchilada.  It doesn't play too well with
tooledit.tcl - a revision to tooledit.tcl that supported this patch would make this patch easier to use -
perhaps with your GUI expertise this is something you could easily handle.

I would suggest we drop the +10000 - it's not needed and doesn't add anything.
I know nothing of TCL which tooedit.tcl is programmed in so sorry can't help you - though I would upgrade
tooledit_gtk if needed.

Yes I see that adding two wear entries is necessary. I think Michael was the last one to change the tool table
so maybe he could chime in.

> 
> 
> I wasn't sure about the INI file setting versus the features mask - the features mask is already in use for
enabling/disabling other interpreter behavior changes.  I think that an INI setting is easier for the
integrator, but that features mask seemed to be there for a reason.  Comments from others would be appreciated.
> 
> Rogge
>

The feature mask for for remapping code.
Again Michael could chime in to let us know why he chose a mask rather then switch but I'm sure it makes remap
code easier.

Thanks for answering the questions.

(Continue reading)

Michael Haberler | 31 Oct 2012 08:40
Picon
Favicon

Re: Development question: interpreter's handling of tool changes for lathe


Am 31.10.2012 um 07:30 schrieb Chris Morley:
>> 
>> I wasn't sure about the INI file setting versus the features mask - the features mask is already in use for
enabling/disabling other interpreter behavior changes.  I think that an INI setting is easier for the
integrator, but that features mask seemed to be there for a reason.  Comments from others would be appreciated.
>> 
>> Rogge
>> 
> 
> The feature mask for for remapping code.

no, not limited to it.

> Again Michael could chime in to let us know why he chose a mask rather then switch but I'm sure it makes remap
code easier.

it was a stupid idea to start with, and arcane to use. I should replace it by plain ini switches.

-m

> 
> Thanks for answering the questions.
> 
> Chris M
> 
> 		 	   		  
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
(Continue reading)

Michael Haberler | 31 Oct 2012 09:05
Picon
Favicon

Re: Development question: interpreter's handling of tool changes for lathe


Am 31.10.2012 um 07:30 schrieb Chris Morley:

>> Yes - the tool table entry for the geometry offset is in (Tool Number) + 10,000.  I agree that it's odd, but
it's the way Fanuc designed it.  Because I was trying to make the interpreter behave the way a Fanuc lathe
interpreter behaves, I figured I'd duplicate the whole enchilada.  It doesn't play too well with
tooledit.tcl - a revision to tooledit.tcl that supported this patch would make this patch easier to use -
perhaps with your GUI expertise this is something you could easily handle.
> 
> I would suggest we drop the +10000 - it's not needed and doesn't add anything.
> I know nothing of TCL which tooedit.tcl is programmed in so sorry can't help you - though I would upgrade
tooledit_gtk if needed.
> 
> Yes I see that adding two wear entries is necessary. I think Michael was the last one to change the tool table
so maybe he could chime in.

looks like I'm married to the keywords 'tool table', and I'm responsible for Xmas lighting now, too;)

sorry, but I would'nt know what to do in that case. The tt data model (haha) is basically inextensible as it
stands, so kludging is IMO the only option right now.

--

A while ago I suggested a DB approach to the tooltable - which would have allowed for a tool being retrieved
through a view, like including holder and wear offsets.

The reaction basically was 'oh my god, he's taking the grandiose flat text file format from me, we will all
have to run Oracle to start with, yada yada etc etc', so that is where we are - kludging around. 

Maybe it helps if folks think around the corner next time before shooting down an idea if "being used to how it
(Continue reading)

andy pugh | 31 Oct 2012 10:50
Picon

Re: Development question: interpreter's handling of tool changes for lathe

On 31 October 2012 08:05, Michael Haberler <mail17@...> wrote:

> looks like I'm married to the keywords 'tool table', and I'm responsible for Xmas lighting now, too;)

And the music too.

> A while ago I suggested a DB approach to the tooltable - which would have allowed for a tool being retrieved
through a view, like including holder and wear offsets.

I thought this was why Redis had been brought in? Or at least part of
the reason.
I have been expecting a shift to a database tool table to happen in
the future, but when (and who) I have no idea.

I think we need to allow wear offsets, and for slot numbers and tool
numbers to be independent. And once you do that the available number
of tools (as I understand it) becomes very limiting.
We already have people with more tool slots than LinuxCNC can handle.

Once you have the wear offset and geometric offset distinction
implicit in the tool-table then the Fanuc-style tool change option
become less intrusive, I think.

--

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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
(Continue reading)

Michael Haberler | 31 Oct 2012 11:07
Picon
Favicon

Re: Development question: interpreter's handling of tool changes for lathe


Am 31.10.2012 um 10:50 schrieb andy pugh:

> On 31 October 2012 08:05, Michael Haberler <mail17@...> wrote:
> 
>> looks like I'm married to the keywords 'tool table', and I'm responsible for Xmas lighting now, too;)
> 
> And the music too.
> 
>> A while ago I suggested a DB approach to the tooltable - which would have allowed for a tool being retrieved
through a view, like including holder and wear offsets.
> 
> I thought this was why Redis had been brought in? Or at least part of
> the reason.

It was a tradeoff.

Redis brings uniform persistence for global state - which is needed in many corners

MySQL would have brought this and a higher level data manipulation language, at a considerable expense of
installation/running effort

SQLite would brought a similar data manipulation language, but isnt really multiuser capable nor networked

Redis has a lower-level query language than the previous two, but all it needs is a single process, an API
library and a Python binding

the tool wear/tool holder offset thing surely can be done in redis - at that lower level, but first some brave
soul needs to come around, rip out the existing TT, and replace it by redis IO - that I really would like to do
in LinuxCNC3 but I'd be happy to support someone doing it in the current codebase.
(Continue reading)

andy pugh | 31 Oct 2012 13:43
Picon

Re: Development question: interpreter's handling of tool changes for lathe

On 31 October 2012 10:07, Michael Haberler <mail17@...> wrote:

> the tool wear/tool holder offset thing surely can be done in redis - at that lower level, but first some
brave soul needs to come around, rip out the existing TT, and replace it by redis IO

This is sort of on my list of things to look at, eventually, if nobody
competent comes along and beats me to it.

--

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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
andy pugh | 1 Nov 2012 15:19
Picon

Re: Development question: interpreter's handling of tool changes for lathe

On 31 October 2012 12:43, andy pugh <bodgesoc@...> wrote:

>
> This is sort of on my list of things to look at, eventually, if nobody
> competent comes along and beats me to it.
>

So, having started to think about this some more:

Tool number. Can more than one tool of the same tool-number exist? Redis
wants a unique key for each entry. Do we make the key be the tool number,
or keep it separate?
(ie, find the tool with number 1, then return the diameter of that tool, or
simply return the tool:1:diameter?).
I can see how you might want a database of named tools, and just change
their allocated T-number to suit. I can also see that mandating unique
T-numbers would be reasonable.

Pocket Number. I think more than 1 tool can share a pocket (gang tooling,
or alternative tool-sets).
Currently pocket-zero is the spindle. How do we handle tools that are not
currently available? (Pocket "none" might work)

Each tool can probably have geometry and wear offsets in XYZ/UVW. Do we
need geometry offsets in ABC? How about wear offsets?

Diameter/Radius

Front Angle / Back Angle

(Continue reading)

John Thornton | 31 Oct 2012 11:48
Picon

Re: Development question: interpreter's handling of tool changes for lathe

I've been using Sqlite database with Python for a bit and it is not that 
difficult to grasp once you get past the starting gate.

My porch light is out can you fix that too?

John

On 10/31/2012 3:05 AM, Michael Haberler wrote:
> Am 31.10.2012 um 07:30 schrieb Chris Morley:
>
>>> Yes - the tool table entry for the geometry offset is in (Tool Number) + 10,000.  I agree that it's odd, but
it's the way Fanuc designed it.  Because I was trying to make the interpreter behave the way a Fanuc lathe
interpreter behaves, I figured I'd duplicate the whole enchilada.  It doesn't play too well with
tooledit.tcl - a revision to tooledit.tcl that supported this patch would make this patch easier to use -
perhaps with your GUI expertise this is something you could easily handle.
>> I would suggest we drop the +10000 - it's not needed and doesn't add anything.
>> I know nothing of TCL which tooedit.tcl is programmed in so sorry can't help you - though I would upgrade
tooledit_gtk if needed.
>>
>> Yes I see that adding two wear entries is necessary. I think Michael was the last one to change the tool
table so maybe he could chime in.
> looks like I'm married to the keywords 'tool table', and I'm responsible for Xmas lighting now, too;)
>
> sorry, but I would'nt know what to do in that case. The tt data model (haha) is basically inextensible as it
stands, so kludging is IMO the only option right now.
>
> --
>
> A while ago I suggested a DB approach to the tooltable - which would have allowed for a tool being retrieved
through a view, like including holder and wear offsets.
(Continue reading)

Peter C. Wallace | 1 Nov 2012 03:28

Re: ferror calculation incorrect in motion


After spending some forum time trying to help a customer with tuning a torque 
mode drive, I have noticed that ferror is calculated incorrectly and if 
minimized will result in less than optimum actual error.

The error appears to be that ferror is calculated before the trajectory is 
calculated so it always compares the previous waypoint with the current 
(encoder) position. This is easily see by the difference in ferror from the 
PID error (they should be the same)

This causes a value equal to the velocity in machine units per second*servo 
thread_period to be added to the ferror.

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
John Kasunich | 1 Nov 2012 04:05

Re: ferror calculation incorrect in motion


On Wed, Oct 31, 2012, at 10:28 PM, Peter C. Wallace wrote:
> 
> After spending some forum time trying to help a customer with tuning a
> torque 
> mode drive, I have noticed that ferror is calculated incorrectly and if 
> minimized will result in less than optimum actual error.
> 
> The error appears to be that ferror is calculated before the trajectory
> is 
> calculated so it always compares the previous waypoint with the current 
> (encoder) position. 

The PID loop was asked to go to the previous waypoint, and comparing
it with the current position tells you how well it was able to achieve
that goal.

If we were to compare the encoder position with the new waypoint
we would be evaluating the PID loop on how well it hit a target it
hasn't even seen yet.

This is easily see by the difference in ferror from
> the 
> PID error (they should be the same)
> 
> This causes a value equal to the velocity in machine units per
> second*servo 
> thread_period to be added to the ferror.
> 
> 
(Continue reading)

Peter C. Wallace | 1 Nov 2012 04:18

Re: ferror calculation incorrect in motion

On Wed, 31 Oct 2012, John Kasunich wrote:

> Date: Wed, 31 Oct 2012 23:05:30 -0400
> From: John Kasunich <jmkasunich@...>
> Reply-To: EMC developers <emc-developers@...>
> To: emc-developers@...
> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
> 
>
>
> On Wed, Oct 31, 2012, at 10:28 PM, Peter C. Wallace wrote:
>>
>> After spending some forum time trying to help a customer with tuning a
>> torque
>> mode drive, I have noticed that ferror is calculated incorrectly and if
>> minimized will result in less than optimum actual error.
>>
>> The error appears to be that ferror is calculated before the trajectory
>> is
>> calculated so it always compares the previous waypoint with the current
>> (encoder) position.
>
> The PID loop was asked to go to the previous waypoint, and comparing
> it with the current position tells you how well it was able to achieve
> that goal.
>
> If we were to compare the encoder position with the new waypoint
> we would be evaluating the PID loop on how well it hit a target it
> hasn't even seen yet.
>
(Continue reading)

EBo | 1 Nov 2012 04:56

Re: ferror calculation incorrect in motion

On Wed, 31 Oct 2012 19:28:30 -0700 (PDT), Peter C. Wallace wrote:
> After spending some forum time trying to help a customer with tuning
> a torque
> mode drive, I have noticed that ferror is calculated incorrectly and 
> if
> minimized will result in less than optimum actual error.
>
> The error appears to be that ferror is calculated before the 
> trajectory is
> calculated so it always compares the previous waypoint with the 
> current
> (encoder) position. This is easily see by the difference in ferror 
> from the
> PID error (they should be the same)
>
> This causes a value equal to the velocity in machine units per 
> second*servo
> thread_period to be added to the ferror.

interesting.  Can you give your preferred technical reference for the 
PID error calculation for review?  I am sure I can dredge several up, 
but you might have a clearer reference.  Also, have you located the 
offending code?  If so what file and line number?

   Thanks and best regards,

   EBo --

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
(Continue reading)

Peter C. Wallace | 1 Nov 2012 05:22

Re: ferror calculation incorrect in motion

On Wed, 31 Oct 2012, EBo wrote:

> Date: Wed, 31 Oct 2012 22:56:28 -0500
> From: EBo <ebo@...>
> Reply-To: EMC developers <emc-developers@...>
> To: emc-developers@...
> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
> 
> On Wed, 31 Oct 2012 19:28:30 -0700 (PDT), Peter C. Wallace wrote:
>> After spending some forum time trying to help a customer with tuning
>> a torque
>> mode drive, I have noticed that ferror is calculated incorrectly and
>> if
>> minimized will result in less than optimum actual error.
>>
>> The error appears to be that ferror is calculated before the
>> trajectory is
>> calculated so it always compares the previous waypoint with the
>> current
>> (encoder) position. This is easily see by the difference in ferror
>> from the
>> PID error (they should be the same)
>>
>> This causes a value equal to the velocity in machine units per
>> second*servo
>> thread_period to be added to the ferror.
>
> interesting.  Can you give your preferred technical reference for the
> PID error calculation for review?  I am sure I can dredge several up,
> but you might have a clearer reference.  Also, have you located the
(Continue reading)

Andrew | 1 Nov 2012 07:44
Picon

Re: ferror calculation incorrect in motion

2012/11/1 Peter C. Wallace <pcw@...>

> > interesting.  Can you give your preferred technical reference for the
> > PID error calculation for review?  I am sure I can dredge several up,
> > but you might have a clearer reference.  Also, have you located the
> > offending code?  If so what file and line number?
>
> This is not a PID issue. The issue is that the ferror is calculated
> differently than the PID error. So if you tune the PID loop properly the
> ferror is larger then the PID error by an amount proportional to velocity.
>
>
> The normal processing sequence that causes the problem is this: (and all
> the
> HAL files I looked at are arranged this way, that is,
> read/motion/pid/write)
>
> encoders are read to get current position
> motion does ferror calculation (on previous waypoint but current encoder
> position)
> motion calculates next waypoint (TP)
> PID uses difference in motions new waypoint and current encoder position
> to calculate error
>
> The problem is that if the PID loop is tuned so it has close to 0 error
> (its
> error, which is the difference in the new waypoint and the current
> position)
> you will have a calculated ferror thats equal to (velocity * sample period)
> because the ferror was calculated from different data (current encoder
(Continue reading)

EBo | 1 Nov 2012 07:51

Re: ferror calculation incorrect in motion

On Wed, 31 Oct 2012 21:22:58 -0700 (PDT), Peter C. Wallace wrote:
> On Wed, 31 Oct 2012, EBo wrote:
>
>> Date: Wed, 31 Oct 2012 22:56:28 -0500
>> From: EBo <ebo@...>
>> Reply-To: EMC developers <emc-developers@...>
>> To: emc-developers@...
>> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
>>
>> On Wed, 31 Oct 2012 19:28:30 -0700 (PDT), Peter C. Wallace wrote:
>>> After spending some forum time trying to help a customer with 
>>> tuning
>>> a torque
>>> mode drive, I have noticed that ferror is calculated incorrectly 
>>> and
>>> if
>>> minimized will result in less than optimum actual error.
>>>
>>> The error appears to be that ferror is calculated before the
>>> trajectory is
>>> calculated so it always compares the previous waypoint with the
>>> current
>>> (encoder) position. This is easily see by the difference in ferror
>>> from the
>>> PID error (they should be the same)
>>>
>>> This causes a value equal to the velocity in machine units per
>>> second*servo
>>> thread_period to be added to the ferror.
>>
(Continue reading)

andy pugh | 1 Nov 2012 12:23
Picon

Re: ferror calculation incorrect in motion

On 1 November 2012 06:51, EBo <ebo@...> wrote:

>
> OK Now the question is should the ferror be calculated based on the
> current encoder position, or the PID on the previous position?
>

The PID error has a well-defined meaning, and is the difference between the
current command position and the current feedback position.
This will, of necessity, be non zero during any active control. (Because if
PID error is zero, PID output is zero).

I am not sure that the current f-error calculation is wrong. There was a
new command position. The system moved for a servo period. The f-error is
how closely the new position matched the commanded position.

PID-error looks forward, f-error looks backwards.

I think the aim is to reduce F-error rather than PID error, because PID
error is what makes PID output.

--

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
(Continue reading)

Peter C. Wallace | 1 Nov 2012 13:47

Re: ferror calculation incorrect in motion

On Thu, 1 Nov 2012, andy pugh wrote:

> Date: Thu, 1 Nov 2012 11:23:09 +0000
> From: andy pugh <bodgesoc@...>
> Reply-To: EMC developers <emc-developers@...>
> To: EMC developers <emc-developers@...>
> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
> 
> On 1 November 2012 06:51, EBo <ebo@...> wrote:
>
>>
>> OK Now the question is should the ferror be calculated based on the
>> current encoder position, or the PID on the previous position?
>>
>
> The PID error has a well-defined meaning, and is the difference between the
> current command position and the current feedback position.
> This will, of necessity, be non zero during any active control. (Because if
> PID error is zero, PID output is zero).

Not quite true, imagine a well tuned velocity servo running at a high speed 
(with FF1 supplying most of the PID output and the integral term making up the 
rest) this PID loop will have a nearly 0 error between the command and 
feedback (thats its job! and consider that any integral term will force the 
error to 0 eventually during a long slew)

So here we have a well tuned PID loop doing what its asked (minimising the 
error it sees) but ferror is not calculated using the same command and 
feedback so will show a error proportional to velocity (its calculated from 
the current feedback but the previous commanded position)
(Continue reading)

EBo | 1 Nov 2012 14:47

Re: ferror calculation incorrect in motion

This is exactly why I asked for references so we could look at the 
mathematical definitions and either experiment with working machines or 
at least develop a simulation model which stress tests the various 
aspects of the two approaches.  I would rather a fully principled 
approach to this (including reviewing the math) than the current list 
thread direction.

On Thu, 1 Nov 2012 05:47:00 -0700 (PDT), Peter C. Wallace wrote:
> On Thu, 1 Nov 2012, andy pugh wrote:
>
>> Date: Thu, 1 Nov 2012 11:23:09 +0000
>> From: andy pugh <bodgesoc@...>
>> Reply-To: EMC developers <emc-developers@...>
>> To: EMC developers <emc-developers@...>
>> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
>>
>> On 1 November 2012 06:51, EBo <ebo@...> wrote:
>>
>>>
>>> OK Now the question is should the ferror be calculated based on the
>>> current encoder position, or the PID on the previous position?
>>>
>>
>> The PID error has a well-defined meaning, and is the difference 
>> between the
>> current command position and the current feedback position.
>> This will, of necessity, be non zero during any active control. 
>> (Because if
>> PID error is zero, PID output is zero).
>
(Continue reading)

Peter C. Wallace | 1 Nov 2012 15:09

Re: ferror calculation incorrect in motion

On Thu, 1 Nov 2012, EBo wrote:

> Date: Thu, 01 Nov 2012 09:47:30 -0400
> From: EBo <ebo@...>
> Reply-To: EMC developers <emc-developers@...>
> To: emc-developers@...
> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
> 
> This is exactly why I asked for references so we could look at the
> mathematical definitions and either experiment with working machines or
> at least develop a simulation model which stress tests the various
> aspects of the two approaches.  I would rather a fully principled
> approach to this (including reviewing the math) than the current list
> thread direction.

This is really simple

http://en.wikipedia.org/wiki/PID_controller

Note that the first paragraph says:

'A PID controller calculates an "error" value as the difference between a 
measured process variable and a desired setpoint. The controller attempts to 
minimize the error by adjusting the process control inputs.'

This is certainly my understanding (that the task of the PID controller 
is to minimize its input error)

The current situation is that the PID loop and ferror have different setpoints 
but the same "process variable" so if you tune to minimize ferror you need to 
(Continue reading)

EBo | 1 Nov 2012 16:53

Re: ferror calculation incorrect in motion

On Thu, 1 Nov 2012 07:09:56 -0700 (PDT), Peter C. Wallace wrote:
> On Thu, 1 Nov 2012, EBo wrote:
>
>> Date: Thu, 01 Nov 2012 09:47:30 -0400
>> From: EBo <ebo@...>
>> Reply-To: EMC developers <emc-developers@...>
>> To: emc-developers@...
>> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
>>
>> This is exactly why I asked for references so we could look at the
>> mathematical definitions and either experiment with working machines 
>> or
>> at least develop a simulation model which stress tests the various
>> aspects of the two approaches.  I would rather a fully principled
>> approach to this (including reviewing the math) than the current 
>> list
>> thread direction.
>
> This is really simple
>
> http://en.wikipedia.org/wiki/PID_controller
>
> Note that the first paragraph says:
>
> 'A PID controller calculates an "error" value as the difference 
> between a
> measured process variable and a desired setpoint. The controller 
> attempts to
> minimize the error by adjusting the process control inputs.'
>
(Continue reading)

sam sokolik | 1 Nov 2012 17:15

Re: ferror calculation incorrect in motion

so - is the work around - tuning by pid error - then set the F-error 
accordingly? or better yet - monitor the pid error instead of the 
f-error (set it high) and have the pid error trigger the estop? (that 
would be hal doable I think)

sam

On 11/1/2012 9:09 AM, Peter C. Wallace wrote:
> On Thu, 1 Nov 2012, EBo wrote:
>
>> Date: Thu, 01 Nov 2012 09:47:30 -0400
>> From: EBo <ebo@...>
>> Reply-To: EMC developers <emc-developers@...>
>> To: emc-developers@...
>> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
>>
>> This is exactly why I asked for references so we could look at the
>> mathematical definitions and either experiment with working machines or
>> at least develop a simulation model which stress tests the various
>> aspects of the two approaches.  I would rather a fully principled
>> approach to this (including reviewing the math) than the current list
>> thread direction.
> This is really simple
>
> http://en.wikipedia.org/wiki/PID_controller
>
> Note that the first paragraph says:
>
> 'A PID controller calculates an "error" value as the difference between a
> measured process variable and a desired setpoint. The controller attempts to
(Continue reading)

Peter C. Wallace | 1 Nov 2012 17:52

Re: ferror calculation incorrect in motion

On Thu, 1 Nov 2012, sam sokolik wrote:

> Date: Thu, 01 Nov 2012 11:15:34 -0500
> From: sam sokolik <samco@...>
> Reply-To: EMC developers <emc-developers@...>
> To: EMC developers <emc-developers@...>
> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
> 
> so - is the work around - tuning by pid error - then set the F-error
> accordingly? or better yet - monitor the pid error instead of the
> f-error (set it high) and have the pid error trigger the estop? (that
> would be hal doable I think)
>
> sam

Thats what I would do.

On a velocity mode servo and without much integral term the difference in 
tuning for minimum PID error vs the (bogus) ferror will not be much different
(in a pure P + FF1 loop you would probably never notice anything wrong as the 
ferror is nullable with FF1)

if you have tuning perfect relative to ferror your trajectory will be 
one sample (servo thread period) behind a system tuned perfectly to minimize 
the PID error.

Where this bug really causes problems is when you have a decent sized integral 
term so the integral part of the PID loop can track motion and null any PID 
error when slewing, therefore causing a large indicated ferror (that is 
basically impossible to tune out)
(Continue reading)

andy pugh | 1 Nov 2012 18:00
Picon

Re: ferror calculation incorrect in motion

On 1 November 2012 16:52, Peter C. Wallace <pcw@...> wrote:

>
> Where this bug really causes problems is when you have a decent sized
> integral
> term so the integral part of the PID loop can track motion and null any PID
> error when slewing, therefore causing a large indicated ferror (that is
> basically impossible to tune out)

How large is this f-error?
To an extent it is a non-issue as long as it isn't big enough to trip the
f-error fault.
(Tune to minimum PID error, make sure that the f-error limit is big enough)

--

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
Peter C. Wallace | 1 Nov 2012 18:08

Re: ferror calculation incorrect in motion

On Thu, 1 Nov 2012, andy pugh wrote:

> Date: Thu, 1 Nov 2012 17:00:33 +0000
> From: andy pugh <bodgesoc@...>
> Reply-To: EMC developers <emc-developers@...>
> To: EMC developers <emc-developers@...>
> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
> 
> On 1 November 2012 16:52, Peter C. Wallace <pcw@...> wrote:
>
>>
>> Where this bug really causes problems is when you have a decent sized
>> integral
>> term so the integral part of the PID loop can track motion and null any PID
>> error when slewing, therefore causing a large indicated ferror (that is
>> basically impossible to tune out)
>
>
> How large is this f-error?

it is one trajectory step per sample (assuming perfect pid tuning)
so at 600 IPM and 1 KHz servo thread it would be 10 mills (10 I/S * .001 
seconds)

> To an extent it is a non-issue as long as it isn't big enough to trip the
> f-error fault.
> (Tune to minimum PID error, make sure that the f-error limit is big enough)
>
> -- 
> atp
(Continue reading)

Stuart Stevenson | 1 Nov 2012 18:25
Picon

Re: ferror calculation incorrect in motion

Gentlemen,
  What is ferror used for in motion or any calculation? I thought it was
only for human feedback during the tuning phase.

PID error and ferror are not two different things?

Just my two cents.

If ferror can be calculated in advance I would love to see automatic tuning
so I don't need to tune the servos and I will still have no following error.

just my dos centavos

Stuart
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
Peter C. Wallace | 1 Nov 2012 18:36

Re: ferror calculation incorrect in motion

On Thu, 1 Nov 2012, Stuart Stevenson wrote:

> Date: Thu, 1 Nov 2012 12:25:31 -0500
> From: Stuart Stevenson <stustev@...>
> Reply-To: EMC developers <emc-developers@...>
> To: emc-developers@...
> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
> 
> Gentlemen,
>  What is ferror used for in motion or any calculation? I thought it was
> only for human feedback during the tuning phase.
>
> PID error and ferror are not two different things?
>
> Just my two cents.
>
> If ferror can be calculated in advance I would love to see automatic tuning
> so I don't need to tune the servos and I will still have no following error.
>
> just my dos centavos
>
> Stuart

Yes ferror is used:

1. For tuning (badly since 0 ferror is not 0 pid error when in motion)
2. for servo fault detection (too large a ferror causes a fault)

Peter Wallace
Mesa Electronics
(Continue reading)

John Kasunich | 1 Nov 2012 19:19

Re: ferror calculation incorrect in motion


On Thu, Nov 1, 2012, at 01:36 PM, Peter C. Wallace wrote:

> 
> Yes ferror is used:
> 
> 1. For tuning (badly since 0 ferror is not 0 pid error when in motion)
> 2. for servo fault detection (too large a ferror causes a fault)
> 

Strictly speaking, ferror is used within LinuxCNC only for #2.

For tuning, the human tuner chooses to probe some pin with halscope. 
Peter is assuming they choose the ferror pin (and that is a reasonable
assumption).  But it isn't hard-coded that way - they could choose to
probe the PID block's error pin, which would give Peter exactly what he
wants.

I still think that for #2, servo fault detection, it makes sense to
compare the measured position with the last position that the PID loop
was asked to go to.  The alternative is to compare the measured position
with a target position that the PID loop hasn't even seen yet.  How can
you expect the PID loop to follow a command that it hasn't seen?

Of course, the answer to that is "that's what FF1 is for".  By using
FF1, the PID loop is essentially assuming that the machine will keep
moving at the same direction and speed that it was before - so it can
anticipate the next position, even though it hasn't seen it yet.  And as
Peter points out, when properly tuned it can arrange to be at that
position just as the command arrives.  Things probably get a bit more
(Continue reading)

EBo | 1 Nov 2012 22:01

Re: ferror calculation incorrect in motion

On Thu, 01 Nov 2012 14:19:29 -0400, John Kasunich wrote:
> On Thu, Nov 1, 2012, at 01:36 PM, Peter C. Wallace wrote:
>
>>
>> Yes ferror is used:
>>
>> 1. For tuning (badly since 0 ferror is not 0 pid error when in 
>> motion)
>> 2. for servo fault detection (too large a ferror causes a fault)
>>
>
> Strictly speaking, ferror is used within LinuxCNC only for #2.
>
> For tuning, the human tuner chooses to probe some pin with halscope.
> Peter is assuming they choose the ferror pin (and that is a 
> reasonable
> assumption).  But it isn't hard-coded that way - they could choose to
> probe the PID block's error pin, which would give Peter exactly what 
> he
> wants.
>
> I still think that for #2, servo fault detection, it makes sense to
> compare the measured position with the last position that the PID 
> loop
> was asked to go to.  The alternative is to compare the measured 
> position
> with a target position that the PID loop hasn't even seen yet.  How 
> can
> you expect the PID loop to follow a command that it hasn't seen?
>
(Continue reading)

Jon Elson | 2 Nov 2012 16:04

Re: ferror calculation incorrect in motion

On 11/01/2012 12:25 PM, Stuart Stevenson wrote:
> Gentlemen,
>    What is ferror used for in motion or any calculation? I thought it was
> only for human feedback during the tuning phase.
It is used to stop motion when the error is excessive.  On my machines,
it causes an E-stop.
>
> PID error and ferror are not two different things?
Well, I think that's the crux of Peter's complaint, is that they should not
be different, but his claim is that the ARE different.  If you want to
demand tight tolerance for following of the commanded path, then
you really need the PID to be striving to minimize the same thing that
is used to stop the system when it doesn't.

I have not explored this very deeply, but I think Peter may be on
to something, and I believe I have seen the same problem but I didn't
find where it was coming from.

Jon

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
Gene Heskett | 2 Nov 2012 17:07
Favicon

Re: ferror calculation incorrect in motion

On Friday 02 November 2012 11:44:04 Jon Elson did opine:

> On 11/01/2012 12:25 PM, Stuart Stevenson wrote:
> > Gentlemen,
> > 
> >    What is ferror used for in motion or any calculation? I thought it
> >    was
> > 
> > only for human feedback during the tuning phase.
> 
> It is used to stop motion when the error is excessive.  On my machines,
> it causes an E-stop.
> 
> > PID error and ferror are not two different things?
> 
> Well, I think that's the crux of Peter's complaint, is that they should
> not be different, but his claim is that the ARE different.  If you want
> to demand tight tolerance for following of the commanded path, then you
> really need the PID to be striving to minimize the same thing that is
> used to stop the system when it doesn't.
> 
> I have not explored this very deeply, but I think Peter may be on
> to something, and I believe I have seen the same problem but I didn't
> find where it was coming from.
> 
> Jon
> 
I'm not sure, but in my attempts to tune the lathes spindle speed servo, I 
may have some instability created by that, which leads to over correction 
and which is then prevented from slowing down by the rc time constants in 
(Continue reading)

Peter C. Wallace | 2 Nov 2012 17:29

Re: ferror calculation incorrect in motion

On Fri, 2 Nov 2012, Gene Heskett wrote:

> Date: Fri, 2 Nov 2012 12:07:45 -0400
> From: Gene Heskett <gheskett@...>
> Reply-To: EMC developers <emc-developers@...>
> To: emc-developers@...
> Subject: Re: [Emc-developers] ferror calculation incorrect in motion
> 
> On Friday 02 November 2012 11:44:04 Jon Elson did opine:
>
>> On 11/01/2012 12:25 PM, Stuart Stevenson wrote:
>>> Gentlemen,
>>>
>>>    What is ferror used for in motion or any calculation? I thought it
>>>    was
>>>
>>> only for human feedback during the tuning phase.
>>
>> It is used to stop motion when the error is excessive.  On my machines,
>> it causes an E-stop.
>>
>>> PID error and ferror are not two different things?
>>
>> Well, I think that's the crux of Peter's complaint, is that they should
>> not be different, but his claim is that the ARE different.  If you want
>> to demand tight tolerance for following of the commanded path, then you
>> really need the PID to be striving to minimize the same thing that is
>> used to stop the system when it doesn't.
>>
>> I have not explored this very deeply, but I think Peter may be on
(Continue reading)

Gene Heskett | 2 Nov 2012 20:31
Favicon

Re: ferror calculation incorrect in motion

On Friday 02 November 2012 15:13:07 Peter C. Wallace did opine:

> On Fri, 2 Nov 2012, Gene Heskett wrote:
> > Date: Fri, 2 Nov 2012 12:07:45 -0400
> > From: Gene Heskett <gheskett@...>
> > Reply-To: EMC developers <emc-developers@...>
> > To: emc-developers@...
> > Subject: Re: [Emc-developers] ferror calculation incorrect in motion
> > 
> > On Friday 02 November 2012 11:44:04 Jon Elson did opine:
> >> On 11/01/2012 12:25 PM, Stuart Stevenson wrote:
> >>> Gentlemen,
> >>> 
> >>>    What is ferror used for in motion or any calculation? I thought
> >>>    it was
> >>> 
> >>> only for human feedback during the tuning phase.
> >> 
> >> It is used to stop motion when the error is excessive.  On my
> >> machines, it causes an E-stop.
> >> 
> >>> PID error and ferror are not two different things?
> >> 
> >> Well, I think that's the crux of Peter's complaint, is that they
> >> should not be different, but his claim is that the ARE different. 
> >> If you want to demand tight tolerance for following of the commanded
> >> path, then you really need the PID to be striving to minimize the
> >> same thing that is used to stop the system when it doesn't.
> >> 
> >> I have not explored this very deeply, but I think Peter may be on
(Continue reading)

andy pugh | 2 Nov 2012 15:36
Picon

Re: ferror calculation incorrect in motion

I was going to forward a link to this discussion to a control theory
specialist at work.

However, rather bizarrely, it is absent from the archive.

It is possible to search and find individual posts, for example:
http://article.gmane.org/gmane.linux.distributions.emc.devel/8106/
But the link to the rest of the thread returns "no article"

--

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

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d

Gmane