Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

The rotary loop works fine by itself.

The linear loop, as it's just an I term is pretty useless/non functional  
by itself. Maybe you could argue it's ok for really small values of I, but  
then the settling time when using both PID loops combined is terrible. I  
was under the impression that was as designed/expected based on the  
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Combining_Two_Feedback_Devices_On_One_Axis


Side question. When doing touchoff/tool touchoff is commanded position or  
actual position used?




Maybe I'll look at a different PID strategy. Perhaps I could add the  
pid.y2.error value from the linear encoder to the pid.Y.command then the  
servo encoder will really have its thumb in the tuning pie. The linear  
encoder won't have to run any actual gain, just spit out the current error  
vs commanded.


-Dave


On Sat, 25 Apr 2020 23:44:46 -0400, Peter C. Wallace   
wrote:



On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 23:13:59 -0400
From: David Berndt 
To: Peter C. Wallace 
Cc: "Enhanced Machine Controller (EMC)"  


Subject: Re: [Emc-users] Encoder reset on homing to index
Resent-Date: Sat, 25 Apr 2020 23:39:11 -0400
Resent-From: "David Berndt" 
Resent-To: "emc-users@lists.sourceforge.net"  


Resent-cc: "Peter C. Wallace" 
 Trying this again for the second time, no more attachments, only a  
google photos link. I really mean it this time.

https://photos.app.goo.gl/xMK4Ep69i1SpznC58

Here are some halscope screenshots. Would saving the halscope data and
distributing that be better/prefered? Not sure what the policy is here.


This isn't really revealing much to me. All the index-enables fire,
commands go to zero, feedback goes to 0 and then the PID.y.output takes
off, PID.y2(linear).output eventually catches on and doesn't do anything
to help, seems to add fuel to the fire instead of acting in an opposite
direction it should.

Please see screenshots, any thoughts are appreciated.

-Dave



The runaway almost suggests you have one PID loop with negative feedback  
and one with positive feedback. Have you tried each loop individually?





On Sat, 25 Apr 2020 14:44:54 -0400, Peter C. Wallace 
wrote:


On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 14:21:45 -0400
From: David Berndt 
To: "Enhanced Machine Controller (EMC)"  
,

   Peter C. Wallace 
Subject: Re: [Emc-users] Encoder reset on homing to index
Thanks for the feedback Peter.
 I took the time to re-order my hal file (it's a bit of a disaster  
with all the other non motion going-ons in there).

 Here is the relevant start of m addf's
  addf hm2_5i25.0.read  servo-thread
addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf pid.x.do-pid-calcs   servo-thread
addf pid.y.do-pid-calcs   servo-thread #rotary
addf pid.y2.do-pid-calcs  servo-thread #linear
addf pid.z.do-pid-calcs   servo-thread
addf pid.a.do-pid-calcs   servo-thread
addf pid.s.do-pid-calcs   servo-thread
 addf sum2.3   servo-thread#pid.y.output  
+pid.y2.output -> 'y-output' -> hm2_5i25.0.7i77.0.1.analogout1

 addf hm2_5i25.0.write servo-thread
  I excluded all the stuff below which is are things like servo amp  
ready, amp fault, coolant, spindle speed, spindle amp draw, f-error  
tracking, stuff that happens in servo-thread but isn't exciting or  
relevant to motion in a realtime way.
 Yes, PID.y.index-enable, pid.y2.index-enable,  
hm2encoder.03.index-enable, and hm2...encoder.01.index-enable are  
all plumbed up and I show them going TRUE during homing.
 When I went out to the cold mill this AM and started fooling around  
I noticed I was getting some following errors even in my previously  
configured "acceptable" config which was driving axis.1.motor-pos-fb  
from the rotary encoder still. Some hal-scoping around shows that  
maybe with the change I need some re-tuning at higher speeds.
 The need for retuning made me think that perhaps if the tuning was  
questionable and that lead to a bit of runaway condition at higher  
speeds then perhaps if I just decreased the max speed and tried  
assigning the linear encoder pos fb to axis pos fb I might see an  
improvement.
 So I did that, and it did. I'm now jogging back and forth at half  
the old max speed and doing some basic G-code tests with the linear  
axis being axis.1.motor-pos-fb. Which is nice because the GUI  
displays more enjoyable numbers.
 I'm not sure which change contributed to what, HAL reorder/cleanup,  
or tuning.
  My homing situation hasn't really changed. I still have to home  
