Hello Guest it is March 29, 2024, 06:21:36 AM

Author Topic: Problem with index homing  (Read 19643 times)

0 Members and 1 Guest are viewing this topic.

Re: Problem with index homing
« Reply #30 on: September 23, 2015, 12:23:05 PM »
Okay, here is CS Labs' response concerning the index homing problem.

Dear sir,
 
CSMIO/IP-A has security that watch over correct homing on index signal.
It's about the index signal can't show up too close or too far from homing switch signal.
More precisely  - homing failed if index signal shows up:
- closer to the switch than 1/24 of pulses entered into  "Config\Config PlugIns\Config\Index Homing\Encoder Pulses/Rev" window,
- further from the switch than 1/1 of pulses entered in to "Config\Config PlugIns\Config\Index Homing\Encoder Pulses/Rev" window.
 
In the mentioned window there must be entered an encoder pulses number with all edges incl. electronic gear of a servo drive if used.
 
If you set all like I described and the problem still exists then you will have to move the homing switch or turn the encoder so the index signal will appear in the safe range (between 1/24 and 1/1)
 
You can see the distance between the index signal and the homing switch signal shown impulses in the "PluginControl\Debug" window "Index Distances" area.
It would be great if the value is close to half of the value entered in "Config\Config PlugIns\Config\Index Homing\Encoder Pulses/Rev"
If the distance is displayed in red then it means that the index signal isn't in the safe range.
 
 

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Problem with index homing
« Reply #31 on: September 23, 2015, 03:04:35 PM »
Ok so really you should be able to see what it says in the Debug page.
First thing however is to work out what the encoder counts actually are so you can enter the correct value in the plugin.
What are your
Steps per unit
Reduction ratio
Ballscrew pitch

Hood
Re: Problem with index homing
« Reply #32 on: September 25, 2015, 12:37:19 PM »
Steps per unit are as follows.
X, Y and Z axis- 500 steps per mm

the reduction from the drive to the ball screws are as follows.- for the x and Y axis, 24 to 40 teeth. for the Z axis, the reduction is 24 to 40 to 60

the ballscrew pits is 5mm per revolution.

Ive worked out that math and I'm pretty sure I'm dead on. I don' think I'm reaching the index pulse too late, because I've experimented with astronomical steps per revolution, and I still get the error. I think I'm going to dave to disengage the ball screws from the servos and place them in another position so that I don't arrive at the index pulse too early. I don't know though. I'm going to reconfigure the machine to inches rather than mm because the g20 g21 parameters in mach are so buggy.

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Problem with index homing
« Reply #33 on: September 25, 2015, 12:55:28 PM »
Ok the numbers I get are 1500 for X and Y and 1000 for Z.

On the Debug page do you get numbers for the Index Distance?
Hood
Re: Problem with index homing
« Reply #34 on: September 25, 2015, 02:04:59 PM »
I must be missing something, Hood. What do the numbers 1500 and 1000 correspond to?

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Problem with index homing
« Reply #35 on: September 25, 2015, 02:38:16 PM »
The encoder pulses per rev  in the Index homing section of the Plugin.

Hood
Re: Problem with index homing
« Reply #36 on: September 26, 2015, 01:10:55 PM »
Update.

This morning I opened the debug window, a window I din't know existed until a few days ago. Go figures. Thats what happens when you don't do your homework. In the debug window I was able to see when each axis was arriving at their respective index points. I experimented with the Z azis and found that it found the index pulse within 3 to 50 pulses.  I performed 10 trials on the z axis and found this to be the case. To even get the z axis index homing to work, I had to input 100 into the pulses per rev window.I tried your above numbers, Hood, but to no avail. I wrote down all the numbers to the test but like the  blockhead I am, I left them at the shop. The accuracy, however, was underwhelming. Sometimes I was dead on and sometimes I was off as much as 2 or 3 thou when returning to a point after zeroing the axis. Whith turned index homing off, the error dropped to .5 thou max.

I then performed the spread test of the y axis. I put 1500 into the pulses per rev window because this worked most of the time. The spread on the Y axis pulses until index pulse varied wildly. The lowest number was 5 and the highest 2300 or so. Needless to say, the pulse only fell within allowable limits about half the time. I can get the numbers from my shop and run real statistical analysis on them if anyone is interested.

So, my final theory- The machine is missing the index pulse and/or noise is generating a phantom index pulse. I'm not sure how or why, but I suspect it has something to do with the ipa itself or the signal/wiring between the optocouplers and the IPA.

A not about the optocouplers- I can watch the index signal light up an led temporarily. When the machine has reached the index limit switch and is backing up while looking for the index signal, I can see it plain as day. A little green blip lights up on the optocoupler signaling that the index signal has been triggered.

I am going to forward this information on to CS labs in the hopes that they have dealt with this before. I'll keep you all apprised of any developments.

Jonathon

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Problem with index homing
« Reply #37 on: September 26, 2015, 02:14:45 PM »
Ok so going by the Z axis, you said it found the pulse between 3 and 50 pulses, so assuming the encoder is 1000 pulses per rev then 1/24 of 1000 would be 41.666 pulses. So even at the max 50 pulses you have seen it is very close to 1/24th of the total. With you setting 100 as the encoder pulses per rev then the IP-A is thinking it is well within the range.
So if you can move your limit switch trigger a slight amount you may get correct results.

You have 500 steps per mm in motor tuning and if the encoder is 1000 pulses per rev then that would mean   each turn of the motor on Z will move 2mm I think. So if you move the switch approx 1mm further you should end up almost in the middle of the the count range.

Not sure why you are not getting the accuracy when using the Index but may be to do with the incorrect values or it could indeed be noise.

My encoder count is 24,000 pulses per rev and when homing I see maybe 5 or so max difference in the Index count, that would equate to 0.001mm variance, if my calcs are correct ::)

Oh and regarding the G20/21 from your earlier post, I only ever use metric but seem to recall that way back when I was doing some testing I got funny issues going between the two. I seem to recall that it is ok if set in Imperial units and going metric but not vice versa. Could be wrong though as it was years ago I did this test.
 What I have always said however, is if you predominantly use metric then set the machine up in metric units, if Imperial is your predominant mode then set the machine in Imperial units.

Hood
« Last Edit: September 26, 2015, 02:19:48 PM by Hood »
Re: Problem with index homing
« Reply #38 on: February 04, 2016, 02:26:42 PM »
Not sure if you figured it out, found the feedback unit specs.  hope it may help.
Re: Problem with index homing
« Reply #39 on: March 12, 2016, 07:30:29 PM »
Index homing problem solved!!!! I know it's been forever guys. But,  as I suspected, the problem was in the optocouplers. I used my Osciliscope to read the signal coming out of the optocouplers and it was very noisy. So, I bought three new encoders from US digital and fit them up to my encoder bodies. index coming now works flawlessly. something else I didn't realize was that the optocouplers introduced a good deal of lag into the system.  I could never run my machine to its full potential without getting a PID loop error.  But with these new encoders my machine is blazing fast!  I made a quick video of my encoder replacement if anyone wants to check it out. http://youtu.be/G07ck2G7PgE