Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: panaceabeachbum 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
-
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
-
Oh forgot to say,did you mean to put G84 in the above example?
Hood
-
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 ;)
-
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.
-
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.
-
Oh forgot to say,did you mean to put G84 in the above example?
Hood
oops meant to put g83 for peck drilling
-
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
-
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.
-
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.
-
thanks , I have been copying and pasting the entire macro folder when updating , instead of just copying the oiler and tool changer macro . Thanks again , will update and give it a whirl
-
That shouldnt be in the macro folder I dont think, should be in C:\Mach3, there could well be one in the macro folder but I dont think it will get used.
Hood
-
Better hang fire there, just checked and it seems it is the one in the macro folder that is used, I was thinking it was the same as the lathe threading in that it is the one in the main Mach3 folder.
Will go and compare them on my computer .
Hood
-
Ok it seems that your one may well have been correct as it is the same as the one in the macro folder, so I dont know why yours is not working correctly.
Have you tried just the G83 on its own?
Hood
-
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.
FWIW, I agree with your assessment. 'Fanboy' mentality is always a detriment to progress on any product. In my brief experience here, the authors of the software seem very interested in constructive criticism, which is really what matters. It makes perfact sense to improve Mach's compatibility with commercial software by doing something as simple as including a decimal in numbers, which should have been there already.
Non-programmers may not understand how lines get parsed or how numbers get interpreted. G-code is interpreted, so each line gets parsed as text. The parser is looking for the decimal in any numeric value. If there is not trap for the absence of a decimal (and why would there be?) then the parser faults. No software has a trap for every conceivable entry error, including Mach, which has no traps for obvious basic errors in calling external subroutines. So faulting other software for not having traps that it really should not need anyway, makes no sense to me. But that's just my opinion others may disagree.
I vote that your suggestion was valid, constructive and well worth a look see from the authors if they seek to step up their game.
-
Hi All,
The "Feature Request" section would be an appropriate place for any suggestion. Title it well and maybe also provide some background as to the why. Feel free to post anything you think would be an improvement to Mach.
Then those responsible can consider your suggestion.This way there should be no misunderstanding as to the content of the posting.
I think it fair to say, that in reading something, the mind set may be to look for a problem in Mach, wonder if someone needs assistence with Mach, or maybe requires some understanding on Mach, or seeks the experience of another. How the posting is presented makes a difference as to the reponse.
Just a reflection,
RICH
-
Good point Rich, I did probably post my observations in the wrong section , they just popped into my mind while typing my g83 question and I thought I would share them. I am in no way trying to find any faults with mach or the wizards . I also wasnt refering to anyone thats posted openly with my other comment, but was responding to a couple of very nasty emails blasting me for pointing out something that I thought was a conerstone of basic geometry , the decimal point.
Hood I still cant get g83 to drill to the proper depths, anything I try under 1" drills to the proper depth but when I call out a depth over 1." it drills to some depth short of that dimension .
Could you zero your machine back some safe distance from the chuck and run a peck drill cycle something like g83 q.o5 z-2.2 f4.00 r.2 and watch your dro and see if it actualy drills to the full 2.2" ? On my machine this will drill to 1.6" depth perfectly but not the 2.2" No hurry just curious if I am the only one having this problem . I dont seem to have any problem if I keep the pecks (q) to .1" or greater or the total depth to 1" or less but the above string just seems to be problamatic
-
RT
I did do exactly that the last day on my lathe to make sure it did work. However I have my machine set in metric so I was using metric dimensions. I had the peck at 10mm and depth at 100mm and it did exactly that.
Seems though you may be onto something with the small peck, I will try out tomorrow with a peck of 1mm and see if I get the problem, if not I will do a G20 and try your code.
Hood
-
Pana...m,
I also use a SS and just ran your code: G83 Z-2.2 R.2 Q.05 F4.0
It drilled to the full 2.2 ( I had the carriage pushing a square along a scale for a physical double check).
I have the following for an initialization string in my config on start up:
G18 G20 G40 G49 G80 G90 G94
Now before running that code via the MDI line, I Zero World X &Z, set home, and part zero X&Z thus no offsets
exist,etc.. to eliminate any influence that could exist.
I copied the M1083 from macros\MachTurn\ to the macro directory i use for the SS. Using Mach3 ver .027 here and
.....v015ogb.dll for the SS plugin.
So it dosen't seem to be problematic here. Haven't used G83 all that much.
RICH
-
RT
Yes there is definitely an issue with short peck distance. I have tried both metric and imperial and get the problem.
You can quite clearly see it if you edit your m1083.m1s macro to
Test = True
Look at the code and you will see the final depth.
If I had the peck at 5mm then it was fine, went to z-55 like it was meant to but if I put the peck at 1 then it only goes to z-27
Will talk to Brian about it when I see him online.
Hood
-
RT
Did you try with the macro I had attached the last day? I just put it in my profiles macro folder and it seems to work fine with that macro.
Hood
-
yes I updated with the macro you posted and it was still doing the same thing , but now that I think about it I have not rebooted since so maybe its just not loaded the new macro, I tend to leave the machine on for days at a time and just turn the servo amps off at night . wouldnt be the first time I have overlooked something basic
-
That shouldnt matter, just check that the one in your profiles folder is the latest, it has a date at the start of the VB for some time in 2008.
Hood
-
still not working as expected , will oonly drill to a depth of 1.6" max
-
Put the macro into test mode and have a look at the code it spits out.
Hood
-
that sounds like its above my pay grade , is there a link with description of how to do that
-
You just need to edit the m1083 macro and change the line Test = False to Test = True, sure I mentioned it a few posts back.
Hood
-
Macros in Mach are VB scripts. Mach has the editor built in.
From the top line of the standard Mach screen:
Operator>VB Scipt Editor
I ran into a problem thinking I could explicitly pick up an external subroutine from wherever it was located, but Mach is adamant about where they are, so it might be a safe assumption that all of Mach is sensitive to placement of external references. So make sure you have your macros in the proper subdirectory (folder) and that there are not more that one version floating around with the same filename.