[MitchB]

I thought this would be easy, but apparently not. I am using Mach4 with a Taig mill with inch units. When I use either the Mach4-IN or Mach4-Inch post processors, the g-code includes the code Q0.1. This seems to stop the g-code from running. I couldn't find information about this code. Any advice? If it's any help, below is the generated g-code.

G00 G49 G40 G17 G80 G50 G90
G20 G64
(Countersink)
M6 T170
M03 S2000
G00 Z0.1000
X0.1645 Y-0.1645
G82 X0.1645 Y-0.1645 Z-0.1524 R0.1000 Q0.1 F5.0
G80
G00 Z0.1000
X2.9939
G82 X2.9939 Y-0.1645 Z-0.1524 R0.1000 Q0.1 F5.0
G80
G00 Z0.1000
Y-1.3355
G82 X2.9939 Y-1.3355 Z-0.1524 R0.1000 Q0.1 F5.0
G80
G00 Z0.1000
X0.1645
G82 X0.1645 Y-1.3355 Z-0.1524 R0.1000 Q0.1 F5.0
G80
G00 Z0.1000
M5 M9
M30

[joeavaerage]

Hi,
I use Mach4 and have done for nine years.

N00160 G82 X-51.6500 Y42.6000 Z-2.5000 F300   R2.0000  P0.100000
N00170  X-8.4500 Y42.5500 
N00180  X-30.0000 Y4.9500  
N00190 M05

This code works. Note that there is no 'Q' word in it, but there is an 'P' word in it.

Note also that G82 is modal, so the two lines N170 and N180 mean that two extra holes are drilled at -8.45,42.55 and -30,4.95 respectively with the same Z,F,R and P parameters. Note also this is mm units.

I think you post is wrong, it should produce a 'P' word but is mistakenly producing a 'Q' word. Sounds like you need to edit the post.

Craig

[MitchB]

The most obvious difference is that yours has line numbers. Can you tell me what post processor produces that? Is it Mach4-MM? Thanks.

[joeavaerage]

Hi,
if you strip the line numbers off the code still runs, so line numbers have nothing to do with it.
This particular piece of code is generated for drilling circuit boards, a UserLanguageProgram as part of EAGLE, a circuit board program.

The real difference is that your code has a Q rather than a P. Try editing the code (by hand) to replace all Q's with P's and then see if it runs.

If it does run, and I suspect it will, then either edit each Gcode file Rhinocam produces OR edit the post.

Craig

[MitchB]

I appreciate the suggestions and agree that they will solve the immediate issue of getting the code to run. But there are many out of the box post processors and I'd just like to find the one that will work consistently.

[joeavaerage]

Hi,
not likely to happen.

Even with the best will in the world those people whom write posts seldom get it absolutely perfect, after all they write CAM software, they did not design and build the CNC machine or the software that drives it and yet that intimate knowledge
is just EXACTLY what is required in order to write a perfect functioning post.

Often times you have to tweak a post, in this case when it generates the Gcode for a G82 you want it to write 'P' instead of 'Q'. If you can find it then it will be a one keystroke edit and thereafter it will work perfectly.
Other examples are where a post is five axis, but most people have three axis machines. The manufacturer of the post will often write a five axis post but only 'turn three on'. If you want a fourth and/or a fifth axis you have
to edit the post to turn those features back on.

Email Rhinocam and ask where you can change the Q to a P.

Have you actually open the post to see what is in there? Is it in Java?

I use Fusion and they have a 300page manual for editing and customizing their posts. You can make a post do damn near anything.

Craig

[MitchB]

... the g-code includes the code Q0.1. This seems to stop the g-code from running.

Actually this is fine. The problem is that G82 requires the dwell parameter (P) and the post processor Mach4-IN did not include it. Once I modified the post processor to include it, it works.

A related issue is that the dwell variable only seems to write integers. So when I set dwell to 0.5, it is set to P0 in the g-code.

[joeavaerage]

Hi,
good news.

Posts often require a few tweaks to get them to work.

A related issue is that the dwell variable only seems to write integers. So when I set dwell to 0.5, it is set to P0 in the g-code.

It is not clear to me that this is an issue with Mach4 OR the post, the later I suspect.
The code I posted shows a dwell time of P=0.100, and it seems to work, so Mach4 can handle fractional dwell times, but maybe the post cannot.

In another related question have you noticed the difference in how Mach4 handles:
G4 P2 and
G4 P2.0

Mach4 interprets an integer parameter as a dwell time in milliseconds and treats any number that includes a decimal point as a dwell time in seconds.
Thus the delay implied by g4p2 is 2 milliseconds whereas the delay implied by g4p2.0 is 2 seconds.

I'm wondering if your conundrum with regard to integer dwell might be resolved by adding a decimal point.

Just as another tip about Mach4, something that you will come across and will have you scratching your head.

Mach4's Gcode interpreter converts all Gcode to lowercase, strips out leading zeros and whitespace. You are advised to write Gcode in the same manner, and/or have your post write it that way.

G4 P 0.45 gets treated the same as
g4p.45 and in 99.999% of cases will act identically. Every once in a while it will not, and it will cause you to question Mach4. I like to leave whitespace to have the Gcode more human readable but I pretty much
universally use lowercase and seldom use leading zeros. It leads to less mistakes.

Craig

Craig

[MitchB]

The RhinoCAM GUI allows fractions for dwell time. The g-code written using its post-processor Mach4-IN truncates the decimal part. It is an issue with the post-processor.

[joeavaerage]

Hi,
then try a dwell time of 500. If indeed the post is truncating the decimal part then Mach4 will 'see' just the integer, and that it interprets as milliseconds.

Craig

[MitchB]

Ah. That makes sense. Since the RhinoCAM GUI allows decimal dwell time and it shows seconds as units, it should be converting to milliseconds for Mach4.

[joeavaerage]

Hi,
I make a lot of small parts for instruments. when using sub 1mm carbide drills it is necessary to at least chip break and partial retract, but more normally fully retract with dwell. The dwell seems
to allow the drill to be (rapid) withdrawn from the hole without breaking, whereas if you withdraw (rapid) immediately after a peck, ie without a dwell interval the drill breaks.

Doing some pointer bosses right now, drill is 0.98mm, depth (blind) is 4.4mm, so 450% depth. Pay attention to peck and retract with small drills.

Craig