On Sat, 25 Apr 2020, David Berndt wrote:
Date: Sat, 25 Apr 2020 23:13:59 -0400
From: David Berndt <ber...@uberwin.com>
To: Peter C. Wallace <p...@mesanet.com>
Cc: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] Encoder reset on homing to index
Resent-Date: Sat, 25 Apr 2020 23:39:11 -0400
Resent-From: "David Berndt" <ber...@uberwin.com>
Resent-To: "emc-users@lists.sourceforge.net" <emc-users@lists.sourceforge.net>
Resent-cc: "Peter C. Wallace" <p...@mesanet.com>
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 <p...@mesanet.com>
wrote:
On Sat, 25 Apr 2020, David Berndt wrote:
Date: Sat, 25 Apr 2020 14:21:45 -0400
From: David Berndt <ber...@uberwin.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>,
Peter C. Wallace <p...@mesanet.com>
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 <p...@mesanet.com>
wrote:
On Sat, 25 Apr 2020, David Berndt wrote:
Date: Sat, 25 Apr 2020 03:23:20 -0400
From: David Berndt <ber...@uberwin.com>
Reply-To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
To: "Enhanced Machine Controller (EMC)"
<emc-users@lists.sourceforge.net>
Subject: Re: [Emc-users] 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
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
