Todo: Optimise G-Code Generator: Don't repeat F/S commands unless changed, also remove modal commands that repeated) about openbuilds-cam HOT 12 CLOSED

Hey man, thanks will check it out

Just a note about the repeated g-code words - thats a legacy from the old Laserweb code days (where a lot of this come from - my past lol) - there's two reasons why, one was some firmware bug at the time but I think thats been fixed (can't even recall the details - although your mention of Marlin might be what I recall... ) - the other is I need some time to rewrite the gcode viewer (lines without a G-word prefix doesnt parse). I started on it last week (moving it to webworker, but theres a couple todo's before I can call that work done. Just got it in so it works basically almost good enough (: but still lots todo - modal values is a part of that work. The old parser does (but its not a webworker)

OpenBuilds/OpenBuilds-CONTROL#3 relates as well (no doubt you already saw the previewer doesnt render G2/3 yet)

from openbuilds-cam.

Going to close out this issue for now. I'll revisit it once the Gcode viewer work is done (Gimme a week (: or so )

from openbuilds-cam.

Okay, the Gcode viewer work is done: https://github.com/OpenBuilds/SW-Machine-Drivers/releases/tag/v1.0.89 or newer has the parser fixed to understand gcode lines without a G-word
So re-opening this issue, will work on optimising the gcode generator tomorrow or next week

from openbuilds-cam.

awesome!
Sketchucam does this by storing all co-ordinates and the last G command, and F value in class variables.
Then code like
if currentX != previousX
gcode += wordformat('X',currentX)
decides whether or not to include that word in the output, obviously repeated for each axis and F and the G command. don't forget to force the G command when needed!

the one massive problem I had with this was Sketchup's override of the = operator that forces all comparisons to be at the resolution of 0.001" which meant that some things that really should have been not equal would resolve to equal and prevent the output of needed code. I doubt you will have this issue in js but equality in floating point math often requires some extra code so just a heads up.

from openbuilds-cam.

Yip we do the same (store and compare) (: - in JS we also sometimes have that issue, but less common - more decimals to work with (;
Just got to find some time to work on it - theres a long todo list for the gcode generator (tsp problem, plunge, optimise output, more postprocessor style of output to support more firmwares, etc thats been on the todo since the laserweb3 days!

from openbuilds-cam.

and I can add to that list:
I need to engrave a line drawing for my daughter with a V bit.
but I can select an outside cut or an inside cut under router, but no 'just follow this line' like under laser.
but selecting laser does not give me Z height control to get a Z depth.

from openbuilds-cam.

from openbuilds-cam.

No-offset cut: added f6c4ae1
Operation is called "CNC Vector (No Offset)"

from openbuilds-cam.

hi, me again..
looks like the fix is relatively simple:
num.toFixed(4).replace(/0+$/,''); // replace trailing 0's with nothing

by adding the .replace() call to all the string conversions when generating Gcode we should
end up without any trailing zeros BUT never do this for RPM or feedrate , only XYZ

from openbuilds-cam.

yes, 5.0000 will end up as 5. and GRBL does not care.
in fact on some controllers the . is required on the end of all numbers (Fanuc is one IIRC)

another way would be to extend the number object to have a method that trims all trailing 0's and then adds one back on if you end up with a trailing .

from openbuilds-cam.

Good start, but I really want to redo the whole generator - theres too many "if "this feature added later" kinda hacks in there (;

from openbuilds-cam.

that is a common problem with software that grows. a rewrite is great but you still have to deal with the options OR you have to have copies of the 'same' code (the basic gcode output) but one for laser, one for router, one for router with ramping and so on. Then it becomes much easier to forget to propagate changes from one to the rest. SketchUcam has 2 such routines, one for plain milling and one for ramping because when I started adding the ramping to the already 'if' rich routine I quickly realized that it would become just too complicated so copied and pasted. Now the one without ramping also does the laser output. to have all 3 sets of options in one routine is just too much I think and there is no way to simplify it with function calls, it just gets longer and longer.

'they' say that all software should be written 3 times and only the 3rd version gets released. reality (certainly my reality) is just not like that, there is no money for the time.

from openbuilds-cam.