[rstbkt]

Trying to cut a part with 4 tool paths. A little glitch happens and I halt the program. I have tried this with the file loaded and after unloading it and get the same results. Using the MDI tab and trying to park the router in a chosen spot, after I enter the x axis and hit enter when x reaches its destination the z axis starts to drive down. It almost looks like the last z command of the file. I halt the z movement and when I try to move the y it gives me an error saying I am missing part of the command. Cant remember how it is stated but it is missing the commands to cut and arc. This is pretty close to what the next command would be after z reaches the point its appears to be moving to.
The file spot drills several holes and then goes back to through drill 4 of them. After the through holes the router moves to safe Z jogs over a tad and starts drilling next to where it should. I have looked at the file and there is no commands telling it to move but the problem or similar problems happen with regularity. I assumed I was skipping steps but watching it, it appears to be an intentional move. The other moves it is changing are of the same type but inches off.

If I were skipping steps after the first run being good and the machine is prepping to move in the positive direction I would expect the moves to be short, not long.
Thanks
Jim

using BobCad V25

Edit: I have to close Mach3 in order to regain control

[mactec54]

rstbkt
It seems your work offsets G54 Etc don't match the part offsets in your program, do you home the machine, then set your work & tool offsets in the control, G54 Etc

You need to post your program, it may help to see what is happening

[rstbkt]

what or who is handlewanker? LOL
I hope this reply was for me. Before I started using my Gecko G540 I was having so much trouble with debounce I disabled my limit switches. After that was a major mod to the gantry and even though re-wiring them was top priority on my list of things to do since getting the G540, getting the new Cad/cam program over-rode that task. I had set the machine and work offsets to the same value. Basically (0,0) of the part. So it looks like I need to finish that up before I can trouble-shoot this issue I'm having. Am I reading that right? Not much of a job to do since most of the wiring is still in place. I just need to re-locate the switches. I still haven't installed Ger's 2010 screenset I purchased 2 weeks ago. I've been concentrating on learning cad/cam program and it was my first one so its been a slow study. Thanks mactec54. I'll get on that tomorrow and see if it makes a difference. Here is the file though.

[mactec54]

rstbkt

That will teach me to check the name, I had just posted using that name & it stayed with this post I have not seen that before

In your program take out all the G53 & any G91.1 for what you are doing the G53 will get you in a lot of trouble,You would change the G53 for a G1 or a G0 depending on what that line of code is doing, A G1 would need some times to have a Feed given, like G1 Z0 F20. Homing your machine & using the G54 offsets in the control for your work X0Y0 is the best way to do it, If you were getting faults with your limit switches, this can be from shielding not being correctly terminated, or some switches pick up noise & make noise as well

The G54 is already in your program, so that part was correct

[rstbkt]

Do you think that I should make the changes from now on? It wont be hard to do. Unfortunately I wont be able to try anything till Saturday with the holiday company. The Gecko has internal shielding/filters so any wiring issues should be solved by the G540. I'll double check my wiring anyway. Thanks for the help. Could you tell me why the G53 and the G 91 would cause the problems. The knowledge would certainly come in handy for the future. I sort of get the G53 because I am setting the machine and part coordinates the same and I am guessing if I kept the two as separate entities this would work and I am guessing the same for G91 if it is referencing from a point that was not calculated properly because I'm not set up correctly. Anyway much appreciated.

[mactec54]

I did not say not to use a G91, but in the header you have a G91.1 you should remove this as it is a made up code, & not a standard, you are not using it so you don't want it in the header

If you want to continue to have problems keep the G53 & you will have problems, there are many ways to use different G-codes Were you have the G53 now you could use a G0 or a G28 In Mach 3 (Home/Soft limits Page ) you can set the G28 to move to a position ( just any were you want each axes to go ) say a tool change or just to move to 0.0

Quite often you may not want the Z axes to go all the way to Z zero, so you can give it a number like G28 Z3. or if not using a G28, you can use a G0 Z3.

;N26 G53 Z0.
;N27 G53 X0. Y0.
N28 M00

