PDA

View Full Version : setting 0,0,0 in Mach3 Mill



sdantonio
10-09-2006, 05:26 PM
Hi,

I've attached a jpeg to make this easier (I was going to try to just describe the question without pictures.

Given a block attached to to router table top and a project that is approximately symmetrical with respect to the y axis, the position 0,0,0 (home) is typically set at point "1" on the diagram (at least that is my understanding). Is there a problem, or will Mack3 have a stroke, if I want to set 0,0,0 at point 2 on the line of symmetry?

Thanks

turmite
10-09-2006, 06:32 PM
Steven you can set 0,0,0 anywhere on the table for mach3, but to do this you need the gcode to correspond using that same position on the model as your 0,0,0.

At least that is my understanding of it, and my understanding may very well be flawed!:eek:

Mike

JFettig
10-09-2006, 08:06 PM
go to the offsets menu, set the offset to 1 (G54) and hit zero at the zero you want on each axis. this is what you do if you home your machine every time. if not you can probably just zero the dro's on the mainpage.

Jon

wildcat
02-24-2007, 01:50 PM
I use Mach3 1.84 and have a followup question about zeroing Mach3. I regularly zero Mach3 by pressing the three "Zero" buttons on the Program Run page. The LED next to the DRO is red at this point. If I look at the offset page the G54 offset contains some non-zero value. OK, so I then start the program. My programs Do not contain any reference to fixtures, i.e. there are no G54s, etc. However, once in a while something goes awry and at least one of the axises will offset by the value shown on the offset page. Why does this happen and why is it not consistent? Is there a way to completely disable the fixture offsets? I never use them but they have messed up my programs before. I have started using the "Ref All Home" button which seems to allow the offsets to be zeroed along with the DRO but it would be good to hear from someone concerning the best practice.

ger21
02-24-2007, 01:55 PM
G54 is the standard coordinate system in Mach3. Sorry, but I'm not sure why you're getting inconsistent results. You might want to try upgrading to a newer version.

sdantonio
02-24-2007, 03:19 PM
Let me revise my question and begin before the system even gets the gcode to mach

Lets assume the same square piece pictured in the post #1 of this thread, and lets assume that you want the origin of the piece to be at point 2 on the diagram. Lets say that starting the cutting at this point is important for future alignment of the piece. Before sending the piest to RhinoCAM (and I am specifically specifying RhinoCAM in the question) does it make a difference how the piece is aligned in Rhino3D. on the piece Does 0,0,0 in Rhino3D have to be at point 2, or can it be someplace else, say point 1. Does this make an important dirrerence in generating the g-code or does the mach offset take care of this?

wildcat
02-24-2007, 04:27 PM
Disclaimer: I don't use Rhino.

You need to be consistent with your assignment of the origin in both your CAM and your setup. In other words, the origin of your actual stock needs to match the origin of your stock in your CAM. Select your origin based on what is easiest to setup. For example, I always the bottom left edge to work in the first quadrant and because of how I use a edge probe. Setting different origins in the CAM will affect the values in the G code but not the distances. I.e., all the operations will be shifted some amount but will still cut just as much. This can be compensated for by setting the DROs by negative of that amount if a mistake was made. Hope that all makes sense.

wildcat
02-24-2007, 04:32 PM
G54 is the standard coordinate system in Mach3. Sorry, but I'm not sure why you're getting inconsistent results. You might want to try upgrading to a newer version.

Ok, I'll give upgrading a try. The same program will run fine most of the time but once in a while in the middle of the same program one or more of the DROs is shifted by the fixture offset amount. Obviously this is really dangerous if the machine is unattended. Is there a keyboard command that would cause this behavior? Perhaps EMI noise has caused that key to be "pressed?" Also, what significance does the small red/green LED next to the DROs on the Program Run page indicate?

wildcat
02-24-2007, 05:50 PM
FWIW: I tried creating a button that does:

DoButton(22)
SetDRO(0, 0)

which should ref the X axis and then zero it but it only seems to ref the X... the zero is never performed.