twice to get a completed homing cycle. I once got persistent runaway  
after homing (caught quickly by f-error), but it wasn't self  
correcting, turning the machine on again (f2) just led to another  
immediate runaway. Restarted linuxcnc to try again and all was well.  
Interesting problems.
  So as it stands now, homing (i have no idea what to actually  
try/change, it's 

Re: [Emc-users] Encoder reset on homing to index

[Peter C. Wallace]

On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 23:13:59 -0400
From: David Berndt 
To: Peter C. Wallace 
Cc: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Encoder reset on homing to index
Resent-Date: Sat, 25 Apr 2020 23:39:11 -0400
Resent-From: "David Berndt" 
Resent-To: "emc-users@lists.sourceforge.net" 
Resent-cc: "Peter C. Wallace" 

Trying this again for the second time, no more attachments, only a google 
photos link. I really mean it this time.

https://photos.app.goo.gl/xMK4Ep69i1SpznC58

Here are some halscope screenshots. Would saving the halscope data and
distributing that be better/prefered? Not sure what the policy is here.


This isn't really revealing much to me. All the index-enables fire,
commands go to zero, feedback goes to 0 and then the PID.y.output takes
off, PID.y2(linear).output eventually catches on and doesn't do anything
to help, seems to add fuel to the fire instead of acting in an opposite
direction it should.

Please see screenshots, any thoughts are appreciated.

-Dave



The runaway almost suggests you have one PID loop with negative feedback and one 
with positive feedback. Have you tried each loop individually?





On Sat, 25 Apr 2020 14:44:54 -0400, Peter C. Wallace 
wrote:


On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 14:21:45 -0400
From: David Berndt 
To: "Enhanced Machine Controller (EMC)" ,
   Peter C. Wallace 
Subject: Re: [Emc-users] Encoder reset on homing to index
Thanks for the feedback Peter.

I took the time to re-order my hal file (it's a bit of a disaster with all 
the other non motion going-ons in there).


Here is the relevant start of m addf's


addf hm2_5i25.0.read  servo-thread
addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf pid.x.do-pid-calcs   servo-thread
addf pid.y.do-pid-calcs   servo-thread #rotary
addf pid.y2.do-pid-calcs  servo-thread #linear
addf pid.z.do-pid-calcs   servo-thread
addf pid.a.do-pid-calcs   servo-thread
addf pid.s.do-pid-calcs   servo-thread

addf sum2.3   servo-thread#pid.y.output +pid.y2.output 
-> 'y-output' -> hm2_5i25.0.7i77.0.1.analogout1


addf hm2_5i25.0.write servo-thread


I excluded all the stuff below which is are things like servo amp ready, 
amp fault, coolant, spindle speed, spindle amp draw, f-error tracking, 
stuff that happens in servo-thread but isn't exciting or relevant to 
motion in a realtime way.


Yes, PID.y.index-enable, pid.y2.index-enable, 
hm2encoder.03.index-enable, and hm2...encoder.01.index-enable are all 
plumbed up and I show them going TRUE during homing.


When I went out to the cold mill this AM and started fooling around I 
noticed I was getting some following errors even in my previously 
configured "acceptable" config which was driving axis.1.motor-pos-fb from 
the rotary encoder still. Some hal-scoping around shows that maybe with 
the change I need some re-tuning at higher speeds.


The need for retuning made me think that perhaps if the tuning was 
questionable and that lead to a bit of runaway condition at higher speeds 
then perhaps if I just decreased the max speed and tried assigning the 
linear encoder pos fb to axis pos fb I might see an improvement.


So I did that, and it did. I'm now jogging back and forth at half the old 
max speed and doing some basic G-code tests with the linear axis being 
axis.1.motor-pos-fb. Which is nice because the GUI displays more enjoyable 
numbers.


I'm not sure which change contributed to what, HAL reorder/cleanup, or 
tuning.



My homing situation hasn't really changed. I still have to home twice to 
get a completed homing cycle. I once got persistent runaway after homing 
(caught quickly by f-error), but it wasn't self correcting, turning the 
machine on again (f2) just led to another immediate runaway. Restarted 
linuxcnc to try again and all was well. Interesting problems.



So as it stands now, homing (i have no idea what to actually try/change, 
it's broken but also kind of fine...) , and more tuning (assuming it's not 
a fools errand to change tuning with the addition of a linear scale...) 
are my next steps.




-Dave



I suspect you will have to track down whats going on with halscope 
(triggered by index-enable going low) and monitor the commanded position, 
feedback position

and PID output



On Sat, 25 Apr 2020 09:44:14 -0400, Peter C. Wallace  
wrote:



On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 03:23:20 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"
  
To: "Enhanced Machine Controller (EMC)" 


Subject: Re: [Emc-users] Encoder reset on homing to index
After a few more hours tonight putzing around with this thing. Here's 
where I'm at.
I've wired up the shared index. It completes both the encoder's 
index-enable cycles. encoder.NRotary.position and 
encoder.nLinear.position both reset to ~0. Home is also at 0 as is 

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

Trying this again for the second time, no more attachments, only a google  
photos link. I really mean it this time.

https://photos.app.goo.gl/xMK4Ep69i1SpznC58

Here are some halscope screenshots. Would saving the halscope data and
distributing that be better/prefered? Not sure what the policy is here.


This isn't really revealing much to me. All the index-enables fire,
commands go to zero, feedback goes to 0 and then the PID.y.output takes
off, PID.y2(linear).output eventually catches on and doesn't do anything
to help, seems to add fuel to the fire instead of acting in an opposite
direction it should.

Please see screenshots, any thoughts are appreciated.

-Dave



On Sat, 25 Apr 2020 14:44:54 -0400, Peter C. Wallace 
wrote:


On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 14:21:45 -0400
From: David Berndt 
To: "Enhanced Machine Controller (EMC)"  
,

Peter C. Wallace 
Subject: Re: [Emc-users] Encoder reset on homing to index
 Thanks for the feedback Peter.

I took the time to re-order my hal file (it's a bit of a disaster with  
all the other non motion going-ons in there).


Here is the relevant start of m addf's


addf hm2_5i25.0.read  servo-thread
addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf pid.x.do-pid-calcs   servo-thread
addf pid.y.do-pid-calcs   servo-thread #rotary
addf pid.y2.do-pid-calcs  servo-thread #linear
addf pid.z.do-pid-calcs   servo-thread
addf pid.a.do-pid-calcs   servo-thread
addf pid.s.do-pid-calcs   servo-thread

addf sum2.3   servo-thread#pid.y.output  
+pid.y2.output -> 'y-output' -> hm2_5i25.0.7i77.0.1.analogout1


addf hm2_5i25.0.write servo-thread


I excluded all the stuff below which is are things like servo amp  
ready, amp fault, coolant, spindle speed, spindle amp draw, f-error  
tracking, stuff that happens in servo-thread but isn't exciting or  
relevant to motion in a realtime way.


Yes, PID.y.index-enable, pid.y2.index-enable,  
hm2encoder.03.index-enable, and hm2...encoder.01.index-enable are  
all plumbed up and I show them going TRUE during homing.


When I went out to the cold mill this AM and started fooling around I  
noticed I was getting some following errors even in my previously  
configured "acceptable" config which was driving axis.1.motor-pos-fb  
from the rotary encoder still. Some hal-scoping around shows that maybe  
with the change I need some re-tuning at higher speeds.


The need for retuning made me think that perhaps if the tuning was  
questionable and that lead to a bit of runaway condition at higher  
speeds then perhaps if I just decreased the max speed and tried  
assigning the linear encoder pos fb to axis pos fb I might see an  
improvement.


So I did that, and it did. I'm now jogging back and forth at half the  
old max speed and doing some basic G-code tests with the linear axis  
being axis.1.motor-pos-fb. Which is nice because the GUI displays more  
enjoyable numbers.


I'm not sure which change contributed to what, HAL reorder/cleanup, or  
tuning.



My homing situation hasn't really changed. I still have to home twice  
to get a completed homing cycle. I once got persistent runaway after  
homing (caught quickly by f-error), but it wasn't self correcting,  
turning the machine on again (f2) just led to another immediate  
runaway. Restarted linuxcnc to try again and all was well. Interesting  
problems.



So as it stands now, homing (i have no idea what to actually  
try/change, it's broken but also kind of fine...) , and more tuning  
(assuming it's not a fools errand to change tuning with the addition of  
a linear scale...) are my next steps.




-Dave



I suspect you will have to track down whats going on with halscope  
(triggered by index-enable going low) and monitor the commanded  
position, feedback position

and PID output



On Sat, 25 Apr 2020 09:44:14 -0400, Peter C. Wallace   
wrote:



On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 03:23:20 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"
   
To: "Enhanced Machine Controller (EMC)"  


Subject: Re: [Emc-users] Encoder reset on homing to index
After a few more hours tonight putzing around with this thing. Here's  
where I'm at.
 I've wired up the shared index. It completes both the encoder's  
index-enable cycles. encoder.NRotary.position and  
encoder.nLinear.position both reset to ~0. Home is also at 0 as is  
homeoffset, so once index is found there should be no need for the  
axis to move. However it takes off and gets caught by a fairly strict  
ferror.
 If I then home it again the result seems to be close enough that the  
small post-index-enable completion jump is within f-error. The axis  
moves a few .001" and settles. I'm not sure what's causing this jump  
in the first/second homing. Because of the ferror the first homing  
attempt does not actually complete the homing cycle, 

Re: [Emc-users] Help with some sporadic followin errors

[Leonardo Marsaglia]

>
> What kind of driver are you using?  I've got HP_UHU on brushed DC servo's
> and a STMBL drive on the AC Servo Harmonic Drive.  In both cases those
> fault out if the following error doesn't match.  In other words, the drive
> counts the steps input and if the encoder pulses don't match the steps past
> a threshold the motor faults out.
>

I'm using ASDA B2 drives from Delta. Looking at the manual it seems they
have a similar alarm like the ones you mentioned besides the overload
alarm.

The step + dir method is working excellent, I think I miss closing the loop
in the control because it's the way I was used to. Anyway, I have one
advantage having the feedback directly from the screw and that's in the
extreme case of belt failure in the X axis. As soon as the joint starts to
fall because of gravity the following error would be detected and turn off
the machine, inhibiting the solenoid of the brake in the X axis and saving
the joint from crashing with the part or the tailstock. But, apart from
that, I'm doing fine with open loop.

El sáb., 25 abr. 2020 a las 23:56, John Dammeyer ()
escribió:

>
> > Don't forget I'm running servos not steppers. But yes, I'm running them
> in
> > step+dir mode. This is the first time I'm using a servo with this control
> > method so I really don't know what could happen if a commanded movement
> > cannot be achieved. I suppose the servo will trigger an overload alarm or
> > something like that. I plan to swtich to analog mode sometime in the near
> > future because it's a better control method in my opinion. But for now we
> > had to go with the open loop config because we were really short of time.
> >
> What kind of driver are you using?  I've got HP_UHU on brushed DC servo's
> and a STMBL drive on the AC Servo Harmonic Drive.  In both cases those
> fault out if the following error doesn't match.  In other words, the drive
> counts the steps input and if the encoder pulses don't match the steps past
> a threshold the motor faults out.
>
> I've not ever faulted the AC Servo Bergerda drive but I'm pretty sure it
> also faults with a following error.
>
> So step/dir works fine for me.  There's no need to get the PC to do that
> for you.
>
> John Dammeyer
>
>
>
>
> ___
> 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] Help with some sporadic followin errors

[John Dammeyer]

 
> Don't forget I'm running servos not steppers. But yes, I'm running them in
> step+dir mode. This is the first time I'm using a servo with this control
> method so I really don't know what could happen if a commanded movement
> cannot be achieved. I suppose the servo will trigger an overload alarm or
> something like that. I plan to swtich to analog mode sometime in the near
> future because it's a better control method in my opinion. But for now we
> had to go with the open loop config because we were really short of time.
> 
What kind of driver are you using?  I've got HP_UHU on brushed DC servo's and a 
STMBL drive on the AC Servo Harmonic Drive.  In both cases those fault out if 
the following error doesn't match.  In other words, the drive counts the steps 
input and if the encoder pulses don't match the steps past a threshold the 
motor faults out.  

I've not ever faulted the AC Servo Bergerda drive but I'm pretty sure it also 
faults with a following error.

So step/dir works fine for me.  There's no need to get the PC to do that for 
you.

John Dammeyer




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

Re: [Emc-users] Help with some sporadic followin errors

[Leonardo Marsaglia]

>
> One caveat, if using backlash comp, I believe the margin goes up to 100%.
> At those turnaround speeds, steppers have maximum torque, but I'd also
> exercise the heck out of it to make sure I wasn't losing a step from
> over pushing it.  If that 100% makes it lose a step, then I'd reduce the
> maxvel and/or max_accel.  Max_accel first.


Hello Gene,

Don't forget I'm running servos not steppers. But yes, I'm running them in
step+dir mode. This is the first time I'm using a servo with this control
method so I really don't know what could happen if a commanded movement
cannot be achieved. I suppose the servo will trigger an overload alarm or
something like that. I plan to swtich to analog mode sometime in the near
future because it's a better control method in my opinion. But for now we
had to go with the open loop config because we were really short of time.

I didn't play with backlash compensation yet, I'll be tunning that this
monday and tell you how it goes. I'm pretty anxious about cutting some
lobes in that lathe :).