Remove all your G53 in the program & just put a G0 , & your program will run as you expected it to

Any shielding for your limits should be grounded at the G540 end only, you ground shields at the source only except for the VFD to Spindle motor, that shield between the spindle motor & the VFD can be grounded at both ends

[rstbkt]

Nope, don't want to continue to have problems. I'll remove and replace as soon as I can.

Any Idea why the Z drives down after entering G0 X0 in the MDI tab. When X reaches 0 the Z starts to drive down and Y will not respond.

[ger21]

G91.1 is not a "made up code". It's tells Mach3 to use Incremental IJ mode. Having it in your g-code prevents the most common error Mach3 users have, the wrong IJ mode.
However, it's important that it's not on the same line as the G90 G91 (G90 in your case).
Here's the reason. There are 4 codes in the same modal group in Mach3:
G90 (absolute distance)
G91 (incremental distance)
G90.1 (absolute IJ mode)
G91.1 (incremental IJ mode)

If more than one of them are on the same line, Mach3 will only read the last one.

So, if, for example, the machine was in incremental mode (G91) prior to loading your g-code, it would stay in incremental g-code even though your program is calling for absolute with your G90, because the G91.1 following the G90 renders it invalid.

Bottom, line, is that you should keep both the G90 and G91.1, but the G91.1 must be on different lines.

[mactec54]

rstbkt

In years of using different controls, I never use MDI for doing axes moves, MDI is never safe, ( Because it is uncontrolled ) but it should not be doing what it is in your case without the Z axes move being put in the MDI

Once you get used to your machine & programming, then you could revisit the G53 & get to see how it works as it can be very useful, it also can cause more trouble than it is worth

The G53 takes absolute coordinates in any axes to reference with machine zero, rather than part Zero, it is non modal & works in absolute only, so when this is used & you are using G54 offsets, the G54 offsets (work Zero) are not used by the G53, so this can put the start position for the next operation in the wrong place, unless it was in the program to move to the correct point in the program, it will stay at the G53 position & start the operation, oops wrong crash

[mactec54]

ger21

G91.1 is a made up code, it is not a industrial standard, & never will be, It also should not be used in the Header line is why I said for rstbkt to remove it

It is also not needed in Mach if you program correctly

[mmoe]

rstbkt

In years of using different controls, I never use MDI for doing axes moves, MDI is never safe, ( Because it is uncontrolled ) but it should not be doing what it is in your case without the Z axes move being put in the MDI

Once you get used to your machine & programming, then you could revisit the G53 & get to see how it works as it can be very useful, it also can cause more trouble than it is worth

The G53 takes absolute coordinates in any axes to reference with machine zero, rather than part Zero, it is non modal & works in absolute only, so when this is used & you are using G54 offsets, the G54 offsets (work Zero) are not used by the G53, so this can put the start position for the next operation in the wrong place, unless it was in the program to move to the correct point in the program, it will stay at the G53 position & start the operation, oops wrong crash

How is MDI any different than running a program? It's perfectly safe, but requires some knowledge of your machine and very basic G code. Personally, I've used MDI on every machine I've owned over the better part of 15 years. If I want to jog the machine to X500 Y400, I can type that in and be there faster than any other way using MDI.

G53 should also be used, IMHO. Typically, when using CAM software, any move after a move to machine coordinate X0Y0Z0 would be made by a specific XY coordinate right away, so it would start up right where it needs to. If the machine is homed with Z0 at the top of the Z stroke, G53 insures that the maximum Z height is achieved, which provides the greatest protection from collisions. Including it for a move to machine zero at the beginning of the program, at toolchanges and at the end of the program will not have any effect on the program, but it does have benefits in making the move safer.

Here's a pair of post processors (inch and metric) that should work well for a generic Mach 3 machine:

[ger21]

ger21

G91.1 is a made up code, it is not a industrial standard, & never will be, It also should not be used in the Header line is why I said for rstbkt to remove it

It is also not needed in Mach if you program correctly

