[Treischl]

Before I get into this, I want to make it VERY CLEAR that I really like the CNC Router Parts Rack and Pinion drives. What follows has me a baffled.

I do a lot of 3D sculpting type work that runs for hours. It is the type of work that steps over about .006-.007 in one axis and then cuts in the other axis. (that was for those of you who do not do that type of work). Typically on my machine, I step the axis that has the dual motors. The feedrate is usually around 180-250 IPM. This particular problem is occuring at the 180 IPM setting.

I was running along nicely when I heard the dreaded "Klunk", the sound of a tooth being skipped in the rack. Of course that was the end of that job.

Started running tests. This happens about every 3 inches or so. I have checked my Mach3 settings to make sure I did not having anything really stupid, like unequal steps between the motors.

Ran a test loop in which I caused the machine to run back and forth at feedrate 1000X. Never missed a tooth. Hmmmm.

Set up another test so that it emulates my normal sculpting work, but is much shorter so I can test faster. Problem is back.

Does not happen when I rapid.

I am thinking this has something to do with Mach3 and not sending the same number of steps to each motor. It is the only thing I can think of at this point.

The tension on the drives is set quite high. It takes a lot to force the pinion off the rack.

Anyone have any suggestions? Remember, this ONLY happens when I step the dual axis repeatedly.

[mmcp42]

you picking up some noise somewhere?

[Treischl]

The following was NOT accurate, after further testing, I discovered the problem had just changed in the sense that the skips are now farther apart.

I may have solved the issue.

The kernel speed was set to 45K in Mach3. Ran the speed test, and it was fine. But I went ahead and dropped the kernel speed back to 35K anyhow and repeated my test pattern.

Problem did not repeat during three test runs.

I was not using those 1000 IPM rapids anyhow, had them set to 600 IPM.

My guess is that my computer is not quite capable of handling the 45K speed, even though the Mach3 test says it is ok.

[CarveOne]

I nearly lost all of my marbles working on a problem just like this a year or so ago. In my case it was in Mach3 Config/Output pins settings. Outputs #2 through #6 were disabled and outputs #7 and #8 were enabled. Changing Outputs #7 and #8 to disabled fixed the problem. The DIR signal to the A axis motor was not the same voltage level as the DIR signal going to the X axis. It was 0.67vdc instead of 4.85vdc as it was for the X axis motor. Be sure to save the configuration changes you make and exit/restart Mach3 for the changes to be implemented.

This was causing racking to the point that the pinion gear would climb up on the rack teeth and then a loud snap was heard as it jumped over the rack teeth under heavy spring loading.

See post #1924 in "CarveOne's Work Table CNC Router Build" and previous posts there for some details.

Mariss Fremaniss was key to my finding the settings error by having me look at the DIR voltage levels with a DMM.

CarveOne

[Treischl]

CarveOne:

Thanks for the reply. I tripled checked those settings. They are and have been disabled. I was hoping I was going to get off easy and benefit from your experience. No such luck.

I did read through the post you referenced. At least it is a place to start!

One thing is REALLY bothering me. . . I cut a much larger project yesterday and did not see any evidence of this problem. I did not mess around with anything in Mach3, change anything with the wiring or mechanically on the machine.

Another thing that bothers me is that this problem only happens when I am making those very small repetitive moves. I can run the back and forth motion test 1000X without losing any steps or jumping a tooth.

[CarveOne]

CarveOne:

Thanks for the reply. I tripled checked those settings. They are and have been disabled. I was hoping I was going to get off easy and benefit from your experience. No such luck.

I did read through the post you referenced. At least it is a place to start!

One thing is REALLY bothering me. . . I cut a much larger project yesterday and did not see any evidence of this problem. I did not mess around with anything in Mach3, change anything with the wiring or mechanically on the machine.

Another thing that bothers me is that this problem only happens when I am making those very small repetitive moves. I can run the back and forth motion test 1000X without losing any steps or jumping a tooth.

If you can get to the Step and DIR signals follow the suggestions by Mariss in my build log as to checking the signal voltages to be sure they exceed the logic low and logic high minimum levels. Some parallel ports and parallel port cards don't supply the correct voltage pulses. A marginal pulse level or too narrow pulse shape will give erratic results in the pulse counts that each motor gets. I was seeing it in multiple stepdown levels but not on a one pass full depth cut. I was seeing stair steps on two adjacent sides of a square pocket while the other two sides have a straight wall.

Your symptoms sound like one motor is not getting the same number of valid pulses at both motors. It causes one motor to get ahead or behind the other.

