search

em / gcanvas

CNC milling with HTML5 canvas
95 stars 19 forks source link

z axes mixed up #10

Open gilles747 opened 10 years ago

gilles747 commented 10 years ago

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?

em commented 10 years ago

Could this be due to linuxcnc using z- as towards the bed, and gcanvas using z+?

Try ctx.map('xy-z')

Still debating weather or not to invert Z by default. It makes no sense, but other tools seem to do it...

em commented 10 years ago

As for non inverse time mode feeds. What exactly goes wrong with G93? There's a lot I can do to make it works across different drivers but I need to know exactly what to degrade to based on what's in the wild.

FYI G93 is always better, if the driver supports it.

em commented 10 years ago

Oh and you can currently get around G93 by just not setting ctx.feedrate and setting it beforehand in your controller, or ctx.driver.send('F1000')

I recently learned that GRBL doesn't support G93. Since G93 is really all about 4 axis milling (it allows you to control how an radial axis move in ratio to a linear axis). I could just use plain F command feedrates until radial axis motion is used.

em commented 10 years ago

Yo. Try it now. I went ahead and inverted Z by default so Z- is towards the bed like everything else uses.

Also I published an early version of my simulator: https://github.com/em/gsim

Still needs a lot of work.

gilles747 commented 10 years ago

Regarding G93, it generates really high numbers after the F, like 200000 and I wondered what could be the cause of such high number and how it is calculated. Somehow I would like to set the speed to a constant value. Also the owner of the fab lab does not use G93 and as such is not too keep that I use this option. I can try, though, in theory there is nothing wrong with it.

gilles747 commented 10 years ago

Regarding the axes orientation, this is better, but there is still something strange; in order to have a stroke('hello world') to display correctly in linuxcnc (or any other simulator I have tried), I needed to do a ctx.map('x-yz'). I wonder if there is a problem with the standard axes orientiation.

em commented 10 years ago

Actually that is -Y... Ok... two problems here.

  1. Y is still opposite of linuxcnc... : [ my bad
  2. I should have made the map() string have some separator character so x-y isn't ambiguous.

Ugh. I really hate the linuxcnc coordinate system but it does seem to be the most common... I'll go ahead and swap Y and add something to the top of the readme saying it uses the same coordinate system as linuxCNC: http://linuxcnc.org/docs/html/common/images/mill-diagram.png

em commented 10 years ago

Actually.. I don't know if I wanna do that yet. I have to think about it. I'm wondering if lineTo(100,100) becoming g1 x100 y-100 is a lot worse than not being compatible with linuxcnc...

Maybe what we really need is some kind of global ~/gcanvas-config.js that gcanvas(1) always runs so you could do any prepatory setup for your machine, like map()

em commented 10 years ago

Z didn't matter because standard canvas has no Z, but when Y gets inverted that's kinda f'ed.

Alex-Canales commented 9 years ago

To get the real Y value, you need to subtract the total size of the operation on the Y axis by the Y coordinate.

realY = height - y;

The joy to translate a coordinate from a screen to a coordinate in classical orthogonal reference...

By the way, your work is amazing, too bad I cannot use it now because of this issue.