Hi Don,

Seeing the same problem after switching over to a servo system is weird indeed! But then, as Roger noted, I am curious if you were merely bench testing with the servo or it was really driving the machine. But my curiosity has other reasons, and I am afraid I have to disagree with Roger. While an unloaded servo will act absolutely differently and  will need careful tuning, there is absolutely no reason for it to move to other locations from those commanded by its driver.

I am very doubtful it's a software bug thought, since you have abstracted it to merely:

PC -> Mach3 -> Parallel Port -> Gecko(/Viper) -> Stepper(/servo)

Thousands of people are using exactly the same setup and no one has reported this. So either they don't have this problem or they just never discovered it. I think its the first option.

After you eliminated a possible wring issue, and considering the above said, the only two links in the above sequence that can be the problem are PC and Parallel Port card. You have switched between two absolutely different PCs with no change. Can you try setting the PP to different mode? This usually has no effect, but who knows... I remember Brian or Art once had a recommendation for the particular setting, but can't seem to recall what it was, so you'd have to try them all and see if it makes any difference. I know your findings show that a break out board looks to be having no effect on the problem, but I wouldn't recommend putting it back into the above sequence - not until you find the most abstracted sequence that works and then start adding things to it and see when the problem appears back again. This is again, just to eliminate any possibility of a combination of things.

So see if you can play with the above sequence, trying out every possible combination of PC and PP (card and settings). Another way would be if you could put your hands on some external motion controller, like the Smooth Stepper.

Dan

H, Dan.  Obviously the signals to the driver are corrupted.  The drivers only send the motors where they are told.
Considering that the base program I'm running is in the Mach manual, it would seem that if it were a common problem, everyone would see it.  It is not subtle if you are checking repeatability.
I've actually used 3+ different PCs.  1) PC Chips mobo, AMD Athlon proc. etc.  2) ASUS P5QL/EPU with Intel E6500 proc. etc. and 3) My current setup: Asus A7N8XE-Delux Mobo with AMD Sempron 2500+, etc.  This Computer has the smoothest OCX Driver test I've seen.  All have exhibited this offsetting behavior.  I also have tried it with a Dell Inspiron 8200 Laptop but had the same results.
I've used at least 3 different PP cables plus my cheater.  Replaced the cables from BOB to Geckos, etc. 
The Larken Viper servo system is just clamped to the top of the mill table, since It is a different form factor than my steppers.  Making precise angular offset measurements is not practical but with an indicator wire and a mark on the pulley on the motor, it is quite obvious that it is doing the same thing the stepper system does.  I don't think the table/leadscrew system has anything to do with what we are observing here.
I believe I saw a reference somewhere on the forum to using EPP Mode with the parallel port. It is the mode I'm using, after having tried all the options in the Bios previously to no effect.

The tests I did today seem to show the same results with the servo as with the Geckos.  I also set to Exact stop mode but other than running slower on the tests, The offsetting was the same.
I did notice that when running the test with G1X+.005 the machine stutters near the beginning of the test about 3 times and then runs smoothly for the remaining 2/3 to 3/4 of the test.  the BOB activity LED flickers accordingly.
OCX Driver test:  CPU Mhz: 1837  Shortest time: about 32.___ us,  Longest time: about 38.___ us.  APIC timing constant: 11910.  Max Variation 2.3___ us  The tallest spike on my 19" LCD monitor in the graphic display was less than a quarter inch tall.
I'll post a pic of the setup.

current setup with Viper drive in system.

Obviously the signals to the driver are corrupted.  The drivers only send the motors where they are told.

Yep.

Considering that the base program I'm running is in the Mach manual, it would seem that if it were a common problem, everyone would see it.  It is not subtle if you are checking repeatability.

Ah, but how many have actually done the sort of testing you are doing? NOT MANY!

I did notice that when running the test with G1X+.005 the machine stutters near the beginning of the test about 3 times and then runs smoothly for the remaining 2/3 to 3/4 of the test.  the BOB activity LED flickers accordingly.

OH???
Now that is interesting! And it looks like a software issue.
I've spent 40+ years writing software. Bugs happen, even in commercial products. (Windows, anyone?) Why not in Mach?

Cheers

Hey Roger,

The reason I doubt it is Mach, is that there are many machines running Mach3 on daily basis producing thousands of precision parts. These people would have easily noted a problem like this if it existed.

Software bug or hardware issue or a combination of both, I think it is something unique to Don's setup that exposes the problem. Just can't see what might it be.

I have had exactly the same problem of losing steps on reversals, but I was able to isolate it to a combination of the BOB and SS plugin I was using. The test I was running was set to incremental jog mode and the finest increment I could read with a DTI (0.01mm), then use the keyboard to step jog one direction and the other repeatedly. I could actually see the DTI needle moving gradually to one side. After the problem was resolved, the DTI was spot on after hundreds of iterations. So no such problem here, but I am using the Smooth Stepper, so can't speak for the PP.

