motor fault at same spot

[brian]

I've just had the bot stop at the same line of a file showing a motor fault
I redid the toolpaths and went with a new .25 compression.
I'm only cutting .25 per pass at 2.5ips which is fairly conservative.
Even when I run the file again over the already cut vectors it stops at the same
line of the file.
The z axis seems to jump up at the instant the bot stops
I ran some test squares and it ran fine.
I'm a bit baffled
Anyone had this experience

Brian

[myxpykalix]

What program are you using to toolpath with?

Do you have another program you could run the same file in and toolpath it and try to see if it does the same thing in the same place?

Do you have a idea of exactly where on the material it stops so you could go back to your dxf and look at your vectors at that same spot to see if there is a issue there?

Can you create another file similar that would make the bot run in the same basic location in the same pattern but with a different file?

What i'm asking is designed to try to figure out if it is a issue with either the file, the toolpathing software or the machine.

The fact that it does it in the same spot even with different tools doesn't negate a bad vector file.

The fact that you can cut test squares in the same locations tells me it may not be the machine.

By RE toolpathing in a different program would tell me there is a problem with your vectors possibly.
This is just a process of elimination...of course it could be none of these things because as you know halloween is coming up and it could also be ghosts and goblins in there!:eek:

[srwtlc]

Post the line of code it stops at (maybe a section of it at that point).

[brian]

here's the line of code
it's seven from the bottom
M3,1085000,16828643,-0.486667

I'm using artcam pro to toolpath with
I've looked at the vector in question up close and see no issues with it.
I've run a previewed toolpath with both shopbot and VisEdit and they show no problems
I have aspire also I will try that approach

Thanks Brian

J3,1.449574,1.547981,0.250000
M3,1.449574,1.547981,-0.243333
CG, ,1.380814,2.249397,20.070064,2.321532,T,1
CG, ,1.305685,3.421957,40.903513,3.209506,T,1
CG, ,1.233753,4.970020,124.758887,6.572725,T,1
CG, ,1.133535,8.584790,150.927243,5.993159,T,1
CG, ,1.111464,10.651245,192.511178,3.089459,T,1
M3,1.105843,12.713328,-0.243333
M3,1.085000,16.828643,-0.243333
CG, ,1.083235,19.915148,350.475057,1.743614,T,1
CG, ,1.117516,24.708532,791.071654,-3.260697,T,1
CG, ,1.147488,27.105067,552.164782,-5.707103,T,1
CG, ,1.206182,30.429737,640.491157,-9.644516,T,1
CG, ,1.246290,33.861451,-338.296982,5.669861,T,-1
CG, ,1.271719,35.154191,64.700123,-0.626090,T,1
M3,1.282968,35.477235,-0.243333
CG, ,1.333340,36.678587,-118.254231,5.560081,T,-1
CG, ,1.402130,39.315126,-170.796529,5.775441,T,-1
CG, ,1.504691,42.346217,124.683457,-2.701545,T,1
CG, ,1.738981,46.401644,157.930667,-7.089485,T,1
J3,1.738981,46.401644,0.250000
J3,1.449574,1.547981,0.250000
M3,1.449574,1.547981,-0.486667
CG, ,1.380814,2.249397,20.070064,2.321532,T,1
CG, ,1.305685,3.421957,40.903513,3.209506,T,1
CG, ,1.233753,4.970020,124.758887,6.572725,T,1
CG, ,1.133535,8.584790,150.927243,5.993159,T,1
CG, ,1.111464,10.651245,192.511178,3.089459,T,1
M3,1.105843,12.713328,-0.486667
M3,1.085000,16.828643,-0.486667
CG, ,1.083235,19.915148,350.475057,1.743614,T,1
CG, ,1.117516,24.708532,791.071654,-3.260697,T,1
CG, ,1.147488,27.105067,552.164782,-5.707103,T,1
CG, ,1.206182,30.429737,640.491157,-9.644516,T,1
CG, ,1.246290,33.861451,-338.296982,5.669861,T,-1
CG, ,1.27171