sdantonio
02-24-2007, 07:10 PM
Disclaimer: I don't use Rhino.

You need to be consistent with your assignment of the origin in both your CAM and your setup. In other words, the origin of your actual stock needs to match the origin of your stock in your CAM. Select your origin based on what is easiest to setup. For example, I always the bottom left edge to work in the first quadrant and because of how I use a edge probe. Setting different origins in the CAM will affect the values in the G code but not the distances. I.e., all the operations will be shifted some amount but will still cut just as much. This can be compensated for by setting the DROs by negative of that amount if a mistake was made. Hope that all makes sense.

Thank you, that's exactly what I wanted to hear. Since the things I make tend to be sylletrical right down the middle it makes the most sense to me to have 0,0,0 be right along that line of symmeter (at one end of it actually) like point 2 in the diagram in post #1. I assumed the origin should be consistent in the cam and Mach and everything should follow through from there. But I wanted to hear someone else with experience comfirm it.

Now the next question, and this is one you probably can't answer (not being a rhino user) and I will have to find out either from trial and error or maybe from asking the RhinoCAM folks. If my origin is set to one end of my line of symmetry in Rhino (point 2), when I start the CAM plugin, does it automatically pick up that origin from the CAD or do I specifically have to assign it myself?

wildcat
02-24-2007, 07:48 PM
Now the next question, and this is one you probably can't answer (not being a rhino user) and I will have to find out either from trial and error or maybe from asking the RhinoCAM folks. If my origin is set to one end of my line of symmetry in Rhino (point 2), when I start the CAM plugin, does it automatically pick up that origin from the CAD or do I specifically have to assign it myself?

You're right... I sure can't answer that directly but what I would do is try generating the G code using whatever procedure you choose in Rhino, load it into Mach, and checkout where the 0, 0 position is in the toolpath window. You could also click on Offline in Mach3 (on the Program Run page) and press Start to simulate the cutting. Watch the DROs and just make sure that everything makes sense from the prospective of where you want the origin to be. I personally like to simulate a run in Mach3 (or now in NCPlot) to make certain that the generated G code is good. I have had CAM programs insert crazy stuff that does not show up in their simulator but is pretty obvious when viewed in Mach and unfortunately painfully obvious if the program is run.

ger21
02-24-2007, 10:40 PM
Now the next question.......If my origin is set to one end of my line of symmetry in Rhino (point 2), when I start the CAM plugin, does it automatically pick up that origin from the CAD or do I specifically have to assign it myself?

Could be either, but you'll need someone with RhinoCAM experience to answer that. I'd think that it would default to the actual CAD file location, but the option to put it somewhere else (lower left usually) might be persistant.

sdantonio
02-24-2007, 11:29 PM
I'll kick the question out to the rhino users group that mcneel sponsors and see what they have to say. Thanks all.

ger21
02-25-2007, 12:12 AM
FWIW: I tried creating a button that does:

DoButton(22)
SetDRO(0, 0)

which should ref the X axis and then zero it but it only seems to ref the X... the zero is never performed.

I just spent an hour trying to figure out why it doesn't zero, then decided to ask Art on the Yahoo group. Should have an answer in the morning.

ger21
02-25-2007, 09:35 AM
FWIW: I tried creating a button that does:

DoButton(22)
SetDRO(0, 0)

which should ref the X axis and then zero it but it only seems to ref the X... the zero is never performed.


This should work.

DoButton(22)
While ismoving()
Wend
SetDRO(0, 0)


If you update to the latest versions, the codes have changed. For 1.90 and later, you should use

DoOEMbutton(1022)
While ismoving()
Wend
DoOEMbutton(1008)

wildcat
02-25-2007, 02:39 PM
This should work.


Works like a charm- thanks!

thuffner3
03-05-2007, 06:40 PM
Sorry to just jump in. I'm reasonably adept at Rhino. It is my experience that if you view your Rhino grid as your router/mill table and build your models as such. you will generate the proper g-code.
If your Rhino Axis intersection is zero then that's where your generated g-code zero is going to be.

