[sdantonio]

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]

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!

Mike

[JFettig]

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

[kentavv]

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]

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]

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?

[kentavv]

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.

[kentavv]

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?

[kentavv]

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]

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?

[kentavv]

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]

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]

I'll kick the question out to the rhino users group that mcneel sponsors and see what they have to say. Thanks all.

[ger21]

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]

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)

[kentavv]

This should work.

Works like a charm- thanks!

[thuffner3]

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]

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]

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

[kentavv]

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.