Don, the stuttering you're seeing is not something normal. Have you tried following the optimization procedure?

Dan

The reason I doubt it is Mach, is that there are many machines running Mach3 on daily basis producing thousands of precision parts. These people would have easily noted a problem like this if it existed.

I am willing to believe, but it is certainly weird!
But if someone is making thousands of parts, I would imagine they would be using an jigs and autoloading of pallets, and under these circumstances just maybe they are also using a touch probe to check each pallet? Dunno, but maybe.

Software bug or hardware issue or a combination of both, I think it is something unique to Don's setup that exposes the problem.

Not arguing at all, but he has swapped so many of the components over. What's left?
Hum - clean XML file?

I have had exactly the same problem of losing steps on reversals, but I was able to isolate it to a combination of the BOB and SS plugin I was using.

Details, please! What was going wrong, and how did you fix it? The info may help here.

The test I was running was set to incremental jog mode and the finest increment I could read with a DTI (0.01mm), then use the keyboard to step jog one direction and the other repeatedly. I could actually see the DTI needle moving gradually to one side. After the problem was resolved, the DTI was spot on after hundreds of iterations.

A neat method. Worth trying here maybe.

Don, the stuttering you're seeing is not something normal.

100% agree. Need to sort it out. High probability of it being responsible. I do NOT get stuttering!

Cheers

Hi, again...  The repeatability test is on page 5-15 of the Using Mach3 Manual.  I changed the feedrate and distance to go to suit my impatient time constraints.  I just wish there was some way to "count" the step pulses as they came out of the parallel port.  Then I could have proof positive if the problem was really inside the computer.
The XML was cleaned out when I did the fresh install this weekend.  I uninstalled Mach3, then went searching through the computer and deleted the Mach3 folder.  Then I emptied the recycle bin.  Then I downloaded a fresh copy of the lockdown version to my Studio 17 laptop and burned a cd from that file.  That is all I installed.  No license file yet.  I was hoping the license file was somehow causing the problem but it was a long stretch. 

As you can see from the pictures, The servo motor is not hooked to the table.  It still offsets (rotates) around as I run the test program...
Roger, please instruct me as to how you set up and conducted the incremental jog test.  It might be interesting to try. 

Also I too would be very interested in details of your SmoothStepper offsetting odessy, and how you solved it.  I have been wondering if, should this be a pp issue(unlikely on 3 computers), a Smooth Stepper might be in the works for a test... 

If I could do it I would try to post a video clip of the "stuttering" behavior.  Any suggestions?
Don

Quote from: Dan13 on November 02, 2010, 03:02:58 AM

I have had exactly the same problem of losing steps on reversals, but I was able to isolate it to a combination of the BOB and SS plugin I was using.

Details, please! What was going wrong, and how did you fix it? The info may help here.

 

It was what you mentioned before. The drive was expecting the direction pulse to appear on the falling edge of the step pulse but the BOB/Smooth Stepper combination was outputting it on the rising edge (or vice versa). I was first trying to eliminate possible factors from the equation to find the ONE that was causing it. First take the BOB out of the equation - no change. Then take the SS out of the sequence and hook the PP directly to the BOB - no change. The switch between different cables. It was only after I accidentally removed both the SS and the BOB from the sequence that I found the problem was gone. A new SS plugin cured the problem. But the BOB was still no use without the SS - only worked with the SS new plugin.

One thing I seem to remember that was causing the problem with the PP was the Dir pulse setting was set too high. Setting it to 0 cured it. But I think Don has tried it.

Hope it helps.

Dan

It was what you mentioned before. The drive was expecting the direction pulse to appear on the falling edge of the step pulse but the BOB/Smooth Stepper combination was outputting it on the rising edge (or vice versa).

A question here. In the past I have always used the Dir line as a 'state' rather than as a pulse. That is, Hi goes CW, Low goes CCW. Does this apply here? Surely?
Otherwise, a timing problem with the transitions. Yuk! Sounds horribly right.

It was only after I accidentally removed both the SS and the BOB from the sequence that I found the problem was gone. A new SS plugin cured the problem.

Are you say then that either the SS or the BoB are apparently altering the timing of the original signal ? Oh Dear.

Cheers

Hi Roger,

I was talking about the Dir setting under Motor Tuning. The value there is how many micro-seconds before the first step in the opposite direction, the Dir pulse changes state. You are correct about the direction line that its Hi or Low state essentially defines the direction of the motor rotation. But the timing is critical here. Change it too soon and you lose one step in the current direction, too late you gain one.

Yes, the SS and the BOB were screwing the timing. It was an abnormal condition that was fixed with a new plugin for the SS. The opto-isolators on the BOB also were changing the timing slightly, but the change was so small that with the perfect timing of the fixed SS plugin it had no effect on the operation, but with the (rather "not perfect") timing of the PP it was adding up to a more substantial change that was affecting the operation.

Dan