Re: [Emc-users] Following Error Joint 2

[John Dammeyer]

> From: Todd Zuercher [mailto:to...@pgrahamdunn.com]
> The trajectory planner obeys the MAX_ACCELERATION, the problem is when you 
> throw backlash compensation in on top of it.  The
> Step generator then needs the extra headroom in STEPGEN _MAXACCEL to catch up 
> with where the trajectory planner is
> commanding it to be plus the backlash take up move.  So the real problem is 
> that the trajectory planner doesn't account for
> backlash, that is something added in on top of it's calculations.

OK.  That makes sense then.  A short move in the opposite direction and then 
back in the other requires extra time for the backlash compensation but the 
trajectory planner doesn't have that information.  So it blindly assumes that 
the machine has 0 backlash.

Doesn't explain why I've been able to run with too low a setting for 
STEPGEN_MAXACCEL for so long without ever having a Following Error but add the 
weight and it's an instant failure.  Which still suggests Ethernet packets are 
probably also being corrupted.

I'll still change to a CAT7 or CAT8 shielded cable.  Just in case.

Thanks everyone.
John

> 
> Todd Zuercher
> P. Graham Dunn Inc.
> 630 Henry Street
> Dalton, Ohio 44618
> Phone:  (330)828-2105ext. 2031
> 
> -Original Message-
> From: John Dammeyer 
> Sent: Thursday, March 04, 2021 3:41 PM
> To: 'Enhanced Machine Controller (EMC)' 
> Subject: Re: [Emc-users] Following Error Joint 2
> 
> [EXTERNAL EMAIL] Be sure links are safe.
> 
> > From: Les Newell [mailto:les.new...@fastmail.co.uk]
> > > I'm going to guess that low-level I/O error is a general 
> > > _Following_Error_Joint_2_?
> >
> > No. It is a different error. I can't remember the exact wording but I
> > have seen it before.
> >
> > The following error message is correct. With steppers you have two
> > acceleration settings. There is the joint acceleration which is used
> > by the trajectory planner and the stepgen acceleration.
> > STEPGEN_MAXACCEL is used to simulate the physical limits of the
> > stepper and it's load. It's a simulated equivalent to to a servo motor
> > running out of torque. If the trajectory planner commands a higher
> > acceleration than STEPGEN_MAXACCEL the stepgen will not be able to
> > keep up and you get a following error in exactly the same way you would on 
> > a servo system that ran out of torque.
> >
> > Les
> That doesn't explain why, if STEPGEN _MAXACCEL is set to 125% of 
> MAX_ACCELERATION that the trajectory planner or Stepgen tries
> to use a number larger than that.
> 
> It's like saying I know you have a 1 gallon pail but because I have 1 gallon 
> in my pail I'm going to pour it into yours.  Too bad it
> overflows when I pour two of my pails into one of yours.  You should have had 
> a 2 gallon pail.
> 
> What the heck is the point of a parameter like STEPGEN_MAXACCEL or 
> MAX_ACCELRATION if it can be broken so easily.
> 
> Just confused here.
> John
> 
> 
> 
> 
> 
> ___
> 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



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

Re: [Emc-users] Following Error Joint 2

[Peter C. Wallace]

On Thu, 4 Mar 2021, John Dammeyer wrote:


Date: Thu, 4 Mar 2021 12:40:34 -0800
From: John Dammeyer 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "'Enhanced Machine Controller (EMC)'" 
Subject: Re: [Emc-users] Following Error Joint 2


From: Les Newell [mailto:les.new...@fastmail.co.uk]

I'm going to guess that low-level I/O error is a general 
_Following_Error_Joint_2_?


No. It is a different error. I can't remember the exact wording but I
have seen it before.

The following error message is correct. With steppers you have two
acceleration settings. There is the joint acceleration which is used by
the trajectory planner and the stepgen acceleration. STEPGEN_MAXACCEL is
used to simulate the physical limits of the stepper and it's load. It's
a simulated equivalent to to a servo motor running out of torque. If the
trajectory planner commands a higher acceleration than STEPGEN_MAXACCEL
the stepgen will not be able to keep up and you get a following error in
exactly the same way you would on a servo system that ran out of torque.

Les
That doesn't explain why, if STEPGEN _MAXACCEL is set to 125% of 
MAX_ACCELERATION that the trajectory planner or Stepgen tries to use a number 
larger than that.


The trajectory planner has no notion of what the stepgen/physical hardware 
limits are, it just obeys is maxaccel constraints (with the one exception:

if you have backlash compensation enabled, the maximum acceleration during
backlash compensation can be double the joint constraints)

If you set the stepgen maxaccel to 125% of the joint constraint, and you have 
backlash compensation enabled, the stepgen constraint will likely cause a 
following error during backlash compensation moves because the stepgen

cannot follow the requested motion.




It's like saying I know you have a 1 gallon pail but because I have 1 gallon 
in my pail I'm going to pour it into yours.  Too bad it overflows when I pour 
two of my pails into one of yours.  You should have had a 2 gallon pail. What 
the heck is the point of a parameter like STEPGEN_MAXACCEL or MAX_ACCELRATION 
if it can be broken so easily.


Well you cannot ask for more than the physical hardware can produce so there 
need to be bounds. Stepgen Maxaccel is useful for a couple of reasons:


1. If the stepgen is used alone, it be used to bound acceleration
(say for step/dir controlled VFD spindle)
2. It can improve robustness with regard to host servo thread jitter
(that is, it can bound velocity corrections to a value the mechanics can follow)





Just confused here.
John





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



Peter Wallace
Mesa Electronics

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



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

Re: [Emc-users] Following Error Joint 2

[Todd Zuercher]

The trajectory planner obeys the MAX_ACCELERATION, the problem is when you 
throw backlash compensation in on top of it.  The Step generator then needs the 
extra headroom in STEPGEN _MAXACCEL to catch up with where the trajectory 
planner is commanding it to be plus the backlash take up move.  So the real 
problem is that the trajectory planner doesn't account for backlash, that is 
something added in on top of it's calculations.

Todd Zuercher
P. Graham Dunn Inc.
630 Henry Street 
Dalton, Ohio 44618
Phone:  (330)828-2105ext. 2031

-Original Message-
From: John Dammeyer  
Sent: Thursday, March 04, 2021 3:41 PM
To: 'Enhanced Machine Controller (EMC)' 
Subject: Re: [Emc-users] Following Error Joint 2

[EXTERNAL EMAIL] Be sure links are safe.

> From: Les Newell [mailto:les.new...@fastmail.co.uk]
> > I'm going to guess that low-level I/O error is a general 
> > _Following_Error_Joint_2_?
>
> No. It is a different error. I can't remember the exact wording but I 
> have seen it before.
>
> The following error message is correct. With steppers you have two 
> acceleration settings. There is the joint acceleration which is used 
> by the trajectory planner and the stepgen acceleration. 
> STEPGEN_MAXACCEL is used to simulate the physical limits of the 
> stepper and it's load. It's a simulated equivalent to to a servo motor 
> running out of torque. If the trajectory planner commands a higher 
> acceleration than STEPGEN_MAXACCEL the stepgen will not be able to 
> keep up and you get a following error in exactly the same way you would on a 
> servo system that ran out of torque.
>
> Les
That doesn't explain why, if STEPGEN _MAXACCEL is set to 125% of 
MAX_ACCELERATION that the trajectory planner or Stepgen tries to use a number 
larger than that.

It's like saying I know you have a 1 gallon pail but because I have 1 gallon in 
my pail I'm going to pour it into yours.  Too bad it overflows when I pour two 
of my pails into one of yours.  You should have had a 2 gallon pail.

What the heck is the point of a parameter like STEPGEN_MAXACCEL or 
MAX_ACCELRATION if it can be broken so easily.

Just confused here.
John





___
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

Re: [Emc-users] Following Error Joint 2

[John Dammeyer]

> From: Les Newell [mailto:les.new...@fastmail.co.uk]
> > I'm going to guess that low-level I/O error is a general 
> > _Following_Error_Joint_2_?
> 
> No. It is a different error. I can't remember the exact wording but I
> have seen it before.
> 
> The following error message is correct. With steppers you have two
> acceleration settings. There is the joint acceleration which is used by
> the trajectory planner and the stepgen acceleration. STEPGEN_MAXACCEL is
> used to simulate the physical limits of the stepper and it's load. It's
> a simulated equivalent to to a servo motor running out of torque. If the
> trajectory planner commands a higher acceleration than STEPGEN_MAXACCEL
> the stepgen will not be able to keep up and you get a following error in
> exactly the same way you would on a servo system that ran out of torque.
> 
> Les
That doesn't explain why, if STEPGEN _MAXACCEL is set to 125% of 
MAX_ACCELERATION that the trajectory planner or Stepgen tries to use a number 
larger than that.

It's like saying I know you have a 1 gallon pail but because I have 1 gallon in 
my pail I'm going to pour it into yours.  Too bad it overflows when I pour two 
of my pails into one of yours.  You should have had a 2 gallon pail.

What the heck is the point of a parameter like STEPGEN_MAXACCEL or 
MAX_ACCELRATION if it can be broken so easily.

Just confused here.  
John





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

Re: [Emc-users] Following Error Joint 2

[John Dammeyer]

Sam,
That little green machine of yours really hauls.   What pitch screws and motors 
(belts/pulley ratio) are you using on the XYZ axis?
John


> -Original Message-
> From: Sam Sokolik [mailto:samco...@gmail.com]
> Sent: March-04-21 9:59 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Following Error Joint 2
> 
> sorry to throw something else into the mix... I was getting following
> errors without realtime errors on the pie because the default internet time
> sync (timesyncd) sucked..
> 
> timesyncd vs ntp
> 
> https://www.youtube.com/watch?v=RDKaFJmB254
> 
> 
> 
> On Thu, Mar 4, 2021 at 11:37 AM John Dammeyer 
> wrote:
> 
> > > A following error is _expected_ if the stepgen maxaccel parameter is not
> > at
> > > least 2x the joints maxaccel value (or if any stepgen constraint is lower
> > > than what linuxCNC may command it to do) So HAL setup can absolutely
> > cause
> > > following errors.
> > > >
> > > > But if electrical noise from the higher load did cause a damaged UDP
> > packet
> > > > then there's the answer.  A quick change in direction to handle
> > backlash and a
> > > > missing message throws out the timing and results in a following
> > error. John
> > >
> > > You can check this by plotting hm2_7i92.packet-error , but if setting the
> > > stepgen maxaccel value stops the following errors it does not seem
> > likely they
> > > are caused by lost packets. Plotting the following error will also give
> > you some
> > > insight into whats going on.
> > >
> > Hi Peter,
> >
> > One other thing about this.  From
> > http://linuxcnc.org/docs/2.7/html/man/man9/hm2_eth.9.html#PACKET%20LOSS
> >
> > "On the other hand, pid-stepper systems will run properly for extended
> > periods of time with packet loss on the order of .01%, as long as following
> > error is increased enough that having stale position feedback does not
> > trigger a following error. Altering the HAL configuration so that during
> > transient packet loss the pid and motion feedback value is equal to the
> > command value, instead of the stale feedback value, appears to improve
> > tuning. This can be accomplished with a mux2(9) component for each feedback
> > signal, using packet-error as the mux2 sel input."
> >
> > I have no idea from that paragraph how to program that into the HAL file.
> > An example would be handy.  Which feedback signal?  What does the mux
> > output do?
> >
> > From the same section:
> > "When a lost packet is detected, the packet-error pin is asserted in that
> > cycle, the packet-error-level pin is increased, and if it reaches a
> > threshold then a permanent low-level I/O error is signaled."
> >
> > I'm going to guess that low-level I/O error is a general
> > _Following_Error_Joint_2_?
> >
> > Going through the files at
> >
> > https://github.com/LinuxCNC/linuxcnc/tree/master/src/hal/drivers/mesa-hostmot2
> > I can find "packet_error_limit" but nothing that reports the following
> > error.  Still missing something.
> >
> > John
> >
> >
> >
> > ___
> > 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



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

Re: [Emc-users] Following Error Joint 2

[Gene Heskett]

On Thursday 04 March 2021 12:59:28 Sam Sokolik wrote:

> sorry to throw something else into the mix... I was getting following
> errors without realtime errors on the pie because the default internet
> time sync (timesyncd) sucked..
>
> timesyncd vs ntp
>
> https://www.youtube.com/watch?v=RDKaFJmB254

This is moderately well known to pi users, Sam. ;-)

Why raspbian tolerates that is a puzzle.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


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

Re: [Emc-users] Following Error Joint 2

[Les Newell]

I'm going to guess that low-level I/O error is a general 
_Following_Error_Joint_2_?


No. It is a different error. I can't remember the exact wording but I 
have seen it before.


The following error message is correct. With steppers you have two 
acceleration settings. There is the joint acceleration which is used by 
the trajectory planner and the stepgen acceleration. STEPGEN_MAXACCEL is 
used to simulate the physical limits of the stepper and it's load. It's 
a simulated equivalent to to a servo motor running out of torque. If the 
trajectory planner commands a higher acceleration than STEPGEN_MAXACCEL 
the stepgen will not be able to keep up and you get a following error in 
exactly the same way you would on a servo system that ran out of torque.


Les



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

Re: [Emc-users] Following Error Joint 2

[Sam Sokolik]

sorry to throw something else into the mix... I was getting following
errors without realtime errors on the pie because the default internet time
sync (timesyncd) sucked..

timesyncd vs ntp

https://www.youtube.com/watch?v=RDKaFJmB254



On Thu, Mar 4, 2021 at 11:37 AM John Dammeyer 
wrote:

> > A following error is _expected_ if the stepgen maxaccel parameter is not
> at
> > least 2x the joints maxaccel value (or if any stepgen constraint is lower
> > than what linuxCNC may command it to do) So HAL setup can absolutely
> cause
> > following errors.
> > >
> > > But if electrical noise from the higher load did cause a damaged UDP
> packet
> > > then there's the answer.  A quick change in direction to handle
> backlash and a
> > > missing message throws out the timing and results in a following
> error. John
> >
> > You can check this by plotting hm2_7i92.packet-error , but if setting the
> > stepgen maxaccel value stops the following errors it does not seem
> likely they
> > are caused by lost packets. Plotting the following error will also give
> you some
> > insight into whats going on.
> >
> Hi Peter,
>
> One other thing about this.  From
> http://linuxcnc.org/docs/2.7/html/man/man9/hm2_eth.9.html#PACKET%20LOSS
>
> "On the other hand, pid-stepper systems will run properly for extended
> periods of time with packet loss on the order of .01%, as long as following
> error is increased enough that having stale position feedback does not
> trigger a following error. Altering the HAL configuration so that during
> transient packet loss the pid and motion feedback value is equal to the
> command value, instead of the stale feedback value, appears to improve
> tuning. This can be accomplished with a mux2(9) component for each feedback
> signal, using packet−error as the mux2 sel input."
>
> I have no idea from that paragraph how to program that into the HAL file.
> An example would be handy.  Which feedback signal?  What does the mux
> output do?
>
> From the same section:
> "When a lost packet is detected, the packet−error pin is asserted in that
> cycle, the packet−error−level pin is increased, and if it reaches a
> threshold then a permanent low-level I/O error is signaled."
>
> I'm going to guess that low-level I/O error is a general
> _Following_Error_Joint_2_?
>
> Going through the files at
>
> https://github.com/LinuxCNC/linuxcnc/tree/master/src/hal/drivers/mesa-hostmot2
> I can find "packet_error_limit" but nothing that reports the following
> error.  Still missing something.
>
> John
>
>
>
> ___
> 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

Re: [Emc-users] Following Error Joint 2

[John Dammeyer]

> A following error is _expected_ if the stepgen maxaccel parameter is not at
> least 2x the joints maxaccel value (or if any stepgen constraint is lower
> than what linuxCNC may command it to do) So HAL setup can absolutely cause
> following errors.
> >
> > But if electrical noise from the higher load did cause a damaged UDP packet
> > then there's the answer.  A quick change in direction to handle backlash 
> > and a
> > missing message throws out the timing and results in a following error. John
> 
> You can check this by plotting hm2_7i92.packet-error , but if setting the
> stepgen maxaccel value stops the following errors it does not seem likely they
> are caused by lost packets. Plotting the following error will also give you 
> some
> insight into whats going on.
> 
Hi Peter,

One other thing about this.  From 
http://linuxcnc.org/docs/2.7/html/man/man9/hm2_eth.9.html#PACKET%20LOSS

"On the other hand, pid-stepper systems will run properly for extended periods 
of time with packet loss on the order of .01%, as long as following error is 
increased enough that having stale position feedback does not trigger a 
following error. Altering the HAL configuration so that during transient packet 
loss the pid and motion feedback value is equal to the command value, instead 
of the stale feedback value, appears to improve tuning. This can be 
accomplished with a mux2(9) component for each feedback signal, using 
packet−error as the mux2 sel input."

I have no idea from that paragraph how to program that into the HAL file.  An 
example would be handy.  Which feedback signal?  What does the mux output do?

From the same section:
"When a lost packet is detected, the packet−error pin is asserted in that 
cycle, the packet−error−level pin is increased, and if it reaches a threshold 
then a permanent low-level I/O error is signaled." 

I'm going to guess that low-level I/O error is a general 
_Following_Error_Joint_2_?

Going through the files at 
https://github.com/LinuxCNC/linuxcnc/tree/master/src/hal/drivers/mesa-hostmot2
I can find "packet_error_limit" but nothing that reports the following error.  
Still missing something.

John



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

Re: [Emc-users] Following Error Joint 2

[Thaddeus Waldner]

> 
> Perhaps you can explain why that message shows up at all in an open loop 
> situation?  What does the FPGA do that would cause that?  Is there a separate 
> message for missing Ethernet or out of sequence Ethernet packets or is it 
> lumped into Following Error on Joint?

A further question that I have; if lost ethernet packets raise a Following 
Error alarm and does NOT raise a Communication Error alarm, does that always 
mean Packet loss threshold is too lenient and/or FERROR, MIN_FERROR is too 
strict?

I actually had the same issue but more sporadically.. happened about once per 
month. I “fixed" it by commenting out the MIN_FERROR and FERROR . 
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error Joint 2

[John Dammeyer]

