Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Tarak on April 24, 2016, 06:41:27 AM
-
Hi All, been awhile since I've been back at the forum, may I pick your brains for some ideas with this rotary issue I'm having?
Question1.)
I've been using this machine for a few years now, it's basically a cylindrical grinder, it works in the same manner as a lathe.
Xaxis is diameter, Zaxis is left and right and A axis is the rotary head (indexable axis not a spindle).
Ever since I can remember, if I run code like the following:
G90 G0 X20. Z0.
G91 G1 A1440. F2000
G0 X20.;***********
X axis will jump out and lose position, tripping out the servo on the line with the**************
I managed to get itto work by entering a really slow feedrate instead of G0, e.g G1 X20. F20 (very, very slow though).
I'm guessing it's to do with the fact I am trying to use the indexable axis as a spindle type arrangement, any ideas why it might be doing this?????????.
Question2.)
A few years back I attempted to use the A axis as both the indexable axis and also a spindle that I could just turn on and off, but I couldn't get it to work.
I tried setting the pins of the spindle to the same as the step and direction on the A axis, but I just got errors about duplicating pin assignments, could someone possible explain exactly how I could get this to work?
Tarak
-
I don't know, but I wonder whether it was the G0 X20 which was really the problem? Sometimes it seems to me that Mach3 highlights the adjacent line.
Looking at your code sample, I see the X axis should already be at X=20, so the X axis servo should have nothing to do. Of course, could it be tripped if the power supply rail dropped too far?
I would start by checking the speed and acceleration on the A axis. To try to spin it at F2000 seems to me to be really asking for a lot. That would explain why the servo was tripping if both the A axis and the X axis shared a common supply. A simple check might be changing the F2000 to F100 say.
Cheers
Roger
-
rodger a F2000 for A axis is normal on some machines I run mine at 2340 if the x,y or Z are running at 1250 if I did a F100 it would lake a long time.
Tarak it should work how you wont it to you will just have to weight to one of the other boys comes along who knows how to set it up
-
To be sure. I was simply suggesting a diagnostic.
Cheers
Roger
-
I
-
Thanks guys,
rcaffin, even though it is programmed to F2000, it only rotates at approx. 100-200 rpm, it's a deceptive value.
Also you will notice it goes from absolute to incremental, so it should rapid out 20mm.
I can run programs all day with no issue, but as soon as I try and rotate A axis for numerous turns in the one spot (in a program), it always jolts on the line after and trips out.
It's one of the strangest issues with Mach3, I've just never figured out??
-
Odd. But if the servo trips out, can you blame Mach?
I am assuming that the servo drive is faulting - right? I would ask why. Is there a power supply problem, or is the servo drive getting a follower error, or is the encoder playing up?
Cheers
Roger
-
a few question what version of Mach are you using, what is driving the machine PP or external controller, what is specks of your computer.
-
Dell box fairly new, W7, Mach .062, ESS w fairly current driver, Homann MB-02 BoBs, Gecko 320X servos on X, Y & Z, Gecko 203V stepper on A axis, SHG-25-50 HD, stock stepper, some reduction between stepper and HD.
Most machining takes about 5% of the CPU or less. NO internet connection.
There's a long series of articles on CNCZone at http://www.cnczone.com/forums/linear-and-rotary-motion/261174-cnc-engineering.html about the A axis I built.
Cheers
Roger
-
Tarak reply 7 is for you
-
MachMotion Mach3 CNC Computer Enclosure X15-350
• 15" Color LCD Flat Panel monitor 1024X768
• Intel Celeron D 360 3.46GHz Processor
• 80GB Hard Drive
• 1Gb Ram
• Microsoft Windows XP, sp3
• Mach3 Installed R3.042.040 (I don't have the latest version installed (R3.043.066), because when I did, I lose the ability to stop the program when I press the STOP button on the switch panel.)
• Switch Panel
• MC-01 ModIO Controller
• USB Smooth Stepper
• Servo Motor, ID 33003 with Industrial Encoder - Qty3
• CNC Teknix Tek10 servo driver - Qty3
rcaffin, you are correct the servo drive is faulting for X axis, but, as long as I do not rotate A axis for multiple turns, I can use X,Z and A axis all day with no issue at all????
Also I can use A, X & Z simultaneously all day with absolutely no issue, but if I rotate A axis for multiple turns, I have to pull X away extremely slow to prevent the machine from tripping out X axis.
Here is a sample program that causes the error, the program is created from this custom screen I made.
(http://s32.postimg.org/ws4mnsy6d/mach3.jpg)
;Annular plunge grinding example
#1=21
#2=20
#3=0.6
#4=2
#5=3
#6=0
#7=1
#8=-1874919423
#9=0
#10=0.2
#11=0.05
#12=20000
#13=15000
#14=0.95
#15=5
#21=10
#23=0
#24=3
#25=1
#28=3
#16=0.6
#17=1
#18=[[#6/[#5+#3]]*#3]
#20=3
#22=-1.1520495086364e-007
#26=[360/#7]
#27=[#22*#4]
#29=6
G90 G21 G57
G18
G90 G0 Z0.
M15;wheel on
G4 P2
X[#2+#11+#17+#21]
A0
M98 P1 L#20
G90 G0 X[#2+#11+#17+#21]
Z0. A0
X[#1+#21]
G4 P1
M16;wheel off
M30
O1
G91 G0 X[#21-[#21*2]]
M98 P2 L#15
G91 G1 A720 F#12
G0 X[#17+#21];THIS IS WHERE X AXIS JOLTS OUT AND THEN TRIPS OUT********
G0 X[[#18-[#18*2]]*#4] Z[[#3*#4]-[[#3*#4]*2]] A[[#22-[#22*2]]*#4]
M209
M99
O2
G91 G1 X[#10-[#10*2]] A360 F#12
M98 P3 L1
M99
O3
M99
O4
G91 G0 X[#21-[#21*2]]
M98 P5 L1
G0 X#21
G0 X[#18-[#18*2]] Z[[#3*#25]-[[#3*#25]*2]] A[#22-[#22*2]]
M99
O5
G91 G1 X[[#11-[#11*2]]-.3] A360 F#13
M98 P6 L#28
G91 G1 X[#9+0.3] A#26 F#13
G91 G0 X#11
M99
O6
G91 G1 A360. F#13
M99
-
Another parametric programmer! Wonderful!
What happens if you change
G0 X[#17+#21];THIS IS WHERE ...
to
G1 X[#17+#21] ?
I don't know what is the problem, but ...
I was using .042 but I upgraded to .062 and things did seem to improve. About all i can suggest is that you do the upgrade and rerun the program. A pain, I know, but I found the upgrade was definitely worth while - it solved some other bugs.
NOTE: while ARTSOFT are promoting .066, the world on the street is that you should stop at .062 instead.
Side issue:
Subroutine O3 is a no-op. I take it you simply truncated it?
Subroutine O6 simply spins the A axis N times: this is a grinding op?
-
rcaffin, yeah I try and use parametric code wherever I can.....much handier and also the best way to get consistency in your programs!
If I change from a G0 to a G1 it only works if I put a crazy slow speed in, but it does work!, if I try and rapid out, or G1 out at a normal medium feed rate, I get the same result of tripping the drive.
I will give .062 another go (I'm pretty sure I did awhile ago, but because I couldn't stop the program once it was started I removed it, not being able to stop the program is a deal breaker for me.)
Subroutine O3 is a no-op. I take it you simply truncated it?................This only is empty because the FINISH button on my screen is not enabled
Subroutine O6 simply spins the A axis N times: this is a grinding op?..........This is for spark out passes.
-
If I change from a G0 to a G1 it only works if I put a crazy slow speed in, but it does work!, if I try and rapid out, or G1 out at a normal medium feed rate, I get the same result of tripping the drive.
Imho, I would really focus on why the drive is tripping. Something is making it do that: what? To be sure, Mach might be sending some funny things to the drive, like a crazy speed, but imho you need to know what. Fwiiw, I don't think .062 has that problem.
I will give .062 another go (I'm pretty sure I did awhile ago, but because I couldn't stop the program once it was started I removed it, not being able to stop the program is a deal breaker for me.)
It would be that for me too, but FeedHold does work for me. NOT instantaneously, I must admit, but usually. There are some caveats though.
* If the program is executing a complex instruction like G8n (drilling) in Mill or G76 (threading) in Lathe, the program may not stop until that whole instruction has completed. This may be because the instruction is actually being run by the ESS, and I have not set Mach up to stop via the ESS. I may do so some day.
* Just sometimes, not very often, Mach does not want to stop on Feedhold, so I have to use the Stop button. I don't know why. Hitting the Stop button does not normally cause the machine to lose its zero. (Hitting Reset does make it lose the zero slightly.)
You can also use Input#1 as a stop signal, but I have not done that.
Cheers
Roger
-
feedhold stops when the buffer has run out of info in Mach3, Mach4 it works when you hit it
-
I seem to remember that you can configure Mach3 to tell the ESS to halt. I imagine that would be faster. Perhaps someone else who has their machine and ESS set up like this could comment?
Cheers
Roger
-
as far as I know it's down to the buffer size on the ESS smaller faster bugger slower, that was from the horse mouth
-
Yes, afaik, the buffer size matters when you configure Mach3 to handle the Feedhold. But I think you can tell Mach3 to send the feedhold through (immediately) to the ESS. I THINK.
I can't ask the machine right now: it's doing a 6 hour run.
Cheers
Roger
-
I will try the v062 later today, but with R3.042.040 when I press the stop button, it runs for a second or two (exactly what you guys said), it just needs to finish the command in the buffer.
hmmmmm...maybe I need to look at sending the feedhold command through to the smooth stepper??
-
I have asked the ESS guys about it should hear back in a few hours
-
with the stop button it should just stop what code did you use with your cycle stop button
-
Yes, with the Stop button and an ESS it does stop almost immediately.
One would like it to FeedHold though.
Cheers
Roger
-
yer yer Rodger not arguing never would with you.
Taraks screen set I can't see a feed hold button that's why I am asking about the cycle stop button, and ask about if there is a way to make feed hold work faster on the ESS forum I would like to know that one my self with my big router at fall wack feed hold is well I don't like to use it a half inch router bit goes everywhere if it crashes and I hit feed hold it does not stop fast enough, for some reason I have to have a big buffer.
-
Hi Dude
Feedhold: I have just checked on my system and the ESS.
We know that Mach3 can tell the ESS to Stop immediately, because the Stop button does just that. Obviously it sends a packet over the ethernet to the ESS which contains an immediate Stop command. So that concept works.
There is an option in the ESS config menu to select whether the Feedhold is done by Mach or by the ESS. If you select Mach then it empties the buffer - which as noted can take a little while. I will guess that if you select 'by the ESS' then Mach itself will also feedhold, but it will send the equivalent of a 'stop' command through to the ESS immediately.
But of course there is a problem here. If you tell Mach to Stop, then you are going to have to restart from the beginning (unless you trust the 'proceed from here' option - I don't. If you do a Feedhold to Mach, the buffer is emptied in a controlled manner and you can sometimes successfully tell Mach to continue. Mind you, I don't trust that option either.
But what happens when you do a Feedhold which is passed immedately to the ESS? What happens to all the stuff in the buffer - both the Mach transmit buffer and the ESS internal buffer? Short answer: I don't know. In a perfect world the ESS might resume smoothly ... maybe. Would I trust it to always do this? NOT without a lot of testing.
For your big router, I can only suggest you hit the Stop button before the cutter goes through the roof. Zero SHOULD be preserved, so you could restart from the beginning.
Cheers
Roger
-
I do hit stop, feed hold in M3 is ok for the times when there is no problems, but when there is na I wont use it.
when Mach 4 is working better and the ESS plug is finished it'S at 85% they just have to do the changes when M4 is changed and get the probing working, the feed hold problem is no more.
Andy will be getting back to me soon I have asked if they can have a look at this thread to see if they can work out what is wrong, what my be the buffer over flowing when Taraks runs the Axis more than one turn, and making the machine crash hard, what could trip the machine.
has profile .XML would help
-
Taraks have a look here some idea's for you to try http://warp9td.com/index.php/kunena/7-general-discussion/5586-ess-buffer?start=6
-
Thanks dude1, I'll have a read when I get a spare minute.
I took rcaffins advice and installed v.062 and it DID fix my issue, WOOHOO! sort of........ the feedhold seemed to work at first, it would pause a basic program, but as soon as I ran a more complex program, the feedhold will NOT stop the machine moving, if I can get past this hurdle I think the problem would be solved.
Oh, I meant to mention, the CYCLE STOP & CYCLE START buttons on my screen don't get used, I have an actual switch panel, I realised early on that when I create a screen I still need the buttons on the screen, otherwise I cannot test the screen, I did think about putting them on the TAB screen though, I only use the TAB screen for all the diagnostic LEDs and such....slightly off topic
Thanks guys!
BTW, I've attached my XML
-
Hi Tarak
Better read the Warp9 stuff soon. It explains about Feedhold and what limits apply to it. If you have a large buffer set up and the instructions are for long moves as well, it can be quite a while before the machine will stop. This is not a fault of Mach3: it is inherent in the use of a PC plus external engine (such as ESS).
Mind you, I am not 100% convinced that Mach3 .062 will ALWAYS obey the Feedhold button - but it will obey the Stop button. It's just that I have had to poke the Stop button a few times myself when Feedhold did not seem to be working.
Cheers
Roger
-
you have a very high Kernel speed set 45000Hz.
I got some good info out of Andy and Rob it gives me something to try
they give a good explanation of what you can do and what the trade off is
-
The advice from Warp9 is that going to a higher kernal speed than 25 kHz may not be either necessary or wise.
Cheers
Roger
-
Thanks dude1 and rcaffin for your help.
I changed the step frequency in the smooth stepper settings as per the recommended:
X axis: 128 kHz
Z axis: 32 Khz
A axis 64 Khz
I then went into the motor tuning settings and set to the max velocity and then set my acceleration, they seem smoother and a bit faster, so I'll happy with that.
I also tested my original program again using v040 (I know I shouldn't bother, and just try to figure out the feed hold issue for v062, I'm just curious).
BTW, with v062, if I'm running a basic program I press feed hold, it displays PAUSE then pauses a second or two later, the small delay is fine, but with a more involved program (coincidence maybe???) I press the space bar and nothing, it doesn't even display pause, no matter how many times I press it, I would love to figure out this pausing issue, it would solve all of my problems......I'm pretty sure my wife would disagree though! :P
Oh I also forgot to ask, if I change the kernal speed to 25 kHz, will I need to re-tune the motors?
This below program works...
;Annular plunge grinding example with finishing cycle
#1=48
#2=47.5
#3=6
#4=2
#5=24
#6=0
#7=4
#8=-1874919423
#9=0
#10=0.1
#11=0.025
#12=12000
#13=3500
#14=0.475
#15=5
#21=10
#23=0
#24=0
#25=1
#28=3
#16=1.5
#17=0.5
#18=[[#6/[#5+#3]]*#3]
#20=3
#22=-1.1520495086364e-006
#26=[360/#7]
#27=[#22*#4]
#29=5
G90 G21 G57
G18
M208
G90 G0 Z0.
G4 P2
G0 X[#2+#11+#17+#21]
A0
M98 P1 L#20
G90 G0 Z0.
A0.
G0 X[#2+#11+#21+0.3]
M98 P4 L#29
G90 G0 X[#2+#11+#17+#21]
M208
Z0. A0
G0 X[#1+#21]
G4 P1
M18
M16
M30
O1
G91 G0 X[#21-[#21*2]]
M98 P2 L#15
G91 G1 A720 F#12
G1 X[#17+#21] F300 ;IF I USE G0, IT WOULD JOLT X AXIS OUT AND TRIP THE SERVO
G0 X[[#18-[#18*2]]*#4] Z[[#3*#4]-[[#3*#4]*2]] A[[#22-[#22*2]]*#4]
M99
O2
G91 G1 X[#10-[#10*2]] A360 F#12
M98 P3 L1
M99
O3
M99
O4
G91 G0 X[#21-[#21*2]]
M98 P5 L1
G0 X#21;THIS LINE SHOULD ALSO TRIP OUT THE SERVO, BUT DOESN'T????
G0 X[#18-[#18*2]] Z[[#3*#25]-[[#3*#25]*2]] A[#22-[#22*2]]
M99
O5
G91 G1 X[[#11-[#11*2]]-.3] A360 F#13
M98 P6 L#28
G91 G1 X[#9+0.3] A#26 F#13
G91 G0 X#11
M99
O6
G91 G1 A360. F#13
M99
-
If you change the kernal speed you are advised to revisit the motor tuning.
Cheers
Roger
-
+1 to rodger if it works better at 25 it's a over flow, one suggestion was to use a delay before the contuse A move so everything is at that point in time
-
And Warp9 recommend 25 kHz with the ESS anyhow. No need for anything faster.
Cheers
Roger (without the 'd')
-
auto correct sux's
-
Snerk :)
-
If youa re still having the issue with the X movement error after an A axis move. I have experienced an issue a few years ago while trying to do 3D rotary machining. My A axis was tuned alot faster then my other 3. This caused the X axis to stall and or freak out as soon as the A axis stopped its rotation and the X axis was asked to move.
-
Oh really?
Details, please, including Mach version number.
Sigh - not another bug??? But if it is, then it might be possible to find a 'fix'.
Cheers
Roger
-
This was years ago. I do not recall the version number. I had a sherline rotary which had 800 steps per. I had the motor tuning ALOT faster then the others. There was no need to have it tuned that fast as it was only stepping a very small amount. my best uneducated guess was the amount of resources it took to process the velocity of the A, When X moved it freaked. Sounds alot like the OP`s description.
-
you need to have the speeds between A and the other Axis set so they move at the same speed, this means the A Axis has to go faster than X, Y or Z, but when in practice if you set the A axis at the same speed the A will be slower you just need to bring up the speed of the A axis so it looks correct on my machine it's 1250 mm/min for X, Y and Z and A is 2200 mm/min and it runs very well it was a lot of slow cutting to get it correct it's just play to it looks good.
but if you get the A axis going to fast it will make thing go wrong fast there is a fine line between bonkers and all good
-
on my machine it's 1250 mm/min for X, Y and Z and A is 2200 mm/min
Is the A speed 2200 mm/min with radius compensation, or should that be 2200 degrees/minute?
Asking.
Cheers
Roger
-
with radius comp, I will have to have a look I am not at the same places as the machine
-
steps per 2.22, velocity 25002, Acc 5025 and use radius for feed rate, it look high but it does not go to fast it's about right when doing constant rotational work. I will have to have a look at what speed is shown when it's moving.
-
Hi Dude
I am curious: why a surface speed of 2200 mm/min for the A axis but only 1250 mm/min for XYZ? Seems as though you are doubling the surface speed and cut volume for the A axis over the others?
Genuine curiosity, as I have only limited experience with my A axis.
Cheers
Roger
PS: thread drift: sorry
-
I will have to double check, but I had it set the same and by god it was slow, I slowly speed it up to it was at a speed that just worked. I am not sure how it works but the movement speed look the same.
I will have a look on Monday and get the RPM, and what speed it shows in the DRO, I might try pushing it higher and see if that crashing problem will happen
-
Hi Dude
OK. Fwiiw, I think the DRO for Radius Compensation is wrongly labeled. There was a problem with it way back when, and it was supposed to have been fixed, but in a nutshell I am strongly of the opinion that the number which should be entered there is Diameter, not Radius.
I have done a lot of testing of the display, and entering the radius simply does not work. The display is all wrong with radius.
So it may well be that the calculations for surface speed also assume the number is diameter. That would account for the 2:1 ratio. Try it maybe?
Cheers
Roger
-
I have just done some testing I can get it to work using radius and it's fine the forum is not letting me post the files with a pick of general config and toolpath page and the code I have to Zip them and try again.
I found a problem with a setting I had to dig out my notes and found a setting that needs changed for it to work it's in the picks
-
files..
-
Fwiiw, I think the DRO for Radius Compensation is wrongly labeled. There was a problem with it way back when, and it was supposed to have been fixed, but in a nutshell I am strongly of the opinion that the number which should be entered there is Diameter, not Radius.
I finally got around to taking some screen shots of some A axis operations. I am cutting teeth around a GT2 pulley in several operations The first is to groove one tooth, subsequent operations move the cutter away from the pulley CL and rotate the pulley a bit, to shave off the corners.
The first photo shows what the display looks like when I enter the DIAMETER into the radius correction DRO.
The second photo shows what i get when I enter the RADIUS.
Actual operation looks exactly like the first (diameter) photo.
Cheers
Roger
-
that's still does not look quite correct I think you may have a bug in Mach3 are those the one's you did in gearotic
-
Well, if it's a bug, then the bug works very well.
Yes, I actually agree, but I think (I am very sure) the bug is a programming error rather than a random corruption. (I have about 50 years of programming experience.)
I wrote the code for this from scratch. I may have mentioned it in Gearotic recently. It runs, and makes GT2 pulleys.
cheers
Roger
-
yer you did if it works it works
-
True.
Fwiiw, going from XL belts to GT2 belts seems to have improved the zero-holding from 0.15 mm to 0.5 mm, so I think it was worth while.
Cheers
Roger
-
my 3D printer use's GT2 pulleys and belts and it's quite good at 5000 mm/min
-
Aaarrgghh ! ! !
That should be be:
'improved the zero-holding from 0.015 mm to 0.005 mm, ' (15 microns to 5 microns)
What was I thinking????
Gerk
Cheers
Roger
-
that's better that's where I would like my big router to be at all the time but it's big so 0.01 to 0.00 over 1000 movements on a single axis is good, I just have to keep it at 1250 mm/min any faster it's moving out by mm at a time in any direction. but it's a easy fix $1200 worth of new parts it came from bad advise years ago lesson learnt only listen to experienced users that have a good name on here not the others.