Hal encoder bug?
- garymcrobertpdx
- Offline
- Premium Member
-
Less
More
- Posts: 101
- Thank you received: 1
22 Dec 2010 16:42 #6212
by garymcrobertpdx
Replied by garymcrobertpdx on topic Re:Hal encoder bug?
I looked at the encoder documentation here linuxcnc.org/docs/html/man/man9/encoder.9.html
but do not understand how I can make use of the the latch_enable and position_latched pins to
achieve positioning of the spindle.
Could you give me a quick synopses of how you would use these
but do not understand how I can make use of the the latch_enable and position_latched pins to
achieve positioning of the spindle.
Could you give me a quick synopses of how you would use these
Please Log in or Create an account to join the conversation.
22 Dec 2010 17:31 #6213
by andypugh
Replied by andypugh on topic Re:Hal encoder bug?
garymcrobertpdx wrote:
I can give you a quick guess, but that is all it is.
It seems that if latch-enable is true then position-latched and counts-latched are zeroed every time a rising (or falling, dependent on the latch-rising and latch-falling parameters) pulse is seen on the latch-in pin. This is all based on looking at the source code, the docs seem less than clear.
So, you could setp latch-enable to true, latch-rising to true and latch-faling to false in the HAL file, net the index pulse to latch-in and then the position-latched pin would always read out in full turns since the index (assuming that at least one index has been seen, your tool-change might need to run the spindle briefly)
You can probably then home the spindle to position-latched = 0.5 using a PID and you should end up with a consistent spindle alignment.
But you probably need to experiment with halscope, halmeter and your hardware turning the spindle by hand to make sure I don't have the wrong end of the stick….
Could you give me a quick synopses of how you would use these
I can give you a quick guess, but that is all it is.
It seems that if latch-enable is true then position-latched and counts-latched are zeroed every time a rising (or falling, dependent on the latch-rising and latch-falling parameters) pulse is seen on the latch-in pin. This is all based on looking at the source code, the docs seem less than clear.
So, you could setp latch-enable to true, latch-rising to true and latch-faling to false in the HAL file, net the index pulse to latch-in and then the position-latched pin would always read out in full turns since the index (assuming that at least one index has been seen, your tool-change might need to run the spindle briefly)
You can probably then home the spindle to position-latched = 0.5 using a PID and you should end up with a consistent spindle alignment.
But you probably need to experiment with halscope, halmeter and your hardware turning the spindle by hand to make sure I don't have the wrong end of the stick….
Please Log in or Create an account to join the conversation.
- garymcrobertpdx
- Offline
- Premium Member
-
Less
More
- Posts: 101
- Thank you received: 1
30 Dec 2010 00:20 #6323
by garymcrobertpdx
Replied by garymcrobertpdx on topic Tool changer via Hal
Perhaps another way of getting the tool change to work.
Can I create a user space Hal component that is
Substituted for hal_manualtoolchange.
The new Hal component causes the execution
of a G code file. Since I have successfully
positioned the spindle using G33 I could then
do every thing with G code and return.
From then on all that is needed is M6 and Tn
In my regular G code programs
Can I create a user space Hal component that is
Substituted for hal_manualtoolchange.
The new Hal component causes the execution
of a G code file. Since I have successfully
positioned the spindle using G33 I could then
do every thing with G code and return.
From then on all that is needed is M6 and Tn
In my regular G code programs
Please Log in or Create an account to join the conversation.
30 Dec 2010 10:57 #6331
by andypugh
Replied by andypugh on topic Re:Tool changer via Hal
garymcrobertpdx wrote:
Yes, that is perfectly possible, and was probably how it was intended to be done. hal_manualtoolchange has the feel of a "placeholder"
This is actually rather more difficult, as the interpreter state is not really right at that point, and I don't know of any way to execute G-code from a HAL component.
One solution that I have proposed (but which requires code changes) is the option to specify a G-code subroutine to be run on toolchange. There are already quill-up and goto M30 options that can be specified in the INI file. I don't know how difficult the changes would be.
Can I create a user space Hal component that is
Substituted for hal_manualtoolchange.
Yes, that is perfectly possible, and was probably how it was intended to be done. hal_manualtoolchange has the feel of a "placeholder"
The new Hal component causes the execution
of a G code file.
This is actually rather more difficult, as the interpreter state is not really right at that point, and I don't know of any way to execute G-code from a HAL component.
One solution that I have proposed (but which requires code changes) is the option to specify a G-code subroutine to be run on toolchange. There are already quill-up and goto M30 options that can be specified in the INI file. I don't know how difficult the changes would be.
Please Log in or Create an account to join the conversation.
- garymcrobertpdx
- Offline
- Premium Member
-
Less
More
- Posts: 101
- Thank you received: 1
01 Jan 2011 22:20 #6352
by garymcrobertpdx
Replied by garymcrobertpdx on topic Encoder bug / tool change challenge
Success!!! I have succeeded in writing hal code that
allows the spindle to operate as it normally works
performing coordinated moves such as hard tapping.
While being able to orient the spindle to a fixed point
of rotation for tool change when a M6 is executed.
The problem with the encoder reset was an aliasing
problem when I decreased the servo thread period
to 200,000 ns rather than the stock 1,000,000 ns
the function works. I need to experiment a bit more
but 500,000 ns appeared to work also.
Next I want to rig a offset variable to allow fine
adjustment of the stop point rather than mechanically
tweaking the encoder. Then work out the details for
selecting and getting the tool into the spindle.
If anyone is interested I can share the code and gory
details of this adventure in spindle design land.
allows the spindle to operate as it normally works
performing coordinated moves such as hard tapping.
While being able to orient the spindle to a fixed point
of rotation for tool change when a M6 is executed.
The problem with the encoder reset was an aliasing
problem when I decreased the servo thread period
to 200,000 ns rather than the stock 1,000,000 ns
the function works. I need to experiment a bit more
but 500,000 ns appeared to work also.
Next I want to rig a offset variable to allow fine
adjustment of the stop point rather than mechanically
tweaking the encoder. Then work out the details for
selecting and getting the tool into the spindle.
If anyone is interested I can share the code and gory
details of this adventure in spindle design land.
Please Log in or Create an account to join the conversation.
01 Jan 2011 23:10 #6353
by andypugh
Replied by andypugh on topic Re:Encoder bug / tool change challenge
garymcrobertpdx wrote:
Glad to hear it. I think that the problems you have had might indicate that there is room for improvement in the way that spindle indexing is handled.
Success!!! I have succeeded in writing hal code that
allows the spindle to operate as it normally works
performing coordinated moves such as hard tapping.
While being able to orient the spindle to a fixed point
of rotation for tool change when a M6 is executed.
Glad to hear it. I think that the problems you have had might indicate that there is room for improvement in the way that spindle indexing is handled.
Please Log in or Create an account to join the conversation.
02 Jan 2011 13:26 #6362
by andypugh
Replied by andypugh on topic Re:Encoder bug / tool change challenge
garymcrobertpdx wrote:
I have been thinking some more about this.
The spindle may move too far in 500mS, and there seems little point in running the servo thread faster than normal just to make the toolchanger alignment work.
The index-enable pin is the "right" way to do it, as that runs in the base thread and will be exact to the limits of the encoder. You set the pin high, the instant the index is seen the encoder is zeroed, and the pin is set low again by the encoder function.
The problem (as you have found) is that the index-enable pin is "in use" by other parts of EMC2 for rigid tapping etc.
There is a simple solution to this, though. You can easily add a second encoder function, using the same A B and Z(index) inputs, for the use of the spindle alignment function. I think you can afford to leave the index-enable on that encoder permanently high. (This can't be done with a "setp" in the HAL file, as that runs once, and it will be reset on the first index, you would have to use the HAL "constant" function www.linuxcnc.org/docview/html/man/man9/constant.9.html )This should leave you with an encoder with a .position pin that cycles from 0 to 1 every rev. (or you can alter the scaling to give an angle in degrees, as this is an encoder only used by the toolchanger)
You could then run a PID with that position as the feedback.
To align the spindle to the exact orientation you want, simply change the PID .command pin value. It will tend to work poorly for values close to zero, but I imagine your toolholders should have 180 degree symmetry so this is not a big problem.
The problem with the encoder reset was an aliasing
problem when I decreased the servo thread period
to 200,000 ns rather than the stock 1,000,000 ns
the function works.
I have been thinking some more about this.
The spindle may move too far in 500mS, and there seems little point in running the servo thread faster than normal just to make the toolchanger alignment work.
The index-enable pin is the "right" way to do it, as that runs in the base thread and will be exact to the limits of the encoder. You set the pin high, the instant the index is seen the encoder is zeroed, and the pin is set low again by the encoder function.
The problem (as you have found) is that the index-enable pin is "in use" by other parts of EMC2 for rigid tapping etc.
There is a simple solution to this, though. You can easily add a second encoder function, using the same A B and Z(index) inputs, for the use of the spindle alignment function. I think you can afford to leave the index-enable on that encoder permanently high. (This can't be done with a "setp" in the HAL file, as that runs once, and it will be reset on the first index, you would have to use the HAL "constant" function www.linuxcnc.org/docview/html/man/man9/constant.9.html )This should leave you with an encoder with a .position pin that cycles from 0 to 1 every rev. (or you can alter the scaling to give an angle in degrees, as this is an encoder only used by the toolchanger)
You could then run a PID with that position as the feedback.
To align the spindle to the exact orientation you want, simply change the PID .command pin value. It will tend to work poorly for values close to zero, but I imagine your toolholders should have 180 degree symmetry so this is not a big problem.
Please Log in or Create an account to join the conversation.
- garymcrobertpdx
- Offline
- Premium Member
-
Less
More
- Posts: 101
- Thank you received: 1
03 Jan 2011 04:16 #6398
by garymcrobertpdx
Replied by garymcrobertpdx on topic Re:Hal encoder bug?
I did try using a second encoder but I did not know about the Hal constant
trick therefore was unable to force the pin encoder.N.index-enable true and
make this method work. But I may have a second go at it to see if I can
make the code simpler.
Speeding up the servo thread made the encoder.N.reset pin work reliably.
When I swap the 2500 CPR junk box encoder for the actual 100 CPR
encoder this problem may disappear. encoder.N.reset is connected to the
encoder index signal using Hal scope I can see the encoder reset in about
50 to 80 microseconds.
Now I need to find a way of connecting the pid.0.command to an easily
adjustable value, perhaps best placed in the ini file. At the moment it is
set to 0.5 in the hal code.
The next big task is the tool exchange routine I have been thinking of the
various ways to approach the problem but I do not yet fully grasp the overall
architecture of EMC2, how all the software blocks relate. Thus where the
best point to append my tool exchange routine.
I could use G code or create a Hal component or maybe a python script.
I have an experimental G code routine which works, but it seems inelegant.
Again it would be convenient to create a table of xy coordinates for tools
in the rack and the ini file may be a good place for it, here they could be
easily edited for fine tuning.
Plus I intend to do more than just exchange a tool, I wish to devise a means
to test the tools integrity every time a tool is taken in and out of the rack.
If a tool has been damaged the machine will alarm out and stop before any
further damage is done.
trick therefore was unable to force the pin encoder.N.index-enable true and
make this method work. But I may have a second go at it to see if I can
make the code simpler.
Speeding up the servo thread made the encoder.N.reset pin work reliably.
When I swap the 2500 CPR junk box encoder for the actual 100 CPR
encoder this problem may disappear. encoder.N.reset is connected to the
encoder index signal using Hal scope I can see the encoder reset in about
50 to 80 microseconds.
Now I need to find a way of connecting the pid.0.command to an easily
adjustable value, perhaps best placed in the ini file. At the moment it is
set to 0.5 in the hal code.
The next big task is the tool exchange routine I have been thinking of the
various ways to approach the problem but I do not yet fully grasp the overall
architecture of EMC2, how all the software blocks relate. Thus where the
best point to append my tool exchange routine.
I could use G code or create a Hal component or maybe a python script.
I have an experimental G code routine which works, but it seems inelegant.
Again it would be convenient to create a table of xy coordinates for tools
in the rack and the ini file may be a good place for it, here they could be
easily edited for fine tuning.
Plus I intend to do more than just exchange a tool, I wish to devise a means
to test the tools integrity every time a tool is taken in and out of the rack.
If a tool has been damaged the machine will alarm out and stop before any
further damage is done.
Please Log in or Create an account to join the conversation.
03 Jan 2011 12:23 #6405
by andypugh
Replied by andypugh on topic Re:Hal encoder bug?
garymcrobertpdx wrote:
thread.gmane.org/gmane.linux.distributions.emc.devel/3920
The simplest way is probably to not use M6 for toolchange, but instead use something like O<M6> CALL [10] and a subroutine file called "M6". That is reasonably clear and can itself perform the M6 to change the tool offsets etc.
You could wire it to one of the G-code analogue outputs (See M66) but that might be a little too elaborate.Now I need to find a way of connecting the pid.0.command to an easily
adjustable value, perhaps best placed in the ini file. At the moment it is
set to 0.5 in the hal code.
You might find the discussion here (though there is little of it) interesting:I could use G code
thread.gmane.org/gmane.linux.distributions.emc.devel/3920
It is not immediately clear to me how these approaches can move an axis. I can think of a number of possibilities, but none seem especially elegant.or create a Hal component or maybe a python script.
G-code is perfectly happy to move to calculated coordinates, so you could potentially move to a grid location defined by the tool pocket number. (modulo arithmetic to give you X and Y offsets from tool-rack home).I have an experimental G code routine which works, but it seems inelegant.
Again it would be convenient to create a table of xy coordinates for tools
in the rack
The simplest way is probably to not use M6 for toolchange, but instead use something like O<M6> CALL [10] and a subroutine file called "M6". That is reasonably clear and can itself perform the M6 to change the tool offsets etc.
That is reasonably easy, you simply need to probe a touch-off plate and check that the tool-length compensated position of the plate is correct.Plus I intend to do more than just exchange a tool, I wish to devise a means
to test the tools integrity every time a tool is taken in and out of the rack.
If a tool has been damaged the machine will alarm out and stop before any
further damage is done.
Please Log in or Create an account to join the conversation.
- Mike_Eitel
-
- Offline
- Platinum Member
-
Less
More
- Posts: 1150
- Thank you received: 184
22 Apr 2011 16:08 #9259
by Mike_Eitel
Replied by Mike_Eitel on topic Re:Hal encoder bug?
HI
I'm searching and saw this thread,..... seems to be the nearest to my wish.
I would like to find a way that on an M6 T1 command I can MANUALY change my tool and do an automated tool length adaptation.
a. I did not found a detailed description on hal_manualtoolchange.
b. I do slightly remember that there is a "stack" problem to use a G38.x command.
c. I remember that there is eventually a way via subroutines ???
Does anybody see achance for my "dream" ?
Mike
I'm searching and saw this thread,..... seems to be the nearest to my wish.
I would like to find a way that on an M6 T1 command I can MANUALY change my tool and do an automated tool length adaptation.
a. I did not found a detailed description on hal_manualtoolchange.
b. I do slightly remember that there is a "stack" problem to use a G38.x command.
c. I remember that there is eventually a way via subroutines ???
Does anybody see achance for my "dream" ?
Mike
Please Log in or Create an account to join the conversation.
Time to create page: 0.093 seconds