> From: Peter C. Wallace [mailto:p...@mesanet.com]
> On Wed, 3 Mar 2021, John Dammeyer wrote:
> 
> > Date: Wed, 3 Mar 2021 23:11:23 -0800
> > From: John Dammeyer 
> >>> The comment on the link about Ethernet latency is what interested me.
> >>> Again if electrical noise causes retries or delays in the Ethernet
> >>> signalling then that could cause this sort of error under heavy load.
> >>>
> >>> John
> > Hi Gene, My AC Servo is run open loop with step/dir.  It's not the Servo
> > Driver that is calling out a following error.  It's LinuxCNC that also has 
> > no
> > clue where the motor actually is unless the AC servo asserts a fault output.
> > And it can't do that because I disconnected it for this test.
> >
> > I don't know how the Ethernet Communications with the MESA 7i92H works.  
> > Page
> > 8 of the user manual says it's UDP which means launch and forget.  The 
> > sender
> > has no way of knowing if the message was received although with only two
> > devices perhaps there's a lower level that does verify that.
> >
> > In either case Page 31 states there are error counters so if there is a 
> > packet
> > error that is detected after a new motion command is issued; like change
> > direction for example.  Then LinuxCNC might well decide to throw up a
> > following error.
> >
> > I will admit that I misread the HAL instructions and had the 
> > MAX_ACCELERATION
> > parameter set to 125% higher.  But with Backlash it was supposed to be 200%.
> > Once I changed that the problem went away.  So bad HAL info generates a
> > following error?  Except that never happened without the extra 92 lbs on the
> > table.
> 
> A following error is _expected_ if the stepgen maxaccel parameter is not at
> least 2x the joints maxaccel value (or if any stepgen constraint is lower
> than what linuxCNC may command it to do) So HAL setup can absolutely cause
> following errors.
Should not the HAL driver code flag that error on start up?  Ie. Pseudo code
IF (BACKLASH <> 0.0) AND (STEPGEN_MAXACCEL < (MAX_ACCLERATION *2) THEN 
  ERROR in Parameter STEPGEN_MAXACCEL.

> >
> > But if electrical noise from the higher load did cause a damaged UDP packet
> > then there's the answer.  A quick change in direction to handle backlash 
> > and a
> > missing message throws out the timing and results in a following error. John
> 
> You can check this by plotting hm2_7i92.packet-error , but if setting the
> stepgen maxaccel value stops the following errors it does not seem likely they
> are caused by lost packets. Plotting the following error will also give you 
> some
> insight into whats going on.
> Peter Wallace
> Mesa Electronics

I'll try that but it doesn't explain why there were no following errors without 
the extra 92 lbs on the table and the incorrect STEPGEN_MAXACCEL.  I believe 
the Following Error Joint 2 message is incorrect.

Perhaps you can explain why that message shows up at all in an open loop 
situation?  What does the FPGA do that would cause that?  Is there a separate 
message for missing Ethernet or out of sequence Ethernet packets or is it 
lumped into Following Error on Joint?

Thanks
John




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

Re: [Emc-users] Following Error Joint 2

[Peter C. Wallace]

On Wed, 3 Mar 2021, John Dammeyer wrote:


Date: Wed, 3 Mar 2021 23:11:23 -0800
From: John Dammeyer 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "'Enhanced Machine Controller (EMC)'" 
Subject: Re: [Emc-users] Following Error Joint 2



The comment on the link about Ethernet latency is what interested me.
Again if electrical noise causes retries or delays in the Ethernet
signalling then that could cause this sort of error under heavy load.

John


And this is what the high frequency gains do, FF2 and Dgain, giving a
boost when the velocity changes. All this assumes that the actual power
available is sufficient to achieve what the controller is asked to make
it do. If the available power sags with the initial accell but the speed
being asked is so high the power available cannot catch it up and is
limiting you then following errors creep into long distance moves.

Hi Gene, My AC Servo is run open loop with step/dir.  It's not the Servo 
Driver that is calling out a following error.  It's LinuxCNC that also has no 
clue where the motor actually is unless the AC servo asserts a fault output. 
And it can't do that because I disconnected it for this test.


I don't know how the Ethernet Communications with the MESA 7i92H works.  Page 
8 of the user manual says it's UDP which means launch and forget.  The sender 
has no way of knowing if the message was received although with only two 
devices perhaps there's a lower level that does verify that.


In either case Page 31 states there are error counters so if there is a packet 
error that is detected after a new motion command is issued; like change 
direction for example.  Then LinuxCNC might well decide to throw up a 
following error.


I will admit that I misread the HAL instructions and had the MAX_ACCELERATION 
parameter set to 125% higher.  But with Backlash it was supposed to be 200%. 
Once I changed that the problem went away.  So bad HAL info generates a 
following error?  Except that never happened without the extra 92 lbs on the 
table.


A following error is _expected_ if the stepgen maxaccel parameter is not at 
least 2x the joints maxaccel value (or if any stepgen constraint is lower

than what linuxCNC may command it to do) So HAL setup can absolutely cause
following errors.


But if electrical noise from the higher load did cause a damaged UDP packet 
then there's the answer.  A quick change in direction to handle backlash and a 
missing message throws out the timing and results in a following error. John


You can check this by plotting hm2_7i92.packet-error , but if setting the 
stepgen maxaccel value stops the following errors it does not seem likely they 
are caused by lost packets. Plotting the following error will also give you some 
insight into whats going on.










Peter Wallace
Mesa Electronics


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

Re: [Emc-users] Following Error Joint 2

[Les Newell]

LinuxCNC is designed to run servos. The stepgens simulate servos and 
will throw a following error if they are unable to generate steps at the 
commanded rate or acceleration. As Peter says, you probably increase 
your stepgen acceleration.


Les

On 04/03/2021 03:17, John Dammeyer wrote:
The Following Error shows up a long way from the home switch. It's the 
PageDown key for moving the Knee closer to the spindle that does it. 
And flipping between the up/down keys with short knee movements with 
the 120 lbs on the table caused the issues.


Recall this is open loop motion with no feedback from the servo other 
than if the servo faults which it doesn't. So weight shouldn't matter. 
Should it? I removed the fault output from the servo drive so it can't 
fault the system.


The comment on the link about Ethernet latency is what interested me. 
Again if electrical noise causes retries or delays in the Ethernet 
signalling then that could cause this sort of error under heavy load.


John




___
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

Re: [Emc-users] Following Error Joint 2

[John Dammeyer]

The load part is interesting.  I wrote this Lazarus program to calculate force 
required based on what was going to be moved and leadscrew pitch etc.  It was 
never finished.  Don't know how accurate it is.
 
Might be worthwhile to add Step Rate and Max Acceleration conversions so the 
numbers could be compared with the INI file parameters in LinuxCNC.
 
I wrote this a while ago and I've forgotten what I was trying to achieve.
John
 
 

 
 
 
> -Original Message-
> From: Thaddeus Waldner [mailto:thadw...@gmail.com]
> Sent: March-03-21 8:19 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Following Error Joint 2
> 
> That was my thinking. It would also need to be a smart motor driver that 
> senses motor rotor position either via encoder or back emf
> and adjusts motor current based on load.
> 
> Thaddeus Waldner
> 
> From: Jon Elson < <mailto:el...@pico-systems.com> el...@pico-systems.com>
> Sent: Wednesday, March 3, 2021 9:57:00 PM
> To: Enhanced Machine Controller (EMC) < 
> <mailto:emc-users@lists.sourceforge.net> emc-users@lists.sourceforge.net>
> Subject: Re: [Emc-users] Following Error Joint 2
> 
> On 03/03/2021 09:17 PM, John Dammeyer wrote:
> >
> > Recall this is open loop motion with no feedback from the
> > servo other than if the servo faults which it doesn't. So
> > weight shouldn't matter. Should it?
> OK,this is EXTREMELY bizarre!  In open loop, how could
> LinuxCNC know anything about the load on the motor?  I think
> maybe it is some kind of electrical noise issue, the
> switching noise from the drive could well increase as motor
> current increases.  Possibly you could put some ferrite
> cores over the motor leads.
> 
> Jon
> 
> 
> ___
> Emc-users mailing list
>  <mailto:Emc-users@lists.sourceforge.net> Emc-users@lists.sourceforge.net
>  <https://lists.sourceforge.net/lists/listinfo/emc-users> 
> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> ___
> Emc-users mailing list
>  <mailto:Emc-users@lists.sourceforge.net> Emc-users@lists.sourceforge.net
>  <https://lists.sourceforge.net/lists/listinfo/emc-users> 
> 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

Re: [Emc-users] Following Error Joint 2

[John Dammeyer]

> >
> > The comment on the link about Ethernet latency is what interested me.
> > Again if electrical noise causes retries or delays in the Ethernet
> > signalling then that could cause this sort of error under heavy load.
> >
> > John
> 
> And this is what the high frequency gains do, FF2 and Dgain, giving a
> boost when the velocity changes. All this assumes that the actual power
> available is sufficient to achieve what the controller is asked to make
> it do. If the available power sags with the initial accell but the speed
> being asked is so high the power available cannot catch it up and is
> limiting you then following errors creep into long distance moves.
> 
Hi Gene,
My AC Servo is run open loop with step/dir.  It's not the Servo Driver that is 
calling out a following error.  It's LinuxCNC that also has no clue where the 
motor actually is unless the AC servo asserts a fault output.  And it can't do 
that because I disconnected it for this test.

I don't know how the Ethernet Communications with the MESA 7i92H works.  Page 8 
of the user manual says it's UDP which means launch and forget.  The sender has 
no way of knowing if the message was received although with only two devices 
perhaps there's a lower level that does verify that.

In either case Page 31 states there are error counters so if there is a packet 
error that is detected after a new motion command is issued; like change 
direction for example.  Then LinuxCNC might well decide to throw up a following 
error.

I will admit that I misread the HAL instructions and had the MAX_ACCELERATION 
parameter set to 125% higher.  But with Backlash it was supposed to be 200%.  
Once I changed that the problem went away.  So bad HAL info generates a 
following error?  Except that never happened without the extra 92 lbs on the 
table.

But if electrical noise from the higher load did cause a damaged UDP packet 
then there's the answer.  A quick change in direction to handle backlash and a 
missing message throws out the timing and results in a following error.
John




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

Re: [Emc-users] Following Error Joint 2

[Gene Heskett]

On Wednesday 03 March 2021 22:17:35 John Dammeyer wrote:

> > -Original Message-
> > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > Sent: March-03-21 6:40 PM
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] Following Error Joint 2
> >
> > On Wednesday 03 March 2021 20:18:44 Gene Heskett wrote:
> > > On Wednesday 03 March 2021 19:42:25 John Dammeyer wrote:
> > > > I made another video with the new 3D printed pulley.  Much
> > > > better balanced as I made the inner hole and outside hub thicker
> > > > and then bored and turned it to the correct diameter and
> > > > concentric with each What I don't understand is why extra weight
> > > > made it show up. The AC Servo Drive is not showing an error and
> > > > motor current rarely goes above 3.5A at 220VAC or about 770W.
> > >
> > > Put the halscope on it, trigger on the home switch, and watch the
> > > control, fb, and error sigs.
> > >
> > > Adjust FF1 for zero error while its cruising, I think it will be
> > > higher than 1.0 Small amounts of FF2 and gain should be
> > > investigated.
> >
> > That should have said "Dgain".
>
> The Following Error shows up a long way from the home switch.  It's
> the PageDown key for moving the Knee closer to the spindle that does
> it.  And flipping between the up/down keys with short knee movements
> with the 120 lbs on the table caused the issues.
>
> Recall this is open loop motion with no feedback from the servo other
> than if the servo faults which it doesn't.  So weight shouldn't
> matter.  Should it?  I removed the fault output from the servo drive
> so it can't fault the system.
>
> The comment on the link about Ethernet latency is what interested me. 
> Again if electrical noise causes retries or delays in the Ethernet
> signalling then that could cause this sort of error under heavy load.
>
> John

And this is what the high frequency gains do, FF2 and Dgain, giving a 
boost when the velocity changes. All this assumes that the actual power 
available is sufficient to achieve what the controller is asked to make 
it do. If the available power sags with the initial accell but the speed 
being asked is so high the power available cannot catch it up and is 
limiting you then following errors creep into long distance moves.

Currently, my plaything is down for mods, like a new cam to switch the 
home switch. I made a ring out of PETG that is about .4mm smaller than 
the flange diameter of this BS-1, to replace the narrow notch I cut in 
the flange for a home switch, and which it will sail right on by at 
search vels above 4 degrees a second. So now, when I get this mod 
finished, waiting the rest of the night for goop to set, but I may 
remake the cam thinner because a trial switch position shows its too 
thick, it 5mm thick and 2 will work the switch, leaving much more real 
estate to glue the switch to.

Take care John.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


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

Re: [Emc-users] Following Error Joint 2

[Thaddeus Waldner]

That was my thinking. It would also need to be a smart motor driver that senses 
motor rotor position either via encoder or back emf and adjusts motor current 
based on load.

Thaddeus Waldner

From: Jon Elson 
Sent: Wednesday, March 3, 2021 9:57:00 PM
To: Enhanced Machine Controller (EMC) 
Subject: Re: [Emc-users] Following Error Joint 2

On 03/03/2021 09:17 PM, John Dammeyer wrote:
>
> Recall this is open loop motion with no feedback from the
> servo other than if the servo faults which it doesn't. So
> weight shouldn't matter. Should it?
OK,this is EXTREMELY bizarre!  In open loop, how could
LinuxCNC know anything about the load on the motor?  I think
maybe it is some kind of electrical noise issue, the
switching noise from the drive could well increase as motor
current increases.  Possibly you could put some ferrite
cores over the motor leads.

Jon


___
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

Re: [Emc-users] Following Error Joint 2

[John Dammeyer]

> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> On 03/03/2021 09:17 PM, John Dammeyer wrote:
> > Recall this is open loop motion with no feedback from the
> > servo other than if the servo faults which it doesn't. So
> > weight shouldn't matter. Should it?

> OK,this is EXTREMELY bizarre!  In open loop, how could
> LinuxCNC know anything about the load on the motor?  I think
> maybe it is some kind of electrical noise issue, the
> switching noise from the drive could well increase as motor
> current increases.  Possibly you could put some ferrite
> cores over the motor leads.
> 
> Jon
Yes again my apologies for not being clear about that.   Step/dir from MESA 
7i92H 

I weighed the mass and it's 118 lbs or so.  I see the motor current climb to 
about 3.5A.  

I agree that I need to add some ferrites on the motor wires.  I've been playing 
with the new motor and a 26 pound vise on the table with no issues for the last 
few weeks.  And then add weight and now errors.   Might just add some ferrites 
to the network cable too.   The AC Servo drive is still sitting out away from 
everything else.  So if the motor itself is radiating it might be picked up by 
one of the other cables.

Baby steps...
John






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

Re: [Emc-users] Following Error Joint 2

[Jon Elson]

On 03/03/2021 09:17 PM, John Dammeyer wrote:


Recall this is open loop motion with no feedback from the 
servo other than if the servo faults which it doesn't. So 
weight shouldn't matter. Should it?
OK,this is EXTREMELY bizarre!  In open loop, how could 
LinuxCNC know anything about the load on the motor?  I think 
maybe it is some kind of electrical noise issue, the 
switching noise from the drive could well increase as motor 
current increases.  Possibly you could put some ferrite 
cores over the motor leads.


Jon


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

Re: [Emc-users] Following Error Joint 2

[John Dammeyer]

> -Original Message-
> From: Gene Heskett [mailto:ghesk...@shentel.net]
> Sent: March-03-21 6:40 PM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Following Error Joint 2
> 
> On Wednesday 03 March 2021 20:18:44 Gene Heskett wrote:
> 
> > On Wednesday 03 March 2021 19:42:25 John Dammeyer wrote:
> > > I made another video with the new 3D printed pulley.  Much better
> > > balanced as I made the inner hole and outside hub thicker and then
> > > bored and turned it to the correct diameter and concentric with each
> > > What I don't understand is why extra weight made it show up. The AC
> > > Servo Drive is not showing an error and motor current rarely goes
> > > above 3.5A at 220VAC or about 770W.
> >
> > Put the halscope on it, trigger on the home switch, and watch the
> > control, fb, and error sigs.
> >
> > Adjust FF1 for zero error while its cruising, I think it will be
> > higher than 1.0 Small amounts of FF2 and gain should be investigated.
> >
> That should have said "Dgain".

The Following Error shows up a long way from the home switch.  It's the 
PageDown key for moving the Knee closer to the spindle that does it.  And 
flipping between the up/down keys with short knee movements with the 120 lbs on 
the table caused the issues.  

Recall this is open loop motion with no feedback from the servo other than if 
the servo faults which it doesn't.  So weight shouldn't matter.  Should it?  I 
removed the fault output from the servo drive so it can't fault the system.

The comment on the link about Ethernet latency is what interested me.  Again if 
electrical noise causes retries or delays in the Ethernet signalling then that 
could cause this sort of error under heavy load.

John




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

Re: [Emc-users] Following Error Joint 2

[Gene Heskett]

On Wednesday 03 March 2021 20:18:44 Gene Heskett wrote:

> On Wednesday 03 March 2021 19:42:25 John Dammeyer wrote:
> > I made another video with the new 3D printed pulley.  Much better
> > balanced as I made the inner hole and outside hub thicker and then
> > bored and turned it to the correct diameter and concentric with each
> > other. Now just shows the Z axis jogging up and down after homing. 
> > I still get the occasional following error but it seems that's a
> > LinuxCNC issue and not the motor.  Or it's electrical noise because
> > the table is loaded down with two vices and a rotary table.  I think
> > close to 200 lbs extra.  I'll have to weigh it.
> > https://youtu.be/AJWI09C6h7U
> >
> > I've read through this thread.  I'm using the MESA 7i92H which is
> > Ethernet based and it's only the PC and the MESA on the network.
> > https://forum.linuxcnc.org/10-advanced-configuration/27171-joint-2-f
> >ol lowing-error?start=10
> >
> > Without all the extra weight on the table there is no following
> > error. If I remove BACKLASH compensation there is no following
> > error.  It appears to go away if I make sure that the
> > STEPGEN_MAXACCEL is set to double the MAX_ACCELERATION.
> >
> > My parameters are
> > P = 1000.0
> > I = 0.0
> > D = 0.0
> > FF0 = 0.0
> > FF1 = 1.0
> > FF2 = 0.0
> > BIAS = 0.0
> > DEADBAND = 0.0
> >
> > PCW on that forum stated that "For PID control of the stepgen, the
> > stepgen is put into velocity mode and a basic velocity mode PID
> > setting is used (FF1 = 1.000, FF2 = .001 (servo period) P= ~150)"
> >
> > My SERVO_PERIOD = 100
> > So should FF2 be set to that?  Or is the stepgen even in velocity
> > mode and does it matter?
> >
> > What I don't understand is why extra weight made it show up. The AC
> > Servo Drive is not showing an error and motor current rarely goes
> > above 3.5A at 220VAC or about 770W.
>
> Put the halscope on it, trigger on the home switch, and watch the
> control, fb, and error sigs.
>
> Adjust FF1 for zero error while its cruising, I think it will be
> higher than 1.0 Small amounts of FF2 and gain should be investigated.
>
That should have said "Dgain".
> > John
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> Cheers, Gene Heskett


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


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

