Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: swarfboy on October 31, 2008, 11:42:39 AM
-
1. DRO's don't always zero they will have 0.0013 left in them sometimes.
2. Step and Dir pulse lengths on some installs will reduce upon opening and closing the motor tuning window.
ie. Step=2 Dir=1 after opening, setting, closing , opening motor tuning will change each by -1
3. Program extrema is not being calculated correctly.
-
1) could be due to your resolution. What's your steps/unit?
-
I'm in millimeters. I have 800 steps/mm. This is the resolution of my lead screw/motor combination. I use 0.9° steppers with 10microsteps with a 5tpi ballscrew.
My parts come out to the correct size and I can step the machine in about 2micron increments so all works.
What does that have to do with me clicking the "zero" button and the DRO not going to zero?
No comments on bugs # 2 and 3?
Brian
-
Velocity of machine is not ever reaching targeted feedrate.
IE. Program a single axis movement like
%
G01 X0 F100
X20
M30
%
Mach never actually reaches the programed feed its always about 4mm/min velocity slower than it should be.
This does not happen in 3.41
-
swarfboy,
bug#2 existed before, but can't remember which version or when,but it was fixed, since that was happening to me and a few others.Was a PITA. Are you using a SS?
Maybe a quick search will bring help bring back memories since it was 6 months or so ago.
Don't understsand #3.
RICH
-
Rich,
"Are you using a SS? " Whats SS?
I'm using the latest release as the subject title says and I have this issue still on one of my machines. I've cleared out and reinstalled Mach from scratch still a problem.
#3 There are program extrema DRO's. Mach parses the Gcode and finds the max and min values of the Gcode for each axis. This tells you the size of the work area for a particular code.
Wow. 165 views and only two people have something to say?
Brian
-
Wow. 165 views and only two people have something to say?
Brian
Were you asking a question or as I was thinking reporting bugs?
Hood
-
Brian,
If I were you, I would post these over at the Yahoo Mach groups as that's where Brian and Art seem to hang more than here.
You'll probably get more input over there on these specific items since they're constantly going over the new revisions.
Dave
-
Brian,
Not surprised, assume a lot of people haven't tried the latest version yet, like me, as i am using 3.042.12.
SS is Super Stepper which provides for using the USB port, forget about it.
I couldn't find anything about Mach not saving the step & direction value other than around Ver 2.61.
Sorry, but for such a PITA, you think i would have remembered what fixed it or what i did.
That said, maybe someone else may post about it.
RICH
-
Reporting bugs. Thanks Dave I'll head over there. This is the tally so far.
1. MAchine Coord DRO's don't always zero they will have 0.0013 left in them sometimes.
2. Step and Dir pulse lengths on some installs will reduce upon opening and closing the motor tuning window.
ie. Step=2 Dir=1 after opening, setting, closing , opening motor tuning will change each by -1
3. Program extrema is not being calculated correctly.
4. Mach seems to be having issues saving CV state if you change the CV dist tolerence or turn CV dist on/off.
Closing and opening the session fixes it, but I've learned mid session changes are risky behavior.
5.Mach is parses the code pretty slow when you open a file. I'm guessing it parses the code for gcode errors and finds program extrema.
I would like to be able to turn off the program extrema calculation method or see it rewritten using RegEX so that it parses faster.
6. If you jog the machine during tool change M6 (so as to be able to physically get to you spindle and change the tool upon pressing cycle
start mach moves to its previous position with no warning or way to cancel this. This needs to have the same dialog added that you get when using
"run from here".
Brian
-
Ok I have a question, you mentioned on one machine you are having these issues. Is it only on one machine? are the others OK?
Hood
-
Only bug #2 occurs on one machine. The rest of the issues are problems in all mach installs of 3.42.015. I've tried uninstalling mach deleting the mach folder, reboot, and reinstalling mach and still problem exists. I didn't try clearing anything in the registry though.
-
I will have a look tomorrow on my machines but I know for sure the DROs dont do that, well sometimes they are out 0.001 but that is a SmoothStepper thing and as I am in metric that is an insignificant number as its not cumulative. As I use the SS I cant test that one out for you.
I think the pulse width was an issue on earlier versions of the Dev revisions but sure that was sorted, certainly not seen reports of it recently. Mine are set to zero on all machines so obviously it doesnt affect me but I will test out tomorrow and see.
Programme extrema is still an issue in Turn I think, not sure about mill but again will check and see on my machines.
Never use CV settings but will test tomorrow if I get a chance.
Wouldnt call 5 a bug but rather a what you would like. Unless that is it is taking exceptionally long of which it did in some of the earlier Dev versions.
I am sure I get the prep move box but again will check for sure.
Hood
Hood
-
I will have a look tomorrow on my machines but I know for sure the DROs dont do that, well sometimes they are out 0.001 but that is a SmoothStepper thing and as I am in metric that is an insignificant number as its not cumulative. As I use the SS I cant test that one out for you.
Like I said sometimes they have 0.0013mm left in them when zeroing. I don't think that is an insignificant number. I asked for zero not close to zero.
Wouldnt call 5 a bug but rather a what you would like. Unless that is it is taking exceptionally long of which it did in some of the earlier Dev versions
The code that parses the Gcode is slow. It needs improvement, maybe needs to be rewritten using regular expressions.
I am sure I get the prep move box but again will check for sure.
There is no dialog box to cancel the prep move that has been added to tool changes.
I added a new bug #7. (see below)
Brian
1. Machine Coord DRO's don't always zero they will have 0.0013 left in them sometimes.
2. Step and Dir pulse lengths on some installs will reduce upon opening and closing the motor tuning window.
ie. Step=2 Dir=1 after opening, setting, closing , opening motor tuning will change each by -1
3. Program extrema is not being calculated correctly.
4. Mach seems to be having issues saving CV state if you change the CV dist tolerence or turn CV dist on/off.
Closing and opening the session fixes it, but I've learned mid session changes are risky behavior.
5.Mach is parses the code pretty slow when you open a file. I'm guessing it parses the code for gcode errors and finds program extrema.
I would like to be able to turn off the program extrema calculation method or see it rewritten using RegEX so that it parses faster.
6. If you jog the machine during tool change M6 (so as to be able to physically get to you spindle and change the tool upon pressing cycle
start mach moves to its previous position with no warning or way to cancel this. This needs to have the same dialog added that you get when using
"run from here".
7. Machine is always underfeeding. If I set feed rate to 100mm/min and give the machine plenty of room to make a single axis move and get up to speed
it is always under feeding by about 4mm/min, it never reaches the programmed feedrate and my max velocity is 800mm/min. It didn't do this in older mach versions.
Brian
-
Hello Brian,
1. Machine Coord DRO's don't always zero they will have 0.0013 left in them sometimes.
I think you are setting zero with the Reff command with no home switches .. This is a known problem at this time (I will fix it but it is working with home switches). Also if you are going to set zero you should use the Zero x,y,z buttons... Last what is your steps per unit ?? You may not be able to get to zero (Limitation of your machine) and this is as close as the software can make your machine round the digital steps to zero.
2. Step and Dir pulse lengths on some installs will reduce upon opening and closing the motor tuning window.
ie. Step=2 Dir=1 after opening, setting, closing , opening motor tuning will change each by -1
This is fixed in 3.042.015
3. Program extrema is not being calculated correctly.
Could you please give an example of what is not correct? For example are you running loops with offset shifts and so on in the code? If so it is hard to tell if you are in the correct position when the reference position is changing :) That is the only time that I know when this is not correct..
4. Mach seems to be having issues saving CV state if you change the CV dist tolerence or turn CV dist on/off.
Closing and opening the session fixes it, but I've learned mid session changes are risky behavior.
You should close and reopen the software to back up your settings...This is a very good idea
5.Mach is parses the code pretty slow when you open a file. I'm guessing it parses the code for gcode errors and finds program extrema.
I would like to be able to turn off the program extrema calculation method or see it rewritten using RegEX so that it parses faster.
It is also the calcs for drawing the toolpath that is slowing down the load time... In the diagnostics page please turn off the toolpath and tell me if you like that better.
6. If you jog the machine during tool change M6 (so as to be able to physically get to you spindle and change the tool upon pressing cycle
start mach moves to its previous position with no warning or way to cancel this. This needs to have the same dialog added that you get when using
"run from here".
Please have a look at the M6Start.m1s and M6End.m1s macros and change them to your liking :) This is the only way to change how the toolchanges are done
7. Machine is always underfeeding. If I set feed rate to 100mm/min and give the machine plenty of room to make a single axis move and get up to speed
it is always under feeding by about 4mm/min, it never reaches the programmed feedrate and my max velocity is 800mm/min. It didn't do this in older mach versions.
\
This has to do with how the feedrate is now calculated.. in the end are not far off (less then one %) this has to do with the amount that your CPU timing is off from what it should be...
Hope that helps you :)
Brian
-
After pressing 'feed hold' and then resuming the operation with cycle start the original feed rate had been forgotten and the system crawls with like an inch per minute.
With the inability to accelerate past 100% with the smooth stepper this is really a problem.
Cheers
Lemo
-
Hello,
Could you please give a bit more info?
Is the machine moving at the programed feedrate of when you did a feedhold?
Are you typing in a new feedrate into the DRO that you would like it to do and it is setting the feedrate back to what is in the program? I have changed much of the feedhold code to save the feedrate that you last where programed at..
-
Brian:
Just downloaded and ran 3.042.015 and have the same issue previously reported regarding 3.042.004 (see below). The part was cut correctly, but looking at the weird numbers in the Tool: Table Display screen was really disconcerting. Have gone back (again) to 3.041.
Previous post follows:
Downloaded and ran 3.042.004 version and had nothing but problems. Code that ran perfectly in version 3.041 would not run without problems in arcs, etc. One thing I noticed on the Diagnostics screen is the abs max x, y, z were all out of proportion to the drawing in the code in mill mode. The figure in the code is 11.5 by 5.5 inches - the Diagnostics screen showed the max to be like 116 (somethings). Yes, I copied my old xml file into Mach before running the code. Yes, my native limits were in inches. I had the same problem with another code.
Bob @ BobsShop
-
I've also had a problem with the feed rate but in my case I've adjusted it with the FRO +/- buttons. Then somewhere along the way the machine changes speed apparently on it'd own (Perhaps commanded by an F word but not to the extent it changes) and the FRO buttons don't do anything any more. You can adjust them from 0 to the max and press the FRO reset and the speed does not change. You're pretty much stuck with the speed you have unless you start the G-code program again.
Sage
-
Bob,
I would like nothing more then to fix your problem.. But you are giving me nothing to work with... If you doing show me the code that I need to run I will not look at the problem.. I have tested it and it worked with the files that I tested. So if you would Screen shots and GCode will go great lengths in helping me find the problem..
Thanks
Brian
Downloaded and ran 3.042.004 version and had nothing but problems. Code that ran perfectly in version 3.041 would not run without problems in arcs, etc. One thing I noticed on the Diagnostics screen is the abs max x, y, z were all out of proportion to the drawing in the code in mill mode. The figure in the code is 11.5 by 5.5 inches - the Diagnostics screen showed the max to be like 116 (somethings). Yes, I copied my old xml file into Mach before running the code. Yes, my native limits were in inches. I had the same problem with another code.
Bob @ BobsShop
-
Hello Sage,
The other versions of Mach3 would look at the Feedrate of the head of the lookahead.. this would reset your feed rate to the lookahead on a feed hold.. This fix was to talke that out, so please be sure that you are on the latest Dev version..
Thanks
Brian
I've also had a problem with the feed rate but in my case I've adjusted it with the FRO +/- buttons. Then somewhere along the way the machine changes speed apparently on it'd own (Perhaps commanded by an F word but not to the extent it changes) and the FRO buttons don't do anything any more. You can adjust them from 0 to the max and press the FRO reset and the speed does not change. You're pretty much stuck with the speed you have unless you start the G-code program again.
Sage
-
I have the following running
F600
G1 x blablablablablablabla lot's of more G1 blabla
Now I hit feed hold. Screetch. Stop!
Now I hit start cycle. And.... crawl crawl crawl. As I mentioned with a rediculous low speed.
No way to get away from the crawl. I'll try that again and look at the feed speed indicator when it happens. I mean I am sure I did, but can't swear what it reported right now.
I'll post that later.
Lemo
-
Hello,
post a Gcode file and tell me what you are doing.. I am NOT seeing this trouble here.. I trust that you are seeing it but if I don't see it I will not be able to fix it.
Thanks
Brian
-
Brian,
1. Machine Coord DRO's don't always zero they will have 0.0013 left in them sometimes.
I think you are setting zero with the Ref command with no home switches .. This is a known problem at this time (I will fix it but it is working with home switches). Also if you are going to set zero you should use the Zero x,y,z buttons... Last what is your steps per unit ?? You may not be able to get to zero (Limitation of your machine) and this is as close as the software can make your machine round the digital steps to zero.
My steps per unit are 800steps/mm. The machine coords zero properly when I home to my switches but when I try to manually zero them I am getting 0.0013 left in the DRO. By manually zeroing I mean I am clicking a button with the SetMachzero() function in it.
2. Step and Dir pulse lengths on some installs will reduce upon opening and closing the motor tuning window.
ie. Step=2 Dir=1 after opening, setting, closing , opening motor tuning will change each by -1
This is fixed in 3.042.015
I have a computer that still has the step/dir pulse reduction issue and its running ver 3.42.015. This is the only machine that does this other mach installs work fine. What could be the issue? I've uninstalled mach and reinstalled and still no go. This included deleting the mach3 folder that was left after uninstall. Any other ideas? Clearing registry entries too?
3. Program extrema is not being calculated correctly.
Could you please give an example of what is not correct? For example are you running loops with offset shifts and so on in the code? If so it is hard to tell if you are in the correct position when the reference position is changing :) That is the only time that I know when this is not correct..
I will look for code that was a problem I believe it was when the code had arcs or code with A rotations. I'll find something and get back to you so you can repeat the problem on your end.
4. Mach seems to be having issues saving CV state if you change the CV dist tolerence or turn CV dist on/off.
Closing and opening the session fixes it, but I've learned mid session changes are risky behavior.
You should close and reopen the software to back up your settings...This is a very good idea
Is there any thing you can do to make changing settings during a session stick better. The problem is when I have to close mach it causes me to need to rehome my machine as some scripts I have written look to see if the machine has been homed for safety reasons.
5.Mach is parses the code pretty slow when you open a file. I'm guessing it parses the code for gcode errors and finds program extrema.
I would like to be able to turn off the program extrema calculation method or see it rewritten using RegEX so that it parses faster.
It is also the calcs for drawing the toolpath that is slowing down the load time... In the diagnostics page please turn off the toolpath and tell me if you like that better.
I run with the toolpath off it has always been a resource hog. IMHO as nice as the features of it are I wish there was some way to reduce its resource requirements.
6. If you jog the machine during tool change M6 (so as to be able to physically get to you spindle and change the tool upon pressing cycle
start mach moves to its previous position with no warning or way to cancel this. This needs to have the same dialog added that you get when using
"run from here".
Please have a look at the M6Start.m1s and M6End.m1s macros and change them to your liking :) This is the only way to change how the toolchanges are done
I run with the toolpath off it has always been a resource hog. IMHO as nice as the features of it are I wish there was some way to reduce its resource requirements.
7. Machine is always underfeeding. If I set feed rate to 100mm/min and give the machine plenty of room to make a single axis move and get up to speed
it is always under feeding by about 4mm/min, it never reaches the programmed feedrate and my max velocity is 800mm/min. It didn't do this in older mach versions.
This has to do with how the feedrate is now calculated.. in the end are not far off (less then one %) this has to do with the amount that your CPU timing is off from what it should be...
Its more than one percent. For me its more like 5%-10%.
Also could you add "CV FeedRate" from the settings screen to the General Config dialog with the other CV options.
Thanks.
Brian
-
Hello,
1.) 1/800 = .00125 or if you round the DRO .0013.. If you would like a machine that can zero you need to have a greater number of steps per unit...
2.) I would like to see the XML that you are working with... if you look for the PulseWidth and DirPulse I would like to know if it is getting saved to the XML.. also exit the software as soon as you make the change to back up the XML
3.) NA
4.) What are you doing that you need to change all the settings of you machine as you are running.. the stuff that you are talking about should be set one time. If you are going to change the settings one time I don't see that there is a problem with shutting down and restarting.
5.) There is no way to lower the resource's... The Driver is taking 50% of the CPU power to make the P Port a motion controller.
6.) I see you have the same reply as 5.) ... So tell me if you have changed your macro..
7.) 800 - 4 = 796 796/800 = .995 so it is 99.5% on so it is .5% off in speed... I think that is less then 1 % :)
I could add this to the doalig at some point but this change will make the new manual incorrect... So at this time I am going to wait.
Thanks
Brian
-
1. Can you not force SetMachZero() to set the DRO to zero at its current position? I'm not understanding why this needs to be calculated I just want to push 0 to the DRO.
2. I'll get it for you and look at this some more. I'm out of the office today.
4. One job I'm running is 0.25" in size with features as small as 0.005" the next job is 12" in size with very few small features. I find CV dist tolerance to be a nice feature but an appropriate distance is different if you part is large or small.
5. I was referring to mach's toolpath display not mach itself. I find myself turing the toolpath on and off. On so I can look and off so I can run cause mach runs better with toolpath off on large gcodes. I'm guessing without a major rewrite of the viewport there's not much that can be done.
6. Copy and pasting stupidity. Sorry. Not yet I'll try this on Friday when I'm back at the shop and post my result.
7. Given 100mm/min is program feed, it is a single axis move, actual feed is 96mm/min, and there is plenty of distance to accelerate to that velocity and the max velocity of the machine is >100 100- 4 = 96/100 = 96% = 4% off in speed.
-
Brian, appreciate your interest. I have already deleted the latest version of Mach and reverted to 3.041. It works fine. In the past, in order to stay current, I have upgraded to the most recent issue of Mach. Since I encountered problems with the last two upgrades, I think I will just sit back and wait for a final release of 3.42.
Thanks again for what you have developed and delivered so far. Mach3 and LCAM are still my programs of choice for making new parts.
Bob @BobsShop - still cutting
-
Hello Bob,
This is fine but know that with out examples you are not going to see any fix for that bug.. part of the low cost of the software is that fact that we need your help to make it better.. I can not fix what I can't see :) .
So it will get fixed if an other reports the problem and makes it so I can see it.. (Crystal ball is broken)
Thanks
Brian
-
1. Can you not force SetMachZero() to set the DRO to zero at its current position? I'm not understanding why this needs to be calculated I just want to push 0 to the DRO.
It is a digital signal.. that is as close as you can set it ... It is so close that I would think it is okay :)
Just to help people there is NO SetMachZero() call. in VB.. there is an OEM button ...
4. One job I'm running is 0.25" in size with features as small as 0.005" the next job is 12" in size with very few small features. I find CV dist tolerance to be a nice feature but an appropriate distance is different if you part is large or small.
If you are going to be doing parts like that you NEED to have more steps per unit..
5. I was referring to mach's toolpath display not mach itself. I find myself turing the toolpath on and off. On so I can look and off so I can run cause mach runs better with toolpath off on large gcodes. I'm guessing without a major rewrite of the viewport there's not much that can be done.
I am looking to change the display code in the next major update... this is a large job and need to have a good release of what we have now before I start :P)
6. Copy and pasting stupidity. Sorry. Not yet I'll try this on Friday when I'm back at the shop and post my result.
I understand!
7. Given 100mm/min is program feed, it is a single axis move, actual feed is 96mm/min, and there is plenty of distance to accelerate to that velocity and the max velocity of the machine is >100 100- 4 = 96/100 = 96% = 4% off in speed.
No fair... you can't change the numbers on me... that is not what you posted! The problem is that we are reporting what it IS doing.. this is something that we will look into more in the next large rev.. for now it is what it is ..
Thanks
Brian
-
Brian, trying again to attach screen shots.
Bob @ BobsShop (Technology is wonderful!! Wish I understood some of it)
-
Brian, (actually, this is the first part of my message - Had wrong file types and could not upload - Attached is the tap file)
Okay, you shamed me into it. Will attach the code and (hopefull) screen shots from version 3.041 and 3.042.015 for your review.
Same code was used in both examples. Native units were set to "Inches," Tools used were T30 - .020 engraving tip, and T14 - .125 center cutting end mill.
Note the program limits in 3.042.015 are X - 136.0905 and Y - 10.8570 - In version 3.041 the limits are X - 10.8942 and Y -5.2502. The part was cut properly using version 3.041. I was unable to cut it with version 3.042.015
Actually, I was afraid I was becoming a pest and had decided to leave well enough alone. But, I really do appreciate your looking at the problem.
-
Bob,
Thanks for the code to test with!!! Now to see if I can find the trouble ;)
Thanks
Brian
-
I see the same trouble on my machine :) I don't give this bug the night to live !
Thanks
Brian
-
Helo Bob.. as far as I can tell I have fixed the problem..
Thanks for the file to test with!
Brian
-
4. One job I'm running is 0.25" in size with features as small as 0.005" the next job is 12" in size with very few small features. I find CV dist tolerance to be a nice feature but an appropriate distance is different if you part is large or small.
If you are going to be doing parts like that you NEED to have more steps per unit..
I don't understand your response. Maybe I was confusing by stating lengths in inches. I have 800steps/mm. I can't change that its based on my motor and screw. I have (400steps/rev * 10micro steps)/(5mm/rev) = 800steps/mm. My machine moves the correct distance, when I say go 10mm and I measure it with an indicator it goes 10mm. The only way I can increase my steps per is to use inches which would be 20320 steps/inch, this does resolve the SetMachZero() issue but now the scale of the unit is to big for my part. Millimeters makes more sense for the scale of the majority of my work. I have no problems machining micro parts at the resolution I have. I don't understand how having more steps would help me fix the scaling issues of CV values. Meaning CV values should be bigger on bigger parts IMO. Having to close and open mach to change that and get it to save properly is silly. I guess the real issue is whats the trouble with saving to the XML and having mach reinitialize it during a session?
Brian
-
Set up two profiles, one for big parts one for small.
Hood
-
A very logical alternative Hood.
IMO anyway.
RC
-
Hellp Brian,
I am not going to go into to much depth on this as it Will make everyone go to sleep :) ...
CV Is not a simple connect both lines, It will run as many as 1000 lines at the same time to make the moves go at the programed feedrate. The smaller the moves (less steps) the less it can blend the move smoothly. The more steps (resolution) the smoother the operation will be.
I don't understand why you are running inch files in MM mode but it is your machine and you can do what you like :) I like to keep the scaling and so on in the Cam system and keep the machine with the same settings (this is how it is done in 99.99% of installations). As for not backing up your settings in the XML, All I can tell you is that the program was never designed to operate in the manner that you are asking it to.. Sorry for the trouble.
Thanks
Brian
-
LEts try this this way. IF you have 800rev/mm then the smallest move you can make would be 1 step and that would be .00125mm. When Mach initializes itself or you home then it sets itself to zero internally. Then it has to track the internal position reguardless of where the user corrd are. IF you ask Mach to zero at a certain point AND that would mean mach had to recalculate where that zero would put it internally. IF that position fell in between the smallest move(.00125 then mach has to make a desision to resolve itself either 1 step above that point or 1 step below that point. NO other way out. NOW Mach will as soon as you move, MACH will bring itself back into 100% position within the smallest step. YOU do not loose that in between amount.
NOW that said your .00125mm step equals about .00004" IT takes a very accurate and expensive machine to work in that resolution. Are you sure your machine is capable of that??? IF so then you need to regear your drive to provide a step size smaller than the .00125mm .
When you home Mach resetts the internal zero so steps do NOT come into play(;-).
(;-) TP
-
I'm not running inch parts in MM sorry for the confusion. EVERYTHING I DO IS IN MILLIMETERS. My machine is mechanically plenty capable of making 0.0013mm moves. Electronically thats another issue. Micro steps aren't uniform unfortunately. Eventually I'll need some scales/encoders on my machine, but for now it does a good job as it is. I've attached an image so you can better understand my work. Sometimes I do run bigger parts. Something the size of a golf club or motorcycle grip. The CV dist tol for tiny parts and for big parts should not be that same for optimum performance of the velocity of the machine. I need to change this setting on the fly reliably and I can't. Mach doesn't seem to want to , at least not reliably. My motors are direct coupled using gearing creates a whole nother set of issues we won't go into and I'm not buying new ballscrews. I guess my only solution is to up my microsteps, this seems silly.
I can home to my switches and it forces the Machine Coord DRO's to zero, why can't the button do the same thing. I don't get it. I've attached some parts I machined so you can understand the size of most of my work.
Brian
-
I would be interested to see some pics of your mill.
Have you tried typing zero into the DROs?
Hood
-
You can't type zero in machine coords DROs.
-
oh sorry should have read what you were wanting :(
Hood
-
Ok you said you press the zero button to put the DRO to zero, what zero button is this?
Hood
-
I built my own screen set. On it I have buttons utilizing SetMachZero(). You can use (0),(1),(2),(3),(4) which refer to x,y,z,a,b. This function zero's the machine coord for the particular axis. IMO it isn't working as it should. I understand the dilemma with the steps per unit, but disagree with the only solution being to say I need to fins a means of increasing my steps per unit.
Image teaching this software to a new user. You have a button that says "ZERO MACHINE COORDINATE AXIS" and now you need to explain to them that it doesn't really zero because of the steps per unit is not allowing it to achieve the true position of zero cause its inbetween microsteps. They look at you crosseyes like you have 3 heads and they are asking what do you mean steps, what resolution, doesn't the machine just do what I say.
It's like this: where ever my machine is now I want it to be zero now. The machine doesn't need to move or calculate or anything just make my current position machine zero.
I know you really only need this when you have homing switches so as to reference, which is what I do, but I'd like to use this function and the way I see it it doesn't work. I'm not understanding why that is an issue. Please educate me.
-
Your button is a custom button? If so I presume it is a VB button? If not what OEM code does it have?
Please educate me why you would need to set machine coords zero at the position you are currently at, I would think most people would just use a work offset but maybe I am not understanding.
Hood
-
(;-) You cannot SET the "machine coor" except at startup or Home. It is Machs internal place keeping system and it is good to about 10 places or so beyond the decimal point.
Machs "user" coor system is based on the steps per unit resolution as compared to the Machine coor base. SOmetimes at the EXTREME side mach has to resolve the conflict of the position requested is smaller than the smallest step and does so accurately.
Very few people try to run there machine at such EXtreme resolution as you are trying.
You also cannot expect the machine to be able to display the absolute zero without providing the correct Steps per rev to do so.
You are attempting a resolution that most humans cannot even measure (;-) WHat are the +/- tolerances that you need to work in??
Perhaps you need to set the dros to display a lesser resolution so you will not be able to see mach resolving the steps issue.
(;-) TP
-
"My machine is mechanically plenty capable of making 0.0013mm moves" - Unless my calculator is broken, that is 0.00005", or 50 *millionths* of an inch. Perhaps your machine, on paper, has that kind of resolution, but I would be surprised if it has that kind of *accuracy* in the real world, unless you're running in a very tightly temperature-controlled environment. As you said the microstep precision alone is nowhere near that good. And, I doubt you have any means of measuring to anywhere near that kind of resolution. Resolution without accuracy is not good for much other than bragging rights. Unless I'm missing something, this seems like you're trying to pick fly poop out of pepper.
Regards,
Ray L.
-
Your calculator is broken Ray ;D either that or your millions are different from the UK ones, regardless however what you are saying is correct and that is why I wish to see pics of this machine as I have never seen one capable of such a degree of accuracy.
Hood
Edit!!!!!!
oops I need to go to here http://www.specsavers.co.uk/index.php?gclid=COzcjZ-W4ZYCFQ_UlAodW1ZCOg I think, sorry ray never noticed you said 50 :(
-
Go back and read my last post, I explain how I set the machine coords via oem code. I can zero my work coords with no issues or even type in those DROs and expected machine coords to behave the same and they don't. Apparently no one agrees that it should work that way guess I'll just have to live with it.
According to one of our customers the machine within the area of a few centimeters is repeatable to about 5microns (0.005mm). Me personally when I cut parts I shoot for around +/-0.05mm, my parts are also a little larger in scale. As far as the spec of the machine we don't quote any.
You can see the machine at http://www.minitech.com the Mininmill3 pro which is on the homepage.
Brian
-
Afraid I cant find where you said the oem code, possibly you can link me to that?
You can zero your machine coords at any point you wish IF you dont have home switches set up in Mach, to do this simply press the Ref All button or the individual Ref buttons. I use this feature to zero the machine coords on my lathe as the homing is done internally in my servo drives.
As for the accuracy of the machine I wont comment further other than to say even if it was capable of 0.005mm then that is almost a 5 fold increase in what you are worrying about.
Hood
-
Hood,
Buttons utilizing SetMachZero(). You can use (0),(1),(2),(3),(4) which refer to x,y,z,a,b. This function zero's the machine coord for the particular axis. IMO it isn't working as it should. I understand the dilemma with the steps per unit, but disagree with the only solution being to say I need to fins a means of increasing my steps per unit.
I use homing switches they zero the machine coords, but the button won't. It just seems odd that you press the zero button and the computer says sorry I can only get close to zero.
You made that sound like you didn't think the machine could make parts with that repeatability. Some of these microfluidics/waveguide users seem have the optical equipment that say they can achieve that. I don't have a means of verifying it in my shop but herea a little mold i cut and I can get some real nice tiny parts..
Brian
-
If you disable the HOME switch in Ports n' Pins like Hood said in reply #50, will it then read all zeros ? May need to Home/Ref one way or the other only.
RC
-
I use home switches so that's no good.
-
Hi, All
This is a bazaar issue, with ver prior to .012-.015, M3 & M5 would Hang req. cyc start to proceed, But no Home/Ref axis Issues. It seems to be that Mach doesn't allow quite enough time to finish the DRO's updating fully. (no home sw's)
One other thing I've noticed after getting the Ref. to re-set Current Position to 0000 & Machine Position to 0000 and running some Test G-code. The Current & Machine Position will show a -0.0010 when finished. The initial Ref.error was +0.0010, Something isn't being Updated
I now others are having Some Similar Issues, As Brian stated It's hard to fix something, If he can't duplicate it
Thanks,Chip
-
Chip
are you saying that if you have no Home switches enabled in Mach that when you press the RefAll button the DROs dont set to zero?
I am doing similar on the lathe and they always set to zero for me, well X sets to my home off distance but Z always zeroes. I have extra VB in my Ref All button to start the homing externally in the drives but the last part of each axis VB is to DoButton(2*) so in effect I am doing the same as I think you are saying.
Hood
-
OK I gues I have to ask, IF you are using Ref home at startup why do you need to reset Machine zero again? Is your machine drifting off of position?
I run all day and at days end do a verify and always return to within a few 10ths to the original machine zero. IF I have to do a Estop,etc of course you would always rehome to make sure you have not drifted off of zero.
Just curious as to why you need to rezero, (;-) TP
-
Hi, Hood
Yes, Also with "ref all home" The 'Ref. x,y,z" just eliminates the VB DoButton(2*) code calls.
I haven't ever seen this on earlier ver's of Mach3, Testing on 2 computers that have tested many versions.
One computer has very stable Driver Test's and the other is multi use (not as stable).
Chip
-
Strange on Chip, my Ref All button has the following in it
DoOemButton (240) 'De-Reference All axis
Sleep(10)
If GetOemLED (809) Then 'Check that Ref Z LED is RED
Do
Call SetModOutput (20,1) 'Activate ModOutPut 20
If GetInput(18) Then Exit Do 'Loop until ModInPut 18 is seen
Sleep (10)
Loop
End If
Call SetModOutPut (20,0) 'DeActivate ModOutPut 20
DoButton (24) 'Set Z axis Home
If GetOemLED (807) Then
Do
Call SetModOutPut (21,1)
If GetInput(19) Then Exit Do
Sleep (10)
Loop
End If
Call SetModOutPut (21,0)
DoButton (22)
So ignoring the Mod stuff basically it is DeReff'ing the axis then pressing the zero buttons, wonder if you put the DeRef at the start of your RefAll button if it would make a difference?
Another thing is I know my VB stopped working on one of the Dev versions and putting the DoButton(2*) twice solved the problem but Brian soon found the bug and solved it.
Hood
-
Hi all,
Just took a look at Swarfboys machine on the internet. I don't relate very well to submicron machining, heck the numbers sometimes don't seem practical in terms of machining. Are the machine movement numbers realistic? How do you know and by what absolute methods?
My two engraving machine tables if purchased new would exceed the miin mill cost. Even got certified papers stating that repeatability is 0.000012" / 0.0003 absolute accuracy over 6" / resolution 0.000004", little chart and all. Whatever that all means in the machining world.
Now, your are not going to use an indicator to even try and measure that kind of movement. I tried using a microscope
at 400x along with a 20x fical micrometer eyepiece using a submicron calibration standard ( it has little spaces and lines down to 0.000020") but I was only able to get to the 0.000040" inch one ( not enough light). And after all the setup and trial and error I am not sure what was measured. Hmm ....were a few steps not recieved or true of the out 253360 steps / inch?
Funny thing is that i will darned for the life of me to be able to get the cutter running true within .001" at about 1" away from the collet. Can't even hone a point down to .0005". So, about the min engraved line width will be about .003" using a point and that's at almost Z=0.
So Swafboy I believe what you say your machine can do but as far as confirming it, well that's a different story in my basement shop. There is a difference in my mind if your using a machine to measure something and to machine something. Don't know how to electronicaly confirm or what is needed to totalize and confirm 253360 of them.
Now havn't tried V*********.015 but when i zero the axis's they go to 0000 in V*********.012 ( no limit switches used).
RICH
-
Hi, Hood
I'll try the DoOemButton (240) VB-code, Repeating the DoButton(2*) 3 times usually fixes it, But it shouldn't be needed, Something in .015 isn't updating properly.
Thanks, Chip
-
Hi, All
Brian and Art fixed the Ref Axis/Ref All Home Problem, I was having, Brian's comment, "This should fix your trouble and wow was that one an odd one to find"..
It should be in an Update Soon.
Thanks, Chip
-
Good news Chip :)
-
swarfboy - will this fix your problem???
I'm having a similar issue also.
Thanks olf20
-
Don't know til its released in a new mach ver.
-
This is not a critical bug, rather an annoying detail. Nevertheless I think it should be eliminated.
I use a VFD to control the spindle speed. The VFD is controlled using a 0-10V voltage. This voltage is generated using the spindle setup in Mach3.
The voltage is directly proportional to the frequency of the spindle output (step signal).
A direction signal is not necessary as most of the spindles cannot run reverse.
If I neglect to define a direction signal, I will be annoyed by a window every single time I start Mach3.
It should be possible to define the output without a direction port definition.
Cheers
Lemo
-
Hello,
Could you please tell me if you are using a SmoothStepper? Mach3 should not give you that message :)
Thanks
Brian
-
I'm sorry.... yes..... WinXP, latest Mach3 dev, AND Smooth Stepper.
It's all Warp9's fault..... ;D
Lemo
-
I had two thoughts about Swarf's issue.
Keep in mind, I am a newbee to CNC and also to MACH 3, so these may not be reasonable ideas . . .
First; my undestanding is that Swarf's button is running some sort of macro. If so, could not the macro reset the machine coords, then MOVE to zero and then reset again, all within the macro? It seems to me that would correct for the minute error in calculating the position and the second reset would be the true zero sought.
Second; is there any practical reason one could not have more than one set of limit swiitches? I do not comprehend the reason to re-zero the machine coordinates at different points, but assumming there is some usefull purpose to that, why could there not be additional limit switched installed for the different set-ups? So you would plug in set A for part A and when you were going to run part B, you just plug in (or switch to) limit switch set B and re-home the mill.
-
second:
Limit switches are like e-stop switches. They protect the maximum envelope the system can move without damaging itself. Even if they can be used/defined as homing as well, they are meant as 'not to be touched'. Actually it's a pita to move a system out of the triggered limit switches.
Lemo
-
I had two thoughts about Swarf's issue.
Keep in mind, I am a newbee to CNC and also to MACH 3, so these may not be reasonable ideas . . .
First; my undestanding is that Swarf's button is running some sort of macro. If so, could not the macro reset the machine coords, then MOVE to zero and then reset again, all within the macro? It seems to me that would correct for the minute error in calculating the position and the second reset would be the true zero sought.
Second; is there any practical reason one could not have more than one set of limit swiitches? I do not comprehend the reason to re-zero the machine coordinates at different points, but assumming there is some usefull purpose to that, why could there not be additional limit switched installed for the different set-ups? So you would plug in set A for part A and when you were going to run part B, you just plug in (or switch to) limit switch set B and re-home the mill.
1) You *can't* zero machine coordinates, other than through a homing operation. That's the whole crux of the issue.
2) You could do that, but it would be a little silly. That is exactly why we have work offsets. You tell the controller where machine zero is, and everything else is referenced to that. You don't *need* multiple machine zeros.
Regards,
Ray L.
-
In latest developement version .018 /.017 something still seems wrong in the the extrema for the mill.
See swaftboy's post "Program Calculation Extrema Error".
RICH
-
1) You *can't* zero machine coordinates, other than through a homing operation. That's the whole crux of the issue.
2) You could do that, but it would be a little silly. That is exactly why we have work offsets. You tell the controller where machine zero is, and everything else is referenced to that. You don't *need* multiple machine zeros.
Regards,
Ray L.
Ray,
Am I missing something. Your first comment says you can't and then your second comment says you could.
That actually illuminates my point, which is as I said, I don't personally comprened the reason to do it, but if one wanted to do it, is it doable?
Personally, I have to agree with you on the logic of one master machine coordinate system and offsets, but the OP wasn't asking if his idea was a good one, he just wanted to know if it was doable.
My engineer brain just can't resist trying to solve a problem, even if the problem is hypothetical.
I was hoping for a comment on my macro idea. I don't know about MAch3's capabilities yet in that regard, but it certainly seems feasible to get rid of the .0013 error or whatever it was that was annoying the OP.
-
There is no contradiction. AFAIK, the *only* way to zero machine coordinates is through a homing operation, which means switches that tell Mach where "home" is. Your question was "why not have multiple sets of home switches", and I indicated that you could, but it would be silly. The first statement still stands, AFAIK, and I think that has been confirmed by others on here already.
Regards,
Ray L.
-
You can set the machine coords to zero if do NOT have home switches enabled, as said previously this is a handy thing for me as on the lathe I do the homing within the servo drives as it is deadly accurate, always exact, well as exact as I can measure (0,001mm).
The OP has failed to say why he needs to set the machine coords to zero at positions other than machine zero, also he has failed to say how he is doing it. Brian said that there is NO SetMachZero() call. in VB.. there is an OEM button
and as far as I see the OP is trying to do it via VB from within a button.
If he wants to zero the machine coords at any point other than machine zero then the best thing to do is disable the home switches and then it can be done. I dont see why he doesnt want to do this as what is the point of having home switches if you deliberately set your machine coords to zero other than at the machines actual zero position. There may be a good reason but after asking, and also someone else asking he has not said why.
Hood
-
Hood,
Thanks for providing yet another excellent reason for using servo motors! I am leaning that way for my next retrofit.
Ray,
Remeber that I am a newbee at this stuff, so I'm probably going to ask some stupid questions, and not understand some of the answers. Please don't take that as me being argumentitive. I appreciate your comments very much.
I dislike the homing operation. My modified Z axis is pretty tall (for a baby mill) and I almost never use the top of it, yet every home has to run the head all the way up while I wait impatiently. Same with the X axis. If the steppers loose steps for some reason, you go thru the whole process again.
Even though, as both myself and Hood pointed out, the OP has not explained his reasoning, I now have my own:
Yesterday I finished a preliminary run with my new 4th axis. It is a stepper powered spin index with a 5C 4" three jaw chuck. On the little baby X2, the rig takes up nearly half of the table. Yet to home, or re-home, I sit and wait for the whole rig to pass in front of me. It may be silly, but if I had to use that rig a lot, I would certainly consider setting up a set of limit switches that would eliminate the ride to the very end of the table, and only set zero at the beginning of the actual useable portion of the table.
I disabled my Z axis homing bacause I had to remove the limit switch to install my new Z axis ball screw. I probably won't reactivate it because it is such a pain.
Incidentally, years ago I had a large Bridegport knee mill with a table that went on forever. That was not a CNC machine, but I can tell you that probably 90% of the time, I used only about 12 to 18" of the middle of the X travel. I can see an advantage to having homing based on that envelope and just turn off homing an reset manually on the rare occations when I needed the whole table.
-
Simpson
No need to home to the extent of your axis, you can have a home switch positioned at any location on an axis, you then set a Home Off distance in Homing and Limits which then tells Mach where the actual machine zero position is for that axis. As an example the X on my lathe is positioned so that both front post and rear turret are at an equal distance from the spindle centre, I have a home off distance set so that when I home with the master tool the X axis DRO is set to the distance it is away from spindle centre (X zero on a Lathe)
On the subject of servos and homing, you need to have servo drives that are capable of doing internal homing, drives like Geckos, Tek10's, Rutex etc dont have that functionality. Greg is considering making this a feature of the SmoothStepper but that will only be when he has time so may not be for a while.
Hood
-
Simpson,
Having the home switches in the middle of travel is quite common - you can put them anywhere you like. In fact, I'm adding optical limit switches to my machine, and may decide to put home in the middle of the table, for the reason you suggest (although Z pretty much HAS to have home in the full up position for, I think, obvious reasons....). It was the idea of having multiple home switches that seemed a little silly to me, and suggested that the OP didn't understand the purpose of the home switches, nor the function of work offsets. When you have multiple sets of home switches, they're really no long home switches. And even on a large machine, I can't imagine the time saved to be worth the problems all the added switches and wiring will create.
Regards,
Ray L.
-
Ray
couple of things, first if your z is relatively out of the way such as on a manual bridgeport you can use an optical without any coolant protection, I did that on my first conversion (manual bridgeport) What I did was have the signal interupted by a piece of steel with two slots in it, one top other bottom. Now if you did that for a home switch then you could have it so that the slot is any desired location of the travel, in fact you could have it so that it is open from your desird position up the way (or down) and write a bit of VB to go in the Ref All button. It would look at the home input from the Z and see if its active or not, if its active then it would move off first so tht its inactive then reverse and start the homing procedure. That is the way my servo drives do their homing, its a great idea as it means you dont have to make sure you are at the correct side of the switch before you do the homing.
hood
-
Ray
couple of things, first if your z is relatively out of the way such as on a manual bridgeport you can use an optical without any coolant protection, I did that on my first conversion (manual bridgeport) What I did was have the signal interupted by a piece of steel with two slots in it, one top other bottom. Now if you did that for a home switch then you could have it so that the slot is any desired location of the travel, in fact you could have it so that it is open from your desird position up the way (or down) and write a bit of VB to go in the Ref All button. It would look at the home input from the Z and see if its active or not, if its active then it would move off first so tht its inactive then reverse and start the homing procedure. That is the way my servo drives do their homing, its a great idea as it means you dont have to make sure you are at the correct side of the switch before you do the homing.
hood
Hood,
That's a good idea! BTW - On a (loosely) related topic - What precautions, if any, are normally taken to prevent machine damage in the case of a servo runaway. I'm wondering if I should provide hard limit switches a bit inboard of the physical end of travel, to prevent the table from running full-speed into the end of travel. (One of the places steppers have an edge - runaways can't happen....)
Regards,
Ray L.
-
Ray
Dont think runaway can happen on the servos I use, they are AC so need the voltage in the correct sequence, if the encoders are faulty and the drive tries to correct then it will fault out after 20 counts or 20ms I think. Having said that I have limits which disable the drives and mach if they are hit, on a lathe this can still cause serious damage as it is impossible to use limits to stop collisions as tools can be sticking out all over the place especially in my case with both front and rear toolpost/turret. It will however stop a turret or toolpost slamming into the chuck on the Z axis or the opposite extent of both X nd Z.
Hood
-
Excellent info!
Having the switch in the middle of the table seems like the perfect solution for homing. Presumably you would have to make sure you were on the correct side of the switch before homing? And I also presume you then could not use the same switch for both homing and limits if the switch were in the middle of the table, so you're back to multiple switches and associated wiring, yes?
That still leaves the issue of machine protection. In my scenareo with the 4th axis rig, wouldn't it still be wise to have a physical switch positioned to stop the travel before the spindle hit the 4th axis chuck if something went awry?
I like the idea of sliding swithces and/or moveable slotted triggers. That would make it very easy to position a limit switch for example. . when the 4th axis rig is set up on the table.
-
Yes you need to make sure you hit from the right side when homing but as I mentioned above my servo drives automatically do that. Example if you have your switch mid axis then from that point on in one direction it is constantly activated. When I press my Ref All button the drive looks at the homing switch, if its active it says to itself I have to back off first so the switch becomes inactive and then I will reverse and start the actual homing. That should be relatively easy to do in VB as well.
My Lathe has sliding limits on the Z axis but to be honest I find it more of a hassle than it is worth but maybe thats just me.
Hood
-
I was wondering how you would get mid travel homing switches to work and was about to ask the same question.
If you have a movable limit switch could you have a VB button that moved that axis through the full travel after homing to find the switch positions and then put that into the soft limits?
It would be a bit of a pain on a large machine though having to set this everytime you restarted with a different limit position.
Steve
-
Keeping in mind that I'm a newbee, and this may not be a great idea, it goes like this;
Take a situation of a machine that has two basic setups that are vastly different; one is normal full table travel for general work and one has a 4th axis rig that takes up almost half of the table (of a baby mill).
My combination homing/limit switches are on a phono jack that just plugs into my CNC controller box. I think it would be a simple matter to add another switch in a position appropriate for the 4th axis work envelope, chain those together on a separate plug and have a second XML file for 4th axis projects. The xml could have the approproate limits for the 4th axis envelope and any other changes that may benafit that type of work.
So as a part of the 4th axis setup, I simply put the rig on the table, plug in the appropriate limit/homing switch chain into the CNC controller and start Mach with the 4th axis XML. Now I have fast homing and limits appropriate for the 4th axis envelope.
Maybe I'm missing something, but this seems like a very usefull proceedure.
-
Simpson, yes that seems like a reasonable idea, just as long as you remember the right profile and plug ;)
Hood
-
If you had the necessary amount of input pins available, (looks like you only need 1 for the additional X axis switch), could you not just wire them all up and then each Profile would ignore the switches that don't apply ?
Sounds like a plan Simpson,
RC
-
The bugs that started this thread have been fixed in ver020. Yay! Thank you.
-
Hello anyone. After install Mach 3.42.015 , I tested several models they came out so far so good for me but i had to set lower speed in Z axis .I hope it is stable for now. Nathan.