Messages

31

CS-Lab / missing encoder pulses with the ip-a

« on: December 23, 2015, 01:20:38 AM »

Hey everyone,

   This is truly a shot in the dark, but I'll post it here anyway. I'm having trouble with my machine missing steps. Ill run a program about an hour long, and when the machine is done, it has lost its zero point by 10 to 20 thou. I have the pulses per rev set correctly so I know its not that. I am using optocouplers to convert a 12v signal to 5v signal. I'm wondering if anyone else has experience doing this and have they had trouble with missed pulses?

Jonathon

32

CS-Lab / Re: ENC threading module setup for ridgid tapping

« on: December 14, 2015, 06:22:13 PM »

Thanks for the info, Hood. I purchased the hardware earlier to make a pulley drive between the motor shaft and a 1/4 in ch shaft that the encoder will mount to. Its a 10k cpr encoder though, so I'm a little worried about play in the 1/4 inch shaft. Any thoughts?

33

CS-Lab / ENC threading module setup for ridgid tapping

« on: December 14, 2015, 01:34:50 PM »

Hello everyone,
 


    I'm back with another question. I'm installing an encoder on my matsuura mc500v so I can do rigid tapping, but Its looking like I need to install the encoder directly on the spindle rather than the spindle motor. The spindle motor has a belt drive and I think the reduction is 2 to 1 from the motor to the spindle. There is a perfect spot on the spindle motor where the 20 mm shaft pokes out of the top where an encoder could be mounted. Attaching an encoder to the spindle rather than the motor would be a retrofit nightmare. The drawbar at the top of the spindle prevents an encoder from being mounted there and to mount it anywhere else would require me to pull the thing apart and remove the bearings. This is not an option. In the ENC manual it states that the encoder must be mounted such that it reads 1 to 1 to the spindle.  Why is there no way to configure the enc module for a reduction drive? This seems pretty intuitive. Thanks for any and all help.

34

General Mach Discussion / Re: CNC Lathe turret tool changer help?

« on: October 18, 2015, 10:30:36 PM »

Congrats! Good to see you got it working finally. I'm thinking that since it finds the tool reliably while only stepping through the tools one tool at a time, its not a hardware issue and can probably be fine tuned to work all the time every time.
joanthon

35

CS-Lab / Re: Position creep in all three axis / csmio/ip-a

« on: October 16, 2015, 06:58:30 PM »

Thanks Mike!

    I'll have to read into the tuning procedure. I have an osciliscope, but I'm not sure how to use it to tune the servo drives. I'll have to do some research. What is a VOM?


Jonathon

36

CS-Lab / Re: Position creep in all three axis / csmio/ip-a

« on: October 15, 2015, 11:57:49 PM »

Mike,

     Thanks for your response.

      I found solutions to both problems yesterday with a bit more investigating. The jerkiness was solved (mostly) by setting the look ahead in mach3 to 200 lines instead of 10. Now it doesn't slam to a stop in the middle of an arch movement for no reason. It will stop though on a direction change so abruptly that I can feel it in my feet. An almighty jerk that makes me worry for my ballscrews.  I lowered my acceleration parameters for the servos from 10 to 7 in the mach motor tuning window and it helps minimally. Though, it may have more to do with the tool path and less with the machine.

As far as the second problem goes, it turned out to be an incorrect steps per unit of distance in the motor tuning window. I had recently set the machine to inches rather than mm. The machine is a metric machine so naturally, in the beginning, I set it up that way. But, mach is buggy when it comes to running a standard program on a metric configured machine. When I switched to inches I calculated the steps in inches but I was off by about 10 pulses per rev. I don't know how I screwed the math up but I did. When I put in the correct value of 12700 pulses per rev the drifting problem went away. I ran the program again and it was spot on.

As far as tuning goes, I think I still have work to do. Each servo drive has three knobs to adjust the gain, zero point and speed I think. Can't remember off the top of my head. But I notice that when I turn these knobs ever so slightly the autotuning gives me different numbers. And running auto tuning on each axis comes up with wildly different.  To top it off, when I run autotune, I usually end up with a final max error of 50 to 100. Thats way too much. Even when I manually adjust the pid parameters I still can't seem to get lower than 20. Ive read the instructions on autotuning the IPA but I'm not real sure about tuning the analog drives themselves on the machine.

37

CS-Lab / Position creep in all three axis / csmio/ip-a

« on: October 13, 2015, 10:17:59 PM »

Hello again Guys,

       I can't seem to catch a break with this retrofit. Today I actually got around to cutting the first real part on the Matsuura MC500V retrofit with CSMIO/IP-A. It was a fixture plate for some parts I plan on making. About halfway through the program I noticed two things that must be addressed.

This first was a jerkiness in arc movements when I tried running faster than 30 ipm. I think this either has to do with rough servo tuning or I need to uncheck constant velocity mode in configurations. I would have tried this today, but I didn't have internet at the shop so I couldn't  research and trouble shoot the problem. If its a servo tuning issue, I might need a bit of help. These are the first servos I've tuned and although I'm using the auto tune application in the CS plugin, I'm still showing slight errors. (I think I get 20 for a max error when oscilating at full speed and acceleration over an inch) When I try to adjust the PID parameters to 'tighten' up the tune, The servodrive makes a high pitched oscillation sound. When I think about all the fiddling I've done with the tuning of these servos, I realize that I should probably start a CS labs servo-tuning thread.

The second problem is a bit more scary. It involves position creep. As the machine worked its way through the program, I noticed that my z depth seemed to be steadily increasing. At the end of the program I confirmed my suspicions. Sure enough, not only was the Z axis creeping, but the X and Y were creeping as well. Its like the machine was missing steps but only in the positive directions for all three axis. After the program was finished (the fixture is useless) I re-homed the machine and suddenly my zero point was back were it started. This leads me to believe its a missing steps problem, but why would it only miss steps in one direction? In the case of the X axis, it was missing steps and thus over-traveling while under load and moving at 20ipm rather than at rapid speed.

Thanks for any and all help!

Jonathon

38

CS-Lab / Re: Problem with index homing

« 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

39

CS-Lab / Re: Problem with index homing

« on: September 25, 2015, 02:04:59 PM »

I must be missing something, Hood. What do the numbers 1500 and 1000 correspond to?

40

CS-Lab / Re: Problem with index homing

« 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.