Re: [Emc-users] Following Error Joint 2

[Gene Heskett]

On Wednesday 03 March 2021 19:42:25 John Dammeyer wrote:

> I made another video with the new 3D printed pulley.  Much better
> balanced as I made the inner hole and outside hub thicker and then
> bored and turned it to the correct diameter and concentric with each
> other. Now just shows the Z axis jogging up and down after homing.  I
> still get the occasional following error but it seems that's a
> LinuxCNC issue and not the motor.  Or it's electrical noise because
> the table is loaded down with two vices and a rotary table.  I think
> close to 200 lbs extra.  I'll have to weigh it.
> https://youtu.be/AJWI09C6h7U
>
> I've read through this thread.  I'm using the MESA 7i92H which is
> Ethernet based and it's only the PC and the MESA on the network.
> https://forum.linuxcnc.org/10-advanced-configuration/27171-joint-2-fol
>lowing-error?start=10
>
> Without all the extra weight on the table there is no following error.
>  If I remove BACKLASH compensation there is no following error.  It
> appears to go away if I make sure that the STEPGEN_MAXACCEL is set to
> double the MAX_ACCELERATION.
>
> My parameters are
> P = 1000.0
> I = 0.0
> D = 0.0
> FF0 = 0.0
> FF1 = 1.0
> FF2 = 0.0
> BIAS = 0.0
> DEADBAND = 0.0
>
> PCW on that forum stated that "For PID control of the stepgen, the
> stepgen is put into velocity mode and a basic velocity mode PID
> setting is used (FF1 = 1.000, FF2 = .001 (servo period) P= ~150)"
>
> My SERVO_PERIOD = 100
> So should FF2 be set to that?  Or is the stepgen even in velocity mode
> and does it matter?
>
> What I don't understand is why extra weight made it show up. The AC
> Servo Drive is not showing an error and motor current rarely goes
> above 3.5A at 220VAC or about 770W.
>
Put the halscope on it, trigger on the home switch, and watch the 
control, fb, and error sigs.

Adjust FF1 for zero error while its cruising, I think it will be higher 
than 1.0 Small amounts of FF2 and gain should be investigated.

> John
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> 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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


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

Re: [Emc-users] Following Error Joint 2

[Peter C. Wallace]

On Wed, 3 Mar 2021, John Dammeyer wrote:


Date: Wed, 3 Mar 2021 16:42:25 -0800
From: John Dammeyer 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: [Emc-users] Following Error Joint 2


I made another video with the new 3D printed pulley.  Much better balanced as 
I made the inner hole and outside hub thicker and then bored and turned it to 
the correct diameter and concentric with each other. Now just shows the Z axis 
jogging up and down after homing.  I still get the occasional following error 
but it seems that's a LinuxCNC issue and not the motor.  Or it's electrical 
noise because the table is loaded down with two vices and a rotary table.  I 
think close to 200 lbs extra.  I'll have to weigh it. 
https://youtu.be/AJWI09C6h7U


I've read through this thread.  I'm using the MESA 7i92H which is Ethernet 
based and it's only the PC and the MESA on the network. 
https://forum.linuxcnc.org/10-advanced-configuration/27171-joint-2-following-error?start=10


Without all the extra weight on the table there is no following error.  If I 
remove BACKLASH compensation there is no following error.  It appears to go 
away if I make sure that the STEPGEN_MAXACCEL is set to double the 
MAX_ACCELERATION.


My parameters are
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0

PCW on that forum stated that "For PID control of the stepgen, the stepgen is 
put into velocity mode and a basic velocity mode PID setting is used (FF1 = 
1.000, FF2 = .001 (servo period) P= ~150)"


My SERVO_PERIOD = 100 So should FF2 be set to that?  Or is the stepgen 
even in velocity mode and does it matter?


You need to double the stepgen acceleration settings if backlash
is enabled. That alone may be the reason for your following errors.


Normally FF2=0 is ok unless you are worried about following errors in the u 
region (FF2 should be set for the number of seconds between reading the stepgen 
position and writing the new velocity so normally a very small number)






What I don't understand is why extra weight made it show up. The AC Servo 
Drive is not showing an error and motor current rarely goes above 3.5A at 
220VAC or about 770W.


John


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



Peter Wallace
Mesa Electronics

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



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

[Emc-users] Following Error Joint 2

[John Dammeyer]

 
I made another video with the new 3D printed pulley.  Much better balanced as I 
made the inner hole and outside hub thicker and then bored and turned it to the 
correct diameter and concentric with each other.
Now just shows the Z axis jogging up and down after homing.  I still get the 
occasional following error but it seems that's a LinuxCNC issue and not the 
motor.  Or it's electrical noise because the table is loaded down with two 
vices and a rotary table.  I think close to 200 lbs extra.  I'll have to weigh 
it.
https://youtu.be/AJWI09C6h7U
 
I've read through this thread.  I'm using the MESA 7i92H which is Ethernet 
based and it's only the PC and the MESA on the network.
https://forum.linuxcnc.org/10-advanced-configuration/27171-joint-2-following-error?start=10
 
Without all the extra weight on the table there is no following error.  If I 
remove BACKLASH compensation there is no following error.  It appears to go 
away if I make sure that the STEPGEN_MAXACCEL is set to double the 
MAX_ACCELERATION.
 
My parameters are 
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
 
PCW on that forum stated that "For PID control of the stepgen, the stepgen is 
put into velocity mode and a basic velocity mode PID setting is used (FF1 = 
1.000, FF2 = .001 (servo period) P= ~150)"
 
My SERVO_PERIOD = 100
So should FF2 be set to that?  Or is the stepgen even in velocity mode and does 
it matter?
 
What I don't understand is why extra weight made it show up. The AC Servo Drive 
is not showing an error and motor current rarely goes above 3.5A at 220VAC or 
about 770W.
 
John
 

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

Re: [Emc-users] following error only while homing

[Todd Zuercher]

So I guess my real question is why does it work on one axis and not the next?
What are the chances that switching to Master and dumping the 5 dummy axis 
between joints 2 and 8 might help?

- Original Message -
From: "Todd Zuercher" <zuerc...@embarqmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Friday, June 23, 2017 5:07:42 PM
Subject: Re: [Emc-users] following error only while homing

- Original Message -
From: "Peter C. Wallace" <p...@mesanet.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Friday, June 23, 2017 2:13:45 PM
Subject: Re: [Emc-users] following error only while homing
>
> Yeah, those are ordered wrong so LinuxCNC's patching aound the encoder step 
> on 
> index fails, but I'm not sure they can be ordered correctly with your mixed 
> (base/servo) thread setup. A normal servo thread only config would be 
> something like
>

Here is a halscope plot of the same pins for the Z axis (which rarely messes 
up), compared with the one for the W axis which almost always doesn't work.

In the Z plot the motor-pos-cmd changes on the 1st servo-thread cycle after the 
index.  But the W motor-pos-cmd change is on the next servo-thread after that, 
worse yet the following error for the W appears to be delayed yet another 
thread cycle.

What's up with that?  I am not getting real time delay messages on this machine 
either.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Peter C. Wallace]

On Fri, 23 Jun 2017, Todd  Zuercher wrote:


Date: Fri, 23 Jun 2017 13:20:26 -0400 (EDT)
From: Todd  Zuercher <zuerc...@embarqmail.com>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] following error only while homing

That is what I've suspected but I can't figure out what I have out of place.
I did another screen shot with the position-cmd zoomed in as much as I could 
and keep it on the screen.
It seems that the index enable falls, and the encoder position is reset,then 
the PID gets whacked for one servo period, then the position-cmd is reset.
I have the PID index-enable pin connected, but I not sure it is actually doing 
anything.

Here are my addf orders:



Yeah, those are ordered wrong so LinuxCNC's patching aound the encoder step on 
index fails, but I'm not sure they can be ordered correctly with your mixed 
(base/servo) thread setup. A normal servo thread only config would be 
something like



addf hm2_5i25.0.read  servo-thread
addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf pid.x_vel.do-pid-calcs   servo-thread
addf pid.y_vel.do-pid-calcs   servo-thread
addf pid.z_vel.do-pid-calcs   servo-thread
addf pid.w_vel.do-pid-calcs   servo-thread

addf sum2.0   servo-thread
addf offset.0.update-output   servo-thread
addf offset.0.update-feedback servo-thread
addf mux2.0   servo-thread
addf mux2.1   servo-thread
addf pid.x_pos.do-pid-calcs   servo-thread
addf pid.y_pos.do-pid-calcs   servo-thread
addf pid.z_pos.do-pid-calcs   servo-thread
addf pid.w_pos.do-pid-calcs   servo-thread
#addf hm2_5i25.0.pet_watchdog  servo-thread
addf and2.0   servo-thread
addf hm2_5i25.0.write servo-thread







- Original Message -
From: "Peter C. Wallace" <p...@mesanet.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Friday, June 23, 2017 11:55:58 AM
Subject: Re: [Emc-users] following error only while homing

On Fri, 23 Jun 2017, Todd  Zuercher wrote:


Date: Fri, 23 Jun 2017 11:21:15 -0400 (EDT)
From: Todd  Zuercher <zuerc...@embarqmail.com>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] following error only while homing

Here are links to a halscope screen shot and log file for my servo machine that 
keeps setting following errors on first try homing.

homing-error.png: https://drive.google.com/open?id=0B6U6HVQUOa1fZndtbzVRU1dpOW8
halscope-homing.log: 
https://drive.google.com/open?id=0B6U6HVQUOa1fbmk5S1dKaFBoWWc


Because the scale of the position command is so huge its hard to tell whats
going on but the ferror size matches the encoder step size at index, This (and
the one cycle ferror duration) suggests that there is a thread/operation order
issue of some kind in the hal file.


Peter Wallace
Mesa Electronics


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



Peter Wallace
Mesa Electronics

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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Todd Zuercher]

I just ran another test with the pid index-enable disconnected for that axis, 
and the halscope trace looks exactly the same as it does when it is connected.
Is there something wrong with that pin in the pid component or is this a 
symptom of my ordering problem?

- Original Message -
From: "Todd Zuercher" <zuerc...@embarqmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Friday, June 23, 2017 1:20:26 PM
Subject: Re: [Emc-users] following error only while homing

That is what I've suspected but I can't figure out what I have out of place.
I did another screen shot with the position-cmd zoomed in as much as I could 
and keep it on the screen.
It seems that the index enable falls, and the encoder position is reset,then 
the PID gets whacked for one servo period, then the position-cmd is reset. 
I have the PID index-enable pin connected, but I not sure it is actually doing 
anything.

Here are my addf orders:

addf hm2_5i25.0.read  base-thread
addf pid.x_vel.do-pid-calcs   base-thread
addf pid.y_vel.do-pid-calcs   base-thread
addf pid.z_vel.do-pid-calcs   base-thread
addf pid.w_vel.do-pid-calcs   base-thread
addf hm2_5i25.0.write base-thread

addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf sum2.0   servo-thread
addf offset.0.update-output   servo-thread
addf offset.0.update-feedback servo-thread
addf mux2.0   servo-thread
addf mux2.1   servo-thread
addf pid.x_pos.do-pid-calcs   servo-thread
addf pid.y_pos.do-pid-calcs   servo-thread
addf pid.z_pos.do-pid-calcs   servo-thread
addf pid.w_pos.do-pid-calcs   servo-thread
#addf hm2_5i25.0.pet_watchdog  servo-thread
addf and2.0   servo-thread


- Original Message -
From: "Peter C. Wallace" <p...@mesanet.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Friday, June 23, 2017 11:55:58 AM
Subject: Re: [Emc-users] following error only while homing

On Fri, 23 Jun 2017, Todd  Zuercher wrote:

> Date: Fri, 23 Jun 2017 11:21:15 -0400 (EDT)
> From: Todd  Zuercher <zuerc...@embarqmail.com>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Subject: Re: [Emc-users] following error only while homing
> 
> Here are links to a halscope screen shot and log file for my servo machine 
> that keeps setting following errors on first try homing.
>
> homing-error.png: 
> https://drive.google.com/open?id=0B6U6HVQUOa1fZndtbzVRU1dpOW8
> halscope-homing.log: 
> https://drive.google.com/open?id=0B6U6HVQUOa1fbmk5S1dKaFBoWWc
>
Because the scale of the position command is so huge its hard to tell whats 
going on but the ferror size matches the encoder step size at index, This (and 
the one cycle ferror duration) suggests that there is a thread/operation order 
issue of some kind in the hal file.


Peter Wallace
Mesa Electronics


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Peter C. Wallace]

On Fri, 23 Jun 2017, Todd  Zuercher wrote:


Date: Fri, 23 Jun 2017 11:21:15 -0400 (EDT)
From: Todd  Zuercher <zuerc...@embarqmail.com>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] following error only while homing

Here are links to a halscope screen shot and log file for my servo machine that 
keeps setting following errors on first try homing.

homing-error.png: https://drive.google.com/open?id=0B6U6HVQUOa1fZndtbzVRU1dpOW8
halscope-homing.log: 
https://drive.google.com/open?id=0B6U6HVQUOa1fbmk5S1dKaFBoWWc

Because the scale of the position command is so huge its hard to tell whats 
going on but the ferror size matches the encoder step size at index, This (and 
the one cycle ferror duration) suggests that there is a thread/operation order 
issue of some kind in the hal file.



Peter Wallace
Mesa Electronics


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Todd Zuercher]

Here are links to a halscope screen shot and log file for my servo machine that 
keeps setting following errors on first try homing.

homing-error.png: https://drive.google.com/open?id=0B6U6HVQUOa1fZndtbzVRU1dpOW8
halscope-homing.log: 
https://drive.google.com/open?id=0B6U6HVQUOa1fbmk5S1dKaFBoWWc
 

- Original Message -
From: "Nicklas Karlsson" <nicklas.karlsso...@gmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Thursday, June 22, 2017 1:23:29 PM
Subject: Re: [Emc-users] following error only while homing

On Thu, 22 Jun 2017 00:06:42 +0100
andy pugh <bodge...@gmail.com> wrote:

> On 21 June 2017 at 19:36, Peter C. Wallace <p...@mesanet.com> wrote:
> 
> > The stepgen is not computing following error it just cant be driven by a
> > position command with a stepwise discontinuity and move instantaneously to
> > the new position.
> 
> 
> I think it might be more interesting than that. Stepgen commanded position
> and encoder position track each other very well, and the f-error is small
> throughout.
> 
> https://docs.google.com/spreadsheets/d/1qRVyQWFl4BIsSNKwy9IYsXrmZLTK8vgVVNX4tAuUmJM/edit?usp=sharing

Yes there could be a following error for stepper generator. I think it is like 
this, it output step frequency and number of stepped steps backs so there could 
be a difference. I modified stepper driver for my own card and also discovered 
decimal point is useful then stepping with a frequency close to servo loop. 
Without decimal there will be quite a lot of jitter then switching between 
integer number of steps and decimal point place flanks withing period. It might 
be step speed have been chosen to avoid jitter.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Nicklas Karlsson]

On Thu, 22 Jun 2017 00:06:42 +0100
andy pugh  wrote:

> On 21 June 2017 at 19:36, Peter C. Wallace  wrote:
> 
> > The stepgen is not computing following error it just cant be driven by a
> > position command with a stepwise discontinuity and move instantaneously to
> > the new position.
> 
> 
> I think it might be more interesting than that. Stepgen commanded position
> and encoder position track each other very well, and the f-error is small
> throughout.
> 
> https://docs.google.com/spreadsheets/d/1qRVyQWFl4BIsSNKwy9IYsXrmZLTK8vgVVNX4tAuUmJM/edit?usp=sharing

Yes there could be a following error for stepper generator. I think it is like 
this, it output step frequency and number of stepped steps backs so there could 
be a difference. I modified stepper driver for my own card and also discovered 
decimal point is useful then stepping with a frequency close to servo loop. 
Without decimal there will be quite a lot of jitter then switching between 
integer number of steps and decimal point place flanks withing period. It might 
be step speed have been chosen to avoid jitter.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[andy pugh]

On 22 June 2017 at 00:19, Peter C. Wallace  wrote:

>
> Only because the step was small (because it was probably not the first
> time homed)


Well, yes, but then the question is _why_ it is triggering the f-error
again.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Tom Easterday]

I moved the Z axis down maybe 1/2" before issuing the home command, so it only 
needs to move a short distance to get back to the switch.
-Tom

> On Jun 21, 2017, at 7:19 PM, Peter C. Wallace  wrote:
> 
> Only because the step was small (because it was probably not the first time 
> homed)


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Peter C. Wallace]

On Thu, 22 Jun 2017, andy pugh wrote:


Date: Thu, 22 Jun 2017 00:06:42 +0100
From: andy pugh <bodge...@gmail.com>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] following error only while homing

On 21 June 2017 at 19:36, Peter C. Wallace <p...@mesanet.com> wrote:



The stepgen is not computing following error it just cant be driven by a
position command with a stepwise discontinuity and move instantaneously to
the new position.



I think it might be more interesting than that. Stepgen commanded position
and encoder position track each other very well, and the f-error is small
throughout.

https://docs.google.com/spreadsheets/d/1qRVyQWFl4BIsSNKwy9IYsXrmZLTK8vgVVNX4tAuUmJM/edit?usp=sharing


--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
?? George Fitch, Atlanta Constitution Newspaper, 1916


