[ronateah]

Good day all - I have recently converted my mill drill using a gecko540 and a dell optiplex. I am using Vetric Cut2D for my GCode generation. Every thing was looking pretty good untill I started doing some milling outside of my initial testing. First I will say i dont think i am losing counts at least in a direct sense. Drilling holes for instance seems to be bang on. The problem I am experiancing is that the x axis will simply stop runing while the other axis will continue to run including the X axis internally to EMC but not physically.

If i stop running the g gode and jog the x axis all is fine (other than X axis needing to be homed). At this point I am not sure if it happens at the same point in the code. I can say that it will occur in more than one file. The problem seems to conincide with a change in the Z axis.

Any thoughts on this one would be greatly appreciated.

I should add these are open loop steppers

[BMG]

Certainly sounds like lost steps.

You should review the wiki (http://wiki.linuxcnc.org/cgi-bin/emc...StepGeneration) for setting up steppers and make sure you did not skip any of the steps.

Take the time to carefully verify your computer's latency and remove any binding issues in your machine.

I as of late have had difficulty with my X axis (48" long) developing a tight spot aroun X=0-4". I lose steps in the area very easily. I still have not completely figured out the problem, but its probably a combination of leadscrew whipping and binding on my pipe side rails.

BMG

[acondit]

Good day all - I have recently converted my mill drill using a gecko540 and a dell optiplex. I am using Vetric Cut2D for my GCode generation. Every thing was looking pretty good untill I started doing some milling outside of my initial testing. First I will say i dont think i am losing counts at least in a direct sense. Drilling holes for instance seems to be bang on. The problem I am experiencing is that the x axis will simply stop running while the other axis will continue to run including the X axis internally to EMC but not physically.

If i stop running the g gode and jog the x axis all is fine (other than X axis needing to be homed). At this point I am not sure if it happens at the same point in the code. I can say that it will occur in more than one file. The problem seems to coincide with a change in the Z axis.

Any thoughts on this one would be greatly appreciated.

I should add these are open loop steppers

It sounds like you are trying to push the X-axis faster than the stepper, drive and/or power supply are capable of handling. If you used stepconf to set up the machine, and the testing of the axis seemed ok there, it is possible that the problem is a lack of sufficent current when multiple axis are moving. Remember it takes more power to cut than to just do a rapid move. When you are testing, you are just testing the ability to do a rapid move.

How fast is your configuration set for on the x-axis? How fast are you commanding it to move when it stops moving? What is the rating of your power supply (volts? and amps?)? What kind of mill did you start with?

In short we need more info to accurately diagnose your problem?

Alan

[ronateah]

BMG

The reason I am not convinced it is lost steps is that one part i am milling is square top and bottom (milled perfectly along the x axis - y movement only) but the both sides are indexed inward 0.100 in two locations. It is along this axis one side only that the new Z is applied not in a step but a ramp. It apears at this point that the path is shifted maybe 25 to 50 thou in the same direction and on both sides. In other words the overall width is on target but the it is offset with each new z. (for ref Z is perpendicular to x and y)

The other issue, and i am sure it is related is in a step change for z while x is moving. It is like x stops z moves x resumes on the screen but some one forgot to tell the drive.

I did deal with computer latency in the beginning of this exercise but I am going to revist it all again to double check

Thanks for your thoughts

Certainly sounds like lost steps.

You should review the wiki (http://wiki.linuxcnc.org/cgi-bin/emc...StepGeneration) for setting up steppers and make sure you did not skip any of the steps.

Take the time to carefully verify your computer's latency and remove any binding issues in your machine.

I as of late have had difficulty with my X axis (48" long) developing a tight spot aroun X=0-4". I lose steps in the area very easily. I still have not completely figured out the problem, but its probably a combination of leadscrew whipping and binding on my pipe side rails.

BMG

[acondit]

BMG

The reason I am not convinced it is lost steps is that one part i am milling is square top and bottom (milled perfectly along the x axis - y movement only) but the both sides are indexed inward 0.100 in two locations. It is along this axis one side only that the new Z is applied not in a step but a ramp. It apears at this point that the path is shifted maybe 25 to 50 thou in the same direction and on both sides. In other words the overall width is on target but the it is offset with each new z. (for ref Z is perpendicular to x and y)

The other issue, and i am sure it is related is in a step change for z while x is moving. It is like x stops z moves x resumes on the screen but some one forgot to tell the drive.

I did deal with computer latency in the beginning of this exercise but I am going to revist it all again to double check

Thanks for your thoughts

If x is moving on the screen and not actually moving, that is the classic definition of lost steps. Emc is sending step commands but the drive or stepper is not responding ( i.e., steps are being lost).

[ronateah]

Alan - I have been running this very slow 10 % of my feed rate and it is a 0.125 end mill at 0.05 cutting depth. My power supply is 50 volt supply at 12.5 amp ( i have to double check current -might be 20amps) I have to go to the shop to get the actual feed rates. This mill is a "First" at least 30 years old.

Also please read my response to BMG

Thanks

It sounds like you are trying to push the X-axis faster than the stepper, drive and/or power supply are capable of handling. If you used stepconf to set up the machine, and the testing of the axis seemed ok there, it is possible that the problem is a lack of sufficent current when multiple axis are moving. Remember it takes more power to cut than to just do a rapid move. When you are testing, you are just testing the ability to do a rapid move.

How fast is your configuration set for on the x-axis? How fast are you commanding it to move when it stops moving? What is the rating of your power supply (volts? and amps?)? What kind of mill did you start with?

In short we need more info to accurately diagnose your problem?

Alan

[ronateah]

Alan

Agree - steps are lost. My perspective is that in a classic sense timing/latency issues are going to cause an intermittent and varing percentage of counts to be lost in all axis and any direction. These problems are some what repeatable and result in counts lost in one axis only.

If x is moving on the screen and not actually moving, that is the classic definition of lost steps. Emc is sending step commands but the drive or stepper is not responding ( i.e., steps are being lost).

[acondit]

Alan - I have been running this very slow 10 % of my feed rate and it is a 0.125 end mill at 0.05 cutting depth. My power supply is 50 volt supply at 12.5 amp ( i have to double check current -might be 20amps) I have to go to the shop to get the actual feed rates. This mill is a "First" at least 30 years old.

Also please read my response to BMG

Thanks

I did read your response to BMG. My point is that it is definitely lost steps, the only question is what is causing them to be lost.

10% of 10 ipm is fairly slow but 10% of 1000 ipm is relatively fast. So what is your specified feed rate? And what are you trying to cut? That depth of cut would be fine for somethings but questionable for others.

I am not familiar with a "First" mill. The G540 is a wonderful drive but it is not the answer to every cnc conversion. So I am first trying to figure out whether it has enough power to do what needs to be done.

If the answer to that question is yes, then next one looks to other questions. So, how heavy is the 'Z' that you are trying to move? How big is the table on the mill? What size steppers are you running and what are their power requirements? How fast is your spindle turning?

Alan

[ronateah]

Alan

I will get back to you with that tomorrow

[Big John T]

Take a look here:

http://www.linuxcnc.org/docview/html...tics.html#r1_3

John

[ronateah]

Well it's late and little to report. In other words no improvemnt. Attached are my ini and hal files. I will add more tomorrow

[Big John T]

Good day all - Every thing was looking pretty good until I started doing some milling outside of my initial testing. First I will say i don't think i am losing counts at least in a direct sense. Drilling holes for instance seems to be bang on. The problem I am experiencing is that the x axis will simply stop running while the other axis will continue to run including the X axis internally to EMC but not physically.

The load on the X and Y axis will be zilch when your drilling. If your X or Y axis stalls when your milling then you are simply overloading the steppers... nothing more nothing less. The fact that EMC still runs indicates that the problem is outside of EMC.

What have you tried?

John

[ronateah]

Alan

100% speed is 18 ipm on all axis. I have had it running at 30 ipm but set back to 18 ipm.

The First is about 5 or 6 hundred lbs, 30 by 10 inch table

I would estimate the z to be about 20 lbs on a worm gear

Nema 23, 497 oz in, 3 volts, 3 amps, 4 mH motors on the x and y slightly smaller on the Z. looking at the current though, I am running 3.3 amps. I will have to double checks this on the motor.

Cutting alumnium with a 0.125 end mill and the spindle running at 2000 rpm.

See the attached dxf. The interior holes are drilled with out issue and the retangular cutout is done with out issue. The exteriour profile is problematic at any speed, down to %10 speed wet or dry run.

I will attach the gcode later on today.

[ronateah]

The load on the X and Y axis will be zilch when your drilling. If your X or Y axis stalls when your milling then you are simply overloading the steppers... nothing more nothing less. The fact that EMC still runs indicates that the problem is outside of EMC.

What have you tried?

John

John - I have tested while cutting and while not with the same problem. I have retested latency (31uS) and tried all manner of adjustment to base period.

I have followed the spread sheets recommendations but i have not tried to adjust any of these (steplen, stepspace, dirsetup, and/or dirhold) as i could not find actual documentation on these in the manuals. I am persuming these are located in the HAL file.

Also, in my ini there a couple of settings which i can not find documentation on.

[EMCMOT]
EMCMOT = motmod
SHMEM_KEY = 111
COMM_TIMEOUT = 0.001
COMM_WAIT = 0.001

One starting emc i get an error. I wrote it down but left it in the shop so i will guess for now, this happens on my first jog but never again. "unexpectected delay on task - see dmesg for details". Can anyone tell me where / how i can look in this log.

Thanks

[acondit]

Alan

100% speed is 18 ipm on all axis. I have had it running at 30 ipm but set back to 18 ipm.

The First is about 5 or 6 hundred lbs, 30 by 10 inch table

I would estimate the z to be about 20 lbs on a worm gear

Nema 23, 497 oz in, 3 volts, 3 amps, 4 mH motors on the x and y slightly smaller on the Z. looking at the current though, I am running 3.3 amps. I will have to double checks this on the motor.

Cutting aluminum with a 0.125 end mill and the spindle running at 2000 rpm.

See the attached dxf. The interior holes are drilled with out issue and the rectangular cutout is done with out issue. The exterior profile is problematic at any speed, down to %10 speed wet or dry run.

I will attach the gcode later on today.

OK, thanks Ron. I have a Grizzly G1006 that is roughly the same size (round column and 9.5" x 32" table) and if I were to convert it to CNC, I would plan on using 640 oz/in motors on the X and Y. I would say that your electronics are about the bottom edge of acceptable for that size mill. It would affect how fast you can move, but it should work. So then the problem is to decide what is happening.

Based on what you have told us so far, I am leaning towards the idea that when you are moving simultaneously in Z and X directions, somehow you don't have enough power to not stall the X-axis.

The x-axis probably takes the most force to move when it is not centered over the saddle. The weight of the table will have more of a tendency to bind slightly against the dovetails and gibs. So, does it matter where the X-axis is when it won't move?

What pitch are your screws? Are they acme lead screws or ballscrews? Are you running direct drive? It takes more power to drive regular leadscrews than it does ballscrews.

If you are running direct drive now, one idea might be to change over to a belt reduction system, . A 2:1 (or even a 4:1) reduction would effectively double (or quadruple) the power of your steppers to the screw and because of the speeds at which you are running, might even increase the speeds at which you could run. This would depend on the torque curve of your particular motors.

Alan

[Big John T]

John - I have tested while cutting and while not with the same problem. I have retested latency (31uS) and tried all manner of adjustment to base period.

How long did you let the latency test run? In many cases you need to run it for quite a while before you see any spikes...

I have followed the spread sheets recommendations but i have not tried to adjust any of these (steplen, stepspace, dirsetup, and/or dirhold) as i could not find actual documentation on these in the manuals. I am presuming these are located in the HAL file.

If you used the StepConf Wizard they are on the basic machine info page.
http://www.linuxcnc.org/docview/html...ic-Information

The info is placed into your .ini file.

The 540 has been added to the 2.3 wizard and is the same as the G203v AFAIK on this page. Also the 540 steps on the rising edge of the signal so the step space and step time must be in the correct order as they are different for this drive. It does not hurt anything except maybe the max step rate (depends on your computer) to set both at 2000 to be safe if your not sure...

http://wiki.linuxcnc.org/cgi-bin/emc...r_Drive_Timing

Also, in my ini there a couple of settings which i can not find documentation on.

[EMCMOT]
EMCMOT = motmod
SHMEM_KEY = 111
COMM_TIMEOUT = 0.001
COMM_WAIT = 0.001

I'm not sure what these are...

One starting emc i get an error. I wrote it down but left it in the shop so i will guess for now, this happens on my first jog but never again. "unexpectected delay on task - see dmesg for details". Can anyone tell me where / how i can look in this log.

Thanks

If you get this error then your base period is too low...

http://www.linuxcnc.org/docview/html...cs.html#r1_2_2

So in a nutshell sounds like you have two problems... the real time error and something physical loading down your axis until the stepper stalls.

If your ways are worn any at all they will be loose in the middle an tight on the ends of the travel. If you stall near the edges this can be the problem.


John

[ronateah]

"Based on what you have told us so far, I am leaning towards the idea that when you are moving simultaneously in Z and X directions, somehow you don't have enough power to not stall the X-axis."

OK i can rule out the z as I have taken the problematic gcode and removed z references. I put and indicator on the machine and taped a pin to be used as an index on the motor timing pulley. I programmed a pause in the code x0.000y0.0000 the readings show a shift to the right 0.003 inches every unloaded (milling air) pass. Absolutely repeatable ten times in a row.

However it could be related to X and Y coordinated motion. I am going to do some further tests this afternoon.

"The x-axis probably takes the most force to move when it is not centered over the saddle. The weight of the table will have more of a tendency to bind slightly against the dovetails and gibs. So, does it matter where the X-axis is when it won't move?"

I think you are referoing to an instance where if i reduced the speed down to below 8% or so the x stoped responding altogether. I mean not even trying to move so i don't think it anything to do with the mechanics. I will test this further.

"What pitch are your screws? Are they acme lead screws or ballscrews? Are you running direct drive? It takes more power to drive regular leadscrews than it does ballscrews.

If you are running direct drive now, one idea might be to change over to a belt reduction system, . A 2:1 (or even a 4:1) reduction would effectively double (or quadruple) the power of your steppers to the screw and because of the speeds at which you are running, might even increase the speeds at which you could run. This would depend on the torque curve of your particular motors."

From memory 10 turns per inch and roughly 3:2 ratio between timing pulleys

[acondit]

OK i can rule out the z as I have taken the problematic gcode and removed z references. I put and indicator on the machine and taped a pin to be used as an index on the motor timing pulley. I programmed a pause in the code x0.000y0.0000 the readings show a shift to the right 0.003 inches every unloaded (milling air) pass. Absolutely repeatable ten times in a row.

OK, that sounds like progress.

However it could be related to X and Y coordinated motion. I am going to do some further tests this afternoon.

I ... don't think it anything to do with the mechanics. I will test this further.

At this point I tend to agree with you that it doesn't sound mechanical. I like to know what is going on though before ruling out one cause or another.


Ron,

I had a lot of trouble with intermittent positioning errors on my cnc-router that turned out to be related to step and dir timing constraints. Not repeatable though but just sudden stopping or loss of steps.

Here is the info that Mariss provided on the G540 in another thread.
Pulse Width = 2uS
Step Pulse = Active High
Direction Precharge = 0uS
Direction = Active High

So steplen should be set to at least 2000 (2000ns = 2us). Initially I would plug in 3000 for each of those 4 items (steplen, stepspace, dirsetup, and/or dirhold). Then once you get everything working fine you could start setting the values for dirsetup and dirhold back to 0 and see if anything changes. Assuming that they are ok, then reduce the value of steplen and stepspace to 2000 and see if they are still ok. According to the info from Mariss dirsetup should be able to be 0 but I would just feel more comfortable verifying that. These values are so short in comparison to the 25000 that I have to use for each that I can't imagine them adversely affecting the timing of your system.

Alan

[acondit]

Ron,

How about posting a picture of your machine?

Alan

[ronateah]

How long did you let the latency test run? In many cases you need to run it for quite a while before you see any spikes...John

three hours

If you used the StepConf Wizard they are on the basic machine info page.
http://www.linuxcnc.org/docview/html...ic-Information
The info is placed into your .ini file.John

I have fond that the StepConfig wizard over writes everything in the ini file including items configured outside of the wizard so i would preferred do this manually. Some of these settings are in the HAL file are they not. or am i missing some thing?

The 540 has been added to the 2.3 wizard and is the same as the G203v AFAIK on this page. Also the 540 steps on the rising edge of the signal so the step space and step time must be in the correct order as they are different for this drive. It does not hurt anything except maybe the max step rate (depends on your computer) to set both at 2000 to be safe if your not sure...

http://wiki.linuxcnc.org/cgi-bin/emc...r_Drive_TimingJohn

Thanks for this

If you get this error then your base period is too low...

http://www.linuxcnc.org/docview/html...cs.html#r1_2_2John

Agreed

So in a nutshell sounds like you have two problems... the real time error and something physical loading down your axis until the stepper stalls.

If your ways are worn any at all they will be loose in the middle an tight on the ends of the travel. If you stall near the edges this can be the problem.
John

Mechanically i think i am good