Machsupport Forum
Third party software and hardware support forums. => CS-Lab => Topic started by: jofriedl on August 31, 2015, 08:36:01 PM
-
Almost done with the Matsuura MC500v retrofit and I'm running into an issue with index homing. When I attempt to reference all axis, the machine moves until it triggers each reference switch, but while its backing off the switch to find the index pulse sometimes I get an error that reads "Index distance not within allowed limit'. I'm not sure what this is about. Using the CSMIO/IP-A plugin, Ive counted the index pulses per revolution (2k in the Z and 3K in the X and Y), so I know thats not it. Even more perplexing is the fact that it doesn't always happen and it won't always happen on the same axis twice. Am I missing something? Thanks for any and all help.
Jonathon
-
Try moving the switch slightly or moving the motor belt a tooth or two, just thinking it may be the Index is too close to the switch.
The only other things I can think of are the index pulse is not being seen correctly due to noise or maybe you have the wrong encoder count set in the plugin?
Hood
-
Thanks for your response, Hood. I disconnected the servo from the ball screw and turned the servo 90 degrees. No change in whatsoever. I looked at the wiring and I really don't have anything that would cause too much noise. I do have 12V to5V optocouplers between the encoders and the IPA; maybe the single pulse is getting lost in the opto-coupling. But there are LEDs on the optocouplers that light up on the pulses. I can see the index pulse flash when I pass it.
As far as having the right number of pulses per revolution, I used the readout from the CSMIO plugin window that displayed the encoder pulses in realtime. I set the encoder at 0 and used the mpg to complete one rotation of the servo. At the end of one rotation the display read 3000 pules for the y axis (I'm assuming the X and Y are the same) and 2000 pulses for the Z axis. Due to different gearing in the Z axis, it comes out to the same number of pulses per inch on all axis. I've also played with the numbers and put pulses per revolution in the tens of thousands so if the index pulse was getting lost it the ipa would simply assume that it hadn't reached it yet.
My only thought it this. Does the index pulse have to come after the axis has moved off of the homing limit switch? What happens if the switch is triggered but the axis decelerates past the index pulse a time or two? Ive played with speed and it seems the issues happens independent of any speed.
-
I do not think it has anything to do with gearing or steps per unit, from memory it it is simply encoder pulses per rev.
Set the encoder setting in the plugin to whatever pulses per rev it is.
For example if your encoder is 2500 line encoder then the pulses per rev will be 10,000, if it is a 1024 line encoder then it will be 4096 i.e. line count of encoder x 4.
Hood
-
O have no way to telling how many lines the encoder has. I've contacted Yaskawa and they don't have any information on the encoders. Can I simply use the method I described above using the CSMIO plugin to count the pulses or should I keep trying to chase down literature on these encoders?
-
What type of motors? AC or DC, what year, roughly, are they?
Hood
-
They are brushed DC and the machine was made in 1979 if that helps.
-
Quite likely they are 500 or 1024 line then, try 2000 or 4096 and see.
Hood
-
the plugin test indicates that they are 2000 pulses per rev so I've got the plugin configured for 2000 lines, but I'll try 4096 when I get to the shop later. Thanks hood. I don't know what CS labs would do without you:)
-
Ah ok, I thought you had said 3000 and that struck me as a weird number for an encoder.
Hood
-
I did say 3000 didn't I. My test indicate that the x and y axis are 3k and the z axis is 2 k. It comes out to 500 pulses per mm if my calculations are correct. It seems odd to me that the encoders would be different but the gearing on the z axis is different as well. The z axis is geared 1/3 Lower so with 2000 pulses per revolution it still comes out to the same pulses per mm. Is that normal?
-
Set the encoder setting in the plugin to whatever pulses per rev it is.
For example if your encoder is 2500 line encoder then the pulses per rev will be 10,000, if it is a 1024 line encoder then it will be 4096 i.e. line count of encoder x 4.
Hood
Did you try 8000 ?
If you've entered 2000, it might quit looking after only searching 1/4 of a turn.
Maybe ?
Russ
-
The gearing is 24 teeth on yhe x and y servos which mesh with a 60 teeth gear on the ball screws.
On the z axis the gear on the servos is 24 teth as well, but it meshes with a 24 tooh gear which in turn drIves the 60 tooth gear on the ball screws. I think my math is correct.
-
I did try 8000. I even tried 10000 and it still would give the same error. 'Index distance not within allowed limit'
-
What pitch are the ballscrews?
According to your info above all axes are 2.5:1.
Hood
-
Assuming the ballscrews are 5mm that would mean encoders are 250 line and thus you need to enter 1000 into the plugin.
Hood
-
Oh lord, I'm so sorry hood. I wrote off that last reply about the gearing in a hurry on my phone and I didn't proofread. What I meant to write is as follows:
The gearing is 24 teeth on the x and y servos which mesh with 40 teeth gear on the ball screws.
On the z axis the gear on the servos is 24 teeth as well, but it meshes with a 40 tooh gear which in turn drives the 60 tooth gear on the ball screws. I think my math is correct.
Also, should I even pay attention to the encoder pulse count in the CSMIO plugin window? Will that tell me how many pulses per revolution the encoders have?
-
Ok it is late here so maybe my calcs are wrong but I make that 1.6666666667 :1 ratio for X and Y and 2.5:1 for Z.
Assuming 5mm pitch ballscrews then it would be 1500 for X and Y and 1000 for Z.
Not sure about the CSMIO, is it in the tuning window you are seeing the encoder counts?
Hood
-
Those were my numbers as well. The window to which I am referring can be found by going to the top right of the menu bar in mach3 and clicking plugin control. There select CSMIO I think and the widow appears. Its the plugin window where you can see how much voltage is going to each drive and which inputs and outputs are active. I'm not at the shop currently, so I don't have it in front of me, otherwise I would take a picture.
jonathon
-
Did you get it working?
Hood
-
Unfortunately, no. I think the problem is this- The machine runs over the limit switch, then reverses to find the next index signal. If the machine find the next index signal before it completely backs off the homing limit, it sends the error. This is the reason that the error is triggered about 80% of the time. I did some tests and I found that if I slowed the machine to an unbearable crawl (2 to 5 inches a minute) it wont send the error. I think the macro should be modified such that the machine triggers the limit switch, then backs off the limit switch completely, then moves to the limit switch again at a much reduced rate. Only then will index homing work on this machine. Unfortunately, I don't know enough visual basic to modify the CS labs macro. Oh well.
Jonathon
-
In other news, I've gotten the tool changer to work beautifully with the DL06 PLC. I've posted a video under the 'posts your video here' section
-
Didnt't think the Index was looked for before the home switch closed but I had to check before I could be sure. I did a test on my Chiron and I could hear the switch close and the axes still moved until the Index was found.
It was going to be hard to manually trip the home switch on the Chiron to keep it closed for longer but the wee lathe was easy to do.
I made a quick video, you can see it here, you can clearly see the axis continues until I release the switch and it then senses the Index.
https://www.youtube.com/watch?v=7dKNaMVlj1E
Toolchanger looks like its working well :)
Hood
-
Nice illustration Hood, mine did the same with the -M.
Back to Hood's first reply regarding noise, did you try the filter ?
Russ
-
Would it be possible for you to either manually operated the switch like I did in the video or just wire a toggle switch to the input for testing.
What I am wondering is if maybe your switch has a wee bit of bounce at the release point and the IP-A is getting confused.
Not even sure if that would affect things but probably worth a try.
Hood
-
Thanks for checking on that, Hood. I upped my input signals filer to 60ms and still no change. Thank you for the suggestion though. You may be right about the limit switches, Hood. Although I have triggered them with the mpg and found that once triggered, the machine has to back off past the trigger point for the contacts to open. It's as if there is 'spring' to the switches. Essentially, they don't open and close at the same point I wonder if this would have something to do with it. However, I tested the system by depressing the switches manually while the machine was indexing the axis (z in this case) and wether or not the error was triggered seemed time dependant. If I released it imediately, the error was triggered. If I held it for a little longer than what it would normally take for the macHine to back off the switch, the error would not be triggered. If I held it for even longer, it would send the error again. This leads me to believe that there is a window of oportunity on the encoder wheel during which the limit switch signal must go low otherwise the error is triggered. This is very odd indeed. I'm thinking of trying to contact cs labs direct in the hopes that they can help resolve the issue. This machine is very accurate for its age, so I'd really like to have the ability to index home. Thanks for everyone's help thus far. I am truly grateful for the community on this forum and especially you, Hood. Your input has been indispensable on this project. I only wish we were on the same continent so I could pay you a proper visit and thank you in person!
Jonathon
-
The trigger point and release point is different on decent switches, so that is definitely not the issue. Not sure if you can see/hear it on the video as the sound is not great but when standing at the machine you clearly hear the click of the switch and the trigger and release are a fair distance apart.
One thing that still puzzles me is the values I calculated, with the assumption of 5mm pitch screws, are exactly half of what you said the CSMIO was reporting on the encoder count, or at least I think that is the case, can't be arsed reading back to check :D
If that is true then afraid I don't have an answer to why that would be but it may well have something to do with the problem and may help CS-Lab find it.
Hood
-
Jonathon,
any progress?
I just went and looked at the encoder position you were monitoring, it seems they are internal counters based on the steps per unit set in motor tuning.
What I did was home the machine and did a G53G0X0 (I home to the positive on X) and the counter showed Zero.
I then did a G53G0X100 and the counter showed 480000. As my steps are 4800 per mm then 100mm = 480000.
So I concluded that the value there was dependent on the steps per unit. To confirm I went back to G53 X0 and then changed the steps per unit in motor tuning to 2400 and commanded a move to G53G0X100 and the reading showed as 240000, so that was as expected.
So basically you can not use that value to work out the encoder counts as it is an internal calculation.
You will need to get the gearing and the pitch of the screws and work it out that way.
Hood
-
Hey Hood,
Sorry for the delayed response. I've been buried under a few other projects for the past few weeks. I did get around to working with the mill yesterday.
As far as steps per unit of distance, I have worked out the pitch of the ball screws and gearing and encoder pulses per revolution. I have been using the mill with index homing disabled and it moves and cuts accurately. I am sending off an email to the cs labs guys today and including the address to this thread. Hopefully it will be something simple that I missed.
-
Will be good to hear what they say :)
Hood
-
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.
-
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
-
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.
-
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
-
I must be missing something, Hood. What do the numbers 1500 and 1000 correspond to?
-
The encoder pulses per rev in the Index homing section of the Plugin.
Hood
-
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
-
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
-
Not sure if you figured it out, found the feedback unit specs. hope it may help.
-
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
-
good to see you got it sorted :)
Hood