G Code Variances from machine to machine?

[Miguel Gonzalez]

Hello everyone, this is my first post on CNC Zone. I'm happy to see there is a resource such as this on the internet!

Bare with me as I am new to G-Code programming, but I have recently tried to connect my company's plasma table (a TITAN by MG Industries with a Hypertherm Navigator controller from about 10 years ago) to a new computer which runs our new Hydrajet water cutting system. The old plasma table keeps giving me error messages every time I try to download a CNC script created with the software I am now using with the Waterjet system (IGEMS for those familiar with it). The code produced by the old software we used previously (SDS 5.6) works fine on the plasma table, and I have compared print-outs of the code produced by the SDS software and that produced by the IGEMS software and I've noticed some differences in the way they write their code.

Are these slight differences the reason the old machine wont download the programs properly? Is there anything I can do to enable the old machine to read the script from the new software, or to make the software write the code in the same manner as the old software did?

Please keep in mind I know next to nothing about CNC programming - I'm taking it upon myself to teach myself how it works and needless to say its a bit of a rocky road!

[gar]

070301-2000 EST USA

Miguel:

I know nothing about the machines you refer to. Thus, your questions are not clear to me.

It appears that you have two computers, or you have disposed of an older computer. How did or does the old or new computer communicate with the machine that you download to? Are you using RS232 for this download communication path? If so what are the details on cable wiring, all parameter settings, and kind of RS232 port?

If not RS232 what is the communication path for the download?

.

[Genguy]

In addition to the port configuration and wiring differences that Gar has mentioned, there are likely differences in the gcode as well. Some machines require a % sign to signal the start and end of a program, some do not recognize LF (line feed) or CR (carriage return) statements. The gcode itself will have slight differences for each machine and manufacture's control. Many gcodes are industry standard but some of them are reserved for custom use and some others may have different uses between a mill or a lathe for example. Some gcodes may not work at all because that particular machine does not have that option installed or enabled. All of these items can cause an error when sending a program.
You really need to use the programming manual for that machine's control to know the function of each gcode for sure. If you are writing code by hand, then you need to learn each one as you go until you are familiar with each function. If you use a CAM program, then there is a "post processor" that translates the standard output of the software to the specific codes that the individual machine requires. In that case a different post processor will need to be used for each machine.

[Miguel Gonzalez]

Originally Posted by gar 070301-2000 EST USA Miguel: I know nothing about the machines you refer to. Thus, your questions are not clear to me. It appears that you have two computers, or you have disposed of an older computer. How did or does the old or new computer communicate with the machine that you download to? Are you using RS232 for this download communication path? If so what are the details on cable wiring, all parameter settings, and kind of RS232 port? If not RS232 what is the communication path for the download? .

That is correct - we have two computers, but we have not disposed of the older one yet until we get the new one communicating properly.

For the communication device we are using an RS232 Fiber Optic line driver and utilize the PhoenixLink software provided by Messer Industries. It is connected through Com Port 1 with a baud rate of 9600. The communication between the computer and the plasma machine work fine - but once the files are retrieved they cannot be read properly and I always get an error message.

[Miguel Gonzalez]

Originally Posted by Genguy In addition to the port configuration and wiring differences that Gar has mentioned, there are likely differences in the gcode as well. Some machines require a % sign to signal the start and end of a program, some do not recognize LF (line feed) or CR (carriage return) statements. The gcode itself will have slight differences for each machine and manufacture's control. Many gcodes are industry standard but some of them are reserved for custom use and some others may have different uses between a mill or a lathe for example. Some gcodes may not work at all because that particular machine does not have that option installed or enabled. All of these items can cause an error when sending a program. You really need to use the programming manual for that machine's control to know the function of each gcode for sure. If you are writing code by hand, then you need to learn each one as you go until you are familiar with each function. If you use a CAM program, then there is a "post processor" that translates the standard output of the software to the specific codes that the individual machine requires. In that case a different post processor will need to be used for each machine.

I see what you mean - I have looked through some of the software's settings and noticed it had two post-processors which can be loaded. One of them was made by the waterjet's manufacturers and is specific for that machine, and then it has a "standard" setting for all other machines. The "standard" setting still dosent work for the old plasma table, and the old postprocessor I used for the plasma table is written on a different file extension (the new postprocessor extensions are .lua files where as the old post processor seems to be a 3 different files - two for plasma, one for oxy - that were put into a folder within the old CAM software package).

So it seems to me like I have to talk to either the manufacturer of the machine, the controller or the software and see if I can get the postprocessor for this machine in a .lua extension?

[gar]

070302-1948 EST USA

Miguel Gonzalez:

I still lack an understanding of the problem.

I believe you are implying that an old computer communicated successfully with your Titan machine. And that was done with your mentioned fiber link. Also this still works. You have old software and new software, and somehow you can look at the output from the two different program sources, and they are not the same.

Can you put the old program created into a file rather than sending it directly to the Titan machine? I assume you can. Do that, then in the old computer send that file to the Titan with some communication program that alters nothing in the file. Does that load into the Titan successfully? Is so, then put a copy of that file on the new computer, make the connections, and then send that file to the Titan. Does this work?