Only because the step was small (because it was probably not the first time 
homed)


Take a look at axis.0.motor-pos-fb and axis.0.motor-pos-cmd in Sebastians test
on a servo system:

http://highlab.com/~seb/linuxcnc/homing-x-first-time.png

Notice the (probably multi-inch) jump to 0 when index is detected

A velocity mode servo system can cope with this because the PIDs command and 
feedback step at the ~same time (and there are some patches to fix derivative 
related problems in the PID comp when index is detected)


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[andy pugh]

On 21 June 2017 at 19:36, Peter C. Wallace  wrote:

> The stepgen is not computing following error it just cant be driven by a
> position command with a stepwise discontinuity and move instantaneously to
> the new position.


I think it might be more interesting than that. Stepgen commanded position
and encoder position track each other very well, and the f-error is small
throughout.

https://docs.google.com/spreadsheets/d/1qRVyQWFl4BIsSNKwy9IYsXrmZLTK8vgVVNX4tAuUmJM/edit?usp=sharing


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Peter C. Wallace]

On Wed, 21 Jun 2017, Jon Elson wrote:


Date: Wed, 21 Jun 2017 13:22:04 -0500
From: Jon Elson <el...@pico-systems.com>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] following error only while homing

On 06/21/2017 12:15 PM, Peter C. Wallace wrote:


A step in the FB position from the encoder and an attempt at an impossible 
step in the commanded stepgen position...



All the complexities / workrounds of this position step on index could be 
avoided if support for encoder counter that can only clear on index was 
dropped.


OK, so stepgen also can compute following error.  Without encoders, it is 
only possible if steps can't be issued fast enough, but with encoders, then 
there are other ways to create a following error.


Thanks,

Jon



The stepgen is not computing following error it just cant be driven by a 
position command with a stepwise discontinuity and move instantaneously to the 
new position.


A PID run velocity mode stepgen (or normal velocity mode servo) can do this 
because both its feedback (from the encoder) and the commanded position make 
this position step concurrently at index detection so the PID comp just 
carries on as if nothing had happened


The PID derivative terms, FF1 and maybe D are patched at index detection so 
the step in command and FB doesn't cause a one servo cycle long thump





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



Peter Wallace
Mesa Electronics

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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Jon Elson]

On 06/21/2017 12:15 PM, Peter C. Wallace wrote:


A step in the FB position from the encoder and an attempt 
at an impossible step in the commanded stepgen position...



All the complexities / workrounds of this position step on 
index could be avoided if support for encoder counter that 
can only clear on index was dropped.


OK, so stepgen also can compute following error.  Without 
encoders, it is only possible if steps can't be issued fast 
enough, but with encoders, then there are other ways to 
create a following error.


Thanks,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Peter C. Wallace]

On Wed, 21 Jun 2017, Jon Elson wrote:


Date: Wed, 21 Jun 2017 11:48:17 -0500
From: Jon Elson <el...@pico-systems.com>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] following error only while homing

On 06/20/2017 10:15 AM, Sebastian Kuzminsky wrote:

On 06/20/2017 08:52 AM, Chris Radek wrote:

On Tue, Jun 20, 2017 at 09:27:46AM +0100, andy pugh wrote:


Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is


pid's index-enables need to be added to the index-enable nets.


Tom has no pids in this config, he's using position-mode steppers with 
encoders.



Where does the following error come from, then?

Jon


A step in the FB position from the encoder and an attempt at an impossible 
step in the commanded stepgen position...



All the complexities / workrounds of this position step on index could be 
avoided if support for encoder counter that can only clear on index 
was dropped.






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



Peter Wallace
Mesa Electronics

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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Jon Elson]

On 06/20/2017 10:15 AM, Sebastian Kuzminsky wrote:

On 06/20/2017 08:52 AM, Chris Radek wrote:

On Tue, Jun 20, 2017 at 09:27:46AM +0100, andy pugh wrote:


Now, this is perfectly normal, and with a servo / pid 
machine the system
knows to ignore the f-error immediately after an encoder 
reset. What is
puzzling me here is why it isn't working in this case. I 
think it is


pid's index-enables need to be added to the index-enable 
nets.


Tom has no pids in this config, he's using position-mode 
steppers with encoders.



Where does the following error come from, then?

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Peter C. Wallace]

On Wed, 21 Jun 2017, Tom Easterday wrote:


Date: Wed, 21 Jun 2017 10:11:01 -0400
From: Tom Easterday <tom-...@bgp.nu>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] following error only while homing

So is that large jump in f-error caused by the difference between 
axis.2.joint-pos-cmd and axis.2.joint-pos-fb?  There is a small 90 degree 
step in pos-cmd that is not mirrored in pos-fb near the end, in line with 
the spike of f-error.  Is that the cause and why is that there?


Yes, and this is why you cannot do homing to index with a stepgen in position 
mode.


When you home to index the encoder position makes a (possibly large on first 
home after startup) step change when the index is detected. The commanded position
must make a matching step. With a servo system, this does not cause a major 
glitch because the commanded and feedback positions both change at once so

any move in progress just continues, in addition the PID component watches
index-enable so is able to discard the result of the derivative terms (FF1 and 
D) so they dont cause a thump.




This does not work with a stepgen in postion mode because the stepgen gets a 
step change in position command, that it cannot follow, this causes a large

instantaneous following error when index is detected


You can use step motors with an encoder and homing to index, but you must 
setup your hal file differently, running the stepgen in velocity mode and 
using a PID component to close the position loop with the feedback from the 
encoder




-Tom


On Jun 20, 2017, at 8:54 PM, Tom Easterday <tom-...@bgp.nu> wrote:

Well, it has been homed and is searching for index when it faults with the 
following errorbut it isn't homed as I have just killed and restarted 
Linuxcnc.  I then move the Z axis down a little bit and then Home All...
-Tom


On Jun 20, 2017, at 7:54 PM, Peter C. Wallace <p...@mesanet.com> wrote:

This looks like it has been homed before (no large step in encoder position at 
index)
Peter Wallace



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



Peter Wallace
Mesa Electronics

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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Tom Easterday]

So is that large jump in f-error caused by the difference between 
axis.2.joint-pos-cmd and axis.2.joint-pos-fb?  There is a small 90 degree step 
in pos-cmd that is not mirrored in pos-fb near the end, in line with the spike 
of f-error.  Is that the cause and why is that there?

-Tom

> On Jun 20, 2017, at 8:54 PM, Tom Easterday  wrote:
> 
> Well, it has been homed and is searching for index when it faults with the 
> following errorbut it isn't homed as I have just killed and restarted 
> Linuxcnc.  I then move the Z axis down a little bit and then Home All...
> -Tom
> 
>> On Jun 20, 2017, at 7:54 PM, Peter C. Wallace  wrote:
>> 
>> This looks like it has been homed before (no large step in encoder position 
>> at index)
>> Peter Wallace
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Peter C. Wallace]

On Tue, 20 Jun 2017, tom-...@bgp.nu wrote:


Date: Tue, 20 Jun 2017 19:52:13 -0400
From: tom-...@bgp.nu
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] following error only while homing

Here is more zoom fwiw??. http://bgp.nu/~tom/pub/enc-6.png

-Tom


This looks like it has been homed before (no large step in encoder position at 
index)




Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[tom-emc]

Here is more zoom fwiw…. http://bgp.nu/~tom/pub/enc-6.png
-Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Sebastian Kuzminsky]

On 06/20/2017 01:31 PM, tom-...@bgp.nu wrote:

The Halscope trace of:  hm2_7i43.0.stepgen.02.position-cmd,
hm2_7i43.0.encoder.02.position,  hm2_7i43.0.encoder.02.index-enable,
axis.2.home-sw-in with trigger of axis.2.f-errored can be seen here:
http://bgp.nu/~tom/pub/enc2.png


Wel that looks fine.  And my reading of the homing code tells me the 
theory i had (about the jump in the encoder position) is wrong.  I now 
think it's perfectly normal for the .motor-pos-fb pin to jump during 
homing, and the homing logic in Motion compensates for it by changing 
the internal home offset at the same time.


Can you show us a plot like that one, but with axis.2.f-error instead of 
.f-errored, add the axis.2.joint-pos-cmd, .joint-pos-fb, and 
.motor-offset pins, and then zoom in on the f-error event?


Also increase the gain so we can see the fine detail on all the 
position-releated pins (both cmd and fb).


Thanks...


--
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[tom-emc]

Yes, when I re-enable the machine (with or without estop first) I get another 
(immediate) following error.  That is, I understand to make the notification 
itself go away I click the X, but what I am seeing is a perpetual following 
error when re-enabling with each new notification piling up on the lower right 
of Axis display.
-Tom


> On Jun 20, 2017, at 4:03 PM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
> 
> What is strange is that pressing Machine (F2) does not clear the alarm. (That 
> won't close the alarm notification window, you have to click the X on that 
> window to make it go away.)
> 
> - Original Message -
> From: tom-...@bgp.nu
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Tuesday, June 20, 2017 3:31:42 PM
> Subject: Re: [Emc-users] following error only while homing
> 
> You guys are prolific, and I appreciate it!  Thanks for all the input.
> 
> A few things in case it hasn’t been clear...
> 
> 1)  I don’t (currently) have a PID involved at all (position-mode steppers 
> with encoders only).
> 2)  If I set FERROR=2 and MIN_FERROR=1, homing DOES complete successfully.
> 2) Pressing estop after the following error, and then trying to turn Linuxcnc 
> back on from there does NOT help, the error persists.  Only exiting and 
> restarting Linuxcnc clears it.
> 
> The Halscope trace of:  hm2_7i43.0.stepgen.02.position-cmd,  
> hm2_7i43.0.encoder.02.position,  hm2_7i43.0.encoder.02.index-enable,  
> axis.2.home-sw-in with trigger of axis.2.f-errored can be seen here:
> http://bgp.nu/~tom/pub/enc2.png
> 
> I’m happy to help debug a (even obscure) bug if you want, but it sounds like 
> I’d be better off using velocity mode and PID ANYWAY, and so should probably 
> do that instead of what I have.  To wit...
> 
>> On Jun 20, 2017, at 2:04 PM, Sebastian Kuzminsky <s...@highlab.com> wrote:
>> I just pushed a totally untested experimental branch named 
>> "2.7-hm2-encoder-raw-position", try building that, keep home-to-index, link 
>> the new .raw-position pin to axis.*.motor-pos-fb and let us know how that 
>> works.
> 
> If you DO want me to test this, please remind me how I go about 
> getting/building/running it.  It has been a while since I have grabbed 
> branches.  This machine runs from the standard release model, so I assume I 
> will need to incant git (all of which I tend to forget within a week of using 
> it for some reason)…
> 
> -Tom
> 
> 
>> On Jun 20, 2017, at 2:19 PM, andy pugh <bodge...@gmail.com> wrote:
>> 
>> On 20 June 2017 at 18:47, Sebastian Kuzminsky <s...@highlab.com> wrote:
>> 
>>> It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
>>> encoder.
>> 
>> 
>> Does homing use the accumulated counts in the counter after index as part
>> of the homing offset? It feels like it should.
>> If it does, then this might not work.
>> 
>> 
>> -- 
>> atp
>> "A motorcycle is a bicycle with a pandemonium attachment and is designed
>> for the especial use of mechanical geniuses, daredevils and lunatics."
>> — George Fitch, Atlanta Constitution Newspaper, 1916
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Todd Zuercher]

What is strange is that pressing Machine (F2) does not clear the alarm. (That 
won't close the alarm notification window, you have to click the X on that 
window to make it go away.)

- Original Message -
From: tom-...@bgp.nu
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Tuesday, June 20, 2017 3:31:42 PM
Subject: Re: [Emc-users] following error only while homing

You guys are prolific, and I appreciate it!  Thanks for all the input.

A few things in case it hasn’t been clear...

1)  I don’t (currently) have a PID involved at all (position-mode steppers with 
encoders only).
2)  If I set FERROR=2 and MIN_FERROR=1, homing DOES complete successfully.
2) Pressing estop after the following error, and then trying to turn Linuxcnc 
back on from there does NOT help, the error persists.  Only exiting and 
restarting Linuxcnc clears it.

The Halscope trace of:  hm2_7i43.0.stepgen.02.position-cmd,  
hm2_7i43.0.encoder.02.position,  hm2_7i43.0.encoder.02.index-enable,  
axis.2.home-sw-in with trigger of axis.2.f-errored can be seen here:
http://bgp.nu/~tom/pub/enc2.png

I’m happy to help debug a (even obscure) bug if you want, but it sounds like 
I’d be better off using velocity mode and PID ANYWAY, and so should probably do 
that instead of what I have.  To wit...

> On Jun 20, 2017, at 2:04 PM, Sebastian Kuzminsky <s...@highlab.com> wrote:
> I just pushed a totally untested experimental branch named 
> "2.7-hm2-encoder-raw-position", try building that, keep home-to-index, link 
> the new .raw-position pin to axis.*.motor-pos-fb and let us know how that 
> works.

If you DO want me to test this, please remind me how I go about 
getting/building/running it.  It has been a while since I have grabbed 
branches.  This machine runs from the standard release model, so I assume I 
will need to incant git (all of which I tend to forget within a week of using 
it for some reason)…

-Tom


> On Jun 20, 2017, at 2:19 PM, andy pugh <bodge...@gmail.com> wrote:
> 
> On 20 June 2017 at 18:47, Sebastian Kuzminsky <s...@highlab.com> wrote:
> 
>> It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
>> encoder.
> 
> 
> Does homing use the accumulated counts in the counter after index as part
> of the homing offset? It feels like it should.
> If it does, then this might not work.
> 
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is designed
> for the especial use of mechanical geniuses, daredevils and lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[tom-emc]

You guys are prolific, and I appreciate it!  Thanks for all the input.

A few things in case it hasn’t been clear...

1)  I don’t (currently) have a PID involved at all (position-mode steppers with 
encoders only).
2)  If I set FERROR=2 and MIN_FERROR=1, homing DOES complete successfully.
2) Pressing estop after the following error, and then trying to turn Linuxcnc 
back on from there does NOT help, the error persists.  Only exiting and 
restarting Linuxcnc clears it.

The Halscope trace of:  hm2_7i43.0.stepgen.02.position-cmd,  
hm2_7i43.0.encoder.02.position,  hm2_7i43.0.encoder.02.index-enable,  
axis.2.home-sw-in with trigger of axis.2.f-errored can be seen here:
http://bgp.nu/~tom/pub/enc2.png

I’m happy to help debug a (even obscure) bug if you want, but it sounds like 
I’d be better off using velocity mode and PID ANYWAY, and so should probably do 
that instead of what I have.  To wit...

> On Jun 20, 2017, at 2:04 PM, Sebastian Kuzminsky  wrote:
> I just pushed a totally untested experimental branch named 
> "2.7-hm2-encoder-raw-position", try building that, keep home-to-index, link 
> the new .raw-position pin to axis.*.motor-pos-fb and let us know how that 
> works.

If you DO want me to test this, please remind me how I go about 
getting/building/running it.  It has been a while since I have grabbed 
branches.  This machine runs from the standard release model, so I assume I 
will need to incant git (all of which I tend to forget within a week of using 
it for some reason)…

-Tom


> On Jun 20, 2017, at 2:19 PM, andy pugh  wrote:
> 
> On 20 June 2017 at 18:47, Sebastian Kuzminsky  wrote:
> 
>> It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
>> encoder.
> 
> 
> Does homing use the accumulated counts in the counter after index as part
> of the homing offset? It feels like it should.
> If it does, then this might not work.
> 
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is designed
> for the especial use of mechanical geniuses, daredevils and lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[andy pugh]

On 20 June 2017 at 18:47, Sebastian Kuzminsky  wrote:

> It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
> encoder.


Does homing use the accumulated counts in the counter after index as part
of the homing offset? It feels like it should.
If it does, then this might not work.


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[andy pugh]

On 20 June 2017 at 18:47, Sebastian Kuzminsky  wrote:

> It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
> encoder.  We already track .rawcount and compute .count from it, and
> compute .position from .count.


If that is the answer then rawcounts * scale => feedback might be the
answer. With annoying type-conversions.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Sebastian Kuzminsky]

On 06/20/2017 11:47 AM, Sebastian Kuzminsky wrote:

On 06/20/2017 11:39 AM, Sebastian Kuzminsky wrote:

On 06/20/2017 11:34 AM, Sebastian Kuzminsky wrote:

On 06/20/2017 10:51 AM, andy pugh wrote:

On 20 June 2017 at 17:37, Peter C. Wallace  wrote:


I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index


He has hooked up axis.*.motor-pos-cmd to the stepgens' .position-cmd,
and motor-pos-cmd does not jump on home.  His stepgens will see a smooth
curve on their .position-cmd inputs even through all stages of homing.

axis.*.joint-pos-cmd includes the homing offset (and a bunch of other
offsets), so it has that discontinuity, so it's good he's not using
that.



I wonder if the answer might be to only connect the encoder once homed?

ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until
homed, and
only then switch it to the encoder.


That should not be needed.

Our shopbot has a similar setup, and it homes fine every time.  It has a
Mesa FPGA, position-mode steppers, and encoder position feedback.  It
homes to switches, but not to index.


Never mind, I misread what you guys are talking about.  I think Peter
and Andy are right, the encoder's feedback jumps, even though the
position command does not.

Home to switch, not to index, and it should work fine.


It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
encoder.  We already track .rawcount and compute .count from it, and
compute .position from .count.


I just pushed a totally untested experimental branch named 
"2.7-hm2-encoder-raw-position", try building that, keep home-to-index, 
link the new .raw-position pin to axis.*.motor-pos-fb and let us know 
how that works.



--
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Sebastian Kuzminsky]

On 06/20/2017 11:39 AM, Sebastian Kuzminsky wrote:

On 06/20/2017 11:34 AM, Sebastian Kuzminsky wrote:

On 06/20/2017 10:51 AM, andy pugh wrote:

On 20 June 2017 at 17:37, Peter C. Wallace  wrote:


I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index


He has hooked up axis.*.motor-pos-cmd to the stepgens' .position-cmd,
and motor-pos-cmd does not jump on home.  His stepgens will see a smooth
curve on their .position-cmd inputs even through all stages of homing.

axis.*.joint-pos-cmd includes the homing offset (and a bunch of other
offsets), so it has that discontinuity, so it's good he's not using that.



