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 <[email protected]>
> wrote:
>
>> On Sat, 25 Apr 2020, David Berndt wrote:
>>
>>> Date: Sat, 25 Apr 2020 23:13:59 -0400
>>> From: David Berndt <[email protected]>
>>> To: Peter C. Wallace <[email protected]>
>>> Cc: "Enhanced Machine Controller (EMC)"
>>> <[email protected]>
>>> Subject: Re: [Emc-users] Encoder reset on homing to index
>>> Resent-Date: Sat, 25 Apr 2020 23:39:11 -0400
>>> Resent-From: "David Berndt" <[email protected]>
>>> Resent-To: "[email protected]"
>>> <[email protected]>
>>> Resent-cc: "Peter C. Wallace" <[email protected]>
>>> 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
<[email protected]>
>>> wrote:
>>>
>>>> On Sat, 25 Apr 2020, David Berndt wrote:
>>>>
>>>>> Date: Sat, 25 Apr 2020 14:21:45 -0400
>>>>> From: David Berndt <[email protected]>
>>>>> To: "Enhanced Machine Controller (EMC)"
>>>>> <[email protected]>,
>>>>> Peter C. Wallace <[email protected]>
>>>>> 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,
>>>>> hm2....encoder.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
>>>>> <[email protected]> wrote:
>>>>>
>>>>>> On Sat, 25 Apr 2020, David Berndt wrote:
>>>>>>
>>>>>>> Date: Sat, 25 Apr 2020 03:23:20 -0400
>>>>>>> From: David Berndt <[email protected]>
>>>>>>> Reply-To: "Enhanced Machine Controller (EMC)"
>>>>>>> <[email protected]>
>>>>>>> To: "Enhanced Machine Controller (EMC)"
>>>>>>> <[email protected]>
>>>>>>> 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
>>>>>> [email protected]
>>>>>> 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.
>>
>> Peter Wallace
>> Mesa Electronics
>>
>> (\__/)
>> (='.'=) This is Bunny. Copy and paste bunny into your
>> (")_(") signature to help him gain world domination.
>
>
> _______________________________________________
> Emc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-users
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
