. .
Page 1 of 4 123 ... LastLast
  1. #1
    I have just seen some Mach3 behaviour which I did not expect, and I'm wondering if this is a bug or a misunderstanding on my part.

    My Mach3 setup is configured to use mm, so all units are in mm or mm/min or whatever. Normally, I generate gcode with Fusion 360 or Vectric Vcarve using mm, and I have never seen any problems. However, almost by accident, today I generated gcode that used inch units. Never mind, I thought, Mach3 should be able to cope with that. However, what seems to happen is that as soon as Mach3 loads (not runs, just loads) the gcode, it tries to switch everything to in from mm. Not only the default feedrate, but even machine coordinates. So, before loading gcode I have set work zero on a corner of my workpiece. I load the gcode and Mach3 then converts the machine coords into inches but doesn't seem to handle the offset of the work coords correctly so the work zero is somewhere a long way from where it should be - in my case, so far out that when I tried to run the gcode (before I noticed this coordinate shift) it tripped the soft limit warning - fortunately.

    In my innocence, I had assumed that Mach3 would see the "inch" command (G20), interpret all the dimensions/coordinates in the gcode and translate them internally into mm, and happily carry on. Instead, it seems to see the G20 while initially parsing the gcode as it loads, which promptly screws it up completely. As part of my testing, I went back to F360, made absolutely no changes except for specifying mm as the units, generated the gcode, loaded it into Mach3, and Mach3 immediately went back to all the correct units without any other action on my part (no need to reset, rehome, anything). So, is the problem that Mach3 just doesn't understand the significance of G20/21, or is it something to do with my CSMIO-IP/M which is upsetting it, or something else? Or is Mach3 brain-dead? You can guess my choice...

    The workaround is obvious - only feed Mach3 with metric gcode, which in my case is not a big deal - but I don't see why the "inch" version should not have worked. Has anyone else seen this?

  2. #2
    Well, I've probably found the answer myself. It was only while starting to write this post that I actually understood what was happening - at first, I didn't even realise that it was due to an in/mm issue - and as a result googling around for answers wasn't very useful. You do need to know the right question before you can get the right answer...

    Looks like Mach3 doesn't really handle in/mm G20/21 commands the way I would expect. However, it should work OK (according to what I have read) if you load the gcode, and then set the work coordinate zero. I was setting the work coords and then loading gcode. It still doesn't make much sense to me, but at least it looks like a way to handle gcode created using the "other" set of units.

  3. #3
    If you must run both imperial and metric code, it's recommended to set up separate profiles for the different units.
    There are a lot of things that can go wrong, especially if there are commands that send the machine to machine coordinate locations. And there are probably a few bugs in there somewhere as well.
    Gerry
    ______________________________________________
    UCCNC 2022 Screenset

    Mach3 2010 Screenset

    JointCAM - CAM for Woodworking Joints

  4. #4
    Mach3 isn't doing anything funny, it's doing what the code you feed it tells it to.
    In addition to a units command G20/G21 is there a G54 through G59 in there?
    Unless you have set your zero in G54 switching to G54 through G59 will lose you your zero.
    It's common for people to be operating in your machine's Absolute Co-ordinates without being aware that multiple offsets are available and to be surprised when a G54 throws them a curve ball.
    You think that's too expensive? You're not a Model Engineer are you? :D

  5. #5
    I freely admit that I fell into that classic IT trap, which is that there is often a disconnect between what the software writer thought the world looks like, and what the user expects. Sometimes these are the same thing, and all goes beautifully. In this case, though, my interpretation of G20/21 from both Mach3 and LinuxCNC documentation led me to expect different behaviour from what Mach3 actually does.

    My interpretation - G20/21 say "all the coordinates in the rest of this gcode file are in in/mm units and interpret them that way." Doesn't sound difficult to me - in simple terms, anything following one of XYZABCIJK gets divided by/multiplied by (depending on native units and what's being read) 25.4. Then carry on using those values, but leave the GUI unchanged. I was expecting Mach3 to continue to display in mm, while reading incoming data in inches and converting it.

    What I actually saw was Mach3 reading a G20 command, saying "This user now wants me to completely move away from my previously-defined mm state and work and display in inches" - so it changes the DRO coordinates, feed rates, etc. What it does not appear to do is convert the work offsets (G54 table, etc) from mm to in, which would have maintained the work coordinate zero, which seems to me like an inconsistency but I expect that there is a reason for it. This was not the behaviour that I expected. I'm not saying that it's wrong, just not what I would have expected. However, this is also why setting the work coordinate origin after loading gcode will work.

    In my case, the simple solution is to make sure I tick the right box in F360 or Vectric Vcarve, my gcode generators of choice, and only ever produce mm unit gcode as this is infinitely easier than having to manage two profiles (and keeping macros in step, etc), maybe having to reload profiles as I move between different gcode files.

    Gerry - I note that you have answered this question elsewhere years ago, but as I mentioned, until I realised why this was happening, I couldn't google successfully for the answer! It took me a little time to note that the gcode was in inches not mm, as I hadn't even considered that this might have been the problem.

    Nick - not really a work offset issue, I think (except as noted above) as exactly the same model produces correct gcode with all the same setup and CAM parameters with only the mm box ticked instead of in. I'm fairly happy with the G54, etc, set of values as I have hand-edited these before when combining multiple gcode files to machine a batch of objects, all of which had the same (0,0) origin when their gcode was created. By using multiple work coord offsets set manually to suit my machining jig and adding a judicious G54, G55, etc, in the gcode, it all worked fine.

    Thanks for the comments, guys.

  6. #6
    What it does not appear to do is convert the work offsets (G54 table, etc) from mm to in, which would have maintained the work coordinate zero, which seems to me like an inconsistency but I expect that there is a reason for it. This was not the behaviour that I expected.
    This would probably be classified as a bug.
    Gerry
    ______________________________________________
    UCCNC 2022 Screenset

    Mach3 2010 Screenset

    JointCAM - CAM for Woodworking Joints

  7. #7
    It's not a bug, it's simply down to the operator to get it together and work in either Metric or Imperial and set the CAD, CAM, machine and controller up accordingly.
    You think that's too expensive? You're not a Model Engineer are you? :D

  8. #8
    My feeling is that software (and anything else that is supposed to help us) should allow us to do the job the way we want, and not impose unnecessary restrictions on us that could be avoided. Yes, we can't beat the laws of physics and some other physical constraints. There is also the valid point, as I alluded to earlier, that the software designer may have a different "world view" from a user which implies a certain way of working. I'm happy, more or less, with that as long as the implementation is consistent - which it does not appear to be in this case.

    Nevertheless, Mach3 is well beyond its "best before" date so no-one is going to fix it, and fortunately there are a couple of easy workarounds in this case which mean that I do not have to manage two machine profiles or unreasonably change my way of working. Ho hum - that's life.

    Gerry - out of interest, do you know what UCCNC would do in this situation? Does it recognise G20/21 and just do what you might expect?

  9. #9
    UCCNC is unitless, so it will not do anything if it sees a G20 or G21. If you want to run both metric and imperial code, you need to setup separate profiles and use the appropriate one.
    Gerry
    ______________________________________________
    UCCNC 2022 Screenset

    Mach3 2010 Screenset

    JointCAM - CAM for Woodworking Joints

  10. #10
    +1
    Machine profiles, one for each set of units is definitely the way forward if for some unfathomable reason switching between systems of measurements.
    You think that's too expensive? You're not a Model Engineer are you? :D

Page 1 of 4 123 ... LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Weird Mach3 + CSMIO/IP-M Probe Problem
    By matt-b2 in forum General Discussion
    Replies: 24
    Last Post: 11-07-2019, 01:05 PM
  2. The best CAD/CAM suggestion, Gcode and Mach3
    By petes in forum CAD & CAM Software
    Replies: 1
    Last Post: 29-01-2015, 11:06 AM
  3. Help needed for a 3d part gcode for mach3
    By Rebekah_harper in forum Computer Software
    Replies: 33
    Last Post: 04-11-2013, 01:55 AM
  4. Mach3 Using a physical button to repeat current gcode
    By RLKS Rob in forum Artsoft Mach (3 & 4)
    Replies: 2
    Last Post: 12-08-2012, 01:30 PM
  5. Day shift Manual Miller/Night Shift Turner and Grinder Required - Berkshire
    By J Maynard in forum Opportunities Available & Sought
    Replies: 0
    Last Post: 06-01-2012, 11:46 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •