SOLVED: Tuning stepper motor with Gecko 201 driver

BigJohnT wrote:

What might be messing with the 201 is doublestep. I'm not an expert on doublestep.

I turned off doublestep by changing the Z's HAL stepspace from 0 to 1. Like this:

setp stepgen.1.position-scale [AXIS_2]SCALE
setp stepgen.1.steplen 1
setp stepgen.1.stepspace 1

At first I thought that had fixed it, based on briefly testing in the StepConfig program at a single slow speed, but further testing at different speeds showed little improvement, so I am back to the drawing board.

I am learning that the X driver and Z driver can be setup differently by manually editing the HAL file.

StepConfig's default 201 settings in my HAL file are: steplen=1, stepspace=0, dirhold=26200, dirsetup=26200
StepConfig's default 203 settings in my HAL file are: steplen=1, stepspace=0, dirhold = 46000, dirsetup=27000

I'm puzzled about why the HAL numbers are different than the recommended timing numbers? wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Drive_Timing Is there some kind of conversion going on?

At any rate I have been experimenting with different HAL timing numbers for the 201 and observe only slight changes in performance -- it still runs way too rough. At faster speeds it sounds like it is grinding gravel and sometimes loses steps. So it appears that there is still something seriously wrong with my setup, regardless whether stepspace=0 or 1.

andypugh wrote:

Is there a good solid +5V to the "common" terminal?

Yep, 5.1V. Like I said the Z runs fine in TurboCNC, so it's gotta be something in the LinuxCNC setup.

What voltages do you see on the "DIR" pin at the drive in each direction? (the step will change too fast to see easily, but should be similar)

Not sure how to measure this and operate the controls at the same time?

The problem might be with the BoB. You might have a BoB designed for 5V sourcing signals, and the G201 expects 0V sinking signals.

I'm using a straight-thru BOB with no isolation or signal conditioning. It works fine in TurboCNC.

I've posted a request for help on Gecko's forum, and I'm searching on CNCzone, but haven't found anything yet.

201's are common as dirt, you'd think someone out there is running them with LinuxCNC and could share their setup info.

andypugh wrote:

What voltages do you see on the "DIR" pin at the drive in each direction?

The DIR pin toggles between 3.4 volts and 0.7 volts as the 201 drive changes directions. That's measured relative to ground, not measured relative to the 201's 5V common.

I've been trying all kinds of configuration settings and pouring over the manuals and at the moment I am stumped.

I guess worse case I could buy another 203 drive but the bank account is running on empty at the moment, and I'm not even sure that I want to permanently install LInuxCNC on this machine. I had encountered a few bugs in TurboCNC, particularly while threading, and had heard that LinuxCNC is reliable for threading (MachIII not so much or so I have heard). So I just wanted to try LinuxCNC to determine if it would run my processes and particularly do a certain threading operation.

I also have a RF45 project coming up that I was hoping to use LinuxCNC on, but it'll be using chinese DM860A drives, not Geckos.

UPDATE: I switched to a different PC of the same HP DC5000 model, and as it happened this 2nd HP DC5000 refused to work with 10.04 (it didn't like the on board graphics chip), so I had to install 8.04 and upgrade to 2.5.3, which was a major ordeal as discussed in another thread. Nonetheless the 8.04 box is running this morning and .....

..... the 201 runs so much better with this 8.04 box. So far I have only tried it with the default 201 timing settings, and it's still not as smooth as TurboCNC. Perhaps further tweaking the tuning will smooth it out sufficiently, we'll see.

As it happens the 8.04 box has higher latency than the 10.04 box, 42000 vs 26000.

I used the same StepConfig settings on both boxes, so in theory the software setup is the same.

Either 1) LinuxCNC runs differently on 8.04 or 2) there is an unidentified hardware problem on my 10.04 box that is messing with the 201. Any thoughts?

I guess the next step is to install 8.04 on the "problem" box and see if the problem with the 201 is still there ?

Remember, I never did figure out why the 10.04 box refused to run the 201 on pins 14 & 16, as discussed in another thread. There was definitely something screwy going on with the parallel port with the 10.04 box.

I think as long as I have this 8.04 box hooked up I will try switching the 201 back to pins 14 & 16 and see what happens.

UPDATE: after tuning the 201's pot and reducing the Z acceleration, the 8.04 box (let's call it HP DC5000 #2 for lack of a better name) is running the Z smoothly at up to 15 ipm. If I "lie" about the latency then I can get it up to 20 - 25 ipm, which is as good as I ever got with TurboCNC.

When I say "smoothly" I mean judging by ear. I haven't actually done any cycle tests with measurements. Nonetheless I trust my ear.

However, if I turn the spindle on (which has a VFD), the Z axis craps out. In fact, even if the Z axis is at idle, the VFD will make the Z motor jump and make intermittent popping noises. So obviously there is some massive interference between the VFD and the 201. Presumably the interference problem can eventually be tracked down and eliminated, so I'm not losing sleep over it at the moment, except to note that I never experienced VFD interference during years of running TurboCNC. I have the covers off both the PC and the drive system box at the moment so fixing the interference could be as simple as putting the covers back on.

It makes me wonder if the original problem with the 201 on the 10.04 box could have been related to some sort of interference ? The 201 is not as robust as the 203 so it's probably more susceptible to interference?

Andypugh, I'll try setting the steplength and space to 20,000 as you suggest but ...... I'm not sure that it is meaningful. In one place the documentation says those settings are in nanoseconds and in another place it says it is in base periods. So a steplen = 1 would be one base period (the base period is 67,000 on my 8.04 box). If that is true then setting the steplen timing to 20,000 in StepConf would have no effect. This seems to be the way it works because no matter what you plug in for step timing in StepConf, the HAL steplen is always 1 ???

In other words, I think LinuxCNC looks at the base period and says "if the base period is longer than the step timing, then the step timing defaults to one base period."

But I'm just a LinuxCNC newbie so don't take my word for it.

UPDATE: using the #2 HP DC5000 running 8.04, I reconfigured the 201 to run on pins 14&16 rather than 6&7. 14&16 did not work at all on the #1 HP DC5000 running 10.04, but they work fine and dandy on this #2 box.

At this point I dunno whether the 14&16 issue is due to Box #1 vs. Box #2 or due to 8.04 vs. 10.04.

Also, the VFD interference went away after switching to pins 14&16. That could be as simple as some wires getting moved slightly when I made the switch.

I think the next step is to try Box #1 with 8.04.