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 <[email protected]>
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 <[email protected]>
wrote:
On Fri, 24 Apr 2020, David Berndt wrote:
Date: Fri, 24 Apr 2020 19:02:54 -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
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 <[email protected]>
wrote:
On Fri, 24 Apr 2020, David Berndt wrote:
Date: Fri, 24 Apr 2020 17:19:10 -0400
From: David Berndt <[email protected]>
Reply-To: "Enhanced Machine Controller (EMC)"
<[email protected]>
To: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
Peter Wallace
Mesa Electronics
_______________________________________________
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.
_______________________________________________
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