El sáb., 25 abr. 2020 a las 20:20, Gene Heskett ()
escribió:

> On Saturday 25 April 2020 18:26:45 Leonardo Marsaglia wrote:
>
> > So I should set the MAX_VELOCITY and MAX_ACCELERATION variables from
> > [JOINT_N] and [AXIS_N] up to 25% higher than the same variables in the
> > [TRAJ] section of the INI file right?
> >
> > And from what the pncconf ini says in the comments, the STEPGEN_MAXVEL
> > and STEPGEN_MAXACCEL variables should be also 25% higher than
> > MAX_VELOCITY and  MAX_ACCELERATION is that correct?
> >
> One caveat, if using backlash comp, I believe the margin goes up to 100%.
> At those turnaround speeds, steppers have maximum torque, but I'd also
> exercise the heck out of it to make sure I wasn't losing a step from
> over pushing it.  If that 100% makes it lose a step, then I'd reduce the
> maxvel and/or max_accel.  Max_accel first.
> >
> >
> > El sáb., 25 abr. 2020 a las 19:07, Peter C. Wallace
> > ()
> >
> > escribió:
> > > On Sat, 25 Apr 2020, Gene Heskett wrote:
> > > > Date: Sat, 25 Apr 2020 17:09:33 -0400
> > > > From: Gene Heskett 
> > > > Reply-To: "Enhanced Machine Controller (EMC)"
> > > > 
> > > > To: emc-users@lists.sourceforge.net
> > > > Subject: Re: [Emc-users] Help with some sporadic followin errors
> > > >
> > > > On Saturday 25 April 2020 17:04:50 Peter C. Wallace wrote:
> > > >> On Sat, 25 Apr 2020, Leonardo Marsaglia wrote:
> > > >>> Date: Sat, 25 Apr 2020 16:53:40 -0300
> > > >>> From: Leonardo Marsaglia 
> > > >>> Reply-To: "Enhanced Machine Controller (EMC)"
> > > >>> 
> > > >>> To: "Enhanced Machine Controller (EMC)"
> > > >>>  Subject: [Emc-users] Help with
> > > >>> some sporadic followin errors
> > > >>>
> > > >>> Hello to all,
> > > >>>
> > > >>> We've almost finished to wire and configure the mazak to work
> > > >>> with LCNC. So far, joint movements  and homing are working
> > > >>> flawlessly. I'm using servos in step+dir mode so no real
> > > >>> feedback is coming from the joints of the machine.
> > > >>>
> > > >>> I happen to have some following erros on both X and Z axis from
> > > >>> time to time, mostly when the machine is not homed (but that
> > > >>> could be my impression). Anyway, I get the following error once
> > > >>> the machine is home too. I cut the servo thread period in half
> > > >>> to 50 ns and it seemed to improve a little but I still get
> > > >>> the errors from time to time.
> > > >>>
> > > >>> I'm posting my HAL and INI files so you can take a look at them.
> > > >>> I really don't know what's causing this. By the way, so far I
> > > >>> only got the error when jogging the machine by hand, but never
> > > >>> with g code.
> > > >>>
> > > >>> Please let me know if there's something I can do to fix this
> > > >>> behaviours. I'll be uploading some videos in a few days.
> > > >>>
> > > >>> Thanks as always!
> > > >>>
> > > >>> Leonardo
> > > >>
> > > >> I would delete the read/write GPIO functions, and set the stepgen
> > > >> maxaccel and maxvel to 25% higher than the machine limits (they
> > > >> are likely set too close currently)
> > > >
> > > > Sounds like good advice, but which ini var is considered the
> > > > machine speed limits?
> > > >
> > > > Thanks Peter.
> > >
> > > The per axis and per joint maxvels
> > >
> > >
> > >
> > > Peter Wallace
> > > Mesa Electronics
> > >
> > >
> > > ___
> > > 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
>
>
> 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. 

