z axes mixed up

[gilles747]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Alex-Canales]

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.