I wonder if the answer might be to only connect the encoder once homed?

ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until
homed, and
only then switch it to the encoder.


That should not be needed.

Our shopbot has a similar setup, and it homes fine every time.  It has a
Mesa FPGA, position-mode steppers, and encoder position feedback.  It
homes to switches, but not to index.


Never mind, I misread what you guys are talking about.  I think Peter
and Andy are right, the encoder's feedback jumps, even though the
position command does not.

Home to switch, not to index, and it should work fine.


It looks like it'd be easy to add a ".raw-position" pin to the hostmot2 
encoder.  We already track .rawcount and compute .count from it, and 
compute .position from .count.



--
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Sebastian Kuzminsky]

On 06/20/2017 11:34 AM, Sebastian Kuzminsky wrote:

On 06/20/2017 10:51 AM, andy pugh wrote:

On 20 June 2017 at 17:37, Peter C. Wallace  wrote:


I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index


He has hooked up axis.*.motor-pos-cmd to the stepgens' .position-cmd,
and motor-pos-cmd does not jump on home.  His stepgens will see a smooth
curve on their .position-cmd inputs even through all stages of homing.

axis.*.joint-pos-cmd includes the homing offset (and a bunch of other
offsets), so it has that discontinuity, so it's good he's not using that.



I wonder if the answer might be to only connect the encoder once homed?

ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until
homed, and
only then switch it to the encoder.


That should not be needed.

Our shopbot has a similar setup, and it homes fine every time.  It has a
Mesa FPGA, position-mode steppers, and encoder position feedback.  It
homes to switches, but not to index.


Never mind, I misread what you guys are talking about.  I think Peter 
and Andy are right, the encoder's feedback jumps, even though the 
position command does not.


Home to switch, not to index, and it should work fine.


--
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Sebastian Kuzminsky]

On 06/20/2017 10:51 AM, andy pugh wrote:

On 20 June 2017 at 17:37, Peter C. Wallace  wrote:


I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index


He has hooked up axis.*.motor-pos-cmd to the stepgens' .position-cmd, 
and motor-pos-cmd does not jump on home.  His stepgens will see a smooth 
curve on their .position-cmd inputs even through all stages of homing.


axis.*.joint-pos-cmd includes the homing offset (and a bunch of other 
offsets), so it has that discontinuity, so it's good he's not using that.




I wonder if the answer might be to only connect the encoder once homed?

ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until homed, and
only then switch it to the encoder.


That should not be needed.

Our shopbot has a similar setup, and it homes fine every time.  It has a 
Mesa FPGA, position-mode steppers, and encoder position feedback.  It 
homes to switches, but not to index.



The ini settings for all joints are of this form:

HOME = 0.000
HOME_OFFSET = -0.260
HOME_SEARCH_VEL = -2.0
HOME_LATCH_VEL = 0.250
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_IS_SHARED = 0


The HAL wiring looks like this:

net x-encoder-pos <= hm2_5i23.0.encoder.01.position
net x-encoder-pos => axis.0.motor-pos-fb

net x-pos-cmd <= axis.0.motor-pos-cmd
net x-pos-cmd => hm2_5i23.0.stepgen.01.position-cmd


Pretty straight forward.

I still want to see the halscope trace.

It might be worth trying (just for debugging purposes) homing to the 
home switch, not the index, since that's the config that works for me. 
If home-to-index is broken we should fix it, and doing that test will 
help tell us if that's the case.


I have a vague memory that there's a fairly long pause at some stage in 
the homing state machine.  I wonder if it was during index homing?  And 
if so, if that's maybe related to this problem?  A halscope trace might 
show us.



--
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[andy pugh]

On 20 June 2017 at 17:37, Peter C. Wallace  wrote:

> I suspect this cannot work the way you have this setup because of the
> instantaneous jump in encoder (feedback) position at index


I wonder if the answer might be to only connect the encoder once homed?

ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until homed, and
only then switch it to the encoder.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Peter C. Wallace]

On Mon, 19 Jun 2017, tom-...@bgp.nu wrote:

Date: Mon, 19 Jun 2017 22:51:59 -0400 From: tom-...@bgp.nu Reply-To: 
"Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net> To: "Enhanced Machine Controller 
(EMC)" <emc-users@lists.sourceforge.net> Subject: [Emc-users] following 
error only while homing


Why would I get a following error only while homing (latest Linuxcnc 2.7.9)? 
I recently added home switches to my machine.  My machine has encoders on 
the steppers on each of the 3 axes so I want to use the index pulse for 
home.  I set up the homing sequence each axis and when I do "Home All" I get 
a following error on my Z axis (first one to home).  I played with all the 
settings and can??t get it to complete unless I set ferror and min_ferror 
very high Also, once there is a following error I can only clear it by 
exiting Linuxcnc and restarting it.  If I just turn it back on, it 
immediately faults again with the same following error.  If I don??t home, 
after restarting Linuxcnc, I can run the Z axis (and X and Y) all day at any 
speed without a following error.


I have tried setting the ferror and min_ferror settings to various reasonable 
values but it didn??t work.  Before adding the switches I had error=0.001 and 
min_ferror=0.0005 and never had a following error appear.  I set ferror to 2 
and min_ferror to 1 (I think those were the values) and it worked but then got 
the following error on the Y axis (the second axis homed).  The values for 
ferror and min_ferror that ??worked?? seem completely unreasonable given I am 
not even moving anywhere near my max velocity during homing.


I have tried changing the sign on the HOME_LATCH_VEL to make it search for 
index in the other direction but the same thing happens.  Below are my 
(current) machine hal and ini.



-Tom



I suspect this cannot work the way you have this setup because of the 
instantaneous jump in encoder (feedback) position at index (and 
cooresponding jump in commanded position) cannot be followed by the

stepgen in position mode. It only happens once because index will not
cause a feedback position jump a second time since its already at 0

One way to make this work is do as others have siggested and run the stepgen 
in velocity mode and run a standard servo velocity PID loop


This has the advantage the you are actually using the encoder feedback
for control rather than just monitoring following error

Peter Wallace
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Gene Heskett]

On Tuesday 20 June 2017 10:03:42 Tom Easterday wrote:

> Is there a parameter I can tweak after it happens in order to clear
> the fault (e.g. can I clear the ferror value) ?  I can then try to
> home again...
>
I've no clue if this would apply to your case or not, Tom.  The mpja dial 
encoders I use for jogging in lieu of manual cranks on this new to me 
Sheldon lathe, are inputting thru a std mesa card encoder, and when the 
jog timeout is finished, 5 seconds after the last "click", I found it 
was needed to hold the encoder on the mesa card in reset, so the next 
time I push the button, to adjust the per step movement or to use it as 
a jog wheel at the last gain setting, the motion induced effectively 
starts at zero = whereever the dial was at when I enabled it.  If I want 
to make a calibrated motion, I set the dial to zero before I push the 
button to enable it, then I can just dial in the motion I need. Wait for 
the 5 second timeout and touch it off at the new position.

But I don't think this is a solution to your problem.

In your case, since zeroing the encoder would move the machine, I believe 
I would AND the home switch input with the index before I sent the home 
switch signal to the motion modules input. And because the index is 
relatively narrow, a slower search velocity might be needed.

That way, motion would be snapshoting the encoders status at the index, 
not on the home switch, but on the next index pulse after the home 
switch activated.  It seems to me that would get rid of a following 
error.  Be sure you debounce the home switch just enough for 
consistency.  And that the home switch is far enough away from any 
mechanical travel stops by a full turn of the motor, and is setup that 
the potentially full turn of the screw, the extra travel needed to find 
the index, will not damage the home switch.  And of course advise the 
list if this latter idea solves the problem.

This advice comes with no warranty of course. :)

> > On Jun 20, 2017, at 9:49 AM, Tom Easterday <tom-...@bgp.nu> wrote:
> >
> > Todd, the ini and hal config were in the first post
> >
> >> On Jun 20, 2017, at 9:21 AM, Todd Zuercher
> >> <zuerc...@embarqmail.com> wrote:
> >>
> >> I just checked my config on my step/dir servo machine, and it is
> >> homing to index on 2 of the axis.  It is not having and problems. 
> >> Maybe you have a configuration problem. Could you post a copy of
> >> your ini and hal file somewhere where we could check it over.
> >>
> >> - Original Message -
> >> From: "Tom Easterday" <tom-...@bgp.nu>
> >> To: "Enhanced Machine Controller (EMC)"
> >> <emc-users@lists.sourceforge.net> Sent: Tuesday, June 20, 2017
> >> 9:00:22 AM
> >> Subject: Re: [Emc-users] following error only while homing
> >>
> >> Andy, you are correct it is related to using index.  Homing works
> >> fine if I don't use index.  The encoder reset makes sense as to why
> >> it CAN happen (but shouldn't be).  Is this just a bug?  I would try
> >> to home a second time but as Todd says, I can't clear the error. 
> >> Linuxcnc shuts off when it happens and pressing on just immediately
> >> faults again.  I have to exit and restart it.
> >>
> >> -Tom
> >>
> >>> On Jun 20, 2017, at 8:13 AM, Todd Zuercher
> >>> <zuerc...@embarqmail.com> wrote:
> >>>
> >>>
> >>> - Original Message -
> >>>
> >>>> From: "andy pugh" <bodge...@gmail.com>
> >>>> To: "Enhanced Machine Controller (EMC)"
> >>>> <emc-users@lists.sourceforge.net> Sent: Tuesday, June 20, 2017
> >>>> 4:27:46 AM
> >>>> Subject: Re: [Emc-users] following error only while homing
> >>>>
> >>>>> On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
> >>>>>
> >>>>> Why would I get a following error only while homing
> >>>>
> >>>> I think it is probably because you are using HOME_USE_INDEX
> >>>> (which will
> >>>> zero the encoder at the index pulse) and feeding the encoder
> >>>> feedback back
> >>>> into LinuxCNC.
> >>>>
> >>>> Now, this is perfectly normal, and with a servo / pid machine the
> >>>> system
> >>>> knows to ignore the f-error immediately after an encoder reset.
> >>>> What is
> >>>> puzzling me here is why it isn't working in this case. I think it
> >>>> is something to do with the fact that your system

Re: [Emc-users] following error only while homing

[Jon Elson]

On 06/20/2017 09:52 AM, Chris Radek wrote:

On Tue, Jun 20, 2017 at 09:27:46AM +0100, andy pugh wrote:

Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is

pid's index-enables need to be added to the index-enable nets.


Well, that certainly will do it!  To explain, index-enable 
is a very funny signal, unlike almost anything else in HAL.
On both the encoder and joint, these are bi-directional 
pins.  When homing or preparing to synch to the spindle, the 
scheme is as follows:


joint sets index-enable to 1
encoder sees index-enable as 1 and enables the encoder 
counter to be zeroed when the index pulse is detected
the encoder component also clears index-enable on that servo 
cycle
joint detects index-enable has been cleared, and ends the 
homing cycle.


So, it is obvious PID also needs to know that on a 
particular servo cycle, the encoder position has made a 
jump, but should not report an error or produce a large PID 
output based on that.  This suppresses errors, but ONLY for 
one servo cycle.


Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Sebastian Kuzminsky]

On 06/19/2017 08:51 PM, tom-...@bgp.nu wrote:

Why would I get a following error only while homing (latest Linuxcnc
2.7.9)?  I recently added home switches to my machine.  My machine
has encoders on the steppers on each of the 3 axes so I want to use
the index pulse for home.  I set up the homing sequence each axis
and when I do "Home All" I get a following error on my Z axis (first
one to home).  I played with all the settings and can’t get it to
complete unless I set ferror and min_ferror very high  Also, once
there is a following error I can only clear it by exiting Linuxcnc
and restarting it.  If I just turn it back on, it immediately faults
again with the same following error.  If I don’t home, after
restarting Linuxcnc, I can run the Z axis (and X and Y) all day at
any speed without a following error.

I have tried setting the ferror and min_ferror settings to various
reasonable values but it didn’t work.   Before adding the switches I
had error=0.001 and min_ferror=0.0005 and never had a following error
appear.  I set ferror to 2 and min_ferror to 1 (I think those were
the values) and it worked but then got the following error on the Y
axis (the second axis homed).  The values for ferror and min_ferror
that “worked” seem completely unreasonable given I am not even moving
anywhere near my max velocity during homing.

I have tried changing the sign on the HOME_LATCH_VEL to make it
search for index in the other direction but the same thing happens.
Below are my (current) machine hal and ini.


Your ini and hal file look right, except that in the hal file all 
stepgens get their .maxvel and .maxaccel from [AXIS_0].  But all your 
[AXIS_*]MAXVEL and MAXACCEL have the same value, so it doesn't affect 
behavior in any way.


I agree with Jon Elson, the next step in debugging this should be to get 
a halscope trace of Z homing and f-erroring, while looking at these pins:


hm2_7i43.0.stepgen.02.position-cmd
hm2_7i43.0.encoder.02.position
hm2_7i43.0.encoder.02.index-enable
axis.2.home-sw-in

Trigger on rising signal on axis.2.f-errored.


--
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Jon Elson]

On 06/20/2017 08:00 AM, Tom Easterday wrote:

Andy, you are correct it is related to using index.  Homing works fine if I 
don't use index.  The encoder reset makes sense as to why it CAN happen (but 
shouldn't be).  Is this just a bug?  I would try to home a second time but as 
Todd says, I can't clear the error.  Linuxcnc shuts off when it happens and 
pressing on just immediately faults again.  I have to exit and restart it.


I think you may need to scope this out with Halscope, 
looking at encoder velocity, ENCODER_INDEX_ENABLE and PID, 
and trigger the trace on amp_enable.  There seem to be two 
problems here.  One is, it should not be tripping a 
following error.  Second, it should not get in a state that 
requires restarting.  Have you tried going to E-stop (F1) 
and then F2?
Going all the way to E-stop really should clear all 
conditions like that.


I'm thinking there may be something wrong in your HAL files 
that is causing the state of the system to get stuck.


Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Jon Elson]

On 06/20/2017 07:13 AM, Todd Zuercher wrote:



I wish that were true.  For some reason my analog servo machine trips up and 
sets a following error on an axis about 25% of the time when trying to home to 
index for the first time after turning on LInuxcnc. (Almost every time since it 
is a 4 axis machine.)  But the alarm is easily cleared, and it always homes 
fine the 2nd try.  I have never been able to figure out why, and no one else 
seems to have been able to replicate the problem.


You should be able to track signals such as encoder position 
and INDEX_ENABLE with Halscope and capture the events when 
this happens.  Homing does cause a discontinuity in the PID, 
which is only masked on following error and P.  The PID 
output gets a bit of a bump due to the D term.  Since it is 
usually moving quite slowly during the final home to index 
move, that shouldn't be enough to trip errors.  You could 
try lowing the final move and see if that helps.  I 
occasionally get a servo amp fault just as the index is 
detected for this reason.  Pretty rare, so I have ignored it.


Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Jon Elson]

On 06/20/2017 03:27 AM, andy pugh wrote:

On 20 June 2017 at 03:51,  wrote:


Why would I get a following error only while homing


I think it is probably because you are using HOME_USE_INDEX (which will
zero the encoder at the index pulse) and feeding the encoder feedback back
into LinuxCNC.

Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for open-loop step
position control but has encoder feedback. However I can't immediately see
why this makes a difference.
I think I have an idea.  If the jump in position is all 
accomplished in one servo cycle, then the jump is handled by 
the logic you describe.  If the jump is spread over a few 
servo cycles or delayed by even one cycle, it will certainly 
cause a following error.  The key is that Tom reports 
setting MIN_FERROR to 1 doesn't suppress the error.  That 
means the position jump is not occurring during the same 
servo cycle where the index pulse is seen.  Is the encoder 
feeding ANYTHING else than LinuxCNC through a simple 
interface? Some external motion controller or drive in the 
path between encoder and LinuxCNC could introduce a delay.

I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.


Yes, since the first home operation should zero the encoder 
counter at the index position, re-doing the home should 
cause a minimal shift in the position.


Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Sebastian Kuzminsky]

On 06/20/2017 08:52 AM, Chris Radek wrote:

On Tue, Jun 20, 2017 at 09:27:46AM +0100, andy pugh wrote:


Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is


pid's index-enables need to be added to the index-enable nets.


Tom has no pids in this config, he's using position-mode steppers with 
encoders.


That's the same setup I use on the shopbot at the local hackspace, and 
it homes fine.  I don't see anything obviously wrong with Tom's config.



--
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[andy pugh]

On 20 June 2017 at 15:52, Chris Radek  wrote:

> > Now, this is perfectly normal, and with a servo / pid machine the system
> > knows to ignore the f-error immediately after an encoder reset. What is
> > puzzling me here is why it isn't working in this case. I think it is
>
> pid's index-enables need to be added to the index-enable nets.


Yes, but, there is no PID here.


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Chris Radek]

On Tue, Jun 20, 2017 at 09:27:46AM +0100, andy pugh wrote:
> 
> Now, this is perfectly normal, and with a servo / pid machine the system
> knows to ignore the f-error immediately after an encoder reset. What is
> puzzling me here is why it isn't working in this case. I think it is

pid's index-enables need to be added to the index-enable nets.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Todd Zuercher]

I don't see why my step/dir servo setup would be any different from a step 
motor + encoder config.  (Obviously, PID settings would be different as they 
would be machine specific.)

One thing to remember the PID loop will likely not be able to correct for a 
stalled step motor.  A few missed steps should be recoverable, but if a step 
motor stalls, the PID loop will command faster and faster velocities, trying to 
catch up to where it thinks it should be, making the stall worse.

- Original Message -
From: "Tom Easterday" <tom-...@bgp.nu>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Tuesday, June 20, 2017 10:15:01 AM
Subject: Re: [Emc-users] following error only while homing

Hmm, it seems like I failed miserably trying to do that when I first built the 
machine (this was my first build and Linuxcnc endeavor) back in 2010.  I have a 
vague recollection someone suggested that as a method of using encoders with 
steppers.  Seems like I spent a bunch of time flailing with getting the pid to 
work and ultimately gave up.  Perhaps I could attempt it again...I assume it 
would be identical to setting up a typical servo system?