Re: [Emc-users] Help with some sporadic followin errors

[Leonardo Marsaglia]

>
> The basic following error in MIN_FERROR, which is effective
> even at zero velocity.
> I note in your .ini file, you have increased FERROR, but
> MIN_FERROR - 0.01
> which in mm user units is quite small.


 Hello Jon,

I've been playing with that config for so many weeks that I don't really
remember if I changed it or not. Anyway, I will increase the MIN_FERROR
just a little bit to see what happens. I'll be trying this on monday. Also
I'll do what Peter sugested too. Fortunately the machine is working like a
charm, this is the only problem I ran into so far.

El sáb., 25 abr. 2020 a las 20:20, Gene Heskett ()
escribió:

> On Saturday 25 April 2020 18:26:45 Leonardo Marsaglia wrote:
>
> > So I should set the MAX_VELOCITY and MAX_ACCELERATION variables from
> > [JOINT_N] and [AXIS_N] up to 25% higher than the same variables in the
> > [TRAJ] section of the INI file right?
> >
> > And from what the pncconf ini says in the comments, the STEPGEN_MAXVEL
> > and STEPGEN_MAXACCEL variables should be also 25% higher than
> > MAX_VELOCITY and  MAX_ACCELERATION is that correct?
> >
> One caveat, if using backlash comp, I believe the margin goes up to 100%.
> At those turnaround speeds, steppers have maximum torque, but I'd also
> exercise the heck out of it to make sure I wasn't losing a step from
> over pushing it.  If that 100% makes it lose a step, then I'd reduce the
> maxvel and/or max_accel.  Max_accel first.
> >
> >
> > El sáb., 25 abr. 2020 a las 19:07, Peter C. Wallace
> > ()
> >
> > escribió:
> > > On Sat, 25 Apr 2020, Gene Heskett wrote:
> > > > Date: Sat, 25 Apr 2020 17:09:33 -0400
> > > > From: Gene Heskett 
> > > > Reply-To: "Enhanced Machine Controller (EMC)"
> > > > 
> > > > To: emc-users@lists.sourceforge.net
> > > > Subject: Re: [Emc-users] Help with some sporadic followin errors
> > > >
> > > > On Saturday 25 April 2020 17:04:50 Peter C. Wallace wrote:
> > > >> On Sat, 25 Apr 2020, Leonardo Marsaglia wrote:
> > > >>> Date: Sat, 25 Apr 2020 16:53:40 -0300
> > > >>> From: Leonardo Marsaglia 
> > > >>> Reply-To: "Enhanced Machine Controller (EMC)"
> > > >>> 
> > > >>> To: "Enhanced Machine Controller (EMC)"
> > > >>>  Subject: [Emc-users] Help with
> > > >>> some sporadic followin errors
> > > >>>
> > > >>> Hello to all,
> > > >>>
> > > >>> We've almost finished to wire and configure the mazak to work
> > > >>> with LCNC. So far, joint movements  and homing are working
> > > >>> flawlessly. I'm using servos in step+dir mode so no real
> > > >>> feedback is coming from the joints of the machine.
> > > >>>
> > > >>> I happen to have some following erros on both X and Z axis from
> > > >>> time to time, mostly when the machine is not homed (but that
> > > >>> could be my impression). Anyway, I get the following error once
> > > >>> the machine is home too. I cut the servo thread period in half
> > > >>> to 50 ns and it seemed to improve a little but I still get
> > > >>> the errors from time to time.
> > > >>>
> > > >>> I'm posting my HAL and INI files so you can take a look at them.
> > > >>> I really don't know what's causing this. By the way, so far I
> > > >>> only got the error when jogging the machine by hand, but never
> > > >>> with g code.
> > > >>>
> > > >>> Please let me know if there's something I can do to fix this
> > > >>> behaviours. I'll be uploading some videos in a few days.
> > > >>>
> > > >>> Thanks as always!
> > > >>>
> > > >>> Leonardo
> > > >>
> > > >> I would delete the read/write GPIO functions, and set the stepgen
> > > >> maxaccel and maxvel to 25% higher than the machine limits (they
> > > >> are likely set too close currently)
> > > >
> > > > Sounds like good advice, but which ini var is considered the
> > > > machine speed limits?
> > > >
> > > > Thanks Peter.
> > >
> > > The per axis and per joint maxvels
> > >
> > >
> > >
> > > Peter Wallace
> > > Mesa Electronics
> > >
> > >
> > > ___
> > > 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
>
>
> 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
>

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

Re: [Emc-users] Help with some sporadic followin errors

[Gene Heskett]

On Saturday 25 April 2020 18:26:45 Leonardo Marsaglia wrote:

> So I should set the MAX_VELOCITY and MAX_ACCELERATION variables from
> [JOINT_N] and [AXIS_N] up to 25% higher than the same variables in the
> [TRAJ] section of the INI file right?
>
> And from what the pncconf ini says in the comments, the STEPGEN_MAXVEL
> and STEPGEN_MAXACCEL variables should be also 25% higher than 
> MAX_VELOCITY and  MAX_ACCELERATION is that correct?
>
One caveat, if using backlash comp, I believe the margin goes up to 100%. 
At those turnaround speeds, steppers have maximum torque, but I'd also 
exercise the heck out of it to make sure I wasn't losing a step from 
over pushing it.  If that 100% makes it lose a step, then I'd reduce the 
maxvel and/or max_accel.  Max_accel first. 
>
>
> El sáb., 25 abr. 2020 a las 19:07, Peter C. Wallace
> ()
>
> escribió:
> > On Sat, 25 Apr 2020, Gene Heskett wrote:
> > > Date: Sat, 25 Apr 2020 17:09:33 -0400
> > > From: Gene Heskett 
> > > Reply-To: "Enhanced Machine Controller (EMC)"
> > > 
> > > To: emc-users@lists.sourceforge.net
> > > Subject: Re: [Emc-users] Help with some sporadic followin errors
> > >
> > > On Saturday 25 April 2020 17:04:50 Peter C. Wallace wrote:
> > >> On Sat, 25 Apr 2020, Leonardo Marsaglia wrote:
> > >>> Date: Sat, 25 Apr 2020 16:53:40 -0300
> > >>> From: Leonardo Marsaglia 
> > >>> Reply-To: "Enhanced Machine Controller (EMC)"
> > >>> 
> > >>> To: "Enhanced Machine Controller (EMC)"
> > >>>  Subject: [Emc-users] Help with
> > >>> some sporadic followin errors
> > >>>
> > >>> Hello to all,
> > >>>
> > >>> We've almost finished to wire and configure the mazak to work
> > >>> with LCNC. So far, joint movements  and homing are working
> > >>> flawlessly. I'm using servos in step+dir mode so no real
> > >>> feedback is coming from the joints of the machine.
> > >>>
> > >>> I happen to have some following erros on both X and Z axis from
> > >>> time to time, mostly when the machine is not homed (but that
> > >>> could be my impression). Anyway, I get the following error once
> > >>> the machine is home too. I cut the servo thread period in half
> > >>> to 50 ns and it seemed to improve a little but I still get
> > >>> the errors from time to time.
> > >>>
> > >>> I'm posting my HAL and INI files so you can take a look at them.
> > >>> I really don't know what's causing this. By the way, so far I
> > >>> only got the error when jogging the machine by hand, but never
> > >>> with g code.
> > >>>
> > >>> Please let me know if there's something I can do to fix this
> > >>> behaviours. I'll be uploading some videos in a few days.
> > >>>
> > >>> Thanks as always!
> > >>>
> > >>> Leonardo
> > >>
> > >> I would delete the read/write GPIO functions, and set the stepgen
> > >> maxaccel and maxvel to 25% higher than the machine limits (they
> > >> are likely set too close currently)
> > >
> > > Sounds like good advice, but which ini var is considered the
> > > machine speed limits?
> > >
> > > Thanks Peter.
> >
> > The per axis and per joint maxvels
> >
> >
> >
> > Peter Wallace
> > Mesa Electronics
> >
> >
> > ___
> > 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


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] Help with some sporadic followin errors

[Jon Elson]

On 04/25/2020 02:53 PM, Leonardo Marsaglia wrote:


I happen to have some following erros on both X and Z axis from time to
time, mostly when the machine is not homed (but that could be my
impression).
For historical reasons, the naming of the following error 
parameters are confusing.
FERROR is a proportional addition to the following error 
limit, such that at a velocity

of n user units per seconds, FERROR * n is added to MIN_FERROR.

The basic following error in MIN_FERROR, which is effective 
even at zero velocity.
I note in your .ini file, you have increased FERROR, but 
MIN_FERROR - 0.01

which in mm user units is quite small.

Jon


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

Re: [Emc-users] Help with some sporadic followin errors

[Leonardo Marsaglia]

So I should set the MAX_VELOCITY and MAX_ACCELERATION variables from
[JOINT_N] and [AXIS_N] up to 25% higher than the same variables in the
[TRAJ] section of the INI file right?

And from what the pncconf ini says in the comments, the STEPGEN_MAXVEL and
STEPGEN_MAXACCEL variables should be also 25% higher than  MAX_VELOCITY
and  MAX_ACCELERATION is that correct?



El sáb., 25 abr. 2020 a las 19:07, Peter C. Wallace ()
escribió:

> On Sat, 25 Apr 2020, Gene Heskett wrote:
>
> > Date: Sat, 25 Apr 2020 17:09:33 -0400
> > From: Gene Heskett 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] Help with some sporadic followin errors
> >
> > On Saturday 25 April 2020 17:04:50 Peter C. Wallace wrote:
> >
> >> On Sat, 25 Apr 2020, Leonardo Marsaglia wrote:
> >>> Date: Sat, 25 Apr 2020 16:53:40 -0300
> >>> From: Leonardo Marsaglia 
> >>> Reply-To: "Enhanced Machine Controller (EMC)"
> >>> 
> >>> To: "Enhanced Machine Controller (EMC)"
> >>>  Subject: [Emc-users] Help with
> >>> some sporadic followin errors
> >>>
> >>> Hello to all,
> >>>
> >>> We've almost finished to wire and configure the mazak to work with
> >>> LCNC. So far, joint movements  and homing are working flawlessly.
> >>> I'm using servos in step+dir mode so no real feedback is coming from
> >>> the joints of the machine.
> >>>
> >>> I happen to have some following erros on both X and Z axis from time
> >>> to time, mostly when the machine is not homed (but that could be my
> >>> impression). Anyway, I get the following error once the machine is
> >>> home too. I cut the servo thread period in half to 50 ns and it
> >>> seemed to improve a little but I still get the errors from time to
> >>> time.
> >>>
> >>> I'm posting my HAL and INI files so you can take a look at them. I
> >>> really don't know what's causing this. By the way, so far I only got
> >>> the error when jogging the machine by hand, but never with g code.
> >>>
> >>> Please let me know if there's something I can do to fix this
> >>> behaviours. I'll be uploading some videos in a few days.
> >>>
> >>> Thanks as always!
> >>>
> >>> Leonardo
> >>
> >> I would delete the read/write GPIO functions, and set the stepgen
> >> maxaccel and maxvel to 25% higher than the machine limits (they are
> >> likely set too close currently)
> >>
> > Sounds like good advice, but which ini var is considered the machine
> > speed limits?
> >
> > Thanks Peter.
>
>
> The per axis and per joint maxvels
>
>
>
> Peter Wallace
> Mesa Electronics
>
>
> ___
> 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] Help with some sporadic followin errors

[Gene Heskett]

On Saturday 25 April 2020 17:04:50 Peter C. Wallace wrote:

