em / gcanvas Goto Github PK

ctx.circle(...)
ctx.circle(...)
ctx.stroke()

For some reason only the last one gets followed

Doing an arc with toolDiameter/2 cancels out to nothing. It should totally do a straight hole.

It's also totally shitty having to use arc at all. Gonna add a drill() method, also thread()

http://www.practicalmachinist.com/vb/cnc-machining/peck-drilling-151128/

Awesome.

Step 1. Remove simulator and browser support once gsim is done
Step 2. Load actual system fonts with libfreetype

Roughing buffers variable stresses that affect finish by first doing a rough cut and then following up with a finishing pass under nearly ideal circumstances and thus better results all around.

Note: Ideal circumstances has arguably more to do with consistent stress than less stress. 1 depth of cut should be ideal and we already have the number.

Not sure how to do the API. Maybe all that's really needed is a context.globalOffset so it can be done with setup blocks:

setup('1/2" roughing', function(ctx) {
  ctx.globalOffset = -ctx.depthOfCut;
  whatever();
});

setup('1/8" finishing', function(ctx) {
   whatever();
});

Gonna have to wait until strokes use the filling algorithm for this to work.

Hi em,
Thank you for your awesome work on this library! I was wondering if it would be at all possible to build a newer version of the build/gcanvas.js file? What would it take? I loaded up the newest version I could find but it doesn't have all the latest functionality. The example file doesn't work without it. It would be immensely appreciated!

Hi everyone.

I'm using Gcanvas with canvg to generate CNC from SVG.

I want to know if it's possible to decrease the amount of generated Gcode commands, for when commands are too close to each other, like less than 0,001 mm (which only makes sense after I convert from px to mm according to my scenario).

A picture is worth a thousand words so, this is what I want to do. I don't remember if I did implemented that or if I just considered, but I'd like to know if it's already implemented in Gcanvas or canvg in any way, shape or form.

Ideally, I wanted to just input a value that relates to how many segments will be generated, so I can fine tune how many segments I need generated based on how long they get generated.

I'm just asking if it's already possible because, if it isn't I imagine it will be a lot of work to implement it.

Thanks in advance.

yep

Hi, when i try to use the single stroke font with the gcanvas, it still converting it to the multiple path g codes, is there a way to achieve single stroke text with gcanvas? Thanks~~~

I am starting to use this lib (nice piece of work) and working with the examples, I generate some gcode (for instance the text "hello world") and looking at the code inside linuxcnc simulator, the text is inverted, as if looked into a mirror.
What am i doing wrong ?

Also, I would like to use feed in mm/minute, thus not using G93 command. Is it possible?

Hi everyone.

I suggest the addition of an option to limit the maximum amount of decimal digits that are output, additionally with the option to choose between truncation and rounding.

If I understood correctly, as it stands, I have to parse the output of the GcodeDriver to extract the values, treat them and reformat the output.

Thanks in advance.

EDIT: finally managed to do it with regex. Using the example from the readme.md and considering no more than 3 decimal digits:

var Gcanvas = require('gcanvas');

var driver = new Gcanvas.GcodeDriver({
  write: function(cmd) {
    // matches a period plus 4 or mode digits; works globally
    console.log(cmd.replace(/[.]\d{4,}/g, match => match.substring(0, 4)));
  }
});

var ctx = new Gcanvas(driver);

Note that this will probably fail if gcanvas outputs commands like G5.1 and you want to remove all decimal digits... Also, I completely disregarded commands that are not movement commands.

I mean... the actual case doesn't make any sense, but it goes down to top, and then helixes upwards to 0 and it's kind of weird. I guess the problem is that it's just not clear in the simulation exactly what you did wrong because it looks like a normal helix path but it's going the wrong direction and you have to know that means you forgot to set a depth.

I think for the sake of air cutting I should min depth to top.

'top' is dangerous because it always plunges down. It would be better to have something where the default assumes the tool is at 0 touching the work surface, and it retracts a safe distance to handle surface tolerances. Just broke a tool because of this...

Meh. I guess I should do this even if it makes the toolpath butt ugly.