Hello Guest it is December 06, 2021, 04:12:57 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - stephanbrunker

Pages: « 1 2 3 4 5 6 »
Thank you for the advice ... but until now I never had any issues with Sourceforge, and I just checked the download with a MAC and it's exactly the one I've uploaded - it hasn't been tampered with.


I just have released a beta version of my Mach3 Threading Helper. To actually cut a thread with Mach3 and the G76 macro, you need a couple of parameters, the numer of passes etc. For metrical threads, Mach3 comes with the G76_thread.exe. My application is far more sophisticated: i lets you select a thread from several standards or let you create your own size. The important feature is, that the tolerances are calculated given to standard and size, that it fits. Then you can simulate the cut - means you can try some number of passes to get the increment you need. Finally, the program generates the GCode which you can copy & paste in your file. So far, my threads had a perfect fit. And it's Open Source.

The supported Threading standards in version 0.10:
  • M - Metric in medium (6g/6H) and fine tolerance (4g/4H)
  • G - Withworth Pipe
  • R/Rc - Tapered Withworth Pipe
  • BSW & BSW Withworth
  • M keg - tapered Metric

When supported, you can cut threads with multiple starts, too.

I've also made a throughly improvement of the G76, G77 and G78 macros and fixed the bugs there as far as possible.

The Sourceforge page:

Try it out and report if you find any bugs ...

General Mach Discussion / Re: Bug in G77 / M1077 macro
« on: April 24, 2015, 02:50:33 PM »
Solving the taper issue is easy - i forgot to post it here:

in the macro, you should edit the line

taper = tTaper()


Taper = GetVar(101)
If Taper > 90 or Taper < 0 Then
   message "Error, Taper out of Bounds"
   code "M30"
   Exit Sub
End If

so it takes the taper angle from a user variable and resets it after use. in the GCode, program prior to your macro call #101=45 , if you want something different than zero.

@ Hood: Thank you! I could locate the issue. The "Preparation Move" Window has two versions: One with SafeZ enabled and one without. If SafeZ is enabled, the preparation move goes first to this position and then to the calculated position. With SafeZ not enabled, there is a "Rapid Height" Input field. I really don't know for what this one is for, but it is by default 0 - and that is the move the machine makes as first one. So, if I every time set the "Rapid Height" to the same value as shown in the "Z" field, nothing happens here. Do you know for what this "Rapid Height" Input is really designated and why it is by default 0? If I'd think for an application, if you check "preparation move at feed rate" (e.g. you are at Z-5) and you want to skip to Z0 at full speed - but with preparation move at feedrate enabled, it doesn't does that. Really strange, that one ...

@ mrprecise44:
Programming a tool change like you wrote is the really clean way. But nontheless, my machine isn't that fast and if I go every time I want to change from one drill to the next bigger one all the way up to the home position, I'm getting old on the way. And I really don't have anything against Mach3. But every programmer knows that while a program grows, new features sometimes have an unexpected impact on the old ones - and the natural state of any program is full of bugs and every single one has to be found and removed. (Look: Entropy ...) And it is quite clear that in Mach3 with it's long evolvement there're some surprises included. For example this "Rapid Height" field. What, by the way, isn't documentated. And I also had some trouble especially with Turn, where the G77/78 macros really weren't checked with the newer versions because somebody should have seen that the use of the T word for the Taper collides with the T word for the tool change. And why the default M6End macro for Turn also has a SafeZ value used while SafeZ isn't part of Turn. And why the Tool setup in Turn is different as documentated and G49 is ignored - but only in Turn. And why "reverse arcs in front post" is by default on. And so on ... But in my opinion, I'm helping the developers and the community with posting this. Because the next Mach3 Newbie without a homed Z axis also doesn't (couldn't) know what this "Rapid Height" means and gets a shock if his machine goes down instead of up ...

I have to make a compromise between safety and time - as always. Most of the time, I make only one or two copies of a part. And given the decision to make them manually or with CNC, I can't do a double test run without tools etc ... given the time needed for the coding, then I would be faster manually. I have to trust the Tool Path simualtions. And I surely don't blame the controller for the mistakes I make - in Germany the saying is "wo gehobelt wird, da fallen Späne". But I have to expect that the CNC controller actually does what is programmed and documentated - nothing more and nothing less. And there can be some optimization.

General Mach Discussion / Re: How to - code manual tool change?
« on: October 22, 2014, 03:07:55 PM »
I think then the procedure (return to home / change tool / probing / zeroing) is directly encoded in the gcode - if there's a macro for that, it's not in the usual manuals ...

But I'll look at this after I have modified my BF20 to accept spindle speed commands only by tapping into the manual speed dial (includes four op-amps and an optocoupler ...)

General Mach Discussion / Re: How to - code manual tool change?
« on: October 22, 2014, 04:59:29 AM »
Oh, I assume that you don't code manually ... since I started with a lathe and my first project was already too complicated for a CAM software, I write my gcode self. Just take a look at the GCode reference in the Mach3Mill Manual and perhaps here: http://www.cnccookbook.com/CCCNCGCodeCourse.htm

I would simply edit the code in a text editor.

So, if i look at the generated code ... the spindle is stopped (line 250: m5), so you go up a bit, something like

N251 G0 Z50

the next one is a return to home which you don't need and it just costs time, so delete the rows 252, 254, and 256 ... if you can change your tool anywhere.

the Line 258: T2M6 is the Tool change command, be sure that in the Mach3 General Options Tool Change command is set to "manually", so you're asked to press "Start cycle" after manually changing the tool.

Line 260: N260G0G90G54X11.5Y12.5125A0.S5000M3 returns to the previous position (not sure), set speed to 5000 and starts the spindle

Line 262: N262G43H2Z.25 applies the new tool offset and goes to the starting z position.

If I code manually, i would put the G43H2 command before the tool change, so you have the new tool length correction already in the DRO and you can test it by simply measuring the distance between tool and surface.

As I've written before, you'ld need a functioning tool table - and the very real risk is if something is wrong and the offsets aren't exact you can crash full on in your workpiece. As a safety measure, I often write the returning to the surface in two steps, to a safe distance with G0 speed and then at feed rate .. so you have a chance to push the emergency stop.

So, before you do anything without knowing what it really does, I propose a crash course in manual g code programming ... there're only a handful of basic commands ... because there're so much possibilities for a failure  >:D

General Mach Discussion / Re: How to - code manual tool change?
« on: October 21, 2014, 01:34:53 PM »
I see two possibilities: I had set up my tooltable with all the Z offsets (measured by touching), so I have only to code for a tool change:

G0 Zxx (move Z up)
G43 Hxx (apply offset)

... that the easiest way. If your Tool has variable length, you'ld need some kind of probe and a macro. I just build my edgefinder and tool length probes, and I still have to write the macro. You'll have to have home switches on the machine, and I would try something like this:

- move to a safe z position
- change tool
- remove work offset (that you have absolute machine coordinates)
- move over the position of the tool probe
- make a G31 probe command to touch the probe
- if your machine is homed correctly and thus the Z position of the probe is known, calculate tool offset
- apply tool offset to the tool table or the work offset (no idea what would work)
- reapply work offset
- move to the last position prior to the tool change

I really should write one ...


Check with Turn - RFH is okay there, it's just on Mill the additional Z0 command in the preparing move.

Thank you for the help. I'm working with version 66, and here're the xml file and the gcode. If I go to line 43, 44 oder 45 with Tool offset #27 active, Z is already in position +50 and "run from here", it should do nothing at line 45, because the last command was z50, and goes up at lines 43 or 44 because the previous tools were longer and there was no Z command with the last tool. The ending is correct so far, but when I hit "Cycle start" after run from here, it proposes the correct Z value, but - and this is mysterious - goes first down to Z0 (with Tool offset
#27) and then up to the right Z value. I have no Idea where the Z0 command comes from ...

I'm also going to check this on turn - as far as I know, the first major difference is that Turn ignores a G49 command and uses the current tool (offset), even if G49 is programmed while Mill takes Tool 0 if G49 is programmed. Because I have a mill and a lathe, this was one bad surprise which I could stop just 4/10 of a Millimeter before impact.


I have serious problems with the "run from here" function in Mach3 Mill. In a program with tool changes, e.g. g43 hxx, t... and m6 commands, resuming a program is impossible and dangerous. Why? I set up my tool table as written in the manual, with the shortest as 0 and all other with the function in the offset screens. In a continous program, everything works fine. But if you have to stop and resume the program with "run from here", it goes south ... or, more precisely, straight down at full speed. Even if you have the matching tool in the machine (at this postion in the program), the correct offset and the DRO's show the right z position, the preparing move overshoot the Z value shown in the preparing move sceen (for example 50) and the DRO and plunges farther down (49,48,47 ...). I don't know how far ... I was lucky enough to avoid a crash so far. But I presume that it ignores the tool offset value and goes for the Z value in combination without Tool offset. I guess that everyone is working on Mach4, but this one should be corrected. The only solution so far is copying the remaining program in a new file and start from the beginning what is somewhat annoying - and that isn't speaking of the danger involved.

Pages: « 1 2 3 4 5 6 »