> On Sat, 25 Apr 2020, Leonardo Marsaglia wrote:
> > Date: Sat, 25 Apr 2020 16:53:40 -0300
> > From: Leonardo Marsaglia 
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > 
> > To: "Enhanced Machine Controller (EMC)"
> >  Subject: [Emc-users] Help with
> > some sporadic followin errors
> >
> > Hello to all,
> >
> > We've almost finished to wire and configure the mazak to work with
> > LCNC. So far, joint movements  and homing are working flawlessly.
> > I'm using servos in step+dir mode so no real feedback is coming from
> > the joints of the machine.
> >
> > I happen to have some following erros on both X and Z axis from time
> > to time, mostly when the machine is not homed (but that could be my
> > impression). Anyway, I get the following error once the machine is
> > home too. I cut the servo thread period in half to 50 ns and it
> > seemed to improve a little but I still get the errors from time to
> > time.
> >
> > I'm posting my HAL and INI files so you can take a look at them. I
> > really don't know what's causing this. By the way, so far I only got
> > the error when jogging the machine by hand, but never with g code.
> >
> > Please let me know if there's something I can do to fix this
> > behaviours. I'll be uploading some videos in a few days.
> >
> > Thanks as always!
> >
> > Leonardo
>
> I would delete the read/write GPIO functions, and set the stepgen
> maxaccel and maxvel to 25% higher than the machine limits (they are
> likely set too close currently)
>
Sounds like good advice, but which ini var is considered the machine 
speed limits?

Thanks Peter.

> Peter Wallace
> Mesa Electronics
>
>
>
> ___
> 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] Help with some sporadic followin errors

[Peter C. Wallace]

On Sat, 25 Apr 2020, Leonardo Marsaglia wrote:


Date: Sat, 25 Apr 2020 16:53:40 -0300
From: Leonardo Marsaglia 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: [Emc-users] Help with some sporadic followin errors

Hello to all,

We've almost finished to wire and configure the mazak to work with LCNC. So
far, joint movements  and homing are working flawlessly. I'm using servos
in step+dir mode so no real feedback is coming from the joints of the
machine.

I happen to have some following erros on both X and Z axis from time to
time, mostly when the machine is not homed (but that could be my
impression). Anyway, I get the following error once the machine is home
too. I cut the servo thread period in half to 50 ns and it seemed to
improve a little but I still get the errors from time to time.

I'm posting my HAL and INI files so you can take a look at them. I really
don't know what's causing this. By the way, so far I only got the error
when jogging the machine by hand, but never with g code.

Please let me know if there's something I can do to fix this behaviours.
I'll be uploading some videos in a few days.

Thanks as always!

Leonardo



I would delete the read/write GPIO functions, and set the stepgen maxaccel and 
maxvel to 25% higher than the machine limits (they are likely set too close 
currently)


Peter Wallace
Mesa Electronics



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

[Emc-users] Help with some sporadic followin errors

[Leonardo Marsaglia]

Hello to all,

We've almost finished to wire and configure the mazak to work with LCNC. So
far, joint movements  and homing are working flawlessly. I'm using servos
in step+dir mode so no real feedback is coming from the joints of the
machine.

I happen to have some following erros on both X and Z axis from time to
time, mostly when the machine is not homed (but that could be my
impression). Anyway, I get the following error once the machine is home
too. I cut the servo thread period in half to 50 ns and it seemed to
improve a little but I still get the errors from time to time.

I'm posting my HAL and INI files so you can take a look at them. I really
don't know what's causing this. By the way, so far I only got the error
when jogging the machine by hand, but never with g code.

Please let me know if there's something I can do to fix this behaviours.
I'll be uploading some videos in a few days.

Thanks as always!

Leonardo


Mazak_QT20.hal
Description: Binary data


Mazak_QT20.ini
Description: Binary data
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Encoder reset on homing to index

[Peter C. Wallace]

On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 14:21:45 -0400
From: David Berndt 
To: "Enhanced Machine Controller (EMC)" ,
Peter C. Wallace 
Subject: Re: [Emc-users] Encoder reset on homing to index

Thanks for the feedback Peter.

I took the time to re-order my hal file (it's a bit of a disaster with all 
the other non motion going-ons in there).


Here is the relevant start of m addf's


addf hm2_5i25.0.read  servo-thread
addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf pid.x.do-pid-calcs   servo-thread
addf pid.y.do-pid-calcs   servo-thread #rotary
addf pid.y2.do-pid-calcs  servo-thread #linear
addf pid.z.do-pid-calcs   servo-thread
addf pid.a.do-pid-calcs   servo-thread
addf pid.s.do-pid-calcs   servo-thread

addf sum2.3   servo-thread#pid.y.output +pid.y2.output -> 
'y-output' -> hm2_5i25.0.7i77.0.1.analogout1


addf hm2_5i25.0.write servo-thread


I excluded all the stuff below which is are things like servo amp ready, amp 
fault, coolant, spindle speed, spindle amp draw, f-error tracking, stuff that 
happens in servo-thread but isn't exciting or relevant to motion in a 
realtime way.


Yes, PID.y.index-enable, pid.y2.index-enable, hm2encoder.03.index-enable, 
and hm2...encoder.01.index-enable are all plumbed up and I show them going 
TRUE during homing.


When I went out to the cold mill this AM and started fooling around I noticed 
I was getting some following errors even in my previously configured 
"acceptable" config which was driving axis.1.motor-pos-fb from the rotary 
encoder still. Some hal-scoping around shows that maybe with the change I 
need some re-tuning at higher speeds.


The need for retuning made me think that perhaps if the tuning was 
questionable and that lead to a bit of runaway condition at higher speeds 
then perhaps if I just decreased the max speed and tried assigning the linear 
encoder pos fb to axis pos fb I might see an improvement.


So I did that, and it did. I'm now jogging back and forth at half the old max 
speed and doing some basic G-code tests with the linear axis being 
axis.1.motor-pos-fb. Which is nice because the GUI displays more enjoyable 
numbers.


I'm not sure which change contributed to what, HAL reorder/cleanup, or 
tuning.



My homing situation hasn't really changed. I still have to home twice to get 
a completed homing cycle. I once got persistent runaway after homing (caught 
quickly by f-error), but it wasn't self correcting, turning the machine on 
again (f2) just led to another immediate runaway. Restarted linuxcnc to try 
again and all was well. Interesting problems.



So as it stands now, homing (i have no idea what to actually try/change, it's 
broken but also kind of fine...) , and more tuning (assuming it's not a fools 
errand to change tuning with the addition of a linear scale...) are my next 
steps.




-Dave



I suspect you will have to track down whats going on with halscope (triggered by 
index-enable going low) and monitor the commanded position, feedback position

and PID output