> On Jun 20, 2017, at 9:59 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
> 
> What if you set up the stepgens in velocity mode with PID (I understand that 
> it is the better way to do hardware stepping with Mesa cards anyway.)  This 
> is how I have my step/dir servos configured (using the encoder feedback for 
> the PID loop rather than the stepgens dummy position feedback.
> 
> - Original Message -
> From: "Tom Easterday" <tom-...@bgp.nu>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Tuesday, June 20, 2017 9:49:51 AM
> Subject: Re: [Emc-users] following error only while homing
> 
> Todd, the ini and hal config were in the first post
> 
>> On Jun 20, 2017, at 9:21 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
>> 
>> I just checked my config on my step/dir servo machine, and it is homing to 
>> index on 2 of the axis.  It is not having and problems.  Maybe you have a 
>> configuration problem.
>> Could you post a copy of your ini and hal file somewhere where we could 
>> check it over.
>> 
>> - Original Message -
>> From: "Tom Easterday" <tom-...@bgp.nu>
>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>> Sent: Tuesday, June 20, 2017 9:00:22 AM
>> Subject: Re: [Emc-users] following error only while homing
>> 
>> Andy, you are correct it is related to using index.  Homing works fine if I 
>> don't use index.  The encoder reset makes sense as to why it CAN happen (but 
>> shouldn't be).  Is this just a bug?  I would try to home a second time but 
>> as Todd says, I can't clear the error.  Linuxcnc shuts off when it happens 
>> and pressing on just immediately faults again.  I have to exit and restart 
>> it.
>> 
>> -Tom
>> 
>>> On Jun 20, 2017, at 8:13 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
>>> 
>>> 
>>> - Original Message -
>>>> From: "andy pugh" <bodge...@gmail.com>
>>>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>>>> Sent: Tuesday, June 20, 2017 4:27:46 AM
>>>> Subject: Re: [Emc-users] following error only while homing
>>>> 
>>>>> On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
>>>>> 
>>>>> Why would I get a following error only while homing
>>>> 
>>>> 
>>>> I think it is probably because you are using HOME_USE_INDEX (which
>>>> will
>>>> zero the encoder at the index pulse) and feeding the encoder feedback
>>>> back
>>>> into LinuxCNC.
>>>> 
>>>> Now, this is perfectly normal, and with a servo / pid machine the
>>>> system
>>>> knows to ignore the f-error immediately after an encoder reset. What
>>>> is
>>>> puzzling me here is why it isn't working in this case. I think it is
>>>> something to do with the fact that your system is set up for
>>>> open-loop step
>>>> position control but has encoder feedback. However I can't
>>>> immediately see
>>>> why this makes a difference.
>>>> 
>>>> I imagine that if you press the home button again it will home Z
>>>> seamlessly, and then f-error homing the next axis.
>>>> 

Re: [Emc-users] following error only while homing

[Tom Easterday]

Hmm, it seems like I failed miserably trying to do that when I first built the 
machine (this was my first build and Linuxcnc endeavor) back in 2010.  I have a 
vague recollection someone suggested that as a method of using encoders with 
steppers.  Seems like I spent a bunch of time flailing with getting the pid to 
work and ultimately gave up.  Perhaps I could attempt it again...I assume it 
would be identical to setting up a typical servo system?

> On Jun 20, 2017, at 9:59 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
> 
> What if you set up the stepgens in velocity mode with PID (I understand that 
> it is the better way to do hardware stepping with Mesa cards anyway.)  This 
> is how I have my step/dir servos configured (using the encoder feedback for 
> the PID loop rather than the stepgens dummy position feedback.
> 
> - Original Message -
> From: "Tom Easterday" <tom-...@bgp.nu>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Tuesday, June 20, 2017 9:49:51 AM
> Subject: Re: [Emc-users] following error only while homing
> 
> Todd, the ini and hal config were in the first post
> 
>> On Jun 20, 2017, at 9:21 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
>> 
>> I just checked my config on my step/dir servo machine, and it is homing to 
>> index on 2 of the axis.  It is not having and problems.  Maybe you have a 
>> configuration problem.
>> Could you post a copy of your ini and hal file somewhere where we could 
>> check it over.
>> 
>> - Original Message -
>> From: "Tom Easterday" <tom-...@bgp.nu>
>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>> Sent: Tuesday, June 20, 2017 9:00:22 AM
>> Subject: Re: [Emc-users] following error only while homing
>> 
>> Andy, you are correct it is related to using index.  Homing works fine if I 
>> don't use index.  The encoder reset makes sense as to why it CAN happen (but 
>> shouldn't be).  Is this just a bug?  I would try to home a second time but 
>> as Todd says, I can't clear the error.  Linuxcnc shuts off when it happens 
>> and pressing on just immediately faults again.  I have to exit and restart 
>> it.
>> 
>> -Tom
>> 
>>> On Jun 20, 2017, at 8:13 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
>>> 
>>> 
>>> - Original Message -
>>>> From: "andy pugh" <bodge...@gmail.com>
>>>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>>>> Sent: Tuesday, June 20, 2017 4:27:46 AM
>>>> Subject: Re: [Emc-users] following error only while homing
>>>> 
>>>>> On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
>>>>> 
>>>>> Why would I get a following error only while homing
>>>> 
>>>> 
>>>> I think it is probably because you are using HOME_USE_INDEX (which
>>>> will
>>>> zero the encoder at the index pulse) and feeding the encoder feedback
>>>> back
>>>> into LinuxCNC.
>>>> 
>>>> Now, this is perfectly normal, and with a servo / pid machine the
>>>> system
>>>> knows to ignore the f-error immediately after an encoder reset. What
>>>> is
>>>> puzzling me here is why it isn't working in this case. I think it is
>>>> something to do with the fact that your system is set up for
>>>> open-loop step
>>>> position control but has encoder feedback. However I can't
>>>> immediately see
>>>> why this makes a difference.
>>>> 
>>>> I imagine that if you press the home button again it will home Z
>>>> seamlessly, and then f-error homing the next axis.
>>>> 
>>>> 
>>>> --
>>>> atp
>>> 
>>> Andy, 
>>> 
>>> I wish that were true.  For some reason my analog servo machine trips up 
>>> and sets a following error on an axis about 25% of the time when trying to 
>>> home to index for the first time after turning on LInuxcnc. (Almost every 
>>> time since it is a 4 axis machine.)  But the alarm is easily cleared, and 
>>> it always homes fine the 2nd try.  I have never been able to figure out 
>>> why, and no one else seems to have been able to replicate the problem.
>>> 
>>> His problem sounds different since he says can't clear the alarm.
>>> 
>>> My other machine with step/dir servos, doesn't have encoder index t

Re: [Emc-users] following error only while homing

[Tom Easterday]

Is there a parameter I can tweak after it happens in order to clear the fault 
(e.g. can I clear the ferror value) ?  I can then try to home again...

> On Jun 20, 2017, at 9:49 AM, Tom Easterday <tom-...@bgp.nu> wrote:
> 
> Todd, the ini and hal config were in the first post
> 
>> On Jun 20, 2017, at 9:21 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
>> 
>> I just checked my config on my step/dir servo machine, and it is homing to 
>> index on 2 of the axis.  It is not having and problems.  Maybe you have a 
>> configuration problem.
>> Could you post a copy of your ini and hal file somewhere where we could 
>> check it over.
>> 
>> - Original Message -
>> From: "Tom Easterday" <tom-...@bgp.nu>
>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>> Sent: Tuesday, June 20, 2017 9:00:22 AM
>> Subject: Re: [Emc-users] following error only while homing
>> 
>> Andy, you are correct it is related to using index.  Homing works fine if I 
>> don't use index.  The encoder reset makes sense as to why it CAN happen (but 
>> shouldn't be).  Is this just a bug?  I would try to home a second time but 
>> as Todd says, I can't clear the error.  Linuxcnc shuts off when it happens 
>> and pressing on just immediately faults again.  I have to exit and restart 
>> it.
>> 
>> -Tom
>> 
>>> On Jun 20, 2017, at 8:13 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
>>> 
>>> 
>>> - Original Message -
>>>> From: "andy pugh" <bodge...@gmail.com>
>>>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>>>> Sent: Tuesday, June 20, 2017 4:27:46 AM
>>>> Subject: Re: [Emc-users] following error only while homing
>>>> 
>>>>> On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
>>>>> 
>>>>> Why would I get a following error only while homing
>>>> 
>>>> 
>>>> I think it is probably because you are using HOME_USE_INDEX (which
>>>> will
>>>> zero the encoder at the index pulse) and feeding the encoder feedback
>>>> back
>>>> into LinuxCNC.
>>>> 
>>>> Now, this is perfectly normal, and with a servo / pid machine the
>>>> system
>>>> knows to ignore the f-error immediately after an encoder reset. What
>>>> is
>>>> puzzling me here is why it isn't working in this case. I think it is
>>>> something to do with the fact that your system is set up for
>>>> open-loop step
>>>> position control but has encoder feedback. However I can't
>>>> immediately see
>>>> why this makes a difference.
>>>> 
>>>> I imagine that if you press the home button again it will home Z
>>>> seamlessly, and then f-error homing the next axis.
>>>> 
>>>> 
>>>> --
>>>> atp
>>> 
>>> Andy, 
>>> 
>>> I wish that were true.  For some reason my analog servo machine trips up 
>>> and sets a following error on an axis about 25% of the time when trying to 
>>> home to index for the first time after turning on LInuxcnc. (Almost every 
>>> time since it is a 4 axis machine.)  But the alarm is easily cleared, and 
>>> it always homes fine the 2nd try.  I have never been able to figure out 
>>> why, and no one else seems to have been able to replicate the problem.
>>> 
>>> His problem sounds different since he says can't clear the alarm.
>>> 
>>> My other machine with step/dir servos, doesn't have encoder index to home 
>>> to.  But it does home fine without ever setting following errors.
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> 
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>>

Re: [Emc-users] following error only while homing

[Todd Zuercher]

What if you set up the stepgens in velocity mode with PID (I understand that it 
is the better way to do hardware stepping with Mesa cards anyway.)  This is how 
I have my step/dir servos configured (using the encoder feedback for the PID 
loop rather than the stepgens dummy position feedback.

- Original Message -
From: "Tom Easterday" <tom-...@bgp.nu>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Tuesday, June 20, 2017 9:49:51 AM
Subject: Re: [Emc-users] following error only while homing

Todd, the ini and hal config were in the first post

> On Jun 20, 2017, at 9:21 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
> 
> I just checked my config on my step/dir servo machine, and it is homing to 
> index on 2 of the axis.  It is not having and problems.  Maybe you have a 
> configuration problem.
> Could you post a copy of your ini and hal file somewhere where we could check 
> it over.
> 
> - Original Message -
> From: "Tom Easterday" <tom-...@bgp.nu>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Tuesday, June 20, 2017 9:00:22 AM
> Subject: Re: [Emc-users] following error only while homing
> 
> Andy, you are correct it is related to using index.  Homing works fine if I 
> don't use index.  The encoder reset makes sense as to why it CAN happen (but 
> shouldn't be).  Is this just a bug?  I would try to home a second time but as 
> Todd says, I can't clear the error.  Linuxcnc shuts off when it happens and 
> pressing on just immediately faults again.  I have to exit and restart it.
> 
> -Tom
> 
>> On Jun 20, 2017, at 8:13 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
>> 
>> 
>> - Original Message -
>>> From: "andy pugh" <bodge...@gmail.com>
>>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>>> Sent: Tuesday, June 20, 2017 4:27:46 AM
>>> Subject: Re: [Emc-users] following error only while homing
>>> 
>>>> On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
>>>> 
>>>> Why would I get a following error only while homing
>>> 
>>> 
>>> I think it is probably because you are using HOME_USE_INDEX (which
>>> will
>>> zero the encoder at the index pulse) and feeding the encoder feedback
>>> back
>>> into LinuxCNC.
>>> 
>>> Now, this is perfectly normal, and with a servo / pid machine the
>>> system
>>> knows to ignore the f-error immediately after an encoder reset. What
>>> is
>>> puzzling me here is why it isn't working in this case. I think it is
>>> something to do with the fact that your system is set up for
>>> open-loop step
>>> position control but has encoder feedback. However I can't
>>> immediately see
>>> why this makes a difference.
>>> 
>>> I imagine that if you press the home button again it will home Z
>>> seamlessly, and then f-error homing the next axis.
>>> 
>>> 
>>> --
>>> atp
>> 
>> Andy, 
>> 
>> I wish that were true.  For some reason my analog servo machine trips up and 
>> sets a following error on an axis about 25% of the time when trying to home 
>> to index for the first time after turning on LInuxcnc. (Almost every time 
>> since it is a 4 axis machine.)  But the alarm is easily cleared, and it 
>> always homes fine the 2nd try.  I have never been able to figure out why, 
>> and no one else seems to have been able to replicate the problem.
>> 
>> His problem sounds different since he says can't clear the alarm.
>> 
>> My other machine with step/dir servos, doesn't have encoder index to home 
>> to.  But it does home fine without ever setting following errors.
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinf

Re: [Emc-users] following error only while homing

[Tom Easterday]

Todd, the ini and hal config were in the first post

> On Jun 20, 2017, at 9:21 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
> 
> I just checked my config on my step/dir servo machine, and it is homing to 
> index on 2 of the axis.  It is not having and problems.  Maybe you have a 
> configuration problem.
> Could you post a copy of your ini and hal file somewhere where we could check 
> it over.
> 
> - Original Message -
> From: "Tom Easterday" <tom-...@bgp.nu>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Tuesday, June 20, 2017 9:00:22 AM
> Subject: Re: [Emc-users] following error only while homing
> 
> Andy, you are correct it is related to using index.  Homing works fine if I 
> don't use index.  The encoder reset makes sense as to why it CAN happen (but 
> shouldn't be).  Is this just a bug?  I would try to home a second time but as 
> Todd says, I can't clear the error.  Linuxcnc shuts off when it happens and 
> pressing on just immediately faults again.  I have to exit and restart it.
> 
> -Tom
> 
>> On Jun 20, 2017, at 8:13 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
>> 
>> 
>> - Original Message -
>>> From: "andy pugh" <bodge...@gmail.com>
>>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>>> Sent: Tuesday, June 20, 2017 4:27:46 AM
>>> Subject: Re: [Emc-users] following error only while homing
>>> 
>>>> On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
>>>> 
>>>> Why would I get a following error only while homing
>>> 
>>> 
>>> I think it is probably because you are using HOME_USE_INDEX (which
>>> will
>>> zero the encoder at the index pulse) and feeding the encoder feedback
>>> back
>>> into LinuxCNC.
>>> 
>>> Now, this is perfectly normal, and with a servo / pid machine the
>>> system
>>> knows to ignore the f-error immediately after an encoder reset. What
>>> is
>>> puzzling me here is why it isn't working in this case. I think it is
>>> something to do with the fact that your system is set up for
>>> open-loop step
>>> position control but has encoder feedback. However I can't
>>> immediately see
>>> why this makes a difference.
>>> 
>>> I imagine that if you press the home button again it will home Z
>>> seamlessly, and then f-error homing the next axis.
>>> 
>>> 
>>> --
>>> atp
>> 
>> Andy, 
>> 
>> I wish that were true.  For some reason my analog servo machine trips up and 
>> sets a following error on an axis about 25% of the time when trying to home 
>> to index for the first time after turning on LInuxcnc. (Almost every time 
>> since it is a 4 axis machine.)  But the alarm is easily cleared, and it 
>> always homes fine the 2nd try.  I have never been able to figure out why, 
>> and no one else seems to have been able to replicate the problem.
>> 
>> His problem sounds different since he says can't clear the alarm.
>> 
>> My other machine with step/dir servos, doesn't have encoder index to home 
>> to.  But it does home fine without ever setting following errors.
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Todd Zuercher]

I just checked my config on my step/dir servo machine, and it is homing to 
index on 2 of the axis.  It is not having and problems.  Maybe you have a 
configuration problem.
Could you post a copy of your ini and hal file somewhere where we could check 
it over.

- Original Message -
From: "Tom Easterday" <tom-...@bgp.nu>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Tuesday, June 20, 2017 9:00:22 AM
Subject: Re: [Emc-users] following error only while homing

Andy, you are correct it is related to using index.  Homing works fine if I 
don't use index.  The encoder reset makes sense as to why it CAN happen (but 
shouldn't be).  Is this just a bug?  I would try to home a second time but as 
Todd says, I can't clear the error.  Linuxcnc shuts off when it happens and 
pressing on just immediately faults again.  I have to exit and restart it.

-Tom

> On Jun 20, 2017, at 8:13 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
> 
> 
> - Original Message -
>> From: "andy pugh" <bodge...@gmail.com>
>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>> Sent: Tuesday, June 20, 2017 4:27:46 AM
>> Subject: Re: [Emc-users] following error only while homing
>> 
>>> On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
>>> 
>>> Why would I get a following error only while homing
>> 
>> 
>> I think it is probably because you are using HOME_USE_INDEX (which
>> will
>> zero the encoder at the index pulse) and feeding the encoder feedback
>> back
>> into LinuxCNC.
>> 
>> Now, this is perfectly normal, and with a servo / pid machine the
>> system
>> knows to ignore the f-error immediately after an encoder reset. What
>> is
>> puzzling me here is why it isn't working in this case. I think it is
>> something to do with the fact that your system is set up for
>> open-loop step
>> position control but has encoder feedback. However I can't
>> immediately see
>> why this makes a difference.
>> 
>> I imagine that if you press the home button again it will home Z
>> seamlessly, and then f-error homing the next axis.
>> 
>> 
>> --
>> atp
> 
> Andy, 
> 
> I wish that were true.  For some reason my analog servo machine trips up and 
> sets a following error on an axis about 25% of the time when trying to home 
> to index for the first time after turning on LInuxcnc. (Almost every time 
> since it is a 4 axis machine.)  But the alarm is easily cleared, and it 
> always homes fine the 2nd try.  I have never been able to figure out why, and 
> no one else seems to have been able to replicate the problem.
> 
> His problem sounds different since he says can't clear the alarm.
> 
> My other machine with step/dir servos, doesn't have encoder index to home to. 
>  But it does home fine without ever setting following errors.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Tom Easterday]

Andy, you are correct it is related to using index.  Homing works fine if I 
don't use index.  The encoder reset makes sense as to why it CAN happen (but 
shouldn't be).  Is this just a bug?  I would try to home a second time but as 
Todd says, I can't clear the error.  Linuxcnc shuts off when it happens and 
pressing on just immediately faults again.  I have to exit and restart it.

-Tom

> On Jun 20, 2017, at 8:13 AM, Todd Zuercher <zuerc...@embarqmail.com> wrote:
> 
> 
> - Original Message -
>> From: "andy pugh" <bodge...@gmail.com>
>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>> Sent: Tuesday, June 20, 2017 4:27:46 AM
>> Subject: Re: [Emc-users] following error only while homing
>> 
>>> On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
>>> 
>>> Why would I get a following error only while homing
>> 
>> 
>> I think it is probably because you are using HOME_USE_INDEX (which
>> will
>> zero the encoder at the index pulse) and feeding the encoder feedback
>> back
>> into LinuxCNC.
>> 
>> Now, this is perfectly normal, and with a servo / pid machine the
>> system
>> knows to ignore the f-error immediately after an encoder reset. What
>> is
>> puzzling me here is why it isn't working in this case. I think it is
>> something to do with the fact that your system is set up for
>> open-loop step
>> position control but has encoder feedback. However I can't
>> immediately see
>> why this makes a difference.
>> 
>> I imagine that if you press the home button again it will home Z
>> seamlessly, and then f-error homing the next axis.
>> 
>> 
>> --
>> atp
> 
> Andy, 
> 
> I wish that were true.  For some reason my analog servo machine trips up and 
> sets a following error on an axis about 25% of the time when trying to home 
> to index for the first time after turning on LInuxcnc. (Almost every time 
> since it is a 4 axis machine.)  But the alarm is easily cleared, and it 
> always homes fine the 2nd try.  I have never been able to figure out why, and 
> no one else seems to have been able to replicate the problem.
> 
> His problem sounds different since he says can't clear the alarm.
> 
> My other machine with step/dir servos, doesn't have encoder index to home to. 
>  But it does home fine without ever setting following errors.
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[Todd Zuercher]

- Original Message -
> From: "andy pugh" <bodge...@gmail.com>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Tuesday, June 20, 2017 4:27:46 AM
> Subject: Re: [Emc-users] following error only while homing
> 
> On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
> 
> > Why would I get a following error only while homing
> 
> 
> I think it is probably because you are using HOME_USE_INDEX (which
> will
> zero the encoder at the index pulse) and feeding the encoder feedback
> back
> into LinuxCNC.
> 
> Now, this is perfectly normal, and with a servo / pid machine the
> system
> knows to ignore the f-error immediately after an encoder reset. What
> is
> puzzling me here is why it isn't working in this case. I think it is
> something to do with the fact that your system is set up for
> open-loop step
> position control but has encoder feedback. However I can't
> immediately see
> why this makes a difference.
> 
> I imagine that if you press the home button again it will home Z
> seamlessly, and then f-error homing the next axis.
> 
> 
> --
> atp

Andy, 

I wish that were true.  For some reason my analog servo machine trips up and 
sets a following error on an axis about 25% of the time when trying to home to 
index for the first time after turning on LInuxcnc. (Almost every time since it 
is a 4 axis machine.)  But the alarm is easily cleared, and it always homes 
fine the 2nd try.  I have never been able to figure out why, and no one else 
seems to have been able to replicate the problem.

His problem sounds different since he says can't clear the alarm.

My other machine with step/dir servos, doesn't have encoder index to home to.  
But it does home fine without ever setting following errors.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following error only while homing

[andy pugh]

On 20 June 2017 at 03:51,  wrote:

> Why would I get a following error only while homing


I think it is probably because you are using HOME_USE_INDEX (which will
zero the encoder at the index pulse) and feeding the encoder feedback back
into LinuxCNC.

Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for open-loop step
position control but has encoder feedback. However I can't immediately see
why this makes a difference.

I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] following error only while homing