Thanks Brian

[myxpykalix]

Brian,
you didn't say if this was a 2d vector file or a 3d carving file? I know that artcam is very "sensitive" sometimes when creating a 3d file from 2d, in that it sometimes picks up alot of pixels and other garbage from a picture.

try toolpathing it in another program (from the start, not vectors transferred from a artcam file) so you have your new program do the whole file creation.:confused:

[brian]

Its a 2d file
I've run this file before.
It was a scaled down version
This is not an easy file to redo
I believe it took me 3-4 hrs the first time.
If you look in "designing and creating shp files"in artcam( order of vector machining) you will see the file I'm running
I'm going to try it with aspire to see if it works

Brian

[Brady Watson]

Inspect your wiring. A little nick in the cable can cause two cables to short momentarily, creating an intermittent problem as the cables bend a certain way. Look real close...Disconnect motor @ connector closest to motor & reseat. Do the same on the other end.

-B

[srwtlc]

What Brady said.

The file snippet ran as expected on my machine. If you're running this near the end of the table, could the apex of the arc be close to tripping a prox switch or hitting the mechanical stops (since you say it's a motor/driver fault)? That part of the code is the closest to X,0.

[brian]

Thanks for the info
I just ran the file in aspire this time and it stop in the same place(does not seem intermittent)
I adjusted the bearing on the Z axis to make sure it was running smooth.
What gets me about this is it stops in the same place (M3,1085000,16828643,-0.486667)every time and it the second pass on the same vector
I will check the wiring tomorrow

Brian

[Ryan P]

A motor fault is indicating an axis cannot move to the instructed location. The file is not likely to be the problem. You say it is in the same line in the file, is it also in the same position on the table? I would suspect the Z being the issue, as you stated the Z pops up when you get the message. What was the Z doing about 3 seconds before you got the fault. The reason I ask is the Alpha motor will try to self correct and if it cannot within three seconds it will fault. What is the length of cutter you are using? Can the Z move down to the location is being instructed to go?

I hope this is of some help. If you are still having this issue please give us a call.

[myxpykalix]

Another thing you could possibly try is to remove your router bit and run the file doing an air cut to see if you hear or see anything perculiar that you might not be able to hear if the router was running and cutting.

Also is it in the "exact" same place when it craps out or "in the same general area"? And is there anything special about the area where it defaults, like the top end of a Z move?:confused:

[brian]

The location
M3,1085000,16828643,-0.486667
is exactly the same(line 40)
befor I redid the toolpath it was line 60 it stopped on
As you can see from above the Z is only -.486667 down from the top of the material which is .73 so The Z axis is know where near its limit.
I posted the file above (previous Post)
I will try out the suggestions thanks

Brian

[srwtlc]

Brian, do you see the same thing happen if you run the file at various locations on the table? Either move to a different spot and run it offset 2d or issue a Z2 at another location and run as normal.

[gundog]

Is it just me but M3 is move 3 to M3,1085000,16828643,-0.486667

There are no decimal points so moving X to 1085000 and Y to 16828643 would be way off the table. This looks like the problem to me.

I can't answer why that code was generated but it seems to have misplaced a decimal point IMHO.

Mike

Never mind I see in the actual code it does have the decimal point.

[brian]

After talking to Ryan from shopbot
I did a test run without the material and it ran fine
Same test with material in place,it failed again.
Something that didn't occur to me was to remove the pressure foot I was using.
After removing the PF I ran the file and it worked.
I'm still baffled as to what caused the fault.
The pressure foot was freshly lubed and the material was baltic birch.
The only thing I can think of was the pressure foot was set wrong(it had bottomed out)
If that was the case I feel a little stupid.

Thanks for all the help

Brian

[myxpykalix]

well, now you know...:o