Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Chris.Botha on September 02, 2009, 05:26:02 AM
-
I am runnign a P4 3.2ghz Intel HT with 1GB of ram with XP pro, minimal install.. it idles on 169mb of ram.
I have had an issue from time to time where mach will freeze up especially if my toolpath display is on.. today i had a real kicker, im using new pathing software that outputs my usual 4 to 10mb files as about 48mb nc files per side, plus 10mb for rotary, so 48+48+10 106mb path total, but only loaded as one piece at a tiem in mach..
Mach cut really badly.. like it was hoppig and skipping. jittering.. and twice it cut right throug my models, once the A axis starteed turning in code that never calls A once.
The code itself is kosher.. smaller files, IE same fiels pathed with larger stepovers, resulting in smaller filesizes work fine.. so is there some limit where mach runs out of steam with nc files?
after crash 2 i loaded the file again and checks resopurces, mach was using 577mb of ram.. Os 169mb so that should leave me with ample free?
A suggestion i was given to overcome this issue was to change my lookahead? that didnt help.
Roland users cuttign the exact same paths dont experience these issues and they cut from machines far smalller than this? I have been told that they have onboard eproms to buffer code etc.. I think i have asked this elsewhere but will a smoothstepper help in this case?
any clues guys?
-
Well with such humongous file you will have a problem if you have the tool path displayed. Turn it off and see what happens. Problem is that Mach can't update the display will the millions of lines of teeny-tiny segments and keep up with everything else too. Brian has been working on putting the graphics into their own thread and I think we will see a new version of Mach in a few months that is much better in that regard.
The other thing you can do to help is take the pulsing load off the PC by using an external motion control board, like a SmoothStepper. Mach may still choke on displaying your super huge files though, but it will take a load off the PC.
-
Hi Chris,
Have you gone through all the optimisation steps?
http://www.machsupport.com/downloads.php (http://www.machsupport.com/downloads.php) 2nd up from the bottom
I had a cranky PC running a Lathe - crashes / blue screens / etc.
All went smoothly after the optimisation steps.
ATB
Derek
-
Chris, as things are now one of the most beneficial steps you could take to help is to add a graphics card if your running onboard graphics.
Brett
-
Jeff: by default i run with toolpath display off.
Derek: Yes i installed as per the optimisation recommendations. Runs great on smaller codes up to 15mb.. only bigger code kills it.
Brett: It has a pcie NV8200 with 256mb or ram.
-
What are you using to post the code? For the parts you show I can't imagine that it should be a file that large. Can you do any arc filtering before posting?
As for the reason, with a 15mb file a 1mb of ram there is going to be quite a lot of, crap now the proper term evades me.....'page swapping', swap file action going on, especially if Mach is trying to load the whole file at once. You could try increasing the amount of memory dedicated to the swap file and/or adding another gb of RAM.
-
I will try more ram.. The software is DeskProto and its the strategy that's causing the huge file, spiral inwards at 0.02 stepover with 0.127 tip.
I am attempting to rewrite the wizard that generates the code to make it use a different strategy too.. hope it helps.
-
Ram will help a lot. I find 256mb to be about the bare min with large files. What is probably happening is Windowes is setting up hd space and using that as overflow MEM for the large file. THIS makes MACH jumpy and jerky at times as the HD MEM is much slower than reg MEM.
Here a 5mb file and mach and windows takes about 167 mB of usable MEM to stay smooth. I RUN 2GB but regularly monitor the MEM loads in testing
Hope that helps, (;-) TP
-
From the Mach3 download page: "Mach3 has a limit of 10,000,000 lines of Gcode even after licensing"
Regards,
Ray L.
-
RAY if you do not have the MEM for mach to load the file into RAM windows will start spooling mem off to disk and that makes MACH choppy.
(;-) TP
-
he has 1 Gig of ram.
Hood
-
BLIND as a bat, thanks HOOD.
What version are you running. We have seen problems with large files in later versions of mach. I have a simple 5mb test file that can Make mach cry UNCLE every time. It has also been know to crash MACH all the way out to a dead computer. ALMOST like mach had a MEM leak and would corrupt itself. Still looking for that one.
Does not seem to happen with V.019.
I think we need to do some more documented testing with large files ,there MAY be a problem that needs FIXIN.
Just a thought, (;-) TP
-
Another vote for coding by hand, my power divider only came out as a few Kb for both sides. Windows Notepad all the way.
-
RAY if you do not have the MEM for mach to load the file into RAM windows will start spooling mem off to disk and that makes MACH choppy.
(;-) TP
Terry,
So you're saying that statement on the ArtSoft download page is wrong?? If so, shouldn't somebody fix it??
-
RAY try loading and running a file that big (;-) The largest I have tried was only 1,000,000 blocks and that did NOT go well. Even with 2GB of MEM
Give it a whirl let us know how it worked for ya
AND that is NOT what I said..
(;-) TP
-
I have one gig in now , will push it up to 3gb but im thinking that its good money after bad, may as well just upgrade the pc to something faster...
will upload the nc file tommorow from work.. .. 48 mb wont fly from home at 15kb/s up..
It seems like mach should be able to handle it..
-
1 gb should work. That 48 meg file should take up about 800 MB of MEM to load.
-
ver = 3.042.020
yeah i got 577mb usage from taskmanager
and answer to previous question. nope no arcs in this software.
to add to descrition of the issue.. its like the whole mill suddenly stops.. then starts again, but all the values are at the wrong places.. it carries on cutting but with incorrect Y and X.
I decided to write a path. wiull upload to rapidshare. I hope i can solve this as i really like the software, and its associated fixtures.
-
the time it started turning A all by itself in code that never actually calls A at all it killed a really nice cutter.. didnt hurt the fixture too much tho... :)
here is a 43.5mb file.. typical output from the pathing wizard. uses 0.127 20' pyramid cutter and 0.02 stepover.
http://rapidshare.com/files/274958564/test_path.7z.html
5 downloads only.. some new limit they using
path is half a ring side as illustration.
-
oops extra info
that path will run fine on mach as long as i use really slow feed.. like 200mm/min through 400mm/min, as compared to my usual of running paths at 800 through 1200mm/min..
seems like the bigger the path the slower mach has to run..
-
What kernal speed are you running? How many steps per unit?
(;-) TP
-
i was running 60 000 hz and 1548.******************x steps per. Vel = 1200mm/min and Acc = 350
no issues.. (other than the harmonic shudder at 800mm/min)
i finally backed Mach all the way back to 24 000 hz and vel 780 and Acc 200 and cut this at 400mm/min to finish that job. anything more than 400 and it started skipping like mad..
thats like being in the dark ages....
-
I would try it at 45 and see IF it will help out. I run at 45 and use 40,000 steps per inch at 50 IPM which is similar to what you run @ 1200mm/M
I use a 2gb board with 2gb mem.
IS the problem JUST with large files? At what size does MACH start to act up?
-
untill now the biggest files I have run have been at about the 12 to 20mb mark. that file was by far the largest.. the 20mb files gave grief if the toolpath display was on even for jsut index stuff, but much smaller files clocking in at only 4 to 7mb will also stall mach if the toolpath display window is on and the toolpath requires a rotation of A.
In answer to the last question, with this toolpath was the first time i got the complete failure where it actually cuts through my models. with other large paths until now its like the machine will stall then start again but in the right postion at least. so i get warning to run down feedrate by hearing the jerky motion of the mill..
-
i was running 60 000 hz and 1548.*
Ah! Now we are getting somewhere. Higher kernel speeds use up a lot more processor time, some PCs won't do them even under the best circumstances. It has as much to do with the design of the motherboard as it does with processor speed. Some new uberfast MBs won't won't at all. If you couple that with huge GCode files and a relatively small amount of ram (lots of page file swapping going on, lots of HD access) and the PC can't keep up with the precise timing Mach needs.
If you want to run really fast pulse rates then jump over to my website and grab a SS. It will pulse faster than you will ever need AND take a huge load off the PC making it a lot easier for it to handle the large files. (I'm not just saying this because I sell them. Given what your trying to do I would heartily recommend one though.)
-
Smoothstepper may be what I'm after, I've got a fairly big and quite powerful machine but I could do with faster movement. My stone ages PC will send it round at 1100mm/min tops. I'll investigate.
-
i may look at a smoothstepper but Im a little nervous after hearing about kens G00 problems with his smoothstepper and his mill crawling and having to edit those codes out. He is on holiday now but I will hear from him when he gets back whether he got that resolved or not. I think the code itself may be very painfull .. my roland which can maintial 900mm/min on xyz is also crawling with the same code output to rml.. i think the lack of arcs to optimize movement is the issue here...
-
What is strange about the G0 problem is that there are only two reports of it. I've sold 50+ SS and have not had a customer have that problem. I suspect there has to be some obscure Mach variable being set in the profile, perhaps one not even visible to the user, that causes this. A similar now defunct mach Variable is responsible for a Limits responding slow on the SS, Greg found that problem and is taking care of it now.
Lots of teeny-tiny moves will make things creep as the machine is trying to accel/decel on every one of them. You might try turning on CV mode and see if that helps. When you combine a huge file and a high pulse rate you are creating a big strain on the CPU so the precise timing needed by the parallel port driver is not possible.
-
CV SHOULD be blending those Micro moves into a fluid fast movement (;-) That is how the big boys do it.
(;-) TP
-
Good point, is the code setting the machine into exact stop mode? that would cause juddering. Constant velocity mode is a lot smoother.
-
nope cv is on at 0.06, changing that value to 0.5 made no difference either
was the first thing i tried
-
Thought it might have been a bit obvious. Unless the code itself is overriding Mach3's settings with a G61 command at the top? Apart from that I'm stumped.
-
here is the posted initialisation code
G17 G21 G40 G49 G64 G90 G94
G64 maybe? but cant think that would affect it like this?
-
Wouldn't think that was it, G64 puts it explicitly in CV mode. :( Wierd, all round.
-
my mill manufacturer, MiniTech has some guys on it. will have some answers soon i hope.
will feedback once i hear
-
two guys have tested that code and apparently not had issues.. they both have ballscrews with half the tpi of my mill so half the work to get the same distance. i may try reducing my microstepping from 10 to 5 to equal their machines..
last resort...
-
THat could very well solve the issue. When Mach is running wide open funny things seems to happen in windows. IT could also be a LPT port issue, Not all port have the same transfer rates. I have seen from 1.5MB per sec all the way to 4 mb per sec transfer rates.
(;-0 TP
-
As I mentioned before it is an issue with trying to get Mach/Windows to do too many things at once; the LPT driver simply can't update at the higher pulse rate while Mach is trying to juggle an enormous file. So you have to do some arc filtering on the file to get rid of millions of 0.001" moves or reduce the pulse rate or go with an external pulse generator.
-
ok so if this application cant do arc fitting can i get another application to do this? can i buy a backplotter/arc fitter application for example?
anyone got an idea of something that does that. the reason i ask this is because while this application does not have arcs it has a supremely programmable interface allowing me to automate path generation significantly.. if i have to add another step to arc fit im happy to do it.
-
Chris what software are you using to generate the code? . Last time I made inquires into the micro coding problem I was told it was WAY TOO COMPLEX to deal with on a simple( low cost) level. They ALL said the same thing(;-)
YOU have made a good point on machine resolution that MANY manf of comercial CNC machines design into the machine. THEY do not use any more resolution than is need to maintain the accuracy of that machine. THat takes the unneed load off of the CPU.
I fall into the same thing at 40,000 steps per unit just to do .001" accuracy. I am using way more resources than what is needed to do the job(;-) BUT this is a test machine designed to run mach hard for testing purposes (;-)
SO how did changing the microsteps turn out??
(;-) TP
-
DeskProto, www.deskproto.com and im kind of tied to it cuz the developer also produces a fixture that allows end users to cut 3 sided work with the click of a button. I want to expand on the wizards in the software to breath new life into milling and make it simpler for new entrants into the market.. wean a few sales away from the printer guys..
I hvae not tested changed microstepping yet.. will be doing so on weekend i guess. i dont have a mill at work so i have to do it at night, kinda make it HAVE to be right the first time...