[tom-emc]

Why would I get a following error only while homing (latest Linuxcnc 2.7.9)?  I 
recently added home switches to my machine.  My machine has encoders on the 
steppers on each of the 3 axes so I want to use the index pulse for home.  I 
set up the homing sequence each axis  and when I do "Home All" I get a 
following error on my Z axis (first one to home).  I played with all the 
settings and can’t get it to complete unless I set ferror and min_ferror very 
high  Also, once there is a following error I can only clear it by exiting 
Linuxcnc and restarting it.  If I just turn it back on, it immediately faults 
again with the same following error.  If I don’t home, after restarting 
Linuxcnc, I can run the Z axis (and X and Y) all day at any speed without a 
following error. 

I have tried setting the ferror and min_ferror settings to various reasonable 
values but it didn’t work.   Before adding the switches I had error=0.001 and 
min_ferror=0.0005 and never had a following error appear.  I set ferror to 2 
and min_ferror to 1 (I think those were the values) and it worked but then got 
the following error on the Y axis (the second axis homed).  The values for 
ferror and min_ferror that “worked” seem completely unreasonable given I am not 
even moving anywhere near my max velocity during homing.

I have tried changing the sign on the HOME_LATCH_VEL to make it search for 
index in the other direction but the same thing happens.  Below are my 
(current) machine hal and ini.

-Tom


 ini ———
# Generated by PNCconf at Thu Apr  8 11:40:39 2010

[EMC]
MACHINE = EMCO
DEBUG = 0

[DISPLAY]
DISPLAY = axis
#EMBED_TAB_NAME = Camera
#EMBED_TAB_COMMAND = camview-emc -w {XID}
EDITOR = gedit
PYVCP = custom_pyvcp.xml
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
MAX_FEED_OVERRIDE = 2.0
MAX_SPINDLE_OVERRIDE = 1.5
MIN_SPINDLE_OVERRIDE = 0.50
INTRO_GRAPHIC = linuxcnc.gif
INTRO_TIME = 2
PROGRAM_PREFIX = /home/tom/linuxcnc/nc_files
INCREMENTS = .1in .05in .01in .005in .001in .0005in .0001in
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
DEFAULT_LINEAR_VELOCITY = 0.25
MAX_LINEAR_VELOCITY = 1.00
MIN_LINEAR_VELOCITY = 0.01
DEFAULT_ANGULAR_VELOCITY = 0.25
MAX_ANGULAR_VELOCITY = 1.00
MIN_ANGULAR_VELOCITY = 0.01
GEOMETRY = xyz
#GEOMETRY = xyza

[FILTER]
PROGRAM_EXTENSION = .png,.gif,.jpg Greyscale Depth Image
PROGRAM_EXTENSION = .py Python Script
png = image-to-gcode
gif = image-to-gcode
jpg = image-to-gcode
py = python

[TASK]
TASK = milltask
CYCLE_TIME = 0.010

[RS274NGC]
PARAMETER_FILE = emc.var

[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
#BASE_PERIOD = 5
SERVO_PERIOD = 100

# [HOSTMOT2]
# This is for info only - config line is in the .hal file
# DRIVER0=hm2_7i43 
# BOARD0=7i43
# CONFIG0="firmware=hm2/7i43/SVST2_4_7I47B.BIT num_encoders=3 num_pwmgens=0 
num_stepgens=4" 

[HAL]
HALUI = halui
HALFILE = EMCO.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal

[HALUI]
MDI_COMMAND = G53 G0 X0 Y0 Z0

[TRAJ]
AXES = 3
COORDINATES = X Y Z
LINEAR_UNITS = inch
ANGULAR_UNITS = degree
CYCLE_TIME = 0.010
DEFAULT_VELOCITY = 0.5
MAX_LINEAR_VELOCITY = 2
#Joypad Test stuff below:
DEFAULT_ANGULAR_VELOCITY = 0.25
MAX_ANGULAR_VELOCITY = 1.0

#ARC_BLEND_ENABLE = 1
#ARC_BLEND_RAMP_FREQ = 1000


[EMCIO]
EMCIO = io
CYCLE_TIME = 0.100
TOOL_TABLE = tool.tbl

#
# Axis X
#
[AXIS_0]
TYPE = LINEAR
# HOME = 0.0 -- see below
FERROR = 0.005
MIN_FERROR = 0.001
MAX_VELOCITY = 2.2
MAX_ACCELERATION = 20
# these are in nanoseconds
DIRSETUP   = 200
DIRHOLD= 200
STEPLEN= 2000
STEPSPACE  = 1200
STEPGEN_MAXACCEL = 40
STEPGEN_MAXVEL = 2.75
#BACKLASH = 0.0005
INPUT_SCALE = -208076.8
SCALE = -50800
MIN_LIMIT = -0.001
MAX_LIMIT = 7.8
# homing
# move here after home switch found:
HOME = 4.0
# home switch is located here:
HOME_OFFSET = 7.8
# initial search velocity in/sec
HOME_SEARCH_VEL = 0.75
# 2nd pass search velocity
HOME_LATCH_VEL = 0.1
# speed to HOME
HOME_FINAL_VEL = 0.5
# yes use index
HOME_USE_INDEX = YES
HOME_IGNORE_LIMITS = NO
HOME_IS_SHARED = NO
# do this after Z and Y is homed
HOME_SEQUENCE = 2
# should unhome if estop or power off? no
VOLATILE_HOME = 0

#
# Axis Y
#
[AXIS_1]
TYPE = LINEAR
# HOME = 0.0 -- see below
FERROR = 0.005
MIN_FERROR = 0.001
MAX_VELOCITY = 2.2
MAX_ACCELERATION = 20.0
# these are in nanoseconds
DIRSETUP   = 200
DIRHOLD= 200
STEPLEN= 2000
STEPSPACE  = 1200
STEPGEN_MAXACCEL = 40
STEPGEN_MAXVEL = 2.75
BACKLASH = 0.0005
SCALE = 50800
MIN_LIMIT = -0.001
MAX_LIMIT = 3.8
INPUT_SCALE = 208076.8
# homing
# move here after home switch found:
HOME = 2.0
# home switch is located here:
HOME_OFFSET = 0
# initial search velocity in/sec
HOME_SEARCH_VEL = -0.4
# 2nd pass search velocity
HOME_LATCH_VEL = -0.1
# speed to HOME
HOME_FINAL_VEL = 0.5
# yes use index
HOME_USE_INDEX = YES
HOME_IGNORE_LIMITS = NO
HOME_IS_SHARED = NO
# do this after Z is homed
HOME_SEQUENCE = 1

Re: [Emc-users] Following error on angular axis

[Eric H. Johnson]

Peter,

It is geared down 4:1, so 40 degrees of shaft rotation for 10 degrees on the
axis.

Regards,
Eric


A plot would help, is ths 10 degrees of motor shaft position?



--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error on angular axis

[Eric H. Johnson]

-Original Message-
From: Peter C. Wallace [mailto:p...@mesanet.com] 
Sent: Thursday, April 14, 2016 10:40 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Following error on angular axis

On Thu, 14 Apr 2016, Eric H. Johnson wrote:

> Date: Thu, 14 Apr 2016 09:20:01 -0400
> From: Eric H. Johnson <ejohn...@camalytics.com>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> To: "'Enhanced Machine Controller (EMC)'" 
> <emc-users@lists.sourceforge.net>
> Subject: [Emc-users] Following error on angular axis
> 
> All,
>
>
>
> I am trying to lick a problem with following error on an angular axis 
> (A). I am using a Mesa 7i43 with the 7i33 quad servo interface. If I 
> set the axis max_velocity above about 2 RPS I start getting following 
> errors on G0 moves with any reasonable value for FError (i.e. under 10 
> degrees). The motor should be capable of almost 60 RPS. The encoder is 
> 500 count, 2000 with quadrature, so only a little over 1Khz / 4Khz 
> when I start to see the problem.
>
>
>
> The tuning is firm and giving good positional accuracy, and 
> mechanically there does not appear to be any significant mechanical 
> resistance to overcome. I have played with a number of the axis 
> parameters, but seems to come back to max_velocity, as adjusting 
> acceleration and PID parameters seems to have minimal effect on following
error.
>
>
>
> Any ideas?
>
>
>
> Thanks,
>
> Eric
>

A plot would help, is ths 10 degrees of motor shaft position?


Peter Wallace
Mesa Electronics


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers
of your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error on angular axis

[Peter C. Wallace]

On Thu, 14 Apr 2016, Eric H. Johnson wrote:

> Date: Thu, 14 Apr 2016 09:20:01 -0400
> From: Eric H. Johnson <ejohn...@camalytics.com>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> To: "'Enhanced Machine Controller (EMC)'" <emc-users@lists.sourceforge.net>
> Subject: [Emc-users] Following error on angular axis
> 
> All,
>
>
>
> I am trying to lick a problem with following error on an angular axis (A). I
> am using a Mesa 7i43 with the 7i33 quad servo interface. If I set the axis
> max_velocity above about 2 RPS I start getting following errors on G0 moves
> with any reasonable value for FError (i.e. under 10 degrees). The motor
> should be capable of almost 60 RPS. The encoder is 500 count, 2000 with
> quadrature, so only a little over 1Khz / 4Khz when I start to see the
> problem.
>
>
>
> The tuning is firm and giving good positional accuracy, and mechanically
> there does not appear to be any significant mechanical resistance to
> overcome. I have played with a number of the axis parameters, but seems to
> come back to max_velocity, as adjusting acceleration and PID parameters
> seems to have minimal effect on following error.
>
>
>
> Any ideas?
>
>
>
> Thanks,
>
> Eric
>

A plot would help, is ths 10 degrees of motor shaft position?


Peter Wallace
Mesa Electronics

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error on angular axis

[Nicklas Karlsson]

D will also help with this. Both FF1 and D together in appropriate amount will 
probably help with this.

> Is the following error proportional to velocity?  FF1 can often help with 
> this, unless it is a torque mode set up, then it becomes a little more 
> complicated.
> 
> - Original Message -
> From: "Eric H. Johnson" <ejohn...@camalytics.com>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Thursday, April 14, 2016 9:20:01 AM
> Subject: [Emc-users] Following error on angular axis
> 
> All,
> 
>  
> 
> I am trying to lick a problem with following error on an angular axis (A). I
> am using a Mesa 7i43 with the 7i33 quad servo interface. If I set the axis
> max_velocity above about 2 RPS I start getting following errors on G0 moves
> with any reasonable value for FError (i.e. under 10 degrees). The motor
> should be capable of almost 60 RPS. The encoder is 500 count, 2000 with
> quadrature, so only a little over 1Khz / 4Khz when I start to see the
> problem. 
> 
>  
> 
> The tuning is firm and giving good positional accuracy, and mechanically
> there does not appear to be any significant mechanical resistance to
> overcome. I have played with a number of the axis parameters, but seems to
> come back to max_velocity, as adjusting acceleration and PID parameters
> seems to have minimal effect on following error. 
> 
>  
> 
> Any ideas?
> 
>  
> 
> Thanks,
> 
> Eric
> 
>  
> 
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error on angular axis

[Eric H. Johnson]

Todd,

It is velocity mode. I am running headless so it is a bit of a pain to setup
for running things like halmeter and halscope unless I setup something like
VNC. 

I won't be able to work on it until tomorrow, but will look at this then.

Thanks all,
Eric


Is the following error proportional to velocity?  FF1 can often help with
this, unless it is a torque mode set up, then it becomes a little more
complicated.



--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error on angular axis

[Todd Zuercher]

Is the following error proportional to velocity?  FF1 can often help with this, 
unless it is a torque mode set up, then it becomes a little more complicated.

- Original Message -
From: "Eric H. Johnson" <ejohn...@camalytics.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Thursday, April 14, 2016 9:20:01 AM
Subject: [Emc-users] Following error on angular axis

All,

 

I am trying to lick a problem with following error on an angular axis (A). I
am using a Mesa 7i43 with the 7i33 quad servo interface. If I set the axis
max_velocity above about 2 RPS I start getting following errors on G0 moves
with any reasonable value for FError (i.e. under 10 degrees). The motor
should be capable of almost 60 RPS. The encoder is 500 count, 2000 with
quadrature, so only a little over 1Khz / 4Khz when I start to see the
problem. 

 

The tuning is firm and giving good positional accuracy, and mechanically
there does not appear to be any significant mechanical resistance to
overcome. I have played with a number of the axis parameters, but seems to
come back to max_velocity, as adjusting acceleration and PID parameters
seems to have minimal effect on following error. 

 

Any ideas?

 

Thanks,

Eric

 

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error on angular axis

[Nicklas Karlsson]

> All,
> 
>  
> 
> I am trying to lick a problem with following error on an angular axis (A). I
> am using a Mesa 7i43 with the 7i33 quad servo interface. If I set the axis
> max_velocity above about 2 RPS I start getting following errors on G0 moves
> with any reasonable value for FError (i.e. under 10 degrees). The motor
> should be capable of almost 60 RPS. The encoder is 500 count, 2000 with
> quadrature, so only a little over 1Khz / 4Khz when I start to see the
> problem. 
> 
>  
> 
> The tuning is firm and giving good positional accuracy, and mechanically
> there does not appear to be any significant mechanical resistance to
> overcome. I have played with a number of the axis parameters, but seems to
> come back to max_velocity, as adjusting acceleration and PID parameters
> seems to have minimal effect on following error. 
> 
>  
> 
> Any ideas?

Yes, integrator will remove following errors over time but then constantly 
moving derivative D is needed. Did you use Linuxcnc builtin tuning? tune mode 
or type I think should be 1 to also enable tuning of feedforward, read manual.

> Thanks,
> 
> Eric


Nicklas Karlsson

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error on angular axis

[andy pugh]

On 14 April 2016 at 14:20, Eric H. Johnson  wrote:

> The motor
> should be capable of almost 60 RPS. The encoder is 500 count, 2000 with
> quadrature, so only a little over 1Khz / 4Khz when I start to see the
> problem.

If you set the f_error to be very large indeed, how fast can the axis
actually rotate? Maybe something in the PID setup (maxerror?) is
artifically limiting the output.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Following error on angular axis

[Eric H. Johnson]

All,

 

I am trying to lick a problem with following error on an angular axis (A). I
am using a Mesa 7i43 with the 7i33 quad servo interface. If I set the axis
max_velocity above about 2 RPS I start getting following errors on G0 moves
with any reasonable value for FError (i.e. under 10 degrees). The motor
should be capable of almost 60 RPS. The encoder is 500 count, 2000 with
quadrature, so only a little over 1Khz / 4Khz when I start to see the
problem. 

 

The tuning is firm and giving good positional accuracy, and mechanically
there does not appear to be any significant mechanical resistance to
overcome. I have played with a number of the axis parameters, but seems to
come back to max_velocity, as adjusting acceleration and PID parameters
seems to have minimal effect on following error. 

 

Any ideas?

 

Thanks,

Eric

 

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Following Error

[Rick]

Hello All,

I was wondering is there any way to be able to set in the INI, the 
following error based on what the commanded feed rate is,

Looking thru all the other machines in the shop, the following error is 
based off of, how many thousands per commanded inches per minute of 
feed, following error is allowed.

  I would think this would help in the tuning aspect of things, and would 
make for a little bigger sense of security, as you would know what the 
limit is regarding the allowed error during operation.

Just a question/thought

Thanks


Rick


Superior Roll  Turning
399 East Center Street
Petersburg MI, 49270
734-279-1831
www.superiorroll.com
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error

[andy pugh]

On 23 October 2014 12:41, Rick r...@superiorroll.com wrote:

 I was wondering is there any way to be able to set in the INI, the
 following error based on what the commanded feed rate is,

If the INI file has both a MIN_FERROR and an FERROR entry then the
allowable error linearly scales between the two, using MIN_FERROR at
zero speed and FERROR at max speed.

http://www.linuxcnc.org/docs/html/config/ini_config.html#sub:AXIS-section

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

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

[Emc-users] Following error pin

[Tomaz T .]

I have two motor drivers (for axis 4 and 5) which have alarm signal telling me 
that motor is off position, and would like to connect that in linuxcnc, so when 
it is active it would trigger following error for certain axis. Which hal pin 
can I use for that input signals to connect on to?  
 
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error pin

[Chris Radek]

On Tue, Oct 08, 2013 at 03:37:49PM +, Tomaz T. wrote:
 I have two motor drivers (for axis 4 and 5) which have alarm
 signal telling me that motor is off position, and would like to
 connect that in linuxcnc, so when it is active it would trigger
 following error for certain axis. Which hal pin can I use for that
 input signals to connect on to? 

I would use axis.N.amp-fault-in

This will cause the same behavior as a following error (abort,
disable the amps, and generate a fault message).

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error pin

[andy pugh]

On 8 October 2013 16:37, Tomaz T. tomaz_...@hotmail.com wrote:
 I have two motor drivers (for axis 4 and 5) which have alarm signal telling 
 me that motor is off position, and would like to connect that in linuxcnc, so 
 when it is active it would trigger following error for certain axis.

I assume that in this system LinuxCNC is not seeing accurate position feedback?

Can you describe the system?

One solution, assuming a step-controlled servo system where the
encoder output only goes to the drives and not back to LinuxCNC would
be to meddle with the normal feedback loop.

So, if you normally have
net x-fb stepgen.0.position-fb axis.0.motor-pos-fb

Then you could have:

net x-fb-raw stepgen.0.position-fb =  mux2.0.in0
net x-fb mux2.0.out = axis.0.motor-pos-fb
setp mux2.0.in1 1000
net error-signal {error source} = mux2.0.sel

So, most of the time the system sees the normal stepgen feedback, but
if the error trips it suddenly sees a bad value.

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

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error pin

[Tomaz T .]

Motors are step/dir controlled hybrid steppers that have encoder, and encoder 
feedback goes only to drivers so linuxcnc doesn't see actual position, and the 
only thing I could use is alarm signal from driver that would trigger linuxcnc 
to stop.
If it helps, this is driver used in system:
http://www.americanmotiontech.com/Products/ProductDetail.aspx?category=2model=HBS57

 
 I assume that in this system LinuxCNC is not seeing accurate position 
 feedback?
 
 Can you describe the system?
 
 One solution, assuming a step-controlled servo system where the
 encoder output only goes to the drives and not back to LinuxCNC would
 be to meddle with the normal feedback loop.
 
 So, if you normally have
 net x-fb stepgen.0.position-fb axis.0.motor-pos-fb
 
 Then you could have:
 
 net x-fb-raw stepgen.0.position-fb = mux2.0.in0
 net x-fb mux2.0.out = axis.0.motor-pos-fb
 setp mux2.0.in1 1000
 net error-signal {error source} = mux2.0.sel
 
 So, most of the time the system sees the normal stepgen feedback, but
 if the error trips it suddenly sees a bad value.  
   
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following error pin

[Tomaz T .]

Motors are step/dir controlled hybrid steppers that have encoder, and encoder 
feedback goes only to drivers so linuxcnc doesn't see actual position, and the 
only thing I could use is alarm signal from driver that would trigger linuxcnc 
to stop.
If it helps, this is driver used in system:
http://www.americanmotiontech.com/Products/ProductDetail.aspx?category=2model=HBS57


 I assume that in this system LinuxCNC is not seeing accurate position 
 feedback?

 Can you describe the system?

 One solution, assuming a step-controlled servo system where the
 encoder output only goes to the drives and not back to LinuxCNC would
 be to meddle with the normal feedback loop.

 So, if you normally have
 net x-fb stepgen.0.position-fb axis.0.motor-pos-fb

 Then you could have:

 net x-fb-raw stepgen.0.position-fb = mux2.0.in0
 net x-fb mux2.0.out = axis.0.motor-pos-fb
 setp mux2.0.in1 1000
 net error-signal {error source} = mux2.0.sel

 So, most of the time the system sees the normal stepgen feedback, but
 if the error trips it suddenly sees a bad value.
 
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[John Thornton]

I've often wondered if a configuration wizard for each family of cards 
would make more sense and have less confusion with a newbee by having 
fewer options to work through. I even started one for the 5i25 once 
until I figured out that Chris had 5i25 in pncconf.

JT

On 10/5/2013 6:26 AM, andy pugh wrote:
 On 5 October 2013 05:54, Chris Morley chrisinnana...@hotmail.com wrote:

 Thanks for that. Some times I think PNCconf is linuxcnc's red hair stepchild.
 I think most Devs underestimate the importance of what it is trying to 
 achieve.
 I think that folk tend to under-estimate just how difficult it is to
 do the job it tries to do.
 I think it was probably a containable task when you started and there
 were 3 cards, 4 daughter boards and a dozen firmware files.

 Then many more cards came along, and cards that declare their own pin
 names, and that have different sets of pins depending on hardware and
 software switches, and some that don't even need firmware, and the job
 got really very big.



--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[John Thornton]

As usual I think I phrased that wrong... If the 5i25 7i77 and 5i25 7i76 
was separate then it would be much easier for the majority of users 
IMHO. By family I guess I meant the 5i25 and daughter cards. I'd bet the 
5i25 has become the most poplar with LinuxCNC users.

And then there is the ever expanding horizons set by Peter.

Anyway as usual just thinking out loud...

JT

On 10/7/2013 8:58 AM, andy pugh wrote:
 On 7 October 2013 14:50, John Thornton bjt...@gmail.com wrote:
 I've often wondered if a configuration wizard for each family of cards
 would make more sense and have less confusion
 How do you separate the families?
 The 7i80 has DB and HD versions, so bridges daughterboard classes and
 the HD-DB adapter lets you connect a 7i77 or 7i76 (or several) to the
 5i20 style boards.

 Just when you think you have a handle on the problem, PCW moves the
 goalposts. :-)