.

[Al_The_Man]

I think it is a Genguy mentioned, a program format problem rather than RS232 transmission problem, unfortunately if you do not have a post-processor for the machine in question, you may have to convert the files manually in a word processor.
Al.

[Miguel Gonzalez]

Originally Posted by gar 070302-1948 EST USA Miguel Gonzalez: I still lack an understanding of the problem. I believe you are implying that an old computer communicated successfully with your Titan machine. And that was done with your mentioned fiber link. Also this still works. You have old software and new software, and somehow you can look at the output from the two different program sources, and they are not the same. Can you put the old program created into a file rather than sending it directly to the Titan machine? I assume you can. Do that, then in the old computer send that file to the Titan with some communication program that alters nothing in the file. Does that load into the Titan successfully? Is so, then put a copy of that file on the new computer, make the connections, and then send that file to the Titan. Does this work? .

Yes, we have two computer stations, basically. One has the old software which outputs G Code which works with the Titan plasma. The new computer uses new software which outputs a variation of the G Code. I can look at the G Code by opening the .txt files created by each program and then compare the two for differences.

Here is an example of the G Code produced by the old software:

%
P12019012
G70
G91
G40
G00X2.220Y-2.464
M19
M20
G01X-0Y0.652
G03X0.030Y0.001I0.030J-0.688
M21
G00X0.030Y1.811
M20
G01X-0Y-0.220
G02X-0.042Y0I-0.030J-2.280
G01X0.080Y0.080
M21
M19
M30

Here is an example of the G Code produced by the new software:


