Machsupport Forum
Mach Discussion => FAQs => Topic started by: cncnovice2 on September 20, 2010, 03:33:32 PM
-
I've been having a recurring problem that seems to involve repeatability when runnung more than one axis at a time on my machine. It seems that if i program it to do a diagonal move and return, after it completes a number of iterations it has offset in one or the other axis by the same number of "steps" as the number of iterations of the program. The program is similar to the one in "Using Mach 3" manual. Except that I'm moving to both X, and Y coordinates. Hence diagonally. If I use the program as shown in the manual, each axis works perfectly. Help! I'm losing my hair.
-
This is a strange one... you're only seeing it when both X and Y are moving...? Is it absolutely repeatable and consistent on both axes? Or it randomly appears on either one of them?
May be the breakout board is under powered? Try using a different power supply with higher current rating.
Dan
-
Hi, Dan, Here is some more detail as to the nature of my problem. I tried origially to post a lengthy description but it choked on it so i'll try to be somewhat abbreviated...
X and Y motors are 1200 oz. in. steppers.
Z motor is a1780 oz. in. stepper
All axes use 5 thread per inch ball screws and 1:2 belt drives.
Mechanically the machine is VERY solid.
Motor drives are Gecko G212
Power supply is a 800VA transformer, rectified into a 27,000 uf capacitor yielding an output of 70VDC.
Breakout board is a PMDX 120.
Now for the problem.
When running repeatability tests such as the program shown on page 5-15 of the Using Mach 3 manusl, each axis repeats and returns to zero perfectly. However, when I changed the program to move 2 axes simultaneously(diagonal), while the DRO says everything is back to zero, one or more of the axes is offset .005” from zero! This corresponds to 50 step increments. The example program is below:
F20G20G90
M98P1234L50
M30
O1234
G1X.1Y.1
G1X0.Y.0
M99
Starting at X 0.0000 and Y 0.0000, when the program as written above ends the X axis has offset exactly +.005”. The Y axis returns to zero perfectly. Does it every time regardless of feedrate, acceleration, etc.
FYI: Motor Tuning info: X and Y Velocity is set to 40, Z is 30. Steps per unit is 20000. Acceleration is set to 4 for all axes. Step pulse is set to 2 u/s per Gecko. I've played with these settings to no avail. The drives are set to 10 microstep per step mode using the jumpers on them.
If I change line 5 of the program to read: G1X.1Y-.1 and run the program, the X axis offsets +.005” and the Y axis offsets -.005”.
If I change line 5 to read: G1X-.1Y-.1 and run it, the X axis returns to zero perfectly, but the Y axis offsets -.005”.
If I change line 5 to read: G1X-.1Y.1 and run it, both axes return to Zero perfectly.
Running any one of these programs repeatedly, continues the offsets: .005, then .005 more etc.
This cumulative offsetting is bothersome. I would suspect some electrical crosstalk but rearranging the wiring etc. hasn't made any difference.
-
My mill is a Bridgeport sized bed mill made by Siber Hegner (Tiawaneze). The head runs up and down the column on ways. All leadscrews are anti-backlash preloaded ballscrews.
THINGS I HAVE TRIED, and things I have noticed.
1.The original computer was a PC Chips mobo with an AMD athlon 2500+ processor on it. 1 gig of RAM, an ATI agp video card, and a Moschips PCI parallel port card to support the MPG. It ran with Windows XP Home Edition and a lockdown version of Mach3 from 2+ years ago. I thought it could be a cheap computer issue, so I recently built another computer. Its Specs follow:
Motherboard: ASUS P5QL/EPU
CPU: Intel E6500 2.93ghz.
RAM: Kingston KVR800D2N5/2G one stick, 2 gigs.
Video card: ASUS EN8400GS Silent Video Card
Hard Drive: Hitachi Travelstar 250 Gig SATA.
Operating System is Windows XP Home Edition, and Mach3 R3.043.022 plus my lic.dat file.
The new computer exhibits the same problem as the old one.
2.I have changed out the parallel cable twice, to no effect.
3.I set up and substituted a CNC4PC model C10 breakout board. This had no effect, so I've reverted back to the PMDX 120.
4.I re set all the drives and breakout board to common ground instead of +5V common. BAD choice! The axes ran jumpy and jerky as hell. I set everything back to +5V common.
5.I tried running the Geckos directly from the printer port with a home made cable, but I got no motion whatsoever. I wonder why?
6.I also wrote another program that moves in a square:
F20G20G90
M98P1234L50
M30
O1234
G1X.1
G1Y.1
G1X0
G1Y0
M99
I got the same offset errors as with the diagonal program. I noticed that the toolpath display was rounding corners on the motion except at the X0Y0 coordinates... So I went into General Config. And changed from Constant Velocity to Exact Stop mode. Running the Square program now yields no offset error! I ran the Diagonal program, and the offset problem is back. It seems that only if one axis is allowed to move at a time will the machine repeat correctly. If 2 or more axes are moving at the same time, something is losing or injecting pulses into the step signal. Huh? I put the General Config back into Constant Velocity mode.
7.Setting Line 5 of the Diagonal Program to read G1X.00005Y.00005 and running it yields an interesting result. The X axis offsets +.005” as with the original program, but now the Y axis also offsets -.005”. Hmmm
-
Can you try running the program at a really slow feedrate, something like 1in/min? Does it still lose position? I think it is something related to the back EMF voltage produced by the motor while decelerating. So use a very slow feed rate and also reduce the acceleration. See it if it cures the problem.
You probably didn't have any motion when connected directly from PP to the Gecko drives, since your PP is outputting low voltages (3.3V is common) which is not enough for the drives.
Dan
-
Dan, Thankyou for the help. The PP voltage being too low for the Geckos is my theory too.
Now to the real problem...
I'm using the program listed in the previous posting. Only the feedrate inline one is changed.
I set the feedrate to 1 inch per minute and the acceleration on each axis to .5. Results: X axis offset +.010, and Y axis offset -.005”.
Curiosity satisfies, so I changed the feedrate to 20 and re-ran it and the results? X axis offsets +.010” and Y axis offsets -.005”.
I changed acceleration back to 4 for all axes, Feedrate 10, ran it again. Results as originally reported. X offset +.005, and Y returning perfectly.
Same results at feedrate set to 20 inch per minute.
I tried it at feedrate 1” per minute and got the same results.
It seems that accelleration rates that are slow are making the problem worse. Huh??? Feedrate didn't seem to matter.
I will try to post a picture of my setup so you can see it. Picture worth a thousand words...
Couls the close proximity of the Gecko motor outputs to each other be the problem? Please make suggestions and I will do my best to implement them and test them. Thanks for your help. Don
-
Hi Don,
It's strange... What's interesting that usually the solution to such problems is a real simple thing. It can also be a combination of several factors and that would really make it hard to detect.
I don't believe it could be it, but we have seen weird things in the past, so just for the sake of it can you uninstall Mach completely and delete its directory including the XMLs. And do a fresh install and set it up from scratch.
Also, what do you have for a step pulse width under motor tuning? Try playing with it. I find that anything above 0 with my G540 doesn't work well. Also try playing with the Step "active low" setting under ports and pins. Also, can you temporarily use a different power supple for the Geckos? Something less than 70VDC. May be up to 60VDC. I still have a feeling it has something to do with the back EMF voltage.
Dan
-
Hi Dan,
The Mach install is a completely new install New computer, new hard drive new installation of Windows XP, new download of Mach 3 from the internet to my empty USB drive, installed and set up using my notes regarding ports and pins, etc. I'll try to put together a more detailed list of the settings and get back to you.
I've tried playing with the stepwidth but it didn't seem to make any difference. I'll try again.
I'll see if I can put together another power supply. It might take some time.
Thankyou for the help and suggestions. Sooner or later we should hit pay dirt. Don
-
When running repeatability tests such as the program shown on page 5-15 of the Using Mach 3 manusl, each axis repeats and returns to zero perfectly. However, when I changed the program to move 2 axes simultaneously(diagonal), while the DRO says everything is back to zero, one or more of the axes is offset .005” from zero! This corresponds to 50 step increments.
Clarify please. If you cycle 50 times the offset is 0.005" or 50 steps. OK, If you cycle 500 times is the offset still the same, or is it 0.05" ?
If the latter, it seems that someone somewhere is losing part of the last stepping pulse. In which case I don't think that it is electrical per se; rather it looks like either configuration or software. I think.
Mind you, switching the DIR line on each reversal might do something a bit strange, depending on the configuration.
Cheers
-
Problem is that Don has the problem only when two axes are moving simultaneously. When moving each axis separately there is no position lose. That's what makes it strange.
Dan
-
Hi Dan and rcaffin.
If I up the number of repetitions, the amount of the offset seems to go up proportionally. As a result, I've been able to get away with ignoring it for one-off and simple parts. But its not supposed to do this.
Dan, I rewired the transformer inputs so my power supply voltage is half, or 35V, measured. While the motors sound a little softer than they do at 70V, the results of running the program were the same...
Test results this time:
Setting to “active Hi” had no effect. Didn't even sound different.
I tried setting the step pulse to 0 and to 5, and it made no change.
These tests were conducted with the original power supply setup.
After rewiring to 35V, The results are the same. I slowed the acceleration down to .5 again and the offsets were X +.010, and Y -.005”. As before.
I tried something else... Acceleration 10 on both axes, and the result is that the X-axis offsets +.010” and the Y-axis offsets -.005”. just like when the acceleration is very slow!!!
Setting the acceleration to 6 yields the result that X-axis offsets +.005 and Y-axis offsets -.005. Hmmmm.
I then returned the acceleration to 4 and as before, the X axis offset +.005 while the Y-axis returned perfectly to zero.
I'm not sure what this means, but I'm with you that back emf or crosstalk may be involved. Do you think re-arranging the motor cables coming out of the Geckos might be worth a try?
Thanks for your help. Don
-
Yes, Don. Do try rearranging the wires, but still a better thing to try would be to use shielded cables for the motor cables. It's got to be something in the particular way you have it all connected and setup. Lots of people are using exactly the same hardware (and of course software ;) ) with no issues, so it's something in the way you have it all arranged. Power supply doesn't seem to do any difference any more, so do try the wiring.
Dan
-
If I up the number of repetitions, the amount of the offset seems to go up proportionally.
OK, so it would seem possible that you are gaining or losing one pulse with each cycle. My suspicion would be that this is happening at the turn-around.
Acceleration 10 on both axes, and the result is that the X-axis offsets +.010” and the Y-axis offsets -.005”. just like when the acceleration is very slow!!!
Setting the acceleration to 6 yields the result that X-axis offsets +.005 and Y-axis offsets -.005.
This almost suggests that the effect is not really dependent on the value for acceleration?
but I'm with you that back emf or crosstalk may be involved.
Somehow I can't see this. It might be the case with a DC servo motor, but I think you said you are running large steppers? I am not aware of any significant back emf problems with steppers.
Two thoughts come to mind.
* You are often getting slightly different results for the X & Y axes. Which one has the greater mass? Could the momentum of the carriages have anything to do with it?
* Have you checked the quality of the drive signals between the SimpleStepper 9assumption?) and the BOB and the driver amplifiers. Could switching the DIR line be causing any problems to the STEP lines?
Cheers
-
I would also check the Ports and Pins configuration, to see whether you have the right sort of pulses for the Geckos. A mis-config here could give you that funny result.
Cheers
-
Somehow I can't see this. It might be the case with a DC servo motor, but I think you said you are running large steppers? I am not aware of any significant back emf problems with steppers.
When a stepper motor decelerates large mass from high speed it will act as a current source and send current back to the drive instead of drawing voltage from it. If the power supply voltage is near the drive's max it could damage the drive if proper means of dissipating this energy are not implemented. I was assuming that Don was having some moderate variant of this phenomenon, since the problem was only occurring when two of the motors where moving in the same time.
Dan
-
Hum, yeah, but as the result was the same at 35 V as at70 V, it does not seem very likely in this case - unfortunately!
Puzzles ...
Cheers
-
Yep
Dan
-
Hi, again. I'll try rearranging the wires but I would like to find some suitable 4 conductor shielded cable to use...
I too am suspecting that the error is occurring at the turnaround point, either when the direction signal is changing, or when the currents to the motors change in their sequence...
Acceleration values are affecting the result, but not in a linear fashion. Too high or too low and the errors get larger???? This is strange.
I'm not aware of any back EMF issues with steppers either but with 6 billion people and thousands of possible configurations of these machines in the world, why is it me that has the weird one?
As per my original posts describing the problem, The only differences are that the Y axis moves – and the X axis moves + when it gets these offset errors. The direction in which the program starts off ( which quadrant it goes into) seems to determine which axis/axes will drift. When they drift, it is always the same direction.
The X and Y axes have exactly the same motors and drive components. 1200 oz.in. Motors, 1:2 timing belts, 5TPI Rockford Ballscrews. The cross slid and table are exactly the same as Tiawanese Bridgeport copies. 9” by 42” table with the same saddle used on the knee mills.
I don't have the knowledge or equipment to test the signal qualities... I would probably smoke the parallel port, knowing my luck...
For information on stepper motor electrical characteristics search www.geckodrive.com for an article called Step Motor Basics. It is VERY informative.
I'll be going to the Oregon GEARS model exhibition in Portland Saturday, but I hope to get some re cabling done soon.
Thanks for all the help. Don
-
As per my original posts describing the problem, The only differences are that the Y axis moves – and the X axis moves + when it gets these offset errors. The direction in which the program starts off ( which quadrant it goes into) seems to determine which axis/axes will drift. When they drift, it is always the same direction.
I find that very consistent with the idea that it is a change in the DIR line at the end of a traverse which may be causing the single step. I don't know exactly how Mach handles reversals, but see the next comment.
I don't have the knowledge or equipment to test the signal qualities... I would probably smoke the parallel port, knowing my luck...
Actually, you can do some testing with no gear at all. First, check the specs on the Gecko drives: do they want positive-going pulses or negative-going? Then look at the Pins&Ports page for outputs: are the lines to the motors drives configured to be normal or inverted? ie, what polarity signals are being created? If there is a mismatch here it could cause the problem. Try altering the polarity of the signals and see whether that makes ANY changes in the behaviour.
What i am suggesting is that IF you have the polarity of the pulses reversed, switching the DIR line may cause a small pulse on a STEP line as an artefact of the software. I have no idea whether this can happen with Mach, but it is not unknown in some device interfaces.
And do check the earthing yet again... Funny stuff.
Cheers
-
Gib play will can cause what you are seeing. You are not llikely to see it until XY move is done but it will be some min/max range varying within the range on return to zero. Backlash could also play into it all. Make sure the mechanics are all correct before looking for lost pulses.
RICH
-
Hi, guys. Thanks for the input. To address your concerns and questions:
The specs on the gecko drives allow them to be set for +5V or 0V common. I've verified this and tested both ways since the PMDX breakout board and the CNC4PC breakout boards both have selector jumpers to set this. As I posted earlier, when I recently tried running in 0V common, the machine was very jerky... +5V ttl style signals seem to work best.
However, Due to my Y axis being inverted as to the Dir polarity as compared to the X axis, it doesn't surprise me that the X and Y axes are offsetting in opposite directions. All Step pulses are set to active lo, as per the manual.
The gibs on the ways are carefully set. Also the running of the program multiple times accumulates error. Gibs and backlash would play within their bounds. Also, the pulleys aren't slipping as I have checked that carefully. The Screw pulleys are keyed as were the original dial carriers, and the motor pulleys have set screws into the flats on the shafts. The mechanics of this machine are Very stiff and solid. Total lost motion measures <.0003”.
I'm in the process of trying to find some suitable 4 conductor shielded cable of about 16Ga. To re-wire all the way from my Geckos, to the motors. When I get this done and test it, I'll report back.
Don
-
Hi I am new in this world (CNC), few days ago, I launch my first works, after I configured Mach3, following word by word the instructions from the manual, when I ran the first job (my companies logo) just using a pencil (after I did all tests and checked de precision of movements and positions) I saw with deception, my machine after 1200 lines, goes erratic in positions, while the screen wich follows the tool path was correct.... in this way I tought, it is not troble from the software, it is probably concerned to the tuning of motors or a mechanical problem... it was both... some pieces of garbage on the leadscrews, and the values of speed and acceleration in motor tuning... well, after many changes and tests, reducing speed and increasing acceleration, finally, the machine is runing ok.
I think your problem is similar, I Hope the solution be in the same way..
-
Hi, again. I've been trying a few things...
I twisted the power supply wires and rerouted the Gecko outputs and got no change in the behavior of my mill. Then I had a flash. I disconnected the power and signal lines from the Y-axis Gecko drive. Then I ran the diagonal program with line 5 reading G1X+.1Y+.1 and the X axis still offset +.005, as before. I don't believe the motor drives or power supply is causing the offsetting.
Next I swapped the X and Y signal headers on the PMDX B.O.B. And changed the Motor Outputs in the ports and pins accordingly. Ran the above program, results: Now the Y axis offsets -.005 and X returns to zero perfectly.
I then swapped X and Y axis headers on the B.O.B. But didn't change the motor outputs back and ran the test. Results: X-axis is offset +.005, and Y axis is returning to zero perfectly.
In Motor Outputs, I changed the Dir Active Low on the X and Y axes. They had been checked for X and X'ed for Y. The X and Y axes were still swapped but directions are now reversed. The result: X axis is perfect but Y axis is offset -.005.
I put things back to their original configuration except that the directions in Motor Outputs were still swapped. The result was X axis offsets +.005 and Y axis returns perfectly to zero.
I put everything back to original, except I left the X-axis Direction X'ed (reversed). Now when I ran the program The x axis was moving in the wrong direction, but both axes returned to zero!
I reversed one pair of output wires from the X-axis Gecko drive. The machine ran the program perfectly.
I changed line 5 of the program to read G1X-.1Y+.1 and ran the test. The result is that the X axis offset -.005 and the Y axis returned to zero!
I changed line 5 of the program to read G1X-.1Y-.1 and ran the test. Result: Both axes offset -.005.
I changed line 5 of the program to read G1X+.1Y-.1 and ran the test. Result was X axis returns perfectly to zero but the Y axis offsets -.005.
I then changed the program back to its original G1X+.1Y+.1 and both axes returned to zero.
By changing the Dir Active Low of the X axis, I've changed the direction of the offset to -. When the machine is commanded to move an axis in the positive direction, it will return to zero when commanded correctly. But is an axis is sent negative, and more than one axis is moving simultaneously, then the axis that is going negative will accumulate steps in the negative direction.
Logic, anyone? It seems that the problem is in the computer. Either in the way the parallel port is interpreting the instructions or in the Mach signal generation or something... Current configuration is that the ports and pins Motor Outputs are all Dir Active Hi and when multiple axes are commanded to move and return to zero, the axis/axes that are commanded to move in the negative direction and return to zero are getting an extra step in the negative direction for each iteration of the program!!!
I guess my problem now is to determine the cure. Help!
Don
-
I'll try to un-install the Mach program and delete the folders and reinstall when I can to see if that changes anything. I doubt it as the problem has occurred with 2 computers and 2 versions of mach3.
I am curious as to what Enhanced pulsing doed in General Config. It is checked in my setup, and seems to be the default setting.
Don
-
It seems that the problem is in the computer. Either in the way the parallel port is interpreting the instructions or in the Mach signal generation or something...
Hum ... I agree with your logic (I think), but why you and apparently no-one else? But i would try to bring this to the attention of Artsoft, methinks.
Cheers
-
Hi Don,
What keeps confusing me is that you're seeing the problem only when there is motion on two or more axes, but never when it's a single axis move.
Would be still interesting to eliminate the breakout board from the equation. I know you tested with two different ones, but anyway. When you tried running the Geckos directly from the PP did you do it with both computers and they both had insufficient voltage going out from the PP? Can you find another PC with a PP that would output 5VDC signals, or find a PP card with 5VDC to install in your current PC?
Dan
-
I have substituted a CNC4PC model C10 B.O.B. and it had no difference in behavior. I'm trying to cobble together a pc with an Asus A-7N8X-E delux motherboard, It is about 6 years old. It would be nice to bypass the P.P. completely, but I'll have to see... I've been wondering if the SmoothStepper would work. It is a possibility if it doesn't create another can of worms.
Don
-
You know, I can't help feeling that you are chasing a lot of dead ends. Sorry, but. Why so?
You seem to have found that the problem is highly reproducible. That argues against random noise.
You seem to have found that the problem is a function of the number of repeat cycles. That certainly is not random noise.
You seem to have found that the problem is not dependant on which motor or which servo driver is used.
I very much doubt that BoBs have anything to do with that.
I very much doubt that the actual CPU board has anything to do with that.
I very much doubt that the PP device has anything to do with that.
This seems to leave the software: Mach and the XML files.
My 2c.
Cheers
-
Hi, again. I hooked up a digital volt meter to the direction pin of X axis of the parallel port on the Intel based computer. When I powered up the computer, the pin went to 3.3V. As soon as I start Mach3, the pin goes to zero volts. I expected it to toggle back and forth when the program runs, but it stays reading 0V the whole time... Pins used are pin 3 is Direction and pin 18 is common.
My setup is configured so that pin 2 is X-axis step, Pin 3 is X-axis Dir., pin4 is Y-axis step, pin 5 is Y-axis direction, etc. Since I twisted the one pair of X-axis motor leads, all three axes are direction active “hi”. All step pins are set active low.
The old PC Chips computer has a NetMos PCI parallel port card on it that I used with an MPG. I decided to check it out. When firing up that computer, the NetMos reads 5.0V on pin 3 until I start Mach3. Then it too goes to 0V. I set all the motor outputs to port 2 and plugged it into the PMDX breakout board. Running the diagonal program X+ Y+ resulted in both axes offsetting -.005”. Running the program with X- and Y- yields perfect return to zero. Yada, yada. It seems that with this parallel port card the polarity of the direction of commanded movement under which the error occurs is reversed from the other computer. The error is still offset to the negative direction as with the other computer, but now it only occurs when the affected axis is starting out in the positive direction. Strange.
I then tried to take the breakout board out of the equation. I have a D-sub 25 male connector that I have used that has 3 separate shielded cables with 4 conductors each. Each cable is wired for an axis so that I can hook it up to a gecko drive directly. Shield goes to earth ground. One wire to com., one to step, and one to direction. As the Geckos are set to +5 volt logic, it should work. Right? Result is no movement at all. I checked everything but for some reason, even the NetMos 5V card doesn't drive the Geckos. Huh? I'm not sure how this TTL stuff works. And yes, I tried reversing the Step and direction settings. No dice.
I plan to hook up the NetMos PP card in the new computer soon, installing the drivers was a pain last time, and then see what effect that has on the symptoms...
Thanks for your help,
Don
-
Don,
It is normal - when starting Mach it takes over the PP and pulls low all the pins. What is not normal is that you don't see the direction pin changing state when moving the axis in different directions. This is strange. You didn't have anything connected to that pin when doing the measuring, did you? I don't know why that would happen...
Where did the D-sub 25 connector go in? How did you plug into the PP DB25? Can you measure the voltage of say the direction pin while it is not connected to the Gecko and compare it to the voltage when it is connected to the Gecko?
Dan
-
Hi, Dan
Nothing was connected to the D-sub 25 pin cable. Just the voltmeter. The plug is a male plug and plugs right into the parallel port. I'll try measuring the voltage at the gecko terminal block while it is attempting to run... Why would it work with the B.O.B. but not the Gecko? Don
-
Don't know, Don, sounds like insufficient current. You will see it when you do the measuring. If the voltage drops noticeably when it is connected to the Gecko (probably to 2V or something) then you'll know the current is insufficient.
Dan
-
Hi, Again Dan. I still had the d-sub cheater cable hooked up from yesterday so I checked voltages at the Gecko terminals.
Voltage on Dir pin at computer startup goes to 4.8 V and stays there even after turning on the Gecko Power supply. I started Mach3 and loaded the diagonal program. While running, the voltage fluctuates between 4.3 and 4.8 volts on my meter. I suspect slow meter response time... I slowed the feedrate to F5 in the program, and now the fluctuation is from 4.6V to 4.9V on the direction pin of the gecko. This being referenced from the com terminal. I hope this is helpful in some way.
-
Hi,again. I was typing while you were posting. Looks like insufficient current isn't the problem. But what could it be?
Don
-
Hmm... Don't know. The voltage should pull low - effectively 0V. Practically you'd measure something like 0.1V or lower.
I will give it a thought, but hopefully someone will chime in with an idea...
Dan
-
Hi everybody. I installed the NetMos PCI parallel port card in the new Intel computer. Installation went well. Whew! I'm not really a great computer geek, so these things sometimes worry me.
Voltage from the NetMos is +5 volts. Duh! A clue here. My Geckos are set for +5V common! No wonder they wouldn't run.
I switched them over to 0V common, and hooked up my D-sub 25 cheater cable. Now the machine runs. But...
Backwards. Makes sense because of the direction polarity. I switched it over in the motor outputs to get it right.
Errors... The machine ran better than it had when running from the B.O.B. In 0v common mode. However, Both axes offset. X axis +.005” and Y axis +.007 or so...Hmm. I changed line 5 of the program to X-.1Y-.1 and ran the program. Now X-axis returns to zero, but the Y axis is offsetting about .0025” each run of the program!
Using 0V common, and no B.O.B. Changes the direction of the offsetting behavior, and introduces an apparent +.0025” offset per run of the program.
I set everything back over to the LPT1 3.3V parallel port. Geckos run... with motor outputs page set for direction active low, the machine runs in the correct directions, but running the G1X+.1Y+.1 program, X axis offsets -.005” every time, but the Y axis offset has been irregular. It seems to range from +.0075” to as much as +.0125 in the 50 iterations of the program! Hmm.
My brain is straining. I realize that the irregularity may be coming from the same source that caused the machine to run jerky with the BOB set to 0v common, but I don't get why now with the machine going positive in both axes, the X axis consistently offsets -.005” and the Y axis is offsetting + some amount more each run of the program. I'm wondering if this is a noise issue as well as a program execution error. Help would be appreciated. Thanks for your continued support.
Don
-
Don,
What happens if you swap the motor cables (running from the Geckos to the motors) of X and Y axes? Does the problem follows or still remains the same on same axes?
Dan
-
First of all, good electrical engineering practice would use 0 V as the common. Using +5 V (if I understand you correctly) is just not good practice. Possible, but unwise imho.
Now, the extra pulse at the end of every cycle, leading to a slow drift sometimes. Some thoughts:
When you move a single axis it is easy for the software, and my understanding is that you have no troubles here.
But when you move two axes at once with a G1 move, the software has to keep the two axes in sync. OK, it does this. But now consider what happens at the end of a pass, when you want to reverse the move. The software has to set things up for the two-axis sync again, in the other direction. Under these conditions it is possible for the software to reset the outputs and incur a single-pulse error on one axis. If you repeat this EXACT cycle you are going to get this single-pulse error every time - if it happens at all.
Note: this is a KNOWN PROBLEM in the CNC world.
Well, who is going to notice a single pulse? It's probably less than a micron or so. Ah, but what if you do this 100 times: the single pulses start to add up. Then you start to see an offset - sometimes.
OK: test this. Try cycling 1.000" 100 times on both axes and log the offset. Now try cycling 1.001" 100 times, and 1.002" and so on. See if the error comes and goes, depending on the EXACT measurement commanded. It will be interesting to see the results.
Cheers
-
Hi dan. I will have to try that tomorrow. Its getting toward 10:40 PM here in the Seattle ares and the kids bedrooms are right over the garage shop. I don't want to wake them. Are you suggesting that I swap the cheater cables from the parallel port to the drives? I'll try that and report back. Thanks for the suggestion.
Don
-
Hi, rcaffin. I have tried 0V common and it runs terribly jerky with the breakout board. Gecko suggested some years ago to use the +5V com. setting as it is supposed to reject noise better. I'd like to know where the "noise" is coming from. When I originally was having this problem I was using a move of 1.00 inches. 50 iterations of that took a long time, so I shortened up the distance. I can see that if this was allowed to go on, a large part run might get ugly real fast. Aren't computers supposed to do what they are told? Don
I'll try changing the program though to see if it has any effect. Thanks for the suggestion.
-
I have tried 0V common and it runs terribly jerky with the breakout board. Gecko suggested some years ago to use the +5V com. setting as it is supposed to reject noise better. I'd like to know where the "noise" is coming from.
The noise source can be too MANY earth connections. You need to have one central earth connection and then to make radial connections to everything else. NO cross-links. Me, I would treat this as a separate problem, but I would want to resolve it completely. Using the +5 V as a 'common' only masks the problem.
When I originally was having this problem I was using a move of 1.00 inches. 50 iterations of that took a long time, so I shortened up the distance. I can see that if this was allowed to go on, a large part run might get ugly real fast.
No reason you couldn't use a move of 0.100" instead. The single-pulse error is not dependent on the length of the move. Try 0.100", 0.101" etc. If your system can handle it, try 0.1000", 0.1005" etc, or even smaller steps.
Aren't computers supposed to do what they are told?
Yeah, just like children are supposed to ... :-)
Yes, they do (normally) execute their instructions faithfully. But they execute them BUGS AND ALL. If there is a small coding error (or approximation), that will be faithfully executed too.
Cheers
-
No, Don. I am suggesting you swapping the cables going from the Gecko drives to the motors.
Dan
-
Ah, I will try that, too. See the following post for some interesting results prior to getting your most recent suggestion, though.
Thanks, Don
-
Hi, I've been trying a few things in response to your suggestions and now am confused.
I swapped the X and Y axes at the Geckodrives. The X axis offsets +.005” the Y axis offsets +.0075 or so... Seems like it might be somewhere outside the computer now.
I checked some voltages... - side of Gecko power supply cap. to chassis ground measured at 11.1V when idle, and varied around 9.8V when the program was running. I grounded the cap. to the chassis near the geckos. The gecko signal common (0V) is reading 0V relative to chassis. I found no change in behavior after I changed the power supply.
I changed the axes in the motor outputs and this didn't change the offsetting behavior noted above. Now It really seems to be something outside the computer.
I disconnected the terminal blocks from the X axis gecko - no power, no signals. Running the program yields the Y axis still offsetting about +.0075”. I disconnected the Y axis terminal block and reconnected the X axis and the X axis still offsets +.005”.
I changed the program to move only the X axis, resulting in no Y axis movement. The X axis still offset +.005”. What??? It used to take 2 axes moving to cause this! I disconnected the X axis and reconnected the Y axis. No movement at all. Whew! I shouldn't with only X axis moves programmed.
I hooked up the B.O.B., set to 0Vcommon. Set motor outputs back correct for the machine. I ran the diagonal test program: It runs smooth like +5V common now unlike before grounding the power supply cap. but... X axis offset +.005 and Y axis offset about +.0075”. Running the X axis only program yields X axis offset of +.005”.
It seems that now, with the power supply grounded to the chassis, the problem hasn't gone away. Using the 0V common has only made the problem worse.
I reset everything back to +5V common, etc. except that the gecko power supply is still grounded. Results are that the diagonal program behaves as before. Any axis that starts in the negative direction offsets in the negative direction.
I ran the X axis only test program. The X axis now offsets -.005” regardless of whether starting out positive or negative!!!
I tried changing vectors, ie X-.1Y-.04 etc. and changing the values does not seem to affect this problem.
I plan to try to re wire the power supply system in the next few days.
A few questions.
1)When using +5V common for the signals, do I dare connect the common to the Star ground?
2)Should I attempt to connect the computer chassis to this ground?
3)What other considerations should I make?
4)I would appreciate photos of your working systems if you wouldn't mind.
Thankyou in advance, Don
-
1)When using +5V common for the signals, do I dare connect the common to the Star ground?
Dunno - might work, might not, depends entirely on the rest of your config. There would have to be risks to power supplies etc, which don't exist when using a common 0 V.
2)Should I attempt to connect the computer chassis to this ground?
IF and only if you are using a common 0 V for every thing, then this would be a good idea. Here in Australia everything has an earth connection, and safety is much improved as a result.
However, you should ideally have an optical isolation stage in the BoB for safest results. There's a lot of power running around the place, and earth loops can carry surprising currents.
Cheers
-
Thanks for the suggestions. My concerns are mostly with regard to frying the outputs of the breakout board. I'll probably not worry about the signal common as the path is short, but I will try to star ground the shield. Everything here is supposed to be earth grounded. My chassis, machine, computer cabinet- they all have electrical grounding through the mains to prevent elecrocution.
I have one other question. Would 18 Ga. conductors be adequate for my stepper motors? I can find 18 Ga. 4 conductor shielded wire but nothing heavier without incurring ridiculous cost. Besides, I think the leads on the motors are about that gauge.
Thanks, Don
-
Hi Don,
18 gauge should be fine. I think it shouldn't have any issues up to some 10 Amps.
Dan
-
Cable has been ordered. Should arrive in a week. I would still like to see pictures of working systems' layouts... Thanks, Don
-
Don,
I don't have ready pictures of my machines' cabinets and taking some is a real hassle now. Hopefully someone else could share. If you search the forum though you'd find quite a few. Hood, for instance, posted his photos on several occasions.
Dan
-
I would still like to see pictures of working systems' layouts...
An open layout where you can get at everything is gold.
Cheers
-
Hi, again... I've rearranged things and put a new computer into the system but I'm still having trouble. The new cable to the motors is 4 conductor plus shield and the shields are star grounded to the Geckdrive power supply minus terminal. I'm still getting offsetting issues. I'll post some pics of the current setup. Please tell me if there is anything obvious...
Don
-
This is the current configuration of the system.
-
Hi Don,
Can you now use your special shielded cable directly from the PP to the Geckos to bypass the breakout board?
Are the signal cables to the Geckos (step and direction) shielded and grounded at the breakout board end? Looks so on the picture, but hard to tell exactly ;)
Dan
-
The new cable to the motors is 4 conductor plus shield and the shields are star grounded to the Geckdrive power supply minus terminal.
Are they grounded at one (Gecko) end or grounded at both ends (Gecko and motor)?
Btw - you could also try putting a large film capacitor (say 0.1 uF) across the big electrolytic.
Cheers
-
I could try it... I've come across a page on Gecko's website on dealing with RFI issues. It suggests using a 5 conductor cable with the shield. My step and direction cables are shielded and the shields are attached to the star ground on the power supply. Gecko suggests grounding the motor case with the 5th wire to the power supply ground and connecting the shield to the electrical box only at that end. I'll try that as soon as I can. I'll try using some coax with the shields of the 4 conductor and coax tied together.
Sorry about the rats nest appearance, there are a LOT of ground connections... Thanks, Don
-
rcaffin, all the shielded cables, including the signals are only grounded at the star connection on the power supply capacitor. I haven't grounded the chassis yet. I'll try that tommorow evening and see what it does before I try to implement the Gecko suggestion. Don
-
rcaffin, all the shielded cables, including the signals are only grounded at the star connection on the power supply capacitor. I haven't grounded the chassis yet. I'll try that tommorow evening and see what it does before I try to implement the Gecko suggestion. Don
It's Roger. :-)
Anyhow, my advice is to NOT ground cables at both ends. I assume the motors are grounded to the chassis, and the power supply *should* be grounded to the chassis as well, but I would NOT run any parallel earth connections. The potential for ground loops is real and bad. For this reason I have reservations about the Gecko 5-way cable idea. Actually, running a serious earth cable in with Step/Dir signal lines strikes me as really bad news.
I admire the star connection on the electro, but it must be a bit of a problem managing it. I know we can buy very heavy brass terminal bars with something like 16+ holes for mains connections in switchboards and junction boxes. I would probably use one of those for the single earth point instead. Ratings of 100s of Amps.
Cheers
-
Hi, Roger, Thanks for the suggestions. I too have reservations about the additional grounding of the motor case for the same reasons you list. I'm trying to keep every thing single connected so there wont be paralleled circuits. The motors are indeed bolted to the aluminum mounting plates on the aluminum brackets on the machine elements and have electrical continuity to the chassis. I don't know how running an additional ground would help unless they were electrically isolated, which would be difficult to achieve. The capacitor has #10- 32 threaded posts so I was able to get a longer screw to lock everything down. I haven't gotten to work on the project this weekend yet but I'm going to try to ground the chassis first. I'll see if that changes the running behavior. Thanks
Don
-
I put a small jumper from the negative terminal to the chassis Aluminum plate, and it had no effect... Hmmm. What am I missing, here?
Don
-
I put a small jumper from the negative terminal to the chassis Aluminum plate, and it had no effect... Hmmm. What am I missing, here?
Don
You know, debugging earth problems from the other side of the planet does present problems! So pls forgive my basic Qs.
I can see 4 wires from the +ve terminal on the electro, apparently going to each of the 4 Geckos?
I can see 12 black wires from the -ve terminal, and I am not sure where they all go. For sure, 4 go to the Geckos, and perhaps 4 more go to the screens on the motor power cables? But the remaining 4? Step/Dir cable screens to the SimpleStepper?
Now, the earth strap you put in. Can you remove it and check to see whether there already is continuity between the -ve terminal on the electro and the chassis? If adding a strap had no effect, you may already have a connection - dunno where.
Are you using the SimpleStepper with a BoB, or is it all connected directly? I can't tell. Off-hand, I don't know whether all your Step/Dir signals have optical isolation, which is HIGHLY desirable.
Btw - nice layout. I wish mine was that easy to access.
Cheers
-
Hi, again Roger. Yeah, its hard to do remote diagnostics. Now to your questions.
1) 4 + wires to Gecko positive terminals.
2) 12 wires... 4 to negative on Geckos, 4 to signal wire shields - at Gecko end only, 4 to stepper wire shields - at gecko end only.
3) The breakout board is a PMDX 120. Older model, now considered "legacy". It has its own mains power supply, the transformer in the lower left of the board. It is driven directly from the Computer.
I removed the temporary earth strap, but there is still continuity from the Cap to chassis. I don't know where.
According to the manual the breakout board AND the Geckos both use optical isolation.
It is on the floor, but accessible. Looks nice but don't work so well... I'm wondering if one of the components - BOB, Transformer, ?, could be shorting to ground... I'll have to try checking.
Don
-
I removed the temporary earth strap, but there is still continuity from the Cap to chassis. I don't know where.
Just an observation but I think you should pursue this.
Tweakie.
-
I removed the temporary earth strap, but there is still continuity from the Cap to chassis. I don't know where.
OH????? As Tweakie said, pursue this one. It might be rewarding.
> According to the manual the breakout board AND the Geckos both use optical isolation.
Nice. And good.
Cheers
-
I will. It seems incorrect for there to be a short? or connection to ground that shouldn't be there. I removed the connector blocks from the Geckos, and then checked from their pins to ground. The short is not there. I'll start disconnecting things and testing untill I find something. Thanks, Don
-
I've been busy. I did find that the A-axis gecko exhibits a continuity from the negative power input to chassis. None of the others does. Hmmm.
I removed ALL the wiring for everything and hooked up only the X axis. I set the gecko and the PMDX BOB to 0V common. I hooked up only the x-axis signal wires. I hooked up only the + and - power wires to the x-axis gecko. I hooked up only the x-axis motor. There, very simple. No shields hooked up, just the wiring for the one drive. I have noticed that the computer MOBO has parallel port shield to chassis continuity, but that doesn't surprise me.
Result? Offsetting behavior. .005" in 50 repititions of the diagonal program. I started hooking up shields to the power supply negative terminal, all to no avail. I tried playing with the step and Dir timing in Motor Tuning, trying values from 0 to 15 us but that had no affect either.
I tried to run the x-axis only program and it offsets the same .005" per 50 repetitions also.
This also occurs with my cheater cable feeding the gecko signals directly from the Parallel port. So, I'm pretty sure the PMDX BOB is not causing any of this.
With only one axis hooked up, where could the problem be.
-
OK, so even with just one axis hooked up you are seeing the creep. I make the creep 0.0001" per cycle, right? Just possibly that is the resolution of your axis?
I am now 99% convinced that this is a bug in how Mach handles multi-axis moves, at least with the Gecko drives. Changing the Dir signal is causing a change in the state of the Step signal which is effectively injecting a single step. The consistency of your results precludes random noise imho.
Checks to run:
1) Verify that this produces the same amount of creep despite having moves of 0.25", 0.5" 0.75"...
2) Verify that N cycles produces a creep of N*0.0001", where N=50, 100, 150, 200 ...
3) Check to see what the single step resolution of your machine is.
If both of these produce positive results, then you have a good case for going to ArtSoft with the data and requesting a check of the code.
A further rather cunning test is as follows, and it assumes that your resolution is 0.0001". Repeat the 50 cycle test for 1.0000", 1.0001", 1.0002" ... See if there is any variation in the creep as you move through the single-step increments. What you will be trying to do here is to alter the state of the Step signal when Dir is flipped. This may or may not produce interesting results - hard to say at this stage.
Making your wiring really clean is worth doing of course, but it seems you really have two separate issues here.
cheers
-
Hi, Roger. The steps per unit on my machine is 20000. 5 thread per inch ball screws. 1:2 reduction belt drives. 200 steps per revolution motors. 10 microstep settings on Gecko G212 drives. Single step resolution of the machine is theoretically .00005" of course the mechanicals aren't that precise. My tests of "backlash" have shown about .0003" or so.
I'm getting a consistent "overshoot" on the way back to Zero such that it returns beyond 0.000. Each cycle seems to move the offset .0001". Only by raising the number of iterations can I see it on my machine dials which are calibrated in .001" increments. If I run the loop 50 times, I get .005 past zero. 100 times, I get .010 past zero. etc.
I have set the system up with ONLY the x axis connected, the logic set to 0V common, ( so the parallel port can run the drive directly) and with or without the breakout board the result is the same.
I believe this computer is using the current lockdown version of Mach3. The only thing common to this setup is the license key and the drive system. I'll try to include a picture of the current setup with my cheater cable.
-
Current setup with only the X axis hooked up.
-
Single step resolution of the machine is theoretically .00005" of course the mechanicals aren't that precise. My tests of "backlash" have shown about .0003" or so.
One pulse at each reversal gives 2*0.00005" = 0.0001" per cycle. As predicted.
Each cycle seems to move the offset .0001". Only by raising the number of iterations can I see it on my machine dials which are calibrated in .001" increments. If I run the loop 50 times, I get .005 past zero. 100 times, I get .010 past zero. etc.
If this applies to 150 iterations and 200 iterations, we have a software bug - or a strange interaction between Mach3 and Gecko. I favour the plain SW bug.
Document fully and report to ArtSoft.
Cheers
-
I just ran some more tests. Changing line 5 from G1x+.1 to G1x-.1 does not change the direction of the offset. it still moves +.
+.005 in 50 repetitions.
+.010 in 100 reps.
I set the line 5 to read G1X+.00005 and ran the program with the loop set for 100 reps. No movement was detected at all. None!.
I set the line 5 for X+.00010 and 100 reps yields +.010 offset.
Set for x-.00010 yields the same +.010 offset. Hmmm.
Now for the wierd one.
I set the line 5 to read G1X+.00015 and ran the 100 reps. the offset looked like almost .0110"!!!
So I ran it again and again - a total of 10 times. Offset is .110 total.
When it runs the program, the movement sounds sort of stuttery, unlike when it is actually moving some distance. ???
-
I have tried some other tests over the last fw days. adjusting the Motor Tuning step pulse numbers from 0us to 15 us has no effect. changing the dir between 0 and 5 us has no effect. I've tried several grounding and shielding schemes but no change in behavior is detected. Hmmm.
-
I just ran some more tests. Changing line 5 from G1x+.1 to G1x-.1 does not change the direction of the offset. it still moves +.
+.005 in 50 repetitions.
+.010 in 100 reps.
That is consistent.
I set the line 5 to read G1X+.00005 and ran the program with the loop set for 100 reps. No movement was detected at all. None!.
This is not inconsistent at all. Such a small change may simply leave the Step signal in the opposite state, such that flipping the Dir line does not cause the change in the Step line. In effect, this is working around the bug (if I am right).
I set the line 5 for X+.00010 and 100 reps yields +.010 offset.
Set for x-.00010 yields the same +.010 offset. Hmmm.
Consistent. But try 150 and 200 cycles as well for really convincing proof.
Now for the wierd one.
I set the line 5 to read G1X+.00015 and ran the 100 reps. the offset looked like almost .0110"!!!
So I ran it again and again - a total of 10 times. Offset is .110 total.
Ok, two parts. The first part is that going from 100 cycles to 1,000 cycles gives 10 time the error. This is entirely consistent with the idea of a bug somewhere, either in Mach3 or in the Mach3/Gecko interaction.
What significance there is to the fact that you are micro-stepping the Geckos is something I am not entirely sure about. It may be worth while asking Gecko about this as well - with full data.
When it runs the program, the movement sounds sort of stuttery, unlike when it is actually moving some distance. ???
Dunno. Obviously you are way down in the acceleration phase, and that could be tricky. I would check this with both ArtSoft and Gecko.
Bottom line: while cleaning up the earthing etc is good, I do NOT think the real problem lies with your hardware. It is in the ArtSoft and/or Gecko domains. You may be able to produce evidence of the problem, but I do not think you can resolve it yourself.
Cheers
-
Hi, Roger. I just uninstalled the Mach software and am cleaning out the computer to make sure it is ALL gone. Then I'm going to download a new copy and install it. Without the license file, at first. If that doesn't fix it, I have one other card in my hat. I have a couple of Larken Automation Viper 200 servo drives and an Ametek servo motor that I'll try to set up to see if it repeats any differently. I know it could open another whole can of worms, but It might be worth a try. Thanks for the help so far. Don
-
Thanks for the help so far. Don
Hey, if the effect is real, I want to know - and to see it fixed! Very selfish motives ... :-)
Cheers
-
So do I.
I just completed purging the old Mach3 install. I installed the Current Lockdown version. Downloaded onto this computer, burned a CD, took CD to shop, installed it into milling machine. No license installed yet. I've configured the axes and run the x-axis test program. Now the darn thing offsets to the minus direction!!! Yup, -.005" in 50 repetitions. I gotta go to dinner. I want to try the same tests as earlier today ie. short travel, 100 reps, etc to see if the behavior is consistent when I fire it up later tonight. I feel like I'm in the "Twilight Zone"... Don
-
The strange-ness gets stranger... I set line 5 of the test program to X-.00015 with the loop set to 100 repetitions, ran the program, and it walked over to -.011...
I set the loop to 500 and ran it again and it walks right over to -.055.
Then I set line 5 to X+.0004 and the x axis buzzed over -.102 total after running the program 10 times. I set the Loop to 500 reps and ran that twice - offset totaled -.100.
Then I set line 5 to X+.0005 and Loop 100 reps, and the x axis buzzes and moves over +.001 after 10 runs of the program. After running the program 20 times the offset was +.002. Yeah. Positive direction this time.
I set the Line 5 to X+.0006 and in 10 runs of the program, it buzzes with a rapid ticking or pulsing of the sound of the drive system - about 10 pulses in the duration of the program, and offsets about .001 per 100 reps...
I set line 5 to X+.0010. Very loud vibratory buzz with about 10 cyclical pulses to the sound, but after running this program 10+ times, there is still NO discernable Offset!!!
I set line 5 to X+.002 . Very loud with 5 initial loud pulses then smoother for the rest of the "run". No discernable offset despite multiple runs of the program. Just nasty buzzing.
I changed the loop to 500 reps.
X+.001 buzzes but does not offset. sound has 9 pulsed and then smooth buzzing... I ran this multiple times with no offsetting.
X+.00015 machine walks right over to -.055". Aargh!
X+.010 table jiggles like a paint shaker and offsets - get this! - -.050".
I am truly bewildered... Don
-
X+.001 buzzes but does not offset. sound has 9 pulsed and then smooth buzzing... I ran this multiple times with no offsetting.
X+.00015 machine walks right over to -.055". Aargh!
X+.010 table jiggles like a paint shaker and offsets - get this! - -.050".
Some of the results are consistent with the idea of a bug at the change of direction. However, this buzzing puzzles the hell out of me. Jiggling like a paint shaker ... ??????? That's really weird!
Thing is, until we can explain everything, we do not know what is going on.
Hum - I don't suppose you can find a digital storage CRO and LOOK at the signals by any chance?
Can I suggest ... putting a pause between each reversal. Yes, that will make the program much slower, but it should let the first motion stop before the second (reverse) motion starts.
Alternately, do you have Mach in Constant Velocity mode? If so, switch to Exact Stop. (Ho hum - or vice versa...)
Running experiments is all very well, but they can be bewildering if you don't have a theory to test. (Sorry about the preaching: my background is a PhD in Physics.) We seem to have some consistency with the number of cycles and the offset, and some consistency with the idea of very small increments producing variable results, so what's the buzzing? Is it that the acceleration parameters are just not handling the mass of the table when you combine very small steps with frequent reversals? Or is there a slight overshoot making the Geckos get very shirty about the reversal? Hence the pause idea.
Cheers
-
Hi Don,
You've been getting very strange results... ??? The exact stop test that Roger suggests is interesting. Following the nature of the problem (its consistency and inconsistency) it looks to me that it is a combination of several things which causes it. Like both the particular mechanics and Gecko's/Mach3...
Dan
-
Hi, Roger. Shaking back and forth like the program calls for, basically. But with the added offsetting.
A storage scope and a way to count the steps would be way cool, but I don't have access to one. Oh, well.
I have been using constant velocity mode. I'll check that out tomorrow, along with the pause idea.
I did, however, get the Larken Viper 200 servo drive and Ametek motor with a 500 line (2000 count) encoder hooked up. It only accepts +5V common signals, so I had to use the PMDX breakout board. I put an index mark on the sproket that is on this motor and an indicator so I can see if it offsets. Yup. It seems to be doing the same things the stepper system does. The PMDX BOB has an activity LED that flashes when pulses are flowing. It seems to flicker in time with the stuttering/pulsing of the tests I ran. I haven't gotten to run all the tests but at .00015 it walked over to its new offset just like the stepper motor system did.
I'll report back soon. Curiosity... OCX driver test - what should I be looking for when running it. It had very small vertical lines in the graphical display when I ran it when I put the computer into service...
Don
Dan, Good to hear from you. It might be a combination of things, but I'm starting to wonder about software/pc issues... Changing out the entire Drive system with the exception of the power supply seems not to cure anything.
Don
-
I did, however, get the Larken Viper 200 servo drive and Ametek motor with a 500 line (2000 count) encoder hooked up. It only accepts +5V common signals, so I had to use the PMDX breakout board. I put an index mark on the sproket that is on this motor and an indicator so I can see if it offsets. Yup. It seems to be doing the same things the stepper system does.
Getting harder to say the problem is random noise, isn't it?
Ahhhh... was the motor hooked up to the hardware, or just sitting bare? This affects the acceleration tuning etc.
Curiosity... OCX driver test - what should I be looking for when running it. It had very small vertical lines in the graphical display when I ran it when I put the computer into service...
Mine does too.
Cheers
-
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
-
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
-
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.
Thank you! I have been educated. I did wonder what those parameters were for.
By way of explanation: working with robotics in the past, I had to write the low-level driver code myself. So I could be sure the Dir state change did NOT clash with the step pulses. Ah well.
So the Dir parameter is the delay in microseconds between a Dir state change and a pulse?
Then what is the Step pulse parameter? I would love to know. it says 0-5, but accepted a 6 (I think).
Is this documented somewhere - I would love to read it up.
*******
Don: this is something to test! Some fine adjustment here might solve your problems.
Cheers
-
Don
Mach3Mill_1.84.pdf, pages 5-12 and 5-13, seem relevant.
Top of page 5-13:
"problems with the test moves (e.g. motor seems too noisy) first check that your step pulses
are not inverted (by Low active being set incorrectly for Step on the Output Pins tab of Ports
and Pins) then you might try increasing the pulse width to, say, 5 microseconds. The Step
and Direction interface is very simple but, because it "sort of works" when configured
badly, can be difficult to fault-find without being very systematic and/or looking at the
pulses with an oscilloscope."
Cheers
-
Interesting thread to follow, that said, i am going to make some comments FWIW.
1.The software is the begining of the controlling process. It could be buggy, but, one dosen't know without some physical indication.
2. It can be useless looking for an electronic step / pulse without the proper equipment.
Ideally it would be nice to have a pulse counter which could simultaneously take and compare say the following:
PC to PP - PP output - drive input - drive output to the motor ....and compare the electronics. Not manny folks have
access to such an instrument or one of high enough quality that it can be trusted as the "last word". Of course the signal quality
along the way by itself can contribute to a problem.
3. The motor acts as a converter to mechanical motion. So anything downstream of it becomes motion / distance.
The motor by itself can be a contributor.So now you have all the variables like timing gear, belt, bearing, screw, nut and
each has it owne level of quality relative to the motion. Yes ....a belt can create what would apear to be a lost step.
So if one wanted to be annal about all this, they would need to isolate each part of the system , define the error against some standard,
put it into perspective to the final outcome namely , motion. Good grief... thats only about 20 tests and it dosn't even include
other devices a user may be using or software influences. All of them need to be done in a very disciplined way and to higher degree than the
min resolution of the system.
Considering the above the user needs to work with what they have and can do and in most cases that is not much.
So what can you do quite accurately?
Minimise the electronics to only that which is needed for motion. PC/PP/drive/ then a motion measuring device upstream of the
mechanics. Simply put, you put out pulses and measure them at motor output shaft. To do that one can make mechanical ( not electronic )
indicator and see what that "block" of the system is doing. ie;
A simple disc of 6 " diameter would have a circumference of 18.849". At 20000 steps per inch, the resolution / single step is equal to 0.00005"
if all was perfect and 18.849 / 20000= 0.0001" of circumferential movement of the disc. An 8" disc would give you 0.0013" of circumferential movement.You need to make at least a 1 rev of the motor since the non linearinty of the stepper should repeat. You can figure out what commanded movement
is required for one complete revolution of the disc. Make note that if you fall in a micro step you may be +- in cicumferential distance.
So the user can check a drive with micro step or without ( use the same motor ) , then swap the cables and compare other drives. Forward and reversemotion.Try the same with a different motor. Try a different PP port. But make note of the data of each test. Not all motors are the same!
At least this way you are comparing electronics to a motion standard without influences of the mechanical system.
Just some thoughts FWIW on testing,
RICH
-
Hi Roger,
The Step Pulse parameter is how many micro-seconds are added to the base step pulse width (don't remember what it is). I think the label is wrong and it would accept values 0-15.
Dan
-
The Step Pulse parameter is how many micro-seconds are added to the base step pulse width (don't remember what it is). I think the label is wrong and it would accept values 0-15.
Ah - seems reasonable, albeit obscure ... :-)
Hum - at 35 kHz clock, you wouldn't want anything over 15 uSec, would you?
One day ... I will haul the CRO out there.
Cheers
-
Hi, All. Good reading your input.
I have tried different step and Dir numbers ranging from 0us to 15 us with no change. I would have expected something... Currently have step set to 2 us per Gecko suggestion.
Question... Does the Direction act as a pulse for each step? or does it change state for reversals of motion direction only, ie. steady state for duration of move in that direction?
My steps are set to "Low Active" in the Motor Outputs. The Direction s are set to what ever makes the axis move the correct direction.
I'm running 25Khz clock on this setup since more than 50 inch per minute gets dangerously fast and toward stall speed of the steppers. I don't make a living off this machine so I want accuracy and reliability more than speed.
I would like setup instruction on using an O'scope as I do have a BK Precision 1530 30mhz scope. If it could be hooked up to see the timing differences between step and direction it would be nice. It is a simple dual trace scope, not a storage type. About 20 years old. If you think it might be helpful, tell me how to set it up on the machine and I'll try it. Most of my advanced electronics has been repair of old tube amps... Very basic.
Rich, good to hear from you, I don't know if my scope is good enough for this application, but if you think it might be, I'm open to suggestion. I have never seen a pulse counter, although it would seem such a device must exist.
The servo motor isn't hooked up and with the iterative tests it is quite obvious that it doesn't return to zero. Also, the stepper motor for the X axis is shown in the picture or more correctly the belt and pulleys. Changing the acceleration doesn't seem to have any effect at this time... I'm sure the problem is not mechanical.
Oscope settings would be helpful.
Don
-
Does the Direction act as a pulse for each step? or does it change state for reversals of motion direction only, ie. steady state for duration of move in that direction?
Dir is a state, not a pulse.
My steps are set to "Low Active" in the Motor Outputs.
Is that what Gecko recommend? if so, OK.
Do confirm with the CRO that the negative going pulse on the Step line is narrow, with a wider Hi state. This is illustrated in the Mach3Mill doco. Check you can vary the width.
I would like setup instruction on using an O'scope as I do have a BK Precision 1530 30mhz scope. If it could be hooked up to see the timing differences between step and direction it would be nice. It is a simple dual trace scope, not a storage type.
Um ... putting into words what I do automatically ... Um! Interesting challenge!
OK. First, disconnect everything from the PP. Bare PC.
Hang channel 1 on Dir and channel 2 on Step. If you have a separate trigger channel hang that on - um, try Step for now. Otherwise trigger off channel 2 for now.
Program the machine to do about 10 steps forward and 10 steps backwards, for many cycles. Adjust the CRO so you can see the Step pulses. The sweep rate won't be very high. The Dir channel will flip up and down. That gets the CRO going.
Now trigger off the Dir channel instead. You should be able to see the slow square wave on the Dir channel and the fast Step pulses on the other channel. Get this going. Now you will be able to see 'ground truth'.
Look at the timing between the Dir transition and the Step pulse downwards (leading edge) transition. What you do NOT want is for the Dir and Step transitions to be too close - that can confuse the Geckos. Also look at how fast the two signals go from Hi to Lo and Lo to Hi: the transition times. Record all these things - paper and pencil & sketches are fine.
Repeat all this with the BoB on the PP, looking at the output of the BoB. What do the pulses look like, and what is the timing like.
Repeat all this with other elements in the chain, up t5o the point of having a running motor. See if there is a shift in the timing between Dir and Step, or if the transitions times change, when some part is put into the chain.
You noted 'stuttering' at the start of a cycle - when Dir changes. This is where I would focus. You want to see what is going on here.
Hypothesis: you are getting a step pulse, or at least an edge of the Step pulse, or part of a Step pulse, while the Dir signal is changing state. This will confuse the hell out of the Geckos and most certainly cause 'stuttering' and screw up the movement of the motors.
Of course, if the stuttering has disappeared but the drift persists .. um ...
Cheers
Roger
-
Hi, Roger. Thanks for the info. I'll try to get to it tomorrow as I'm shor on time today. Don
-
I would like to note that it is not as easy as it may look trying to capture the timing between the step and direction signals using a plain scope. Thing is there is also the motor acceleration factor and the step pulse stream is not going to be constant frequency. One could probably try a very slow speed and VERY small acceleration and even then it's not going to be easy.
May be you could try in Incremental Jog mode, defining ONE motor step there...? But don't know if your scope can capture a single pulse.
Dan
-
Hi Dan
I would like to note that it is not as easy as it may look trying to capture the timing between the step and direction signals using a plain scope. Thing is there is also the motor acceleration factor and the step pulse stream is not going to be constant frequency. One could probably try a very slow speed and VERY small acceleration and even then it's not going to be easy.
True, true, but I think the arrangement I have described should work.
First of all, the CRO will trigger off the Dir transition in one direction only. That's the nature of CRO triggering, especially with something as simple as a BK Precision.
What will be seen on the CRO when it triggers off the Dir transition will be the Step pulses as they ramp up in speed, so their spacing will of course vary.
But if the machine is set to do 100 cycles back and forth, each cycle will be the same. So it should be possible to see the pulses on the screen. If 100 is not enough, try 200 ...
Cheers
May be you could try in Incremental Jog mode, defining ONE motor step there...? But don't know if your scope can capture a single pulse.
Dan
[/quote]
-
Corrected version - got interrupted for dinner...
Hi Dan
I would like to note that it is not as easy as it may look trying to capture the timing between the step and direction signals using a plain scope. Thing is there is also the motor acceleration factor and the step pulse stream is not going to be constant frequency. One could probably try a very slow speed and VERY small acceleration and even then it's not going to be easy.
True, true, but I think the arrangement I have described should work.
First of all, the CRO will trigger off the Dir transition in one direction only. That's the nature of CRO triggering, especially with something as simple as a BK Precision.
What will be seen on the CRO when it triggers off the Dir transition will be the Step pulses as they ramp up in speed, so their spacing will of course vary.
But if the machine is set to do 100 cycles back and forth, each cycle will be the same. So it should be possible to see the pulses on the screen. If 100 is not enough, try 200 ...
Cheers
-
Land of the strange anomalies, here. I hooked up the O'scope. It works. I think. First the program I am running that gives me enough time to observe the traces. I found that slowing the feedrate too much gives either to short blips instead of pulses, or trace scans that are very hard to watch...
Program: F10
G20G90
M98P1234L100
M30
O1234
G1X1.0
G1X0.
M99
Scope settings: Channel 1 hooked to pin 2 (step) Lower Trace in Pictures. Channel 2 is hooked to pin 3 (Dir) upper trace in pictures.
External trigger is hooked on the Dir pin. Coupling is DC for all. Amplitude is set to 1 Volt per division for both channels, Triggering is set Ext., DC, Auto level, Normal mode.
First observation was that the upper trace is only showing a 1 volt signal... lower trace is showing 3 volts. That is unusual. Both signals are set to Low Active in the motor outputs
The first 2 pictures show going out, and going back .1mS per division time.
-
Continued, The next pair of screen shots is time base set to 5uS/div. Starts out with Direction pulses- oh, yeah - Pulses, not steady state.??? Is this a clue? Step pulse is delayed about 2-3 uS on rise from Dir pulse. Both fall together.
I changed the Dir in Motor Tuning from 0 to 5uS and the delay changed to 5uS - a full division on the scope. Both still fall together.
Changed Dir to 0 and Step to 5uS and step is delayed 2-3 us from Dir.
I didn't take pics of those traces.
-
img-0815: HUH???????
NO WAY!!!!!!!!
I do not know what is going on here, but no way should you get anything like that trace! It seems to show that the DIR line is pulsing in sync with the Step line. I have not put a CRO on my system, but I will stick my neck out and say this should NOT be happening! Dir is meant to be a 'static' state.
Second, and related: 1 v pulses? Something very faulty here.
Question: is this a bare PP output, or is there anything hanging off it?
Comment: either way, something has one (I hope just one) big internal fault. Either you have the wrong lines, or the PP has a major defect, or whatever is connected to the PP has a major defect. I just cannot believe Mach would pulse the Dir line like that. Far too much potential for disaster.
Step pulse is delayed about 2-3 uS on rise from Dir pulse. Both fall together.
Well, the step pulse making its rising transition a little time after the Dir pulse is right, but everything else is way wrong.
Positive news: you now have the means to properly investigate what is going on. With this gear you should be able to crack the bug.
Negative news: you have a fault somewhere ... but you knew that anyhow.
Also, I will be off the air for a week+ from Saturday. Sorry about that. Give you time to really explore combinations.
Cheers
-
Hi, Roger, Have a nice vacation. Yeah, I couldn't believe it either. Something seems very wrong.
All that is attached to the parallel port is my cheater cable to which I have hooked the probe leads to the outer end. Nothing else. The 1V pulses concern me too. I even swapped channels, then cables, to verify it was NOT coming from the testleads or Scope. I'm going to drag out the other computer and hook up the scope to see if it exhbits similar behavior. Also, I have recieved another PCI parallel port card from Ebay, I might install in the current computer. Might be interesting to see what voltages it puts out. I'll try to keep things orderly, and take notes so you can see when you get back. Thankyou for the help. At least we are finding something.
Don
-
By the way. From the Geckodrive manual, Minimum logic "0" time is 0.5 uS while the minimum logic "1" time is 4.5 uS. Microstepping occurs on the falling edge of the step input.
Step pulse "0" time: .5uS min.
Step pulse "1" time: 4.0uS min.
Direction Setup: 1uS min.
-
All that is attached to the parallel port is my cheater cable to which I have hooked the probe leads to the outer end. Nothing else. The 1V pulses concern me too.
I had better point out something you definitely need to test here. If the output PP is completely unloaded you can get fake signals on floating lines through capacitive coupling. The 1 V signal may be due to a broken connection somewhere at the PP output. You should check this by loading the whole cable - say with a BoB. If the 1 V signal disappears or changes much when the cable is loaded then try another cable! Or, as you suggest, another computer, or another parallel port card. That Dir signal is definitely wrong.
Step pulse "0" time: .5uS min.
Step pulse "1" time: 4.0uS min.
Direction Setup: 1uS min.
The last line is the key one. The Dir line must finish changing state at least 1 uS before the Step line starts to change state.
Cheers
Roger
-
Yes, those pulses ARE strange. The direction line is a state and shouldn't be pulsing! The way it looks I am amazed your motors were rotating anyway... Are you sure the scope is set up correctly?
Dan
-
Hi, I'm pretty sure the scope is set up correctly. I swapped the leads and channels to verify this. I will check on Roger's suggestion of loading the port and seeing if the voltages and signals change. It would be interesting to see if a problem is in the PP. The dir pulse is changing a couple of uS before the step rises, but they fall together. Thus the direction pulse is still "setup" when the step pulse falls. It should work this way, but I would be worried about stray induced steps getting into other lines, or something. Hmmm. Maybe that is part of my problem... Thanks.
Don
-
I recalled that the PMDX BOB has a demo mode... It moves the X axis 1024 steps, then moves the Y axis 1024 steps, then moves the X axis back 1024 steps, then moves the Y axis 1024 steps back. Then is continues this cycle until the start button is depressed again. It occurred to me that if I started with the Dials on 0.000, then I could see if the Drives and Motors were repeating. The demo mode runs at 100 pulses per second, slowly but with no ramping/acceleration. After running this program for about 2 hours, it had not offset at all. Thus I believe the Geckos and their associated wiring are working correctly.
I wrote a dwell into the program. It now has a line that reads G4P1 before each G1 line. Running the machine from the computer, I discovered that There was no offsetting behavior until I set the acceleration to 0.5. The I got -.010 offset in 100 iterations. Any faster acceleration up to 10 was fine. I didn't try any faster acc. Rates. I swapped the outputs in Motor Outputs and swapped the wires at the BOB output. Results are the same.
I disconnected the BOB and hooked up my cheater cable, this time I terminated the leads to common with 4.7k resistors. The O'scope looks pretty much the same. Pin #3 is putting out 1V signals and pin #2 is putting out 3V signals. I changed the dwell to 3 seconds at each end of the run in the program so I would have plenty of time to see what is happening. Hmm. Weird stuff again. The trigger is set to the step signal, otherwise the scope just stares at you on the return direction. I'll post a couple of pictures. The timing between the direction and step pulses is varying during the move! It often starts out with one timing orientation and then just changes... Also, On the way back, where there is no Direction signal, I've noticed a twitch just before the end of the move. It seems to be a little early for it to be related to the deceleration, but it occurs only on the way back.
The upper trace is the step signal, lower trace is the direction signal. Note that the 1st and 3rd steps seem to be simultaneous with the direction pulses but the 2nd and 4th are leading or lagging. The step traces are not moving on the screen, the Direction pulses are moving earlier and later. Photos are on next post due to the forum software not cooperating...
???
Don
-
The photos, I hope.
-
Hi Don,
That is a nice debugging feature of the PMDX that you discovered. It proved what we had already been guessing - that everything after the Geckos outputs was fine. The problem is somewhere between Mach3 and Geckos inputs.
So are you saying that the offsetting disappears at higher acceleration rates? Interesting... if so you have the solution now, but don't know the cause yet.
Anyway, I really don't like your pictures of the signals. Something is surely wrong there. Can you connect the scope in exactly the same manner to the PMDX outputs while it's set to demo mode? Would be interesting to see the signals. For some reason, I am thinking your scope is not set right. Can you just use one channel and look at the direction signal? Just set the scope to DC mode and jog each side. I am pretty much sure that the direction is a state and should look like a DC line on the scope.
Dan
-
Hi, Again. First, Duh! The 1Volt O'scope readings are my fault. The variable gain on the scope was set. Now the traces show 3V logic for everything. I've moved the pins around in Mach and the stepped direction signal is always there. The wierd thing is that the steps lag the dir pulses sometimes and sometimes not...
2 Questions that come to my mind are: 1) Why is the Direction signal a pulse? 2) Why is the timing of the pulses changing?
I'll post a picture of the driver test, showing tha it is acceptable... I think.
Dan. I'll hook up the Breakout board and try to hook up the scope to its outputs. However, I didn't see any change recently going from direct connection from Mach to the Geckos vs. Mach, BOB, Geckos. It is worth a try, though. I suspect something in the computer is the problem. But what? Only Windows XP and Mach 3 are on it.
-
Driver test.
-
Hi, again Dan. It appeared after I installed the dwell in the program that the offsetting went away except at the extremely slow acceleration rate of 0.5... Why would very slow accel. cause the steps/direction signals to malfunction? The fact that sometimes the pulses are leading vs. lagging bothers me a lot. I would expect that the direction pulses ( if they are supposed to be pulses) wouls stay in the proper timing sequence. The two O'scope pictures show clearly a timing difference, sometimes during the same line of code execution.
Thanks for the help, Don
-
I just tried the jog mode. Set the Dir Pin to Pin 2 hooked up the scope to pin 2 and ground, terminated the pin with a 4.7k resistor to ground, and set the jog rate to 30% feedrate. Note that the little ticks on the lower part of the trace are the screen reticle. The timing of the direction "Pulses" seems to be varying, even across the screen. When I ran jog at 100%, the trace was jittering and flickering. Not steady. It is definitely not setting a steady state!
-
Hi, Again. First, Duh! The 1Volt O'scope readings are my fault. The variable gain on the scope was set. Now the traces show 3V logic for everything.
Glad you discovered it, Don. Was actually hoping you'd find a similar fault of yours with the direction pulsing issue ;)
Hi, again Dan. It appeared after I installed the dwell in the program that the offsetting went away except at the extremely slow acceleration rate of 0.5... Why would very slow accel. cause the steps/direction signals to malfunction?
Have got no explanation to this at this point.
The fact that sometimes the pulses are leading vs. lagging bothers me a lot. I would expect that the direction pulses ( if they are supposed to be pulses) wouls stay in the proper timing sequence. The two O'scope pictures show clearly a timing difference, sometimes during the same line of code execution.
Thanks for the help, Don
This is something to be worried about indeed. Absolutely not the way it was meant to be.
I just tried the jog mode. Set the Dir Pin to Pin 2 hooked up the scope to pin 2 and ground, terminated the pin with a 4.7k resistor to ground, and set the jog rate to 30% feedrate. Note that the little ticks on the lower part of the trace are the screen reticle. The timing of the direction "Pulses" seems to be varying, even across the screen.
Again, this needs to be investigated. Have never tried to look at the Mach signals with a scope, but I do know that I can measure the direction state with a voltmeter and it would show 5V or 0V depending on the direction. Could be Brian has changed something in last versions...? Don't think so. But would be nice of him to chime in here and confirm this.
When I ran jog at 100%, the trace was jittering and flickering. Not steady. It is definitely not setting a steady state!
A symptom of a not perfect driver test, though yours looks good (if the picture shows the worst case).
Dan
-
Hi, Guys. I ordered a SmoothStepper last Thursday, and it arrived Monday. I've installed it and I will post pictures of its outputs. It looks promising. No more jittering and the Direction signal is a STEADY! state. Steps are stable also.
Don
-
Hi Don,
Good news! And the signals look like they should be. I still wonder though why you were seeing those odd signals with the PP...
Dan
-
Don't know... I'll try putting the whole machine though trial runs tomorrow, though. I hope this is the solution... Don
-
Don't know... I'll try putting the whole machine though trial runs tomorrow, though. I hope this is the solution... Don
The mind boggles as to why the PP gave that sort of signal. Definitely should not. But ... the SS has many advantages for you, like an extra port.
If this works we will count it as an international triumph!
Here's hoping
Cheers
Roger
-
I didn't get to do very much today but the diagonal program repeated perfectly both at accelerations of .5 and 10 units per sec. squared. I never had that luck before. I'm thinking we Did it!. Why the strange PP signals Is still a mystery though... Having the second port and a third that will work with my Z-bot jog dial MPG will be great. Thanks for the help, guys.
Don
-
I didn't get to do very much today but the diagonal program repeated perfectly both at accelerations of .5 and 10 units per sec. squared. I never had that luck before. I'm thinking we Did it!. Why the strange PP signals Is still a mystery though... Having the second port and a third that will work with my Z-bot jog dial MPG will be great. Thanks for the help, guys.
Don
I'll send my bill in ... :-)
Good luck, and hope it is fixed.
cheers
-
Hi Don,
Glad you got it sorted.
The PP issues still bother me though... so the problem is not fixed (nor found) ;) , but you rather found a workaround.
Dan
-
I got a chance to look at the outputs of the parallel port after untangling the redundant ports and pins situation that the Smoothstepper was warning me about. The Direction signal is now a steady state. However, the step signals are not very clear. Nothing like the sharply defined square waves of the smoothstepper. I'll post pictures but unfortunately they were soft on focus... The do show the almost continuous step line with the pulses under it. Doesn't look good at all. Don
-
I got a chance to look at the outputs of the parallel port after untangling the redundant ports and pins situation that the Smoothstepper was warning me about. The Direction signal is now a steady state.
Are you saying that for all this time you had a conflict of signals by configuring the same direction pin more than once within the Mach setup ?
Tweakie.
-
I got a chance to look at the outputs of the parallel port after untangling the redundant ports and pins situation that the Smoothstepper was warning me about. The Direction signal is now a steady state.
I would have never guessed this could be causing the problem. Thanks for the update, Don.
Dan
-
The pulsed direction signals must have been from the conflicting ports&pins assignments but the problem remained after correcting that. Apparently, the problem is in the computer itself. I glad the smoothstepper is working, although my MPG unit is a little strange in its behavior. Another thread maybe. Thanks for the help.
Don
-
Check the latest version of the SmoothStepper SW. It appears that it may be possible for a direction change to lose a single pulse. Whether this applies to your problem or not I do not know.
Cheers