Peace
Neil

sdantonio
03-05-2007, 09:37 PM
Hi Neil,

Thanks for the reply, I was told the same thing from Mitch at McNeel. So I should be all set here.


Sorry to just jump in. I'm reasonably adept at Rhino. It is my experience that if you view your Rhino grid as your router/mill table and build your models as such. you will generate the proper g-code.
If your Rhino Axis intersection is zero then that's where your generated g-code zero is going to be.

Peace
Neil


MitMitch Heynick wrote:
Just a clarification, you are not going to "send" the model to RhinoCAM,
RhinoCAM runs *inside Rhino*, that is the principal advantage. The part for
0 CAM will correspond with the world 0 by default, but you can also create
custom machining planes and origins as you wish by using the Set MCS option
under MOps. You can imagine it's like moving around the model instead of
moving the model itself.

If you have a bilaterally symmetric object, aligning the symmetry axis with
one of the principal axes (X or Y) is generally a good idea from both a
modeling standpoint as well as a CAM standpoint.

stumpy
03-28-2007, 11:59 PM
Problems with offsets I have encoutered also mainly in the x/y axis and I thought it was me more than any thing. I have found that if you put in a edge finder dia it doesnt seem to caluclate it for some reason. The offset page is so confusing,as to which button to push. In my y/x axis it seems to be off the dia of the pin. I also have a problem with the z axis. In the mpg mode if i move it in the - direction its fine but move it + direction it still moves in the - direction. Any answers for this. My next move is to find the edge of the part move it 1/2 the dia of edge finder and call the 0 and see what happens. Glad to know other people are having this problem and hope to solve this some how.
Sonny

wildcat
03-29-2007, 10:39 AM
FWIW: I thought I had mine solved by zeroing the offsets but this past weekend I had the same problem appear. The X axis suddenly offset by the amount that WAS in the x offset before zeroing it. If it was some other value I could believe it was related to my setup but the fact that it matched teh previous value perfectly it is hard to believe there is not a problem with Mach.

HuFlungDung
03-29-2007, 12:14 PM
I do not know by experience how Mach works, but the default on powerup for the machine coordinate system should in fact, be the G53 coordinate system.

When a program is run, then if, as was indicated above, G54 is the default work offset, the offset values present in that particular register should then be applied to the programmed values.

So if you have troubles setting your part zero, I would suggest that you first set Mach to G53 mode before setting the work offsets. You might be able to set Mach by issuing a G53 command in MDI mode.

For safety's sake, always call the work offset in the start lines of your program. Never let the machine assume anything. Tell it what you want.

stumpy
03-29-2007, 09:35 PM
I do not know by experience how Mach works, but the default on powerup for the machine coordinate system should in fact, be the G53 coordinate system.

When a program is run, then if, as was indicated above, G54 is the default work offset, the offset values present in that particular register should then be applied to the programmed values.

So if you have troubles setting your part zero, I would suggest that you first set Mach to G53 mode before setting the work offsets. You might be able to set Mach by issuing a G53 command in MDI mode.

For safety's sake, always call the work offset in the start lines of your program. Never let the machine assume anything. Tell it what you want.

Why would you want to call up a g53 in the command line,when you go to the offset page and set your offset if you are using g54. Could you tell me which button you click on if you are using the lower left corner of the part? I just dont understand why it doesnt take the edge finder amount properly. I'm going to post a picture a picture of the offset so it helps people out.
Sonny

HuFlungDung
03-29-2007, 10:03 PM
G53 is not a work offset. It is the primary coordinate system that is the basis to perform offsets from.

Work offsets have no meaning if they are not relative to the machine's coordinate system. That is all I am saying. For Mach to 'default' to G54 as the primary work offset does not mean that there is not a machine coordinate system. From the symptoms of some of the troubles that are described in this thread, I would wonder if Mach is properly cancelling out of the work offsets when the user is attempting to reset them. If Mach cannot do this automatically, then you should be able to force the right procedure so that offsets are not performed on top of existing offsets.