--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[Chris Morley]

 Date: Mon, 7 Oct 2013 12:12:00 -0500
 From: bjt...@gmail.com
 To: emc-users@lists.sourceforge.net
 Subject: Re: [Emc-users] Following Error with Steppers
 
 As usual I think I phrased that wrong... If the 5i25 7i77 and 5i25 7i76 
 was separate then it would be much easier for the majority of users 
 IMHO. By family I guess I meant the 5i25 and daughter cards. I'd bet the 
 5i25 has become the most poplar with LinuxCNC users.
 
 And then there is the ever expanding horizons set by Peter.
 
 Anyway as usual just thinking out loud...
 
 JT
 

I think the real big advantage is that a second person would be developing it.
It is a huge undertaking to keep current.

After the user picks 5i25 in PNCconf, it tailors it's self to the 5i25, so I'm
not sure how a separate program would help that much.

One big pain, is the fact the user has to copy files in to folders using sudo,
just so PNCconf can see the 5i25. This could be fixed with the firmware repo.

Chris M


  
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[Marius Liebenberg]

Chris
I don't think it is necessary for a production unit. Meaning a system 
that is running a machine but as in my case where I have several 
installations on the same machine. I use this machine to develop configs 
and test new features and whatever else I have to do with LCNC. Like if 
a person ask me to help with a config, I will copy it to this machine 
and test from here. Or when I start e new conversion, I first write the 
config on this machine and then when I am done, pull the latest LCNC 
from either 2.5.x or from master and then put the config on that machine.
So in my case it is better if I have the config stored in the same 
location as the release that I am using.

To be honest, it would be nice to have but I am sure we can live without 
it. Don't want to make more work for you.

On 2013/10/05 02:51 AM, Chris Morley wrote:

 Date: Fri, 4 Oct 2013 11:25:22 +0200
 From: mar...@mastercut.co.za
 To: emc-users@lists.sourceforge.net
 Subject: Re: [Emc-users] Following Error with Steppers

 Chris
 It seems that the erronous lines are gone but I just realized that I
 cannot change the location where the files are generated to. I was
 running form a dev RIP and the files where created in the production
 directory. Would it not be better if one could place the generated
 config in the RIP directory that you are working in?

 The thought is that PNCconf puts them in your personal config location.
 (~/linuxcnc/configs/) is they are relatively safe and in one location.

 Aside from developers or power users, I didn't expect anyone to be running
 2 different versions of linuxcnc on a system.

 I am open to ideas about it.
 selectable folder location?
 I am a wondering if it starts to get easy to lose where stuff is...

 Chris M


   
 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


-- 
Regards / Groete

Marius D. Liebenberg
MasterCut cc
Cel: +27 82 698 3251
Tel: +27 12 743 6064
Fax: +27 86 551 8029
Skype: marius_d.liebenberg



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 131004-1, 2013/10/04
Tested on: 2013/10/05 08:12:15 AM
avast! - copyright (c) 1988-2013 AVAST Software.
http://www.avast.com


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[Marius Liebenberg]

On 2013/10/05 06:54 AM, Chris Morley wrote:
 Thanks for that. Some times I think PNCconf is linuxcnc's red hair
 stepchild. I think most Devs underestimate the importance of what it
 is trying to achieve. But just about when I'm ready to remove it from
 linuxcnc someone mentions it was very helpful :) Chris M

NOOO! never think of that again please. It is very very useful even if 
has some small issues. It is one of the most important pieces of code of 
LCNC. Don't kid yourself, we need it very much.I for one will be very 
lost without that and stepconf for that matter.



-- 
Regards / Groete

Marius D. Liebenberg
MasterCut cc
Cel: +27 82 698 3251
Tel: +27 12 743 6064
Fax: +27 86 551 8029
Skype: marius_d.liebenberg


---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 131004-1, 2013/10/04
Tested on: 2013/10/05 08:24:09 AM
avast! - copyright (c) 1988-2013 AVAST Software.
http://www.avast.com




--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[Steve Blackmore]

On Sat, 5 Oct 2013 04:54:44 +, you wrote:


Thanks for that. Some times I think PNCconf is linuxcnc's red hair stepchild.
I think most Devs underestimate the importance of what it is trying to achieve.
But just about when I'm ready to remove it from linuxcnc someone mentions
it was very helpful :)

Chris - without stepconf or pncconf new users would be stuffed. If you
are not a programmer or understand the language of the ini files or hal
files you're lost. Both do a good job of getting a basic file in an easy
to follow format. Writing docs is a difficult, and often thankless task,
your efforts are very much appreciated.   

Without you I'm sure many would give up at the first hurdle. 

Steve Blackmore
--

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[andy pugh]

On 5 October 2013 05:54, Chris Morley chrisinnana...@hotmail.com wrote:

 Thanks for that. Some times I think PNCconf is linuxcnc's red hair stepchild.
 I think most Devs underestimate the importance of what it is trying to 
 achieve.

I think that folk tend to under-estimate just how difficult it is to
do the job it tries to do.
I think it was probably a containable task when you started and there
were 3 cards, 4 daughter boards and a dozen firmware files.

Then many more cards came along, and cards that declare their own pin
names, and that have different sets of pins depending on hardware and
software switches, and some that don't even need firmware, and the job
got really very big.

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

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[Belli Button]

Hey no!  We love PNCconf, for an initial setup it the fastest method to get
about 90% done.  Life would be miserable without it (really).



-Original Message-
From: Marius Liebenberg [mailto:mar...@mastercut.co.za] 
Sent: 05 October 2013 08:24 AM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Following Error with Steppers


On 2013/10/05 06:54 AM, Chris Morley wrote:
 Thanks for that. Some times I think PNCconf is linuxcnc's red hair 
 stepchild. I think most Devs underestimate the importance of what it 
 is trying to achieve. But just about when I'm ready to remove it from 
 linuxcnc someone mentions it was very helpful :) Chris M

NOOO! never think of that again please. It is very very useful even if has
some small issues. It is one of the most important pieces of code of LCNC.
Don't kid yourself, we need it very much.I for one will be very lost without
that and stepconf for that matter.



--
Regards / Groete

Marius D. Liebenberg
MasterCut cc
Cel: +27 82 698 3251
Tel: +27 12 743 6064
Fax: +27 86 551 8029
Skype: marius_d.liebenberg


---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 131004-1, 2013/10/04 Tested on: 2013/10/05 08:24:09 AM
avast! - copyright (c) 1988-2013 AVAST Software.
http://www.avast.com





--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from the latest Intel processors and coprocessors. See abstracts and
register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[Gene Heskett]

On Saturday 05 October 2013 12:04:59 Belli Button did opine:

 Hey no!  We love PNCconf, for an initial setup it the fastest method to
 get about 90% done.  Life would be miserable without it (really).

I hereby nominate that for the understatement of the year.

I hope also that I have headed off a proposal from one of the guys at 
Intel, who submitted some patches yesterday to lay the groundwork for a 
power management scheme that shuts off inactive ports.

Since LCNC's use of the parport from an isolcpus=corenum core, is 
completely invisible to normal tools like top, I pointed out that powering 
down a port in very heavy use had the potential to maim/kill somebody, and 
damage half a million dollars worth of machinery.  I hope I got the point 
across that there were more places where linux was used than just on his 
lappy at the library where you need every milliampere hour you can get when 
you can't plug it in.  Then he wanted to marry the control of such a PM 
facility to root, and I blew up again.  If the control is there, and 
someone builds a kernel with it not disabled, the potential is there.  It  
absolutely MUST be user controllable if implemented.  Not even negotiable 
without that IMO.

I do not know how LCNC goes about locking the port(s) for its exclusive 
use, but I'd hate like hell for us to find out linux can shut down the 
hardware interface we're using by running Stuarts 26 foot table into the 
end stops at the servo's full speed. That should be grounds for organizing 
a hunting party.

How is the I/O card for the BBB coming along?

Cheers, Gene
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)

You will be audited by the Internal Revenue Service.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[Chris Morley]

 Date: Thu, 3 Oct 2013 16:20:51 +0200
 From: mar...@mastercut.co.za
 To: emc-users@lists.sourceforge.net
 Subject: Re: [Emc-users] Following Error with Steppers
 
 Chris
 This is a very old bug that has been reported several times. At least 
 once by myself. It is still in all the latest code on master. We just 
 delete these lines each time. :)
 
 On 2013/10/03 04:43 AM, Chris Morley wrote:
 
  From: bodge...@gmail.com
  Date: Wed, 2 Oct 2013 18:47:08 +0100
  To: emc-users@lists.sourceforge.net
  Subject: Re: [Emc-users] Following Error with Steppers
 
  On 2 October 2013 18:26, Russell Brown russ...@lls.lls.com wrote:
 
   loadrt abs names=
   loadrt lowpass names=
  This is a stepfconf bug. I can't recall what prompts it. I thought it
  was fixed. (it tries to load a bunch of components with blank names,
  and then their pin names collide)
 
  Pncconf bug -but is probably fixed. what version was this made with?
 

Ok I think it's really fix this time. seems asking for a gladeVCP sample panel
but without a spindle speed display set it off.
Sorry It took so long - I thought I fixed it...musta been busy with Gscreen.

I also did some other work mostly related to spindle command signals.

Please test if you can and report bugs (this fix is in master)

Chris M

  
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Following Error with Steppers

[Marius Liebenberg]

Chris
It seems that the erronous lines are gone but I just realized that I 
cannot change the location where the files are generated to. I was 
running form a dev RIP and the files where created in the production 
directory. Would it not be better if one could place the generated 
config in the RIP directory that you are working in?
On 2013/10/04 08:06 AM, Chris Morley wrote:

 Date: Thu, 3 Oct 2013 16:20:51 +0200
 From: mar...@mastercut.co.za
 To: emc-users@lists.sourceforge.net
 Subject: Re: [Emc-users] Following Error with Steppers

 Chris
 This is a very old bug that has been reported several times. At least
 once by myself. It is still in all the latest code on master. We just
 delete these lines each time. :)

 On 2013/10/03 04:43 AM, Chris Morley wrote:
 From: bodge...@gmail.com
 Date: Wed, 2 Oct 2013 18:47:08 +0100
 To: emc-users@lists.sourceforge.net
 Subject: Re: [Emc-users] Following Error with Steppers

 On 2 October 2013 18:26, Russell Brown russ...@lls.lls.com wrote:

   loadrt abs names=
   loadrt lowpass names=
 This is a stepfconf bug. I can't recall what prompts it. I thought it
 was fixed. (it tries to load a bunch of components with blank names,
 and then their pin names collide)

 Pncconf bug -but is probably fixed. what version was this made with?

 Ok I think it's really fix this time. seems asking for a gladeVCP sample panel
 but without a spindle speed display set it off.
 Sorry It took so long - I thought I fixed it...musta been busy with Gscreen.

 I also did some other work mostly related to spindle command signals.

 Please test if you can and report bugs (this fix is in master)

 Chris M

   
 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


-- 
Regards / Groete

Marius D. Liebenberg
MasterCut cc
Cel: +27 82 698 3251
Tel: +27 12 743 6064
Fax: +27 86 551 8029
Skype: marius_d.liebenberg



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 131003-1, 2013/10/03
Tested on: 2013/10/04 11:25:29 AM
avast! - copyright (c) 1988-2013 AVAST Software.
http://www.avast.com


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users