Hello Guest it is October 24, 2021, 12:34:54 AM

Author Topic: couple of things I have noticed with mach /g83 problem  (Read 12349 times)

0 Members and 1 Guest are viewing this topic.

couple of things I have noticed with mach /g83 problem
« on: June 12, 2009, 10:17:05 PM »
I have been using my big lathe quite a bit with mach this week . I have upgraded from an earlier version of mach and installed a smooth stepper at the same time so i am not sure which one is causing the problem . When i peck drill I cant get the depths called out .  G84 q.1 z-2.5  f1.00 r.1 only drills to a depth of 1.6"   I have run a number of drill files that were drilling to the proper depths before the upgrades that will not drill to the proper depth now
Machine moves the proper distance in all other functions.

I have noticed a couple of other things, that while they dont cause problems in Mach , are not std and do cause problems in other commercial cnc controllers. Just observations so please dont take ay of this the wrong way .
I am running Yasnac mx3 , milltronics cent7, sinumerik 802c and the latest thin controller from HAAS .

Some of the Mach wizards generate coordinates that are 5 decimal places , the haas controller, sinumerik and the Yasnac on mazaks and other eguip will only accept numbers to 4 places or they fault .

all the wizards seem to generate coordinates that sometimes do not have a decimal point if they fall on a whole number x1 , y3 etc . All  of the commercial controllers I am running have problems with any numbers that dont have decimal points .
quite often feed rates are generated with out a decimal point , same problem as above.

I realize 99% of the time files generated are run only in mach and all the wizard were/are written with this in mind , I am only pointing these things out as I am guessing the goal is to make everything as close to std gcode/programing as possible and the decimal point thing seems to cause problems on a number of machines

« Last Edit: June 12, 2009, 10:19:41 PM by panaceabeachbum »

Offline Hood

*
  •  25,838 25,838
  • Carnoustie, Scotland
    • View Profile
Re: couple of things I have noticed with mach /g83 problem
« Reply #1 on: June 13, 2009, 02:35:43 AM »
Seems to me you should be complaing to Hass and Milltronics telling them that their machines are not adaptable in the code they can accept , wonder what they will tell you ;)
 You could always edit the wizards to put out code that will be accepted by your less adaptable machines :D

Hood

Offline Hood

*
  •  25,838 25,838
  • Carnoustie, Scotland
    • View Profile
Re: couple of things I have noticed with mach /g83 problem
« Reply #2 on: June 13, 2009, 02:41:39 AM »
Oh forgot to say,did you mean  to put G84 in the above example?
Hood

Offline RICH

*
  • *
  •  7,419 7,419
    • View Profile
Re: couple of things I have noticed with mach /g83 problem
« Reply #3 on: June 13, 2009, 09:13:30 AM »
Here's my take on this:
Gcode is defined by the NIST RS274 Standard ( 1960's ) and I think there is a European Std also.
Do the standard's define things down to the number of "decimal points" ? I don't know. There are other standards out there also.

The problem can be be summarised by asking the question:

What are the requirements of the controlling program?

If all controllers where truly standardised then there would be no need for a manual for any of them.
So a program ends up having a post processor to allow adjustment such that the receiver program,
namely the controller ( MACH, HAAS, FANUC, etc)  can interpret a g-code appropriately. The controller may or may not allow for flexible a configuration. I think many companies out there want it that way. There are proprietary canned cycles out there. You often will see a note like "READ THE MACHING CENTERS MANUAL FOR SPECIFICS".

At the user level we make a dumb assumption that if it works in one it should faultlessly work in another without
the understanding or taking the time to answer the question above. Even if we knew the answer exactly the user
probably couldn't adjust for it. You get responses like. the program has a bug, or it doesn't do something correctly, or maybe it don't fit a preconceived notion of how the user thinks it should work, and "your left holding the bag".The vendor may simply answer you that "ours" is correct and it's your problem.
Thus,  compatibility problems have existed for over 40 years and will continue for probably another 40 years.

Ask a vendor to change his $20,000 program for you or get rid of some quirk's on his end! Will never happen.

I don't fault Mach or any other controller program, or pass a judgement on them, but rather just say "that's life".
In the context and understanding of my long winded reply,  not a problem relative to the requirement of MACH.
RICH  ;)
 

Offline Tweakie.CNC