stumpy
03-29-2007, 10:15 PM
G53 is not a work offset. It is the primary coordinate system that is the basis to perform offsets from.

Work offsets have no meaning if they are not relative to the machine's coordinate system. That is all I am saying. For Mach to 'default' to G54 as the primary work offset does not mean that there is not a machine coordinate system. From the symptoms of some of the troubles that are described in this thread, I would wonder if Mach is properly cancelling out of the work offsets when the user is attempting to reset them. If Mach cannot do this automatically, then you should be able to force the right procedure so that offsets are not performed on top of existing offsets.

Being a machinist and working with Fanuc controllers this puzzles me because I'm doing it the same way as if I would at work. I wished Mach3 would have a seperate page for the work offsets. In other words you have a position page with the position your at that moment then you go to the offset page and insert the postions in on the page. All I know is when I set the offsets then run the program and I know where it should go and it is off not a little amount I'm talking about .125 or more which isnt good. For some reason I'm not able to insert a jpg to show you the offset page and the buttons I'm clicking on to set offset.
Sonny

ger21
03-29-2007, 10:37 PM
If you do a G53 X0 Y0 in MDI mode, you can then reset you're work offsets without getting wierd results.

stumpy
03-29-2007, 10:41 PM
Here is the offset page,as you can see by the arrows those are the button I'm selecting to set the offset. Is this wrong? In the edge finder dia box I put in .125 and then in the right hand corner it shows up .062 which is 1/2 of the edge finder dia. So far that is right but when you run the program it doesnt work properly. However I cant do any thing right now because my Z is not working properly (another problem to resolve:mad: ). In the MPG mode I tell it to go + and it goes - and untill I resolve this dead in the water.
Sonny

stumpy
03-29-2007, 10:45 PM
If you do a G53 X0 Y0 in MDI mode, you can then reset you're work offsets without getting wierd results.
Do you use this command prior to doing your offsets?
Sonny

stumpy
03-29-2007, 10:53 PM
Do you use this command prior to doing your offsets?
Sonny
No I havent because this is the 1st time I heard about this.
Sonny

HuFlungDung
03-29-2007, 11:08 PM
:confused:

HuFlungDung
03-29-2007, 11:08 PM
:confused:

Confused Hu? Me too

:D

:D

stumpy
03-29-2007, 11:15 PM
Confused Hu? Me too

:D

:D
Confused about what? :confused: I didnt know that this had to be done prior to setting offsets. How strange.
Sonny

ger21
03-29-2007, 11:19 PM
It doesn't have to be, but it's an easy way to reset everything. Did you try it? Does it help?

stumpy
03-29-2007, 11:27 PM
It doesn't have to be, but it's an easy way to reset everything. Did you try it? Does it help?

Well like i said in previous post I'm having problems with the Z and until that is resolved I cant do any offset setting because the Z isnt working properly and I havent heard back from Art on how to resolve it. I have a co-worker who is going to help me on this problem but it wont be until Tuesday of next week.
Sonny

stumpy
04-01-2007, 01:30 PM
Hi Steve:
I was having the same problem I believe I would set the g54 offset in the lower left and when I ran the program it was always off in the "Y" axis and off as much as .250. I contacted Art and he didnt understand my problem. So I contacted Brian at New Fangled Soutions and he told me there was a bug in the offset commands. He also told told me that on the offset page to use the "select" button rather than the image of the spindle. Contact me at stumpys@ecis.com and I will send you the file or send you the contact info for Brian.
Sonny

Hi,

I've attached a jpeg to make this easier (I was going to try to just describe the question without pictures.

Given a block attached to to router table top and a project that is approximately symmetrical with respect to the y axis, the position 0,0,0 (home) is typically set at point "1" on the diagram (at least that is my understanding). Is there a problem, or will Mack3 have a stroke, if I want to set 0,0,0 at point 2 on the line of symmetry?

Thanks