I disagree with both statements.
It definitely should be in the header, as long as you follow the rule I mentioned above.
And technically you don't need any of the header codes, G91.1 is just as important as any of the others. Whether it's needed or not has nothing to do with it. If the machine is not currently in the mode you expect to be in , than it's 100% needed.

[mmoe]

ger21

G91.1 is a made up code, it is not a industrial standard, & never will be, It also should not be used in the Header line is why I said for rstbkt to remove it

It is also not needed in Mach if you program correctly

Whether G91.1 is an industry standard or not, it's a Mach 3 standard and is no less valid that the other variations to G code that nearly every controller on the market possesses. It's not just a "made up" code, it's a specific function that Mach 3 understands which allows for the controller to be configured in more than one IJK method and switched between them as desired via these G codes. If other controllers offered that feature, how would they provide access to it? They would also have to have "made up" codes that provide that functionality, and perhaps they would have used the same as Mach 3. G91.1 and G90.1 should be used so as to be certain that the controller is set to match the method that the CAM system has used to program the arcs. It does not hurt to have it there, and in the off chance that the machine has been set to G90.1, having G91.1 in the first lines will set it to match the program. The question is, is there any reason NOT to have it there, and the answer is no.

It is not incorrect to program in G91.1 in some instances and potentially G90.1 in others, so it's not a question of programming correctly. What is correct will vary depending on the specific needs of the job or the preferences of the programmer. G91.1 is what I'd consider the standard method, but I wouldn't be surprised to hear that there are some who prefer G90.1.

[mactec54]

mmoe

The thing is with this G91.1 Etc is it is not even needed for Mach to do the same function correctly, so if you want to use this program, in a different control you will have a problem

If Mach config is set up correct, it is not needed in a program, you just use a G90 or G91 & Mach works perfect with this, this way your programs will work on other controls without any change, & you only need one post processor, if you have a cam system, or you would need a special post processor, to add this special made up code that is not needed to run in Mach

[mmoe]

G90 and G91 do not have anything to do with G90.1 and G91.1, so I'm not sure what you are trying to say. Mach will work perfect without G91.1 if the controller is set to incremental IJK and the CAM is outputting incremental IJK. If the controller is set to absolute IJK and the CAM system is set to incremental IJK, you'll have problems. Including G91.1 eliminates the possibility of having those problems. Mach can also function in G91.1 while in G90 mode, or it can function in G90.1 while in G90 mode. It can also function in G90.1 while in G91 mode and G90.1 while in G90 mode. Right there are 4 possible combinations of incremental/absolute modes for both positioning and IJK. If you don't tell Mach which it is, it will default to whatever it is currently set to and that may not be what is needed. I do believe that the vast majority probably keep Mach set to G91.1, and in most cases it would not be an issue, but there is always the possibility that it gets changed and including G91.1 or G90.1 will prevent it from ever being an issue.

Anyone who is using Bobcad and operates two machines with different controllers would just run a second post for any second machine they have. It only takes moments to do so and the file would be customized to the second machine, as it should be. This is why Bobcad has the CAM tree (as well as most other CAM systems). Selecting a different post processor and saving a modified version of the program is not a big deal at all and ensures the greatest possibility that there won't be a problem.

Even if you use entirely standardized G-code (no G91.1), the likelihood that any two machines with two different controllers are going to read the code the same way is not high because it's not only the G-code that is needed, but the formatting and the M codes which are machine specific. My Num 750 controller (previous machine, but let's pretend I still have it) would not be able to tool change based on the code that my Mach 3 controller uses, nor would it be able to toolchange based on standard toolchanging code because it used an advance tool call. Any toolchange made needed to be the next tool, not the currently needed tool. Even if that weren't a problem, it also needed a different spindle start command which had to alternate depending on which head was currently in use. It also used M50 as the spindle stop command, and would not recognize M5.