On Sat, 25 Apr 2020 09:44:14 -0400, Peter C. Wallace  wrote:


On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 03:23:20 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"
   
To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Encoder reset on homing to index
After a few more hours tonight putzing around with this thing. Here's 
where I'm at.


I've wired up the shared index. It completes both the encoder's 
index-enable cycles. encoder.NRotary.position and encoder.nLinear.position 
both reset to ~0. Home is also at 0 as is homeoffset, so once index is 
found there should be no need for the axis to move. However it takes off 
and gets caught by a fairly strict ferror.


If I then home it again the result seems to be close enough that the small 
post-index-enable completion jump is within f-error. The axis moves a few 
.001" and settles. I'm not sure what's causing this jump in the 
first/second homing. Because of the ferror the first homing attempt does 
not actually complete the homing cycle, ishomed is not set.


For the homing thing, I may setup a mux to turn off the 
pid.yLinear.output. Maybe leave it off until everythings homed, or 
everythings homed + some time, or some other benchmark. My machine spends 
very little of it's time in an unhomed state and the control tends to stay 
on 99% of the time so homing/rehoming isn't really much of a priority. Or 
maybe abandon indexed homing.



It would also be nice to be able to feed pid.yLinear.feedback into 
axis.1.motor-pos-fb. But that's a recipe for the axis taking off/tripping 
ferror instantly. I'm not sure why, I can watch the pid.yRotary.feedback 
and pidyLinear.feedback and they're quite close to each other. I think 
this works fine pre-homed and breaks after homing but I'd have to re-run 
that experiment to be 

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

Thanks for the feedback Peter.

I took the time to re-order my hal file (it's a bit of a disaster with all  
the other non motion going-ons in there).


Here is the relevant start of m addf's


addf hm2_5i25.0.read  servo-thread
addf motion-command-handler   servo-thread
addf motion-controllerservo-thread
addf pid.x.do-pid-calcs   servo-thread
addf pid.y.do-pid-calcs   servo-thread #rotary
addf pid.y2.do-pid-calcs  servo-thread #linear
addf pid.z.do-pid-calcs   servo-thread
addf pid.a.do-pid-calcs   servo-thread
addf pid.s.do-pid-calcs   servo-thread

addf sum2.3   servo-thread#pid.y.output +pid.y2.output  
-> 'y-output' -> hm2_5i25.0.7i77.0.1.analogout1


addf hm2_5i25.0.write servo-thread


I excluded all the stuff below which is are things like servo amp ready,  
amp fault, coolant, spindle speed, spindle amp draw, f-error tracking,  
stuff that happens in servo-thread but isn't exciting or relevant to  
motion in a realtime way.


Yes, PID.y.index-enable, pid.y2.index-enable,  
hm2encoder.03.index-enable, and hm2...encoder.01.index-enable are all  
plumbed up and I show them going TRUE during homing.


When I went out to the cold mill this AM and started fooling around I  
noticed I was getting some following errors even in my previously  
configured "acceptable" config which was driving axis.1.motor-pos-fb from  
the rotary encoder still. Some hal-scoping around shows that maybe with  
the change I need some re-tuning at higher speeds.


The need for retuning made me think that perhaps if the tuning was  
questionable and that lead to a bit of runaway condition at higher speeds  
then perhaps if I just decreased the max speed and tried assigning the  
linear encoder pos fb to axis pos fb I might see an improvement.


So I did that, and it did. I'm now jogging back and forth at half the old  
max speed and doing some basic G-code tests with the linear axis being  
axis.1.motor-pos-fb. Which is nice because the GUI displays more enjoyable  
numbers.


I'm not sure which change contributed to what, HAL reorder/cleanup, or  
tuning.



My homing situation hasn't really changed. I still have to home twice to  
get a completed homing cycle. I once got persistent runaway after homing  
(caught quickly by f-error), but it wasn't self correcting, turning the  
machine on again (f2) just led to another immediate runaway. Restarted  
linuxcnc to try again and all was well. Interesting problems.



So as it stands now, homing (i have no idea what to actually try/change,  
it's broken but also kind of fine...) , and more tuning (assuming it's not  
a fools errand to change tuning with the addition of a linear scale...)  
are my next steps.




-Dave


On Sat, 25 Apr 2020 09:44:14 -0400, Peter C. Wallace   
wrote:



On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 03:23:20 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)"  


Subject: Re: [Emc-users] Encoder reset on homing to index
 After a few more hours tonight putzing around with this thing. Here's  
where I'm at.


I've wired up the shared index. It completes both the encoder's  
index-enable cycles. encoder.NRotary.position and  
encoder.nLinear.position both reset to ~0. Home is also at 0 as is  
homeoffset, so once index is found there should be no need for the axis  
to move. However it takes off and gets caught by a fairly strict ferror.


If I then home it again the result seems to be close enough that the  
small post-index-enable completion jump is within f-error. The axis  
moves a few .001" and settles. I'm not sure what's causing this jump in  
the first/second homing. Because of the ferror the first homing attempt  
does not actually complete the homing cycle, ishomed is not set.


For the homing thing, I may setup a mux to turn off the  
pid.yLinear.output. Maybe leave it off until everythings homed, or  
everythings homed + some time, or some other benchmark. My machine  
spends very little of it's time in an unhomed state and the control  
tends to stay on 99% of the time so homing/rehoming isn't really much  
of a priority. Or maybe abandon indexed homing.



It would also be nice to be able to feed pid.yLinear.feedback into  
axis.1.motor-pos-fb. But that's a recipe for the axis taking  
off/tripping ferror instantly. I'm not sure why, I can watch the  
pid.yRotary.feedback and pidyLinear.feedback and they're quite close to  
each other. I think this works fine pre-homed and breaks after homing  
but I'd have to re-run that experiment to be sure. Seeing the machine  
@actual position being off a few thou is really disconcerting. I can  
always press the @ to switch to machine commanded, which is (hopefully,  
if the linear is more accurate) much closer to reality.



-Dave


Is the index enable signal wired to both PID components in hal?

Also What is the thread order?
(it should be 

[Emc-users] New debs for armhf are available

[Gene Heskett]

At the usual place, click on the link in my sig.  When you see my ancient 
pix, add 'lathe-stf/' to the address and hit enter.

You'll get a directory listing, click on 'linuxcnc4rpi4' and you should 
be there.

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] Encoder reset on homing to index

[Peter C. Wallace]

On Sat, 25 Apr 2020, David Berndt wrote:


Date: Sat, 25 Apr 2020 03:23:20 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"

To: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] Encoder reset on homing to index

After a few more hours tonight putzing around with this thing. Here's where 
I'm at.