%MAIN PROGRAM:101
(DATE:03/02/07 13:43:07
(MATERIAL:Steel)
(THICKNESS:0.2)
N10 MAIN-ZERO:X0.0 Y0.0
N11 ACTIVE-TOOLS:1

N12 TEMPORARY-ZERO:X0.3 Y0.5
N13 CALL-SUBROUTINE:1 (CUTTING NR:1 NAME:test101)

N14 END-PROGRAM

N15 DEFINE-SUBROUTINE:1 (CUTTING NAME:test101)
N16 G0 X3.0 Y4.0
N17 T3 (QUALITY:3)
N18 G0 Z0
N19 M4 (PIERCING TYPE 2)
N20 G4 F5.00
N21 G1 F39 G41 X3.0 Y4.5
N22 G3 X3.0 Y1.5 I3.0 J3.0
N23 G3 X3.0 Y4.5 I3.0 J3.0
N24 M5
N25 G40
N26 G0 Z3.9
N27 G0 X-0.0 Y-0.5
N28 T3 (QUALITY:3)
N29 G0 Z0
N30 M4 (PIERCING TYPE 2)
N31 G4 F5.00
N32 G1 F39 G41 X-0.0 Y-0.0
N33 G1 X-0.0 Y6.0
N34 G1 X6.0 Y6.0
N35 G1 X6.0 Y-0.0
N36 G1 X-0.0 Y-0.0
N37 G1 X-0.3 Y-0.0
N38 M5
N39 G40
N40 G0 Z3.9
%


As you can see there are some differences in the way the code is written, specifically near the beginning. The plasma gives me an error message saying Incorrect M Code.

The files are transmitted fine, it is the reading of them that seems to be a problem.

[gar]

070305-1559 EST USA

Miguel:

I have not closely looked at your two programs, but here are gross differences.

%MAIN etc may be a severe problem and may be the cause of Incorrect M code.

The two programs do not look like the same part, but I have not looked closely.

No right paren on the date time line comment may be a problem.

The program structure of the second program is quite different than the first. Thus, it is not going to work.

Your problem is probably not new computer vs old computer, but different software intended for different CNCs.

Can you run the old software on the new machine, and if not, why not?

.

[Miguel Gonzalez]

Originally Posted by gar 070305-1559 EST USA Miguel: I have not closely looked at your two programs, but here are gross differences. %MAIN etc may be a severe problem and may be the cause of Incorrect M code.

I noticed this main difference as well, so I manually edited out the %MAIN but I continued to get error messages from other sources. I am not trained in coding G Code manually though, thus why I brought it here.

Originally Posted by gar 070305-1559 EST USA The two programs do not look like the same part, but I have not looked closely. No right paren on the date time line comment may be a problem.

That is correct, they are not the same part. I only posted them up for illustrative purposes of the differences in the parameters used by the two different programs in writing the script.

Originally Posted by gar 070305-1559 EST USA The program structure of the second program is quite different than the first. Thus, it is not going to work. Your problem is probably not new computer vs old computer, but different software intended for different CNCs. Can you run the old software on the new machine, and if not, why not? .

The old software runs off the DOS platform and we no longer have working installation disks for that particular software. Renewing our service contract with the company that created the old software would be quite expensive and is not something we would favor since we had some very serious problems with the stability of their software after they switched to a Windows enviroment for their CNC programs. It was so bad we reverted back to their DOS program because their Windows program did not work at all. The new software package we have aquired with the new computer (and a different company) is excellent, except it only works with our Waterjet and gets error messages on our Plasma. Ideally we would like to get both our machines working off the same platform and off a single computer station.

[gar]

070306-1051 EST USA

Miguel:

It does not help you much to compare two different parts on two different software packages.

You probably can not drop the first %. I would say it is a necessity that a first % exist. The problem is that your old CNC interprets the M of MAIN as an M code and no number is associated with M.

Generally DOS programs are reliable.

Your first G-code sample is relatively standard.

On-line you can download the HAAS mill manual from
http://www.haascnc.com/customer_serv...mc/96-8000.pdf

A generic postprocessor directed at Fanuc might produce code close to what you want.

You can manually write your own G-code program.

The P-line just after the first % is probably the program name. May or may not be required. In a HAAS or Fanuc program this would be an O-number.

Study the HAAS manual as that may help you understand the normal G-codes. And program structure.

.

[Miguel Gonzalez]

Originally Posted by gar 070306-1051 EST USA Miguel: It does not help you much to compare two different parts on two different softtware packages. You probably can not drop the first %. I would say it is a necessity that a first % exist. The problem is that your old CNC interprets the M of MAIN as an M code and no number is associated with M. Generally DOS programs are reliable. Your first G-code sample is relatively standard. On-line you can download the HAAS mill manual from http://www.haascnc.com/customer_serv...mc/96-8000.pdf A generic postprocessor directed at Fanuc might produce code close to what you want. You can manually write your own G-code program. The P-line just after the first % is probably the program name. May or may not be required. In a HAAS or Fanuc program this would be an O-number. Study the HAAS manual as that may help you understand the normal G-codes. And program structure. .

I went ahead and created a simple part on both machines to produce the script for both. It is a 6" x 6" square with a 3" diameter circle in the center.

Listed first is the code from the old software & system:

%
P03020701
G70
G91
G40
G00X3.250Y-2.000
M19
M20
G41
G01X-0Y0.500
G03X0Y0I0J-1.500
M21
G40
G00X-3.000Y-5.000
M20
G41
G01X-0Y0.500
X0Y6.000
X6.000Y0
X0Y-6.000
X-6.000Y0
X-0.250Y0
M21
M19
M30

Listed below now is the code from the new software & system:

%
(DRWlasma101)
(MTR:Steel)
(THK:6.35)
(HPR:52000 BAR)
(ABR
(ABG:1 G/MIN)
(ORF:0.01)
(TUB:0.04)
G90
G97
G71
(T:1)
(C:Vertical Connector NO:1)
G00 X118.612 Y-81.917
M4 (TYPE:1)
M245
G41
G01 X120.644 Y-81.881 F281
G01 X120.644 Y-81.881
G03 X44.456 Y-83.219 I82.55 J-82.55 F319
G03 X120.604 Y-84.42 I82.55 J-82.55
M246
M3
G04 F0.5
G40
G00 X0. Y-6.35
M4 (TYPE:2)
M245
G04 F6.
G41
G01 X6.35 Y-6.35 F281
G01 X6.35 Y-6.35 F281
G01 X8.89 Y-6.35
G01 X11.43 Y-6.35 F365
G01 X13.97 Y-6.35 F449
G01 X151.13 Y-6.35 F534
G01 X153.67 Y-6.35 F449
G01 X156.21 Y-6.35 F365
G01 X158.75 Y-6.35 F281
G01 X158.75 Y-8.89
G01 X158.75 Y-11.43 F365
G01 X158.75 Y-13.97 F449
G01 X158.75 Y-151.13 F534
G01 X158.75 Y-153.67 F449
G01 X158.751 Y-156.21 F365
G01 X158.751 Y-158.75 F281
G01 X156.211 Y-158.75
G01 X153.671 Y-158.75 F365
G01 X151.131 Y-158.75 F449
G01 X13.97 Y-158.75 F534
G01 X11.43 Y-158.75 F449
G01 X8.89 Y-158.75 F365
G01 X6.35 Y-158.75 F281
G01 X6.35 Y-156.21
G01 X6.35 Y-153.67 F365
G01 X6.35 Y-151.13 F449
G01 X6.35 Y-13.97 F534
G01 X6.35 Y-11.43 F449
G01 X6.35 Y-8.89 F365
G01 X6.35 Y-6.35 F281
G01 X6.35 Y-6.35
G01 X6.35 Y-0.
M246
M3
G04 F0.5
G40
M30

In this instance, I receive an error on the line I put in bold, saying the Radius at Arc beginning and Radius at the End are not within the Arc Radial Error Tolerance: F319.

So its still not writing the code correctly, basically. There are similarities but there are some strong differences as well that are sufficient to make this not able to be interpreted correctly by the controller.

I am going to read that manual you linked. Thank you for that piece of information. I think the main problem from all the research I've done is the post processor is not writing the code in a way the controller can understand. I have tried to find a post processor file which will work with our new CAM software and the controller, but the new CAM software we use is based on the .LUA programming language which is very new, so there arent very many resources available. I wonder if I can somehow plug one of those generic post processors into the CAM software we are using and fall back on that - something I will have to try.