In fact, my current machine would not be able to read the Mach 3 programs that it's new controller uses if I still had the original controller installed because Mach 3 works differently than the PLC controlled tool changes that were previously done on the same machine. In other words, two different controllers on the exact same machine would require two different programs even though the physical machine is identical. These sort of machine specific differences are present in the vast majority of CNC equipment and it would be unlikely that you could use "industry standard" G-code and just put it in the next machine. M codes and formatting are where the problems would arise and it just makes more sense to output a machine specific program given that it takes about 20 seconds to generate another one.

[mactec54]

mmoe

I have 5 different controls in one of my shops, & the same programs will run on any of the 5 machines with no changes to the programs

All I can say is lean how to program, & you don't need to use these codes in Mach, I know what the G91.1 is used for but is not needed, if you know what you are doing

If you program in absolute (most do Should) then you set everything up to work in absolute there is never a need to do I & J any different, once set you are done
G90 for absolute machining G91 when incremental machining, there is not much to it, why make it more cumbersome than it has to be

[rstbkt]

Don't you guys think for a minute I ran away from all this. I'm trying to absorb all of it. Right now its like water on a ducks back. But I'm learning something here.

[mactec54]

I disagree with both statements.
It definitely should be in the header, as long as you follow the rule I mentioned above.
And technically you don't need any of the header codes, G91.1 is just as important as any of the others. Whether it's needed or not has nothing to do with it. If the machine is not currently in the mode you expect to be in , than it's 100% needed.

In rstbkt program it has been programmed in absolute, so what is in the header is incorrect, & yes he does not need a lot of the other codes in the header as well but the G91.1 stood out

No absolute or incremental call should be in a header at any time, it should only be in the program were it is being used

[mmoe]

In rstbkt program it has been programmed in absolute, so what is in the header is incorrect, & yes he does not need a lot of the other codes in the header as well but the G91.1 stood out

No absolute or incremental call should be in a header at any time, it should only be in the program were it is being used

I'm still not following what you are trying to say. His program is in absolute coordinates mode, but not absolute IJK mode. The header is perfectly correct other than that you can't have G90 and G91.1 on the same line for formatting reasons which have nothing to do with the file being in absolute. G90 and G91.1 will remain active at the same time as they need to be for this program if they are called out on two separate lines.

If you change the G91.1 to G90.1, which would be absolute IJK, you get a completely different (incorrect) result. The controller could potentially be setup to default to G90.1, so if the CAM software is set to output incremental IJK, it is absolutely critical that G91.1 is called out. Here's a image of the program in G91.1 (as it should be):




And here is the same program with the controller set to G90.1 without calling G91.1:




If the program had included G91.1 at the beginning of the file, it would have come out right even though the controller was set to do the opposite. This is why I feel it's not worth the risk to exclude it. While in the perfect world, you may want to be able to take the same program from machine to machine, I doubt that the OP has any need for that, but as a beginner to CNC is much more likely to have an issue with accidentally programming in the incorrect IJK mode for the controller's settings. It's a fail-safe of sorts, and if the only downside is that you might not be able to run the program with that one code in it on another machine, I'm not seeing what the problem really is. Whatever machine that is would tell you the error, and it would take 10 seconds to modify the code out of the header. I think it's much more likely that the machines would differ by far more than that one code.

[mactec54]

Here's a image of the program in G91.1 (as it should be):
If the program had included G91.1 at the beginning of the file, it would have come out right even though the controller was set to do the opposite.

a beginner to CNC is much more likely to have an issue with accidentally programming in the incorrect IJK mode for the controller's settings.

When you are programming if the post processor it set for incremental output that's what you are going to get, if it is set for absolute that is what you are going to get, there is not accident about it, it is either one or the other, which you still don't need, the made up codes G91.1 or G90.1 to make it work, it will run just fine without theses codes, Read the Mach Manual

It's very strange that you have to use this made up code G91.1 & G90.1, to get the program to run correct

When I just ran the same program without the G91.1 just as the program is, & it ran through correctly, which tells you, it is not needed to get the correct cut part, I ran 2 other programs as well with lost's of I&Js without a hesitation which correctly cut the parts