[SCzEngrgGroup]

Tom,

I'm wondering if M30 behavior is correct/has changed. I was recently running a program using G55. When M30 is executed, it appears it executes a G54. I'm surprised I never got bit by this before. Has it always been this way? Is this really correct?

Regards,
Ray L.

[mactec54]

SCzEngrgGroup

It's most likely nothing to do with the M30 program rewind, when this happens it is defaulting to the machine control which is normally G54, If your first call in your program is G55 then that is what it will change to as soon as it sees it, you may have the G55 placed wrong in your program if you are having a problem with it

You can have any number of work offsets in your program M30 does not have anything to do with using offsets

[SCzEngrgGroup]

I didn't have a G55 in the program, I just set it manually, then ran the program. The program itself contained no fixture changes at all. I've done this before, though perhaps not recently, and don't recall ever seeing this behavior. If I put the G55 in the program it works fine.

Regards,
Ray L.

[bhurts]

I had the same issue with m30 and m2 clearing offsets to default at g54. I asked Tom about it and he gave me a patch to keep m30 from canceling offsets. Look on the dynomotion Yahoo group and look for the thread titled "Scary but harmless" and it should tell you where to find the patch.

Ben

[mactec54]

I didn't have a G55 in the program, I just set it manually, then ran the program. The program itself contained no fixture changes at all. I've done this before, though perhaps not recently, and don't recall ever seeing this behavior. If I put the G55 in the program it works fine.

Yes what offset you are using should always be called in the program, looks like problem solved

[mactec54]

I had the same issue with m30 and m2 clearing offsets to default at g54. I asked Tom about it and he gave me a patch to keep m30 from canceling offsets. Look on the dynomotion Yahoo group and look for the thread titled "Scary but harmless" and it should tell you where to find the patch.

M30 & M2 do not clear offsets, the control always should default to G54, work offsets should always be called in a program, a patch or work around is a bad thing to have in place, shame on dyomotion for doing a work around (patch), as they had it setup correct to start with

[bhurts]

Really I must disagree. When I say cleared offsets I mean reverts to g54 Not change any offset values. I don't know your background but I know mine. I have never seen a control revert to g-54. I have seen them revert to g-53. If Hass doesn't clear work offsets at m30 then having the option in dynomotion makes since.

Ben

[mactec54]

Really I must disagree. When I say cleared offsets I mean reverts to g54 Not change any offset values. I have never seen a control revert to g-54. I have seen them revert to g-53. If Hass doesn't clear work offsets at m30 then having the option in dynomotion makes since.

Reverts to G54, That's what the control should do, nobody is saying that it clears what is in the offset, for the given offset call

A Haas control default is G54, & will stay there until you call a different offset in your program, (G55,G56,G57 Etc,When you turn your machine on Power up it will be in G54,

G53 is a totally different action when it is being used, but it to has to be written in the program for it to be used, it does not just happen by it's self

[bhurts]

I understand how offsets are called. The point is g54 is a fixture offset like the rest and reverting to it at the end of a program would serve no purpose. You can call another offset at anytime at the beginning or during a program so starting at g54 is in no way safer. All m30 does is call program end and restart. Also you can call work offsets from mdi where no program end is required. Is this unsafe since it doesn't change to g-54 before you run a program? The only thing unsafe I can think of when running any cnc machine is hitting the start button when you don't know exactly what's going to happen.

Ben

[mactec54]

I understand how offsets are called. The point is g54 is a fixture offset like the rest and reverting to it at the end of a program would serve no purpose.

You are saying some of what I have already said.

M30 is Program rewind, I already said this in the first post,

As for the control reverting back to a G54, It will only do so if you don't have anything different in your program, It does not just go to the machine Default for no reason, if your program does not have say a G55 ( or anything at all regarding the offset) in the start of your program then the control will Default to G54 or what ever offset you have in your program

This has nothing to do with the End of the Program, it's what you have at the beginning of the Program that the machine control is looking at

Ray fixed his problem by putting the G55 in his program were it should of been

If you don't tell the control what you want it to do, then it will do what is in the control Default, if you crash, because of this, don't blame the machine, Blame yourself for not writing the program correct

You can stop this happening by just programming correct to start with, it's as simple as that

[TomKerekes]

Hi Ray,

I'm not sure of the "correct" behavior. The original NIST code has various references stating that M30 should reset to Fixture #1 (G54). I don't think there is really any standard behavior.

But we have received numerous complaints about this as being scary and confusing. So in Version V4.31j and later we changed M30 to not reset the fixture number and left M2 still resetting it. See this Yahoo Post

But I think the best approach is to always explicitly set the fixture to be used in your code. Following that approach none of this matters.

Regards
TK

[bhurts]

I think I have misunderstood some of what you are saying and you likewise misunderstood my first post. In dynomotion when you call m30 at the end of a program the control would switch to g54. The reason this was a problem is begat of how k-motion buffers its commands. I have my look ahead set at 10 seconds. When the control read the m30 it would show the dro in g54 coordinates for the last 10 seconds of the program. When you look up and the dro says your where you know you shouldn't be it scares the crap out of you. The program still executes correctly but the dro has already started showing g-54 coordinates while its still running another work offset. All Tom did was change m30 so it remains in the current offset when the program ends. It in no way effects how the control reacts when running another program. The control still defaults to g-54 if no offset is called in a program. The real issue I had with your post was you calling shame on dynomotion and Tom when you misunderstood what the patch was for. You have a lot of posts on here and your opinion holds weight. I have always respected your opinions. I just don't want them to reflect badly on a great product and programmer over a misunderstanding.

Ben

[mactec54]

bhurts

The problem you were seeing, is not what Ray had, he had not programed the G55 into his program, so it went to a G54 offset the control Default

As what I said I stand by it, I'm aware they have a great product, but if they change how the control works, & it is not to a standard, then that is not a good thing to do, If they did have a real problem, then yes they need to put it right, But they should not be making changes that are not needed

[mactec54]

But I think the best approach is to always explicitly set the fixture to be used in your code. Following that approach none of this matters.

This is what I have been saying in all the posts, you always should have the offset you are using in your program

[dertsap]

most cnc's will hold what ever offset is called and it will stay modal until another offset is called , which is to say that m30 can come up all day long and the offset (g54-g5#@) will not change . But there are a lot of professional cnc's which will default back to g54 once m30 is reached , or the reset is hit or what have you . Many times it can be changed in the machine parameters .
Bottom line is to get in the habit of always having the offset call after each tool call , it's simply the proper and professional way of doing things

[bhurts]

Mactec54

Have you read Toms comments in posts #11. Also did you follow his link to the Yahoo post that was the reason for this "workaround". Make sure you hit the see all messages on this subject button at the end of the linked post. You will see that everything we discussed here was gone over there in depth. You will also see how hard Tom works to make his product as user friendly and safe as possible. You will also see that everything you said in post #6 is incorrect.

Quote
M30 & M2 do not clear offsets, the control always should default to G54, work offsets should always be called in a program, a patch or work around is a bad thing to have in place, shame on dyomotion for doing a work around (patch), as they had it setup correct to start with.

M30 and M2 did indeed clear fixture offsets.

Ben

[mactec54]

bhurts
There is some misunderstanding as to what was happening for it to be changed, but it was not what you stated in your posts, if you read post 13 it gives you all you need to know, I'm not sure why you keep changing the story

Indeed if M30 & M2 did actually clear the fixture offsets, then this did need to be fixed,(Not just a Patch) because these are two totally different things, that should not be connected in anyway

But this does not change the fact that the problem that Ray had,(Post #1) was because he did not have the work offset in the program in use, once he put it in the program all was good

[SCzEngrgGroup]

Hi Ray,

I'm not sure of the "correct" behavior. The original NIST code has various references stating that M30 should reset to Fixture #1 (G54). I don't think there is really any standard behavior.

But we have received numerous complaints about this as being scary and confusing. So in Version V4.31j and later we changed M30 to not reset the fixture number and left M2 still resetting it. See this Yahoo Post

But I think the best approach is to always explicitly set the fixture to be used in your code. Following that approach none of this matters.

Regards
TK

Tom,

Yes, I've concluded that, as with so many things in the world of G-code, the exact functionality of M30 is really not at all standardized. I did find a document on EMC or LinuxCNC which seemed to indicate they did revert to G54 on an M30. But some other controls do not, and I'm 99% certain Mach3 does not, as I used to run the same program multiple times in other fixtures and never had this happen. I'm just surprised I never got bit by it before now.

Personally, I think it is odd to revert to G54 on an M30, so I'm happy to hear you've changed it. M30 started out as a "rewind" when the program was stored on paper tape, so I'm not sure I even see the logic of having it monkey with fixtures.

Thanks!

Regards,
Ray L.