Yeah, I knew the SVG needed reworking to be used to create gcode but my point was that OBCam shouldn't hang on it.
Calculating toolpath offsets is quite a lor of maths that needs good data to work from. With bad data (ie files that are not toolpath friendly, has missing indexes, odd points etc) it has to work extremely hard to try and figure it out. Internally we use Clipper (just like many other applications like Slic3r, vectric, easel, lw4, jscut and many more does under the bonnet) The paid applications uses propriety code to "fix" broken files but you wont be seeing much of that in "Free / entry level applications"
and I thought Sketchup was the only one to produce sequences of arcs with reversed endpoints (-: The solution in sketchup is to use the BZ tools plugin to 'create polyline' which reorients all the segment directions. You only need to do this when the 'phlatten' tool fails to create a clean outline.
Oh no, soooo many applications do that! Someday when I get a couple days to work on it, Clipper has some tools to helps with that but any new layer introduced adds complexity that needs a lot of testing
Hello I'm trying to generate a gcode for cutting with an acro 1515, blackbox controller and 10w endurance laser. One point I don't get is that even if I choose "laser operations vector" , the generated gcode does not turn on laser on/off for each path: it turns it on once at the start and off after all paths are processed. I need it to turn on before each path and turn off when moving between paths (G0 moving). On top of that, how do I get rid of Z Safe Height? setting it to 0 does not work. I attached the openbuildscam gcode and an example of what I'd like. Could someone please help ?
Did you setup Grbl Laser Mode properly : $32=1 most important one to set. Read gnea/grbl for full details Re the Safe Height, will check and fix soon, for now 0.001 should work
what he means is that all Z moves should be replaced by M3/M5 but the file only has a starting M3 and an ending M5, as for a router. I tried it myself and that is what I got, Z moves and M3/M5 as for a router. The above is required if $32=0 else you get laser cut lines between objects in the job. When $32=1 then G0 moves will turn the laser off which achieves the same thing as a M3/M5 per block. I see that the gcode contains extraneous F and S words, which is something that can contribute to streaming errors for short line segments since each line is much longer that it really needs to be and GRBL has to work harder to process each line (same with the trailing zeros which should be trimmed). so Code: ; GCODE Generated by cam.openbuilds.com on 2019-09-10 G21 ; mm-mode G21 G90 G17 F1000 M3 ; Operation 0: Laser: Vector (no path offset) ; Tool Diameter: 20 G0 Z0 G0 F1000 X0.0000 Y50.0000 G0 Z0 G1 F600 Z-0.1000 G1 F800 X100.0000 Y50.0000 Z-0.1000 S760 G1 F800 X100.0000 Y0.0000 Z-0.1000 S760 G1 F800 X0.0000 Y0.0000 Z-0.1000 S760 G1 F800 X0.0000 Y0.0000 Z-0.1000 S760 G1 F800 X0.0000 Y50.0000 Z-0.1000 S760 ; retracting back to z-safe G0 Z0 M5 G53 G0 Z0 G0 X0 0 M30 should be Code: ; GCODE Generated by cam.openbuilds.com on 2019-09-10 G21 ; mm-mode G21 G90 G17 ; Operation 0: Laser: Vector (no path offset) ; Tool Diameter: 20 G0 Z0 G0 X0.0 Y50.0 M3 S1 ; move this here, where it was it caused a 100% power flash before the job starts G1 Z-0.1 S760 F600 G1 X100.0 Y50.0 G1 X100.0 Y0.0 G1 X0.0 Y0.0 G1 X0.0 Y50.0 ; retracting back to z-safe G0 Z0 M5 G53 G0 Z0 G0 X0 0 M30 is there a howto somewhere for setting a dev environment? maybe I can fix some of this for you.
note its for a Laser... Check the Grbl Wiki gnea/grbl (Laser Mode page): laser Mode in grbl works like this: M3 or M4 at the start of the Job enables the laser (you kind want M4 though as it adapts power as a function of acceleration which looks better) Then G0 moves are laser-off G1/2/3 moves are Laser On M5 at the end disables it. In particular gnea/grbl - we use the second suggestion (G0 to disable) as its better standard As G0 vs G1/2/3 is the ON/OFF you dont want M3/5 between entities, thats long gone Grbl 0.9 way of doing things. Grbl 1.1's been with us since 2016 hehe with this way... People just sometimes forget to set $32=1; Laser Mode (its in our Machine profiles so I assume user forgot to load ours) We are up to spec on that man (; - is SketchuCam? I do agree taking out Z moves for laser, seperate issue, like i said - have to investigate why thats back - took it out a couple months ago but we did go through a heavy rewrite to move the CAM ops to webworkers to speed things up so it mustve jumped back in. Remove Z moves from laser operations · Issue #55 · OpenBuilds/OpenBuilds-CAM
PS @RaphK you should also check, CAM -> Settings -> Select the Acro profile (it sets M4 instead of M3) Your file shows S250. Is this a 25% burn (default grbl settings has S1000 = max power)
quite, I was editing my post after clicking post a bit too soon... not perfectly, but well within usefulness (-: SketchUcam generates an M3/4 and M5 pair for every (what would have been a ) Z move. This does work correctly with GRBL as far as I can tell, guess I need to push 'install laser' to the front of the long list of things to do. Here is a sample output from SketchUcam Code: % (Generated by SketchUcam V1.5-58fdf15) (Bit diameter: 3.0mm) (Feed rate: 2000.0mm/min) (Plunge Feed rate: 1000.0mm/min) (Material Thickness: 6.0mm) (Material length: 790.0mm X width: 550.0mm) (Overhead Gantry: true = Conventional Cut) (Plunge Diam First) (Optimization is ON) (LASER for GRBL PWR) (Origin offset ~ 9.0mm, ~ 11.1mm) (www.PhlatBoyz.com) G90 G21 G49 G17 F1000 G00 X0 Y0 M05 G00 X0.000 Y0.000 M04 S30000 G01 X100.000 F2000 G01 Y50.000 G01 X0.000 G01 Y0.000 M05 G00 X9.387 Y74.671 M04 S31500 G01 X42.806 F2000 G01 Y96.471 G01 X9.387 G01 Y74.671 M05 G00 X0 Y0 (home) M05 M05 M30 %
ahh man, edited posts suck (; as my reply now doesnt address the first wrong reply lol! in short form yes... except! M3/5 stops motion. Start/ends of burns will have crisp little spots. Fine for cuts, sucks for engravings. Grbl Laser Mode is awesome and see no reason to recommend hacking around a perfect solution Which is your old and still open issue Todo: Optimise G-Code Generator: Don't repeat F/S commands unless changed, also remove modal commands that repeated) · Issue #9 · OpenBuilds/OpenBuilds-CAM Priorities! (see Build software better, together )
Hi, thanks all for your replies! I try to digest all this, I'm just a newbie... by the way, I found a gcode optimiser (optimizing the traveling salesman problem for G0) that seems promising, do I open a ticket on github for integrating it on openbuildscam? https://xyzbots.com:4000/gcode-optimizer/
Unfortunately in the real world its not so good. It changes order of pocket operations and all other kinds of messes. Played with it a lot, its was coded by a former devpartner of mine (; Works well on "certain" files but that eliminates it from integration. It has to be very clever and work on everything. There are better ways of solving it than that... Way better. Post processing gcode, why, when we have the raw data to work with. OpenBuildsCAM is low priority though, most code time is spent in CONTROL. Majority of users go for Fusion or Vectric for CAM. OpenBuildsCAM fills that bottom end of free and kinda easy to get you started but we really hope you move on to better as your skills grow Too busy making even more awesome stuff, but hey when it slows down, there's still a lot of work to be done on CAM (see git for just some of whats on the todo)
Hello after some cuts, all is perfectly working as per Peter Van Der Walt and David the swarfer said: set $32=1; Laser Mode G0 moves are laser-off G1/2/3 moves are Laser On no need for M3/M5 between entities Thanks all for your help! By the way, if someone is aware of an illustrator plugin to export gcode to blackbox, please let me know. At the moment, I'm trying to modify Diego Monzon's illustrator2gcode panel. So far, I modified the G0 instead of G1 setting but there is still a scale issue.
Hello Peter, I have gotten the machine working and am now addressing GCODE. I have looked at several documents that explain gcode and am now ready to proceed to the next step. Just so you know, when I press the cam.openbuilds.com link at the bottom of OpenBuilds CAM page, I receive a 404 Error. But when I copy the link and paste in the browser, it takes me to the correct CAM page. I am intending to use the Workbee 1510 as a drag-knife. In configuring the Gcode generator, drag-knife is does not appear as a tool option. The closest option seems to be the "Plotter Pen" option. Will this work?
Thank you will let the store team know about the link In the Setting tab, there is no "tool" for Dragknives as they dont require any interface, no startup commands, etc. Its not a powered tool. They just sit at the end of the z axis and are controller by the z axis Everything else happens in the toolpath setup
Thank you for the help. I have not as yet discovered how to increase the F (speed) value in the code generator. Is the speed limit a function of the machine capability? Is the 1000 value the highest I can expect of the Worbee 1510?
hello why the plunge ops on the code came at 400? after reaching 0? forgive the rookie ; GCODE Generated by cam.openbuilds.com on 2019-10-21 G21 ; mm-mode G54; Work Coordinates G21; mm-mode G90; Absolute Positioning M3 S1000; Spindle On ; Operation 0: Drill: Continuous (Centered) ; Tool Diameter: 3.00 G0 Z10 G0 F1000 X14.9674 Y26.9679 G0 Z0 G1 F5 Z0.0000 G1 F400 X14.9674 Y26.9679 Z-6.0000 S1000 G1 F400 X14.9674 Y26.9679 Z0.0000 S1000 ; retracting back to z-safe G0 Z10 M5 S0; Spindle Off
You mean retracting out of the hole, you'd prefer it to happen at a faster rate than feedrate? The logic behind feedrate for the retraction is that the flutes may be packed with chips, so its a safety thing
if you notice on the code the z goes down at 5mm/s until z0 the the plunge is at 400 in and out why is that?
Added comments next to commands: G0 Z10 ; We start off by raising to Z10 G0 F1000 X14.9674 Y26.9679 ; We then G0 over to above the starting point G0 Z0 ; As per the gcode standard we G0 down to Z0 as thats free air (Z0 = top of material, so from Z10 to Z0 is done at max feedrate (G0 in Grbl runs at the configured max feedrate) G1 F5 Z0.0000 ; This is the line you mention, it wont execute as we are already at Z0 from the line before, but, CAM does allow starting at non Z0 starting points to, then this line would have an effect. In your case it exists and is ignored. I do notice the F5 though, which is weird, will investigate it. G1 F400 X14.9674 Y26.9679 Z-6.0000 S1000 ; Plunge down to Z-6 G1 F400 X14.9674 Y26.9679 Z0.0000 S1000 ; Retract ; retracting back to z-safe G0 Z10 So: Still not sure what you are asking: But in reference to: F400 is what you set as the plunge feedrate, the F5 move is ignored as you are already at Z0 from the preceeding G0 move
Can you export your workspace so I can look into where the F5 move comes from? (File -> Export Workspace (.obc) ZIP the OBC file to attach it here
What I set was a feed rate of 5, that is my confusion here, why is doing it at 400 where that number came from
Ahh see now you included the detail that kept me guessing... So still, give me your OBC and we'll look into it
Logged as official bug: Center Drill, wrong plunge feedrate used in gcode output · Issue #58 · OpenBuilds/OpenBuilds-CAM
im changing the "f" rate manually on the text editor but let me know if can be fixed later to test it