I've wired up the shared index. It completes both the encoder's index-enable 
cycles. encoder.NRotary.position and encoder.nLinear.position both reset to 
~0. Home is also at 0 as is homeoffset, so once index is found there should 
be no need for the axis to move. However it takes off and gets caught by a 
fairly strict ferror.


If I then home it again the result seems to be close enough that the small 
post-index-enable completion jump is within f-error. The axis moves a few 
.001" and settles. I'm not sure what's causing this jump in the first/second 
homing. Because of the ferror the first homing attempt does not actually 
complete the homing cycle, ishomed is not set.


For the homing thing, I may setup a mux to turn off the pid.yLinear.output. 
Maybe leave it off until everythings homed, or everythings homed + some time, 
or some other benchmark. My machine spends very little of it's time in an 
unhomed state and the control tends to stay on 99% of the time so 
homing/rehoming isn't really much of a priority. Or maybe abandon indexed 
homing.



It would also be nice to be able to feed pid.yLinear.feedback into 
axis.1.motor-pos-fb. But that's a recipe for the axis taking off/tripping 
ferror instantly. I'm not sure why, I can watch the pid.yRotary.feedback and 
pidyLinear.feedback and they're quite close to each other. I think this works 
fine pre-homed and breaks after homing but I'd have to re-run that experiment 
to be sure. Seeing the machine @actual position being off a few thou is 
really disconcerting. I can always press the @ to switch to machine 
commanded, which is (hopefully, if the linear is more accurate) much closer 
to reality.



-Dave


Is the index enable signal wired to both PID components in hal?

Also What is the thread order?
(it should be hardware_read, motion, PID, hardware_write)


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] Encoder reset on homing to index

[andy pugh]

On Sat, 25 Apr 2020 at 01:03, David Berndt  wrote:

> Feels a bit unsatisfying though. I understand the timing issues (though
> I'm not sure with a slow homing cycle I should care) but not solving this
> in a reasonably elegant way in software seems like a fail to me.

To solve it _properly_ in the software you would need to solve it in
the FPGA software.

I don't think you need to worry about common grounds. If  each encoder
index can drive the Z inputs of one channel on the 7i77 it can drive
the Z input of two of them.
(Though if they are wired as differential inputs I am not sure if you
would go with parallel or serial)

I guess that the linear scale pulse is the one to use.

-- 
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, 1912


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

Re: [Emc-users] Encoder reset on homing to index

[David Berndt]

After a few more hours tonight putzing around with this thing. Here's  
where I'm at.


I've wired up the shared index. It completes both the encoder's  
index-enable cycles. encoder.NRotary.position and encoder.nLinear.position  
both reset to ~0. Home is also at 0 as is homeoffset, so once index is  
found there should be no need for the axis to move. However it takes off  
and gets caught by a fairly strict ferror.


If I then home it again the result seems to be close enough that the small  
post-index-enable completion jump is within f-error. The axis moves a few  
.001" and settles. I'm not sure what's causing this jump in the  
first/second homing. Because of the ferror the first homing attempt does  
not actually complete the homing cycle, ishomed is not set.


For the homing thing, I may setup a mux to turn off the  
pid.yLinear.output. Maybe leave it off until everythings homed, or  
everythings homed + some time, or some other benchmark. My machine spends  
very little of it's time in an unhomed state and the control tends to stay  
on 99% of the time so homing/rehoming isn't really much of a priority. Or  
maybe abandon indexed homing.



It would also be nice to be able to feed pid.yLinear.feedback into  
axis.1.motor-pos-fb. But that's a recipe for the axis taking off/tripping  
ferror instantly. I'm not sure why, I can watch the pid.yRotary.feedback  
and pidyLinear.feedback and they're quite close to each other. I think  
this works fine pre-homed and breaks after homing but I'd have to re-run  
that experiment to be sure. Seeing the machine @actual position being off  
a few thou is really disconcerting. I can always press the @ to switch to  
machine commanded, which is (hopefully, if the linear is more accurate)  
much closer to reality.



-Dave


On Fri, 24 Apr 2020 20:01:26 -0400, David Berndt   
wrote:


The rotary encoder is supplying it's own power (+5v) as it's the encoder  
relay/output from an amplifier and not directly from the rotary encoder.  
The linear encoder is using the inbuilt 7i77 5v. Common ground, at least  
I assume all the encoder inputs have a common ground... So I guess  
jumpering the index over shouldn't be a big deal.


Feels a bit unsatisfying though. I understand the timing issues (though  
I'm not sure with a slow homing cycle I should care) but not solving  
this in a reasonably elegant way in software seems like a fail to me.  
Maybe that's just the Covid Crankiness talking.


-Dave



On Fri, 24 Apr 2020 19:23:18 -0400, Peter C. Wallace   
wrote:



On Fri, 24 Apr 2020, David Berndt wrote:


Date: Fri, 24 Apr 2020 19:02:54 -0400
From: David Berndt 
To: "Enhanced Machine Controller (EMC)"  
,

Peter C. Wallace 
Subject: Re: [Emc-users] Encoder reset on homing to index
 If I understand you correctly that would be the goal. But how do I  
tie them together?


As I understand it now I'll need to detect when index-enable changes  
state to false, as an indication of the preferred index signal being  
detected. Then fire a oneshot to encoder.LinearNumber.reset



I was suggesting that you wire the preferred physical index signal
to both encoder inputs, Then connect motions index-enable pin to both
encoder index enables in hal, no one-shots or resets involved.

In general you would not want to do a physical encoder counter reset
in hal (at least when in motion) because:

1. Its not synchronized with the actual index signal so it will cause a  
somewhat random count error proportional to velocity (random because
the time of index occurance is random compared to the counter reset at  
the servo-thread write time)


2. Resetting the counter will corrupt the velocity calculation



-Dave



On Fri, 24 Apr 2020 18:20:07 -0400, Peter C. Wallace   
wrote:



On Fri, 24 Apr 2020, David Berndt wrote:


Date: Fri, 24 Apr 2020 17:19:10 -0400
From: David Berndt 
Reply-To: "Enhanced Machine Controller (EMC)"
   
To: emc-users@lists.sourceforge.net
Subject: [Emc-users] Encoder reset on homing to index
Can anyone enlighten me as to how hm2_5i25.0.encoder.N.position  
seems to get reset during homing to index? I assume somethnig is  
triggering hm2_5i25.0.encoder.N.reset? But I don't see that plumbed  
up anywhere in my HAL.
 I'm adding a linear encoder to a servo axis and am retaining my  
servo homing, but when it homes I need to zero the linear encoder as  
well if the rotary is going to zero to avoid huge f-errors and other  
issues...

 Thanks,
-Dave


 Why dont you use the preferred index signal to zero both encoders?


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

 Peter Wallace
Mesa Electronics
  ___
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
(")_(")