If you have a break out board between the computer and your motors it could be correct levels at the input of the board and incorrect at the outputs going to the motors. I have G203V drivers and a C11G board. If using a G540 you have a little different situation with getting access to the wires. For the DIR signal the voltage level goes high when running in one direction and a low level when running in the other direction.

CarveOne

[ger21]

If you have a G540, try increasing the pulse widths in motor tuning to 15 or so. The G540 seems to be very sensitive to marginal ports.

[Treischl]

Carve:

Yes, the G540 is a little different. Not sure how I am going to get at the signals? First I would have to figure out which pins are which in the DB9.

About the only things I can think of at this point is to try a different parallel cable from the computer to the G540 and if that does not work, send the G540 back to Gecko to have it checked out.

This is one ugly problem!

[jsheerin]

I had a similar problem with my G540 and a crap parallel port. I would not get motion on my Z motor during very slow moves. Typically I'd make a move with lots of movement in X and Y but very minimal Z movement, so it might move 0.25" while the X and Y both went 48" or something like that. And the Z would sometimes not move. I tracked it down to low voltage levels from my parallel port, just like Carveone. I used an oscilloscope to do this. You have to load the port with either the G540 or resistors that draw similar current when you do this or the voltages will look fine. I installed a breakout board parallel port and found that a few of the pins on that weren't up to snuff either. So I ended up using dual break out ports and custom wiring a cable that used pins from both ports to drive the G540. Works great now. I have some posts in the Gecko forum where I show scope shots of what the step pulses looked like. I don't know how it was working at all.

[CarveOne]

Carve:

Yes, the G540 is a little different. Not sure how I am going to get at the signals? First I would have to figure out which pins are which in the DB9.

About the only things I can think of at this point is to try a different parallel cable from the computer to the G540 and if that does not work, send the G540 back to Gecko to have it checked out.

This is one ugly problem!

Tell me about it. Been there & done that. I was going in circles trying to find a place to identify a problem. Wasn't sure if it was hardware or software related for months. Nothing I tried or was told to try worked until Mariss told me what to look for in the Dir signal line.

In the G540 situation, all you can do is insure that the signal looks good at the input to the G540 parallel port connector. You can buy or make a back to back DB25 connector that is wired all pins straight through. The purchased version may have a small board with terminals on it. This will be inserted onto the G540 connector and the parallel cable plugged onto the other end. This allows you to probe the signals with a DMM or oscilloscope.

CarveOne

[Treischl]

Changed the parallel cable this morning. Ran the test 3X, everything worked fine. Failed on the fourth test. Grrrrr. Then noticed that G540 was very, very hot. Shut it down, cooled it off with compressed air for a while.

Ran test 3X, worked good. Failed on 4th.

Something is beginning to tell me this is a heat issue with the G540.

That sort of makes sense too. The shop was cooler during the last few weeks when I was running the machine and didn't have any problems. It has been warming up quite a bit and now I started to see the troubles.

Just found this:

Any control box containing a G540 must have an adequate input and exhaust fanor an exhaust fan and an internal fan to circulate the air. The red graph shows if the G540 is left in still air or in a sealed environment under full load it will overheat, which may result in damage to the G540. The green and blue graphs show the effectiveness of a circulation fan. Note from the blue graph that nothing is gained by having a fan/heatsink combination. Every degree above 25C ambient will push the peak temperature up one degree as well; it is recommended to monitor the temperature in your case to take this into account.

Marcus Freimanis
Geckodrive, Inc.
February 23, 2009

Well darn, I could have sworn that I read somewhere that it was normal for the Gecko to get hot and that it was not a problem. So much for that theory! Or my memory, or what is left of it.

[Treischl]

So, I made the trip to "Do It Yourself Electronics" in Needham, MA this morning. Purchased an 80mm, 120 VAC fan. Neat place, they even had a cord that was made to fit it.

Got back, fabricated a bracket to hold the Gecko and fan, mounted it all up and tried it out.

Ran the test 10 times. NO FAILURES! This morning it failed on the 4th after a cold start. It seems I have learned my lesson.

I am just happy that I did not wreck the Gecko, or have to go through what Carve did.

Thanks to all the people who pitched in to help, even though it was a heat issue, all those suggestions helped me eliminate a lot of possible causes very quickly!

[CarveOne]

Even with the new fan running it is a good idea to heat sink the G540 anyway. If the fan quits running for any reason the job will probably keep running to completion.

Glad you got it working.

CarveOne