Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: Fermate on December 05, 2024, 04:56:50 AM
-
When I load a Huge G Code file (more then a million lines) my Z axis start skipping steps!
The error can be reconstructed like this:
Startup Mach4 hobby and everything runs normal
Load a G Code file with more than 1 000 000 lines.
Jog the Z axis and it will start skipping steps.
Try to run the job and the axis (mostly Z) will skip steps, ruining the stock.
I have tried to replace the PC with a fast one and a LOT of RAM but the problem is the same.
Have updated Mach4 from 4.2.0.4809 to 4.2.0.5036 but problem is the same.
I am running ESS V 285
My PC is running Windows 11 Pro with the setup configuration that ESS setup guide is giving.
All other jobs runs normal and have done for more than a year.
Is there a limit on how many lines the Hobby version can handle?
Gaute Espeland
Norway
GMT +1
-
As far as I am aware Mach4 does not have a limit on the number of lines of GCode. However, there is an issue with memory available to the Graphics Card or Embedded Graphics Chip. Artsoft recommend a minimum of 512MB but 1GB or upwards may be more appropriate.
Or you could just add a screen button to toggle the Mach4 Toolpath Display OFF/ON. With Toolpath Display OFF your 1 million plus GCode files should run OK and without issue.
Tweakie.
-
However, there is an issue with memory available to the Graphics Card or Embedded Graphics Chip. Artsoft recommend a minimum of 512MB but 1GB or upwards may be more appropriate.
The PC have 64Gb RAM but maybe the Graphic card cant use it?
Or you could just add a screen button to toggle the Mach4 Toolpath Display OFF/ON. With Toolpath Display OFF your 1 million plus GCode files should run OK and without issue.
Thanks! I will try that and report back
-
This topic may be of some help...
https://www.machsupport.com/forum/index.php?topic=30928.msg214631#msg21463
Tweakie.
-
Hi,
I use a Dual core Atom without a graphics card to run my machine. It has 4G RAM fitted, but being only a 32 bit OS it can only address 3G....and of
that 3G about 0.5G is used for graphics. In short my machine PC is tiny and gutless and yet it works fine.
I regularly load and run jobs of 8MB and more without problems.
Craig
-
Wild guess..... is it possible that your G code contains many many moves so small that no actual step pulse gets generated, and therefore the machine is trying to consume motion commands faster than Mach and the ESS can process them?
-
This topic may be of some help...
https://www.machsupport.com/forum/index.php?topic=30928.msg214631#msg21463
Tweakie.
Yes I found this solution and tested it out yesterday.
And you where right; When jogging the Z-axis the problem is now gone!
Its a pity not to be able to see the Toolpath but its better than loosing steps.
I regularly load and run jobs of 8MB and more without problems.
Craig
This file is 35Mb and it looks to me (even if I have not tested the exact limit) that the problem comes when passing 30Mb.
-
Wild guess..... is it possible that your G code contains many many moves so small that no actual step pulse gets generated, and therefore the machine is trying to consume motion commands faster than Mach and the ESS can process them?
Probably not a bad idea. I had some problems before when the tolerance was set too high that the G Code file got very big.
But I dont understand how I can miss steps if no step is generated?
-
And this is the suggested solution from techsupport:
Can you try and run the file at half the speed that it is programmed ? It sounds like the Z axis is missing steps due to the speed it is being commanded to travel at.
And the ticket is marked SOLVED...
-
The problem would have been caused by the processing overload, not specifically by a move so small that no step pulse would be generated.
-
And the ticket is marked SOLVED...
I reopened the ticket and pointed out that this is happening BEFORE the program is started.
The answer from techsupport was:
You may want to increase the buffer int he ESS plugin just a little. It should be at 180 by default. Try it at 200
This did not help, probably because the issue with the Graphics is happening independent of the ESS buffer.
My ticket is now marked closed and can’t be reopened.
Is there any way of solving the Graphis problem other than dropping the Toolpath Display?
Changing the graphic card?
Tuning Mach4 to use more Graphic memory? (How?)
Is this problem reported as a known bug?
Will it be solved / fixed?
Anyway big thanks to @Tweakie.CNC for this workaround:
However, there is an issue with memory available to the Graphics Card or Embedded Graphics Chip. Artsoft recommend a minimum of 512MB but 1GB or upwards may be more appropriate. Or you could just add a screen button to toggle the Mach4 Toolpath Display OFF/ON. With Toolpath Display OFF your 1 million plus GCode files should run OK and without issue.
-
Was it mentioned if you have onboard graphics or a dedicated graphics card? I know long ago onboard graphics could be a problem and was at times mentioned as a possible issue. You'd likely not need an Nvidia 4090, but some sort of dedicated graphics card might be worth a try.
-
Was it mentioned if you have onboard graphics or a dedicated graphics card? I know long ago onboard graphics could be a problem and was at times mentioned as a possible issue. You'd likely not need an Nvidia 4090, but some sort of dedicated graphics card might be worth a try.
Thanks for the tip.
The PC have a separate NVIDIA GeForce GT710
But I can try to swap it with something newer
-
There is no programmed line limit in Mach 4. However, there is a resource limit that will impose a line limit which is arbitrary/dnynamic because every line may not have the same number of characters. The issue is that Mach is a 32 bit application so it doesn't matter if your machine has 64 GB of memory. The maximum memory a 32 bit application can address is 4 gigabytes. And Windows itself will use 1 GB for its own usage so really it is only 3 GB available to the application "at one time". So you are most likely exceeding this limit and the application is having to swap memory in and out of process. This WILL cause a studder. The good news is that a 64 bit version of Mach 4 is coming soon. 64 bit applications can address 17,179,869,184 gigabytes. A stunning number, right? However, the motion plugin developer will also need to provide a 64 bit version of their plugin. A 32 bit plugin will NOT work.
Steve
-
Hi,
I only ever have had two issues.
I often use a circular interpolation type tool path with a small diameter endmill to 'drill' a hole. When making circuit boards I use a 1.5mm endmill
to 'drill' holes and go around the periphery of the board. For instance if I require a 2mm hole, several 2.4mm holes, and several more 3.2mm holes
then they would all be done with the 1.5mm endmill. Saves having to swap out drills all the while.
The issue I have noticed is when the size of the interpolated hole is only very slightly bigger than the endmill. For example if I want a 1.6mm hole
but am using my regular 1.5mm four flute endmill. Mach4 does this no trouble, but the code length of the Gcode file increases markedly, often 150kb
of code for each such hole. Were the hole 2.4mm, the code for that tool path would only be 5kb.
While such a toolpath is running the screen no longer updates. I have always presumed that the very large number of very small moves which constitute the tool path
dominate the PC's processing power, and the screen updates are lost for the duration. Immediately the hole is complete the screen updates and the Gcode file resumes execution.
Mach4 does however do as it's supposed to its just that the toolpath is not displayed under that one, and only one, circumstance.
In more recent times I've got a new spindle with a pneumatic HSK32 tool interface, so swapping tools is much easier, and I no longer bother with interpolating holes as small as 1.6mm...
although I still use it for holes 2mm and bigger.
The second issue is a little more concerning. Every once in a while, when my machine is making a linear interpolated move at g0 speed, ie rapids, which in standard tuning is 15m/min
with pulse rates to the servos of 250kHz, the machine does a stutter. It sounds bloody awful, with a hell of a thump. You'd swear that the machine has just crashed
and that steps would surely be missed....but no. The machine resumes without losing steps and maintains perfect reference. This 'stutter' might happen once a week, and I use my
machine daily.
My guess is that my machine PC (dual core Atom single board PC, with NO video card an 4G RAM) is memory page switching and that causes the stutter.
What tends to support my guess is that my machine is seldom if ever turned off. It may run, powered up rather than machining, for months at a time.
As time progresses this 'stutter' happens more frequently. If I power down the PC, then the 'stutter' occurs but less frequently. I presume that memory page
swapping becomes more common the longer the PC runs. As a consequence, I power down my PC once a month just to give it a chance to re-boot afresh and
minimize the tendency to page swap.
I suppose I could always use a much more powerful PC, but I've been using this little Dual core Atom for ten years and aside from this occasional 'stutter' it's never 'put
a foot wrong'....so I never get around to swapping it out with a better PC.
I have a couple of PCB's that I make that take six hours or more to run, say 5MB to maybe 8MB. I've never had my little PC, nor Mach4 nor the ESS baulk or do anything weird
with these files. It takes two minutes or so for the little Atom to digest and load such a toolpath, but thereafter it runs the Gcode fille perfectly, including screen updates
for hours at a time.
Craig
-
...
The second issue is a little more concerning. Every once in a while, when my machine is making a linear interpolated move at g0 speed, ie rapids, which in standard tuning is 15m/min with pulse rates to the servos of 250kHz, the machine does a stutter. It sounds bloody awful, with a hell of a thump. You'd swear that the machine has just crashed and that steps would surely be missed....but no. The machine resumes without losing steps and maintains perfect reference. This 'stutter' might happen once a week, and I use my machine daily.
...
Craig
Thank you all for info everyone!
It helps a lot when sitting alone up in Norway and try to figure things out.
I got hold of an old Multicam 1000 router during the pandemic and replaced all the electronics except the steppers, the drossel (choke coil in English?) and the RC filter.
I put in an ESS, 4 x MA860H and a new power supply.
Since the original power supply was around 36V and I was afraid of too high voltages I picked a power supply of 48V 1000W.
I had no clue on what to set the Microsteps to on the drivers, so I picked 1000 Pulses / rev.
Setting the standstill current to be reduced to 50% to reduce heating sounded smart so I turned on that function.
Tuning the motors was ok when it came to speed; just turn up until they failed and the reduce some 20%. But for the acceleration, again I had no clue and just guessed; Turning it up until it failed and then turn it down.
It all looked very well, and I start running jobs and enjoying my new big work area.
But sometimes I could hear a “clunk” in the machine and the tool skipped a few steps and ruined the material. There seems not to be any pattern on when it was happening.
I replaced the NUC with a fast workstation with lots of RAM and power, but the error kept coming at random times.
Most of the times it failed when lifting the Z axis so I tuned down the feed and acceleration and it got better but not good.
I suspected that there was not enough power when all the axis was moving at the same time, so I mounted a huge capacitor across the power supply
but no change.
Then when I loaded a huge job, I noticed that the “clunk” also came when jogging and it happened every time and was easy to recreate; just load a huge file (35Mb / 1000 000 lines) and there it was, every time.
This problem was “solved” with a tip from Tweakie by turning off the screen update. Happily, I now turned off the screen update and turned up my feed again but ups the “clunk” was still around when running jobs.
I guess that big files and screen updates is a separate problem that comes in addition to my fundamental problem.
As I am creating wood decorations (Viking / stave church style) for doors and windows on Norwegian cottages (see facebook.com/hyttedekor) , and the jobs typically runs a raster of 0,3mm for 12-18hours, I would really like to avoid turning down the feeds “just in case” and be sure that I run on the optimal, safe, feed to minimize job time.
I have found that running the raster along the longest side of the wood, minimizes the chances for a “clunk” but this generates a lot of sanding afterwards. I 45-degree raster is much better.
When creating a small sign and running 45 degrees I experienced that the Z axis was continually losing steps for every cut. The cut was “sloping” downward into the material.
One of the suggestions from Mac tech support was to increase the ESS buffes size from 0.180 to 0.200 sec, I tried that, and it solved that problem.
The problem with big files is still there so I guess that it is a separate problem.
The “cluck” however is also still there at “random” times so I guess that my machine have many separate problems.
What is wrong with my setup?
I really need a setup that I can trust 100% as some of the wood I am using is very big and expensive and it’s a catastrophe if the tool is running off.
• Should I drop the micro stepping?
• Should I increase the power voltage to 70V?
• Should I stop using a common power and give each stepper a separate supply?
• Are windows 11 a problem?
• The PC is on a network (2 network cards) to be able to transfer files to it, must it be disconnected when I run jobs?
• How do I tune the acceleration to optimize it but keep it safe?
All tips are appreciated!