Hal encoder bug?

More
18 Dec 2010 07:51 #6128 by garymcrobertpdx
There appears to be a bug in the hal encoder component.
The encoder.N.reset fails to reliably reset the encoder counts
and position. A encoder reset occurs about every third or fourth
reset pulse regardless of the pulse width or period.

I have spent several hours attempting to get reliable behavior with
no success, all I can conclude that this is a genuine bug.

Is this a known bug, is there a work around?

Please Log in or Create an account to join the conversation.

More
18 Dec 2010 13:00 #6135 by BigJohnT
Replied by BigJohnT on topic Re:Hal encoder bug?
Are you trying to read the encoder via the parallel port? A bit more info would be helpful to diagnose your problem.

John

Please Log in or Create an account to join the conversation.

More
18 Dec 2010 14:12 #6138 by andypugh
Replied by andypugh on topic Re:Hal encoder bug?
I can't see many ways for the reset to be buggy. (I have had a look at the code)

Can you pastebin your HAL file?

Please Log in or Create an account to join the conversation.

More
19 Dec 2010 21:51 #6170 by garymcrobertpdx
Replied by garymcrobertpdx on topic Re:Hal encoder bug?
My hardware at the moment is bench top test system and
A bit of a hack but it works well enough for experimenting.

I have a 2500 count / rev encoder from my junk box. I know
this is way more counts / rev than desired so I run things slow.
The encoder is attached to the output shaft of the step motor.

The index output is attached to parport pin 10, pins 11 & 12 are
attached to outputs A & B. With my Tek scope and I see a very
nice 4.5 volt 250 micro second index pulse.

My Hal code snippet
Net parport_10_in <= parport.0.pin-10-in => encoder.0.phase-z
Net parport_10_in => encoder.0.reset
Net parport_11_in <= parport.0.pin-11-in => encoder.0.phase-A
Net parport_12_in <= parport.0.pin-12-in => encoder.0.phase-B

Using Hal scope and Hal meter I observe encoder.0.position
and encoder.0.counts. These appear not to be reliably reset to
0 when encoder.0.reset = true.

Please Log in or Create an account to join the conversation.

More
19 Dec 2010 22:26 #6172 by PCW
Replied by PCW on topic Re:Hal encoder bug?
I think this is the expected behavior especially if you are running the encoder update part in a base thread
and the capture part in a servo thread.

If you want to clear the encoder count on index, you should probably use the normal homing method (set index enable, wait for index enable clear)

Please Log in or Create an account to join the conversation.

More
19 Dec 2010 23:03 #6173 by andypugh
Replied by andypugh on topic Re:Hal encoder bug?
Which threads are you running encoder.update-counters and encoder.capture-position in?
And what is the timing of each thread?

Please Log in or Create an account to join the conversation.

More
20 Dec 2010 18:43 #6189 by garymcrobertpdx
Replied by garymcrobertpdx on topic Re:Hal encoder bug?
The bulk of the hal code is created using the wizard, setup
for encoder use so I get thread assignments

addf Parport.0.read base-thread
addf encoder.update-counters base-thread

addf encoder.capture-postion servo-thread

From the ini file Base_period 50000 servo_period 1000000

I then put my few lines of code into the custom hal folder

My first attempted was to use the encoder.N.index-enable pin
but it is already linked to the motion.spindle-enable pin and
it is a bidirectional pin also.

Being a newbie I had was not sure how to work this out so
the other pin was an attractive option. unfortunately it works
differently than expected.

So is it that the servo period is to slow to capture the index
250 microsecond pulse and would work properly when I
run the code on my faster computer rather than the junker
that I have at my work bench

I have devised a not so elegant work around using G33 M5
to turn the spindle one rev and stop. Seems to work OK but
I rather not do it this way.

Please Log in or Create an account to join the conversation.

More
20 Dec 2010 19:03 #6191 by andypugh
Replied by andypugh on topic Re:Hal encoder bug?
garymcrobertpdx wrote:

So is it that the servo period is to slow to capture the index
250 microsecond pulse and would work properly when I
run the code on my faster computer rather than the junker
that I have at my work bench


No, you would generally always keep the servo period at 1mS, and the base thread period should be fine for capturing the reset pulse.
I was wondering if the update-counters function was running in the servo thread, which would explain the effect.

Out of interest, why are you wanting to reset the encoder?

You might find that the latch-enable etc pins do what you want. The actual source code is here, if you want to ponder in detail what the pins do.
git.linuxcnc.org/gitweb?p=emc2.git;a=blo...04eb0d55015e;hb=HEAD

It seems that the latch functions run in the base thread, but the reset only runs in the servo thread. This is probably reasonable, as the typical source of a reset pulse will run in the servo thread too.

Please Log in or Create an account to join the conversation.

More
20 Dec 2010 19:40 #6192 by garymcrobertpdx
Replied by garymcrobertpdx on topic Re:Hal encoder bug?
I am still pursuing the accurate positioning of my spindle.

I think it was you that suggested using a mux and a pid
and the tool change bit to accomplish this.

So I thought if I zeroed the encoder position on the index
Pulse, with the encoder position linked to the pid feedback
and set the pid command input to zero. With the pid output
linked to the stepgen which drives my spindle motor.

Hopefully this would cause the spindle to rotate to a repeatable
position for tool change. It seemed to work but then completely
miss the mark, that is when i discovered the reset problem.

Please Log in or Create an account to join the conversation.

More
21 Dec 2010 12:42 #6199 by andypugh
Replied by andypugh on topic Re:Hal encoder bug?
I think that you should be able to do what you want with latch_enable and position_latched.

I expect to find out some time next year, I have the same puzzle to solve.

Please Log in or Create an account to join the conversation.

Time to create page: 0.345 seconds
Powered by Kunena Forum