Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+1)

I'm running Mach3 at home.   w a 2' x 3'  table.   a 60 90 from china  nice place in Chicago.   I would have to look at the board/mfg to tell you more.


I'm a professional prototyper in the bay area.  At work i use Haas mills and Surfcam, but at home i'm doing  topo maps and stuff and my pro software doesn't handle STL files well and doesn't do nice heightmapping like your system.  easiest 180.00 i ever spent.

I hadn't had the time to pick out what might have caused the issue.    in mach3 display the toolpath just went off positive in x for ever.


i'll add in that g40

in 25 years anytime i've needed to modify a post, i had to relearn it.  as I've needed to do that about once every 3 years.


oh.. and took some digging but I found a nice gray scale  mapper that is much easier to use then the USGS

might want to pin it.


https://tangrams.github.io/heightmapper/#11.375/39.0487/-122.8176

Hey, that's a really great site for grabbing heightmaps!

Oh I see, it's drifting off to the side indefinitely. It could be that it's somehow not switching to absolute coordinates, so each absolute X coordinate just sends it off further and further down the X axis, in spite of the G90 that the Mach3 post includes at the beginning of the G-code. Maybe the controller is expecting it with some other G/M codes somehow. It seems like it could just be something finicky with the controller like that. Whatever it is I'd really like to know what it is and work in a fix - understanding the what/why of it.

It could very well be something else too, like the G40. There's no telling what the issue is without some trial-and-error just messing around with it. It could even have something to do with the lack of a "start read" character, the % line. I'd suggest trying removing that first line from the  working G-code and see if it still works, or if its presence is inconsequential.

PixelCNC's posts are relatively simple, I tried to keep all the cruft out and avoid over-complicating anything with features and vernacular nobody ever uses 99.99% of the time. The most complex part are the codeblock definitions at the bottom where it references different variable names/states within the block's string of characters. You could really just directly replace PixelCNC's program prefix codeblock with the one that works for you, but knowing why the Mach3 post isn't working with your 6090 controller would be much more useful to others in the future. That way I can work in a fix without breaking Mach3 support for other controllers that the posts already work for.

Thanks!