Re: [Emc-users] Encoder reset on homing to index
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 a
Re: [Emc-users] Encoder reset on homing to index
There's about .0015-.002" of backlash and an .0005" spring in the system at reasonably force levels at the highest points of stiction on the ways. I'm sure I could get more spring out of the system if I run an endmill into the vise, but we're not really testing that here. Ballscrews, precision Apex gearboxes, big metal couplings (whatever they brand is called) and reasonable ballscrew bearings, no belts, on a 5000lb universal mill. It's stiffer than the average 6040 router. Rotary scale works out to 254000/inch, Linear is 50800/inch. Running drives with +/-10v in torque mode. I tuned the system to work with the linear scales only. It sucks in terms of following error compared to what I've achieved with the rotary. Getting the acceleration errors out is a challenge with the linear scale (probably because those acceleration errors are actually real as opposed to the rotary that has no idea what table position really is). Still ~.001 following error isn't terrible. I then took the tuned linear and turned the sum2'ing with the rotary back on, so both loops are running, then I crank up the I term on the linear pid and let that run. It seems to give good results. I can run with the linear scale as the feedback into axis.1.motor-pos-fb. But I've given up on homing to index. It's not something I need that badly and I can't justify any more machine downtime for it really. I may consider instead of adding more I to the linear PID that perhaps I should play with the gain on the sum'ing of the two PID outputs. But I'm not sure that's useful. I also tried inserting the Linear PID result into the rotary BIAS, and although that worked it didn't do anything better than where I was at before. Currently If I g2 a 2"dia circle at 20IPM (a normal feed rate for me) the follow error at reversal peaks at ~.0006" as the backlash is pulled out. It's an improvement for sure. My time now would be better spent on finding a new ballscrew. -Dave On Sun, 26 Apr 2020 13:34:14 -0400, Roland Jollivet wrote: No-one has mentioned the mechanics of the system.. (or have they?) What is the mechanical coupling like between the stepper and the linear scale. Obviously it's most susceptible to backlash and belt stretch. If the stepper is holding fast, how much linear deviation can you get if you try move the carriage to and fro? (stiffness) Also, how many steps/linear increment? On Sun, 26 Apr 2020 at 16:47, dave engvall wrote: Not that I know much about this but: It is my understanding that the rotary because it has less quantatization error does a better job on control but unless your machine is very tight a poorer job on position. Early on I tried my machine with a 5 um linear glass scale. It was very difficult to tune. Later on tuning with a rotary encoder was a cinch by comparison. I've not tried both scales yet but that is where I'm headed. Conversation with Stu and the group that did the installation might shed some light. Does the information coming off the sensors need to be reallocated. Just thinking(?) out loud. On my machine, a well worn BP size, using I has never given me better following error. I get by with P, FF1, FF2, zero or very small D and no I. just my tuppence! Dave On 4/25/20 10:56 PM, David Berndt wrote: > 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 attachmen
[Emc-users] Encoder reset on homing to index
No-one has mentioned the mechanics of the system.. (or have they?) What is the mechanical coupling like between the stepper and the linear scale. Obviously it's most susceptible to backlash and belt stretch. If the stepper is holding fast, how much linear deviation can you get if you try move the carriage to and fro? (stiffness) Also, how many steps/linear increment? On Sun, 26 Apr 2020 at 16:47, dave engvall wrote: > Not that I know much about this but: It is my understanding that the > rotary because it has less quantatization error does a better job on > control but unless your machine is very tight a poorer job on position. > Early on I tried my machine with a 5 um linear glass scale. It was very > difficult to tune. Later on tuning with a rotary encoder was a cinch by > comparison. I've not tried both scales yet but that is where I'm headed. > Conversation with Stu and the group that did the installation might shed > some light. Does the information coming off the sensors need to be > reallocated. Just thinking(?) out loud. > > On my machine, a well worn BP size, using I has never given me better > following error. I get by with P, FF1, FF2, zero or very small D and no I. > > just my tuppence! > > Dave > > On 4/25/20 10:56 PM, David Berndt wrote: > > 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. > >>>
Re: [Emc-users] Encoder reset on homing to index
Not that I know much about this but: It is my understanding that the rotary because it has less quantatization error does a better job on control but unless your machine is very tight a poorer job on position. Early on I tried my machine with a 5 um linear glass scale. It was very difficult to tune. Later on tuning with a rotary encoder was a cinch by comparison. I've not tried both scales yet but that is where I'm headed. Conversation with Stu and the group that did the installation might shed some light. Does the information coming off the sensors need to be reallocated. Just thinking(?) out loud. On my machine, a well worn BP size, using I has never given me better following error. I get by with P, FF1, FF2, zero or very small D and no I. just my tuppence! Dave On 4/25/20 10:56 PM, David Berndt wrote: 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-controller servo-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 th
Re: [Emc-users] Encoder reset on homing to index
On Sun, 26 Apr 2020, David Berndt wrote: Date: Sun, 26 Apr 2020 01:56:05 -0400 From: David Berndt To: Peter C. Wallace Cc: "Enhanced Machine Controller (EMC)" Subject: Re: [Emc-users] Encoder reset on homing to index 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 You could also simplify things by using a single joint for Y 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 runa
Re: [Emc-users] Encoder reset on homing to index
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 stan
Re: [Emc-users] Encoder reset on homing to index
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. enco
Re: [Emc-users] Encoder reset on homing to index
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
Re: [Emc-users] Encoder reset on homing to index
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 a
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 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?
Re: [Emc-users] Encoder reset on homing to index
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
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
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
Re: [Emc-users] Encoder reset on homing to index
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
(")_(") 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
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
(")_(") 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
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 -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 ___ 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
Just a plain KA300 chinese linear encoder. On Fri, 24 Apr 2020 17:39:51 -0400, Leonardo Marsaglia wrote: Just because I'm curious, Is this an absolute linear encoder or an incremental one (or may be it can work in both ways)? El vie., 24 abr. 2020 a las 18:28, andy pugh () escribió: On Fri, 24 Apr 2020 at 22:21, David Berndt wrote: > > 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? The encoder counts reset when encoder.N.index-enable is true and an index is seen. You can detect this as the index-enable goes false a the same time. -- 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 ___ 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] Encoder reset on homing to index
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
Re: [Emc-users] Encoder reset on homing to index
> > Index-enable enable is true when index-enable is false? Who designed this? > Politicians? The index-enable pin is IO so It's set to TRUE when the homing sequence requires it. You can also set it to TRUE via HAL (I'm doing the latter with my homing sequence because I'm using servos in step+dir mode without encoder feedback) Once is true, it stays in that value until the encoder triggers the physical index pulse. I'm passing it through an edge component because I'm using the index as a "second" home switch once the latch state of the homing sequence starts. El vie., 24 abr. 2020 a las 18:43, David Berndt () escribió: > Index-enable enable is true when index-enable is false? Who designed > this? > Politicians? > > I don't even know what to say as I try to wrap my mind around this one... > Isn't there some sane/simple way to just tie the index-enable out bit > from > the one encoder to the index-enable in bit on the second encoder? > > If I have to setup a whole bunch of oneshot shenanigans for this I'm > going > to be very disappointed. > > -Dave > > On Fri, 24 Apr 2020 17:25:00 -0400, andy pugh wrote: > > > On Fri, 24 Apr 2020 at 22:21, David Berndt wrote: > >> > >> 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? > > > > The encoder counts reset when encoder.N.index-enable is true and an > > index is seen. > > You can detect this as the index-enable goes false a the same time. > > > ___ > 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] Encoder reset on homing to index
Am Fr., 24. Apr. 2020 um 23:43 Uhr schrieb David Berndt : > Index-enable enable is true when index-enable is false? Who designed > this? > Politicians? > > I don't even know what to say as I try to wrap my mind around this one... > Isn't there some sane/simple way to just tie the index-enable out bit > from > the one encoder to the index-enable in bit on the second encoder? > > If I have to setup a whole bunch of oneshot shenanigans for this I'm > going > to be very disappointed. > the index is captured in hardware, not in software. otherwise you could miss it. http://linuxcnc.org/docs/html/man/man9/hostmot2.9.html#encoder > > -Dave > > On Fri, 24 Apr 2020 17:25:00 -0400, andy pugh wrote: > > > On Fri, 24 Apr 2020 at 22:21, David Berndt wrote: > >> > >> 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? > > > > The encoder counts reset when encoder.N.index-enable is true and an > > index is seen. > > You can detect this as the index-enable goes false a the same time. > > > ___ > 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] Encoder reset on homing to index
Index-enable enable is true when index-enable is false? Who designed this? Politicians? I don't even know what to say as I try to wrap my mind around this one... Isn't there some sane/simple way to just tie the index-enable out bit from the one encoder to the index-enable in bit on the second encoder? If I have to setup a whole bunch of oneshot shenanigans for this I'm going to be very disappointed. -Dave On Fri, 24 Apr 2020 17:25:00 -0400, andy pugh wrote: On Fri, 24 Apr 2020 at 22:21, David Berndt wrote: 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? The encoder counts reset when encoder.N.index-enable is true and an index is seen. You can detect this as the index-enable goes false a the same time. ___ 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
Just because I'm curious, Is this an absolute linear encoder or an incremental one (or may be it can work in both ways)? El vie., 24 abr. 2020 a las 18:28, andy pugh () escribió: > On Fri, 24 Apr 2020 at 22:21, David Berndt wrote: > > > > 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? > > The encoder counts reset when encoder.N.index-enable is true and an > index is seen. > You can detect this as the index-enable goes false a the same time. > > -- > 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 > ___ 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
On Fri, 24 Apr 2020 at 22:21, David Berndt wrote: > > 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? The encoder counts reset when encoder.N.index-enable is true and an index is seen. You can detect this as the index-enable goes false a the same time. -- 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
[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 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