*
  • *
  •  8,836 8,836
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: couple of things I have noticed with mach /g83 problem
« Reply #4 on: June 13, 2009, 09:39:44 AM »
I think that the way to go is to look for a GCode editor that can modify the Mach Wizards code (or any other) to obtain compatibility with your controllers. Some of the editors I have seen in the past have quite sophisticated 'search and replace' capacity and may do the job.

Tweakie.
KEEP SAFE !
Re: couple of things I have noticed with mach /g83 problem
« Reply #5 on: June 13, 2009, 01:17:59 PM »
I dont think there is a universal std your correct , maybe i should rephrase to say that its pretty much an accepted practice that all numerals that are not comands (g4, g1, m* etc) have a decimal place in them and that some of the Mach wizards generate coordinates and feedrates that do not have decimal places.
If it was only the HAAS that had a problem with this it might be easy to say the problem is theirs , but since all the commercialy avail controllers (that I have) have problems with the lack of decimal points and all the cam software i have ever used puts decimal points in all coordinates and feed rates I would say its pretty much an accepted std here in the US.

I realize there are pre and post processors that are machine specific , but they in no way are intended to (or have the ability to) go thru code and look for missing decimal places. I also am not familiar with any gcode editors with this ability either.

I am in no way knocking Mach or the wizards, I recently read a post by Brian in which he mentioned cleaning up g28 to operate more like the excepted std so i assumed there was a desire to move as close to the center of the "std" way of doing things in the cnc world.

Generating huge strings of code where some coordinates have decimal points and some dont just seemed like an issue to me .   I have been a long term user of a number of cam programs and have been operating commercial cnc equipment for 20 years and its common place to use decimal points in all coordinates and feed rates .

As I pointed out in my initial post no its not a problem if your runnig the files in Mach as I am sure 99.99% of the members here are , I am just pointing this out in an attempt to better a great product , nothing more.  I know another user of mach that generates cut files for his plasma table to protype parts and then takes the code to another shop with a large commercial machine to cut thousands of parts who has also had the same issue.
« Last Edit: June 13, 2009, 01:36:26 PM by panaceabeachbum »
Re: couple of things I have noticed with mach /g83 problem
« Reply #6 on: June 13, 2009, 01:38:54 PM »
Oh forgot to say,did you mean  to put G84 in the above example?
Hood

oops meant to put g83 for peck drilling

Offline Hood

*
  •  25,838 25,838
  • Carnoustie, Scotland
    • View Profile
Re: couple of things I have noticed with mach /g83 problem
« Reply #7 on: June 13, 2009, 03:08:58 PM »
The fact is that the wizards are not really part of Mach, they are additions which were written by numerous different people and given to ArtSoft for inclusion to make peoples lives easier :) Also there is nothing whatsoever stopping you from going into these wizards and editing the VB so that what is put out suits your other controls.

On the G83 thing, I tested it today on the lathe and it worked fine, I just have version 021 on the lathe though. I have however  tested it in simulation with version 027 and again it seems to work fine.
 Can you attach your G83 macro and I will compare to mine to see if there are any differences, you will find it in C:\Mach3 and its called M1083.m1s

Hood
Re: couple of things I have noticed with mach /g83 problem
« Reply #8 on: June 13, 2009, 03:40:16 PM »
no big deal on the decimal point thing , if this were my project I would welcome constructive advice on how to better things, I get the impression that alot of folks would rather get defensive and explain things away than be open minded and consider another viewpoint  , my apologies for even bringing it up.

Back on the g83 subject I attached the file you mentioned , maybe its something simple . Thanks for offering to take a look.

Offline Hood

*
  •  25,838 25,838
  • Carnoustie, Scotland
    • View Profile
Re: couple of things I have noticed with mach /g83 problem
« Reply #9 on: June 13, 2009, 03:54:26 PM »
That is an old macro you have, last updated March2005.
The one attached is the one that should come with the latest versions of Mach and was updated last on March 4 2008.
You will need to download it to a location on your drive then rename to m1083.m1s then paste it to C:\Mach3 in doing so overwriting the one you have there.

BTW dont really think anyone was being defensive as such, my comments were certainly in good humour or at least were intended that way :)
Hood

Edited to remove macro as it may not have been the correct one.
« Last Edit: June 13, 2009, 05:05:27 PM by Hood »