- Configuring LinuxCNC
- Basic Configuration
- Latch phase of homing - seemingly random distance traveled?
Latch phase of homing - seemingly random distance traveled?
05 Jun 2018 20:20 - 05 Jun 2018 20:21 #111702
by Sparky961
Note: I'm currently dealing with two different machines, so this is unrelated to my other recent posts.
This one has LinuxCNC 2.6.2, so maybe there's something that's been fixed already. Or maybe it's configuration, but if is I'm stumped.
I'm watching the limit switches for the X axis while homing. It correctly travels toward the limit switch to start, then reverses direction at my much slower latch speed. Sometimes it will stop just after releasing the home switch, but more often it keeps traveling away from the home switch at the latch speed for seemingly random distances.
In my most recent test, I did the following in sequence:
Home X
--> Stopped just after releasing home switch
Home X
--> Stopped just after releasing home switch
Home X
--> Traveled for about 6" after releasing the home switch.
WTF?
In other words, (W)hat (T)roubleshooting steps should I (F)ollow?
Thanks, this one really has my mind boggled. I can post the config if it helps, but the same thing seems to work on the other machine I've been working on. I hope it's something stupid I've overlooked.
This one has LinuxCNC 2.6.2, so maybe there's something that's been fixed already. Or maybe it's configuration, but if is I'm stumped.
I'm watching the limit switches for the X axis while homing. It correctly travels toward the limit switch to start, then reverses direction at my much slower latch speed. Sometimes it will stop just after releasing the home switch, but more often it keeps traveling away from the home switch at the latch speed for seemingly random distances.
In my most recent test, I did the following in sequence:
Home X
--> Stopped just after releasing home switch
Home X
--> Stopped just after releasing home switch
Home X
--> Traveled for about 6" after releasing the home switch.
WTF?
In other words, (W)hat (T)roubleshooting steps should I (F)ollow?
Thanks, this one really has my mind boggled. I can post the config if it helps, but the same thing seems to work on the other machine I've been working on. I hope it's something stupid I've overlooked.
Last edit: 05 Jun 2018 20:21 by Sparky961.
Please Log in or Create an account to join the conversation.
05 Jun 2018 21:10 #111704
by Sparky961
Replied by Sparky961 on topic Latch phase of homing - seemingly random distance traveled?
In the meantime, I've discovered that there's some really convoluted ClassicLadder and additional HAL configuration I hadn't seen before. The job of this code, as is told to me, is to catch the index pulse from the drives (servo drives taking step/direction signals, but can output an index pulse too... not the most fun to work with) to improve homing accuracy. I've since turned down the latch speed to very slow and it seems to work repeatably now. If I have the opportunity I'll try to dig into the other code and figure out what's going on there. Maybe if I post it here I can get some assistance understanding what's there.
Please Log in or Create an account to join the conversation.
06 Jun 2018 21:59 #111794
by rodw
Replied by rodw on topic Latch phase of homing - seemingly random distance traveled?
The conditional code may not be required as the homing configuration supports homing to an index. Also latch velocity is controlled in the ini file. I think this all still holds for V 2.6. Here are the homing docs for 2.6
linuxcnc.org/docs/2.6/html/config/ini_ho...html#_home_use_index
Maybe your config has been carried forward from an earlier version pre 2.6
linuxcnc.org/docs/2.6/html/config/ini_ho...html#_home_use_index
Maybe your config has been carried forward from an earlier version pre 2.6
Please Log in or Create an account to join the conversation.
07 Jun 2018 01:08 - 07 Jun 2018 01:09 #111808
by Sparky961
Replied by Sparky961 on topic Latch phase of homing - seemingly random distance traveled?
The configuration of this system is a bit odd. It's used on both of the machines I've been working on lately.
This is the current state of my understanding:
The motors are A/C servos with optical encoders but no hall sensors. If there's any alignment between the motor phases and the encoders I'm not aware of it. The drives are Allen Bradley Ultra3000, set up for self-sensing commutation (because of no hall sensor feedback), and inputs to the drive are step and direction.
This means that the drive is closing the position loop, so from the computer end it is an open loop "stepper" system. That said, these drives seem to have plenty of power and can be tuned so they maintain position very well and accelerate acceptably. The tools and procedure to do so have been a learning curve for sure.
I have to do some research into where LinuxCNC is looking for the index pulse during the homing/latching routine. I _can_ get a buffered signal out of the drive that mirrors the index pulse on the actual encoder. I think I can probably use this in the homing routine, it has just been a lower priority than most other things at the moment.
One machine needs to be the fastest possible but accuracy and repeatability would be acceptable to within, say, 0.020". Homing with only the limit switch is probably sufficient here. The other one is supposed to be a functioning VMC so much repeatable homing needs to be maintained. It's on the VMC that I'd like to improve this, but my attention has been divided between the two.
This is the current state of my understanding:
The motors are A/C servos with optical encoders but no hall sensors. If there's any alignment between the motor phases and the encoders I'm not aware of it. The drives are Allen Bradley Ultra3000, set up for self-sensing commutation (because of no hall sensor feedback), and inputs to the drive are step and direction.
This means that the drive is closing the position loop, so from the computer end it is an open loop "stepper" system. That said, these drives seem to have plenty of power and can be tuned so they maintain position very well and accelerate acceptably. The tools and procedure to do so have been a learning curve for sure.
I have to do some research into where LinuxCNC is looking for the index pulse during the homing/latching routine. I _can_ get a buffered signal out of the drive that mirrors the index pulse on the actual encoder. I think I can probably use this in the homing routine, it has just been a lower priority than most other things at the moment.
One machine needs to be the fastest possible but accuracy and repeatability would be acceptable to within, say, 0.020". Homing with only the limit switch is probably sufficient here. The other one is supposed to be a functioning VMC so much repeatable homing needs to be maintained. It's on the VMC that I'd like to improve this, but my attention has been divided between the two.
Last edit: 07 Jun 2018 01:09 by Sparky961.
Please Log in or Create an account to join the conversation.
07 Jun 2018 01:37 #111812
by Sparky961
Replied by Sparky961 on topic Latch phase of homing - seemingly random distance traveled?
Are the signals used for HOME_USE_INDEX the set of axis.n.index-enable ? The "enable" part throws me off a little if this is true.
Please Log in or Create an account to join the conversation.
07 Jun 2018 03:39 #111814
by Sparky961
Replied by Sparky961 on topic Latch phase of homing - seemingly random distance traveled?
I was able to track down where I think this is happening in the source, with the hope that I could figure out what it's looking at for an index pulse. Unfortunately is looks like it only gives a 'signal' to the driver and the driver is responsible for setting zero when the index is received.
Can someone tell me which driver this refers to?
(/usr/src/linuxcnc-dev/src/emc/motion/homing.c)
Can someone tell me which driver this refers to?
(/usr/src/linuxcnc-dev/src/emc/motion/homing.c)
case HOME_INDEX_SEARCH_START:
/* This state is called after the machine has made a low
speed pass to determine the limit switch location. It
sets index-enable, which tells the encoder driver to
reset its counter to zero and clear the enable when the
next index pulse arrives. */
/* set the index enable */
joint->index_enable = 1;
/* and move right into the waiting state */
joint->home_state = HOME_INDEX_SEARCH_WAIT;
immediate_state = 1;
home_do_moving_checks(joint);
break;Please Log in or Create an account to join the conversation.
07 Jun 2018 16:36 #111898
by andypugh
Replied by andypugh on topic Latch phase of homing - seemingly random distance traveled?
index-enable means "at the next index I want you to zero the encoder counts and position"
Then when the encoder counter (software or FPGA) next sees an index pulse it zeros the counts and resets the index-enable pin.
But I don't think that stepper systems know particularly well what to do with index-enable. So you need to run them as a PID-controlled velocity loop, with step-rate being the velocity command.
Then when the encoder counter (software or FPGA) next sees an index pulse it zeros the counts and resets the index-enable pin.
But I don't think that stepper systems know particularly well what to do with index-enable. So you need to run them as a PID-controlled velocity loop, with step-rate being the velocity command.
Please Log in or Create an account to join the conversation.
07 Jun 2018 16:48 #111900
by Sparky961
Replied by Sparky961 on topic Latch phase of homing - seemingly random distance traveled?
In the case you've described, what does the external index signal get connected to?
Please Log in or Create an account to join the conversation.
07 Jun 2018 17:49 #111908
by andypugh
Replied by andypugh on topic Latch phase of homing - seemingly random distance traveled?
To the index input of the encoder counter.In the case you've described, what does the external index signal get connected to?
Please Log in or Create an account to join the conversation.
07 Jun 2018 17:53 #111911
by PCW
Replied by PCW on topic Latch phase of homing - seemingly random distance traveled?
Homing to index does assume you have encoder feedback, otherwise its quite tricky capturing the
very short index pulse and dealing with the feedback offset (the encoder driver zeros the position on index detection)
The HM2 firmware has had home to index capability on stepgens for years but there's no driver support
very short index pulse and dealing with the feedback offset (the encoder driver zeros the position on index detection)
The HM2 firmware has had home to index capability on stepgens for years but there's no driver support
Please Log in or Create an account to join the conversation.
- Configuring LinuxCNC
- Basic Configuration
- Latch phase of homing - seemingly random distance traveled?
Time to create page: 0.085 seconds