Updated jogging commands to use G1 instead of G0

[hchahine]

Using G0 to jog or outline will ignore set feedrate and go to grbl maximum set feedrate. This is usually undesirable and messes with the UI since it's ignoring what one has set in Laserweb panel. Replaced all with G1 instead to respect actual setting supplied in LW.

[ghost]

No one else reported issues... Also, cannot merge this. Its ignorant of a) gcode standards and b) the other firmwares we support (sending G1 to Smoothieware turns on the laser. If S!=0 was sent sometime before. Or if no S was sent yet it will default to 80% power. Grbl in Laser Mode should do the same. This is a really wreckless change

See https://github.com/LaserWeb/LaserWeb3/blob/master/public/js/jog.js#L22 dis you set your feedrate appropriately on the UI in the inpits below the jog buttons?

[ghost]

As an update: if grbl doesn't support F with G0, its not our fault. Open a request on grbl's side to have it added, or set your default seek rate appropriate ly in $$

[hchahine]

Yes, I did set the feedrate appropriately. Machine did not respond to these. This is why I noticed something's not quite right with the grbl/LW interface. I thought grbl adhered to standards.

https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration#110-111-and-112--xyz-max-rate-mmmin

"$110, $111 and $112 – [X,Y,Z] Max rate, mm/min" ..."NOTE: This max rate setting also sets the G0 seek rates."

In grbl, a G0 will ignore suppied feedrate and just go to max seek rate so there is no configurability with feedrates via LW if using G0 which would be pretty handy (at least when outlining).

It appears as of 1.1e there is a new jogging mode:

https://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging

Perhaps, using this could help along with having a switch in software to use seperate jogging commands for smoothieware vs grbl

[chamnit]

@openhardwarecoza : G0 shouldn't accept an F feed rate word at all. It always runs at some fixed speed, usually max. It can't be altered by gcode but can by a rapid override.

I know that Smoothie accepts a seperate F word for G0's. Last week or so, we established this mistake by Smoothie, not Grbl. To be fair though, the NIST standard wasn't explicitly clear on this while LinuxCNC is (and was tested to ensure the correct way).

[ghost]

(: no problem Sonny, as i said, if you configure default seek rate appropriately its not been an issue yet.

I will accept a pull to hide the UI for the feedrates if firmware == grbl just to clean it up, but i definitely still wont allow G1 jog moves (:

On Jan 22, 2017 7:22 AM, "Sonny Jeon" notifications@github.com wrote:

@openhardwarecoza https://github.com/openhardwarecoza : G0 shouldn't accept an F feed rate word at all. It always runs at some fixed speed, usually max. It can't be altered by gcode but can by a rapid override.

I know that Smoothie accepts a seperate F word for G0's. Last week or so, we established this mistake by Smoothie, not Grbl. To be fair though, the NIST standard wasn't explicitly clear on this while LinuxCNC is (and was tested to ensure the correct way).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/pull/223#issuecomment-274309997, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2yexDoQzsp96fZ9__P59llKytL0Vks5rUueSgaJpZM4LqRlD .

[hchahine]

There is no default seekrate anymore only max. Either you set your machines max to something low so that seeking via G0 is reasonable BUT you will limit you machines work potential OR you set your machines max to actual desired max and deal with super fast jogging/bounding without any configurability via GUI.

I know in software we can distinguish between grbl and smoothieware firware but does LW know the version? I'd be happy to have a go at putting in a switch to allow this feature to work as expected if firmware = = grbl >v1.1 using new jogging modes.

I accept not using G1 for jogging at all and maintaining support for smoothieware but I would like to see the same behaviour in grbl.

[ghost]

Yes we do detect firmware in frontend (to enable the speed/power overrides if supported)

On Jan 22, 2017 7:36 AM, "hchahine" notifications@github.com wrote:

There is no default seekrate anymore only max. Either you set your machines max to something low so that seeking via G0 is reasonable BUT you will limit you machines work potential OR you set your machines max to actual desired max and deal with super fast jogging/bounding without any configurability via GUI.

I know in software we can distinguish between grbl and smoothieware firware but does LW know the version? I'd be happy to have a go at putting in a switch to allow this feature to work as expected if firmware = = grbl

v1.1 using new jogging modes.

I accept not using G1 for jogging at all and maintaining support for smoothieware but I would like to see the same behaviour in grbl.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/pull/223#issuecomment-274310462, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2wtE9hMoJVVTAqc7dKvUbC1JlhEeks5rUuregaJpZM4LqRlD .

[tbfleming]

I thought LW switched to GRBL 1.1's jogging commands, J$= instead of G0 or G1. J$= has a feedrate.

[ghost]

Not yet. Thats why i say, happy to accept a pull that looks at firmware == grbl. I just wasnt happy with the G1 plan

On Jan 22, 2017 7:59 AM, "Todd Fleming" notifications@github.com wrote:

I thought LW switched to GRBL 1.1's jogging commands, J$= instead of G0 or G1. J$= has a feedrate.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/pull/223#issuecomment-274311142, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2-DEx9g_VuDmf_qkHdC8g4NVd098ks5rUvBSgaJpZM4LqRlD .

[cprezzi]

I don't think it makes sense that the frontend has to adjust for firmware differences! I have moved most of the differences already to the backend (in lw.comm-server) so the frontend can just send "jog x +10" to the backend, which translates it to gcode corresponding to the connected firmware.

[ghost]

Ahh yes thats true (though frontend will need to adapt by hiding the two feedrate inputs) Existing implementation in lw3 sends g0's using sendGcode() from frontend though https://github.com/LaserWeb/LaserWeb3/blob/master/public/js/jog.js

[cprezzi]

At the end I'd like to have a "supported features" command that tells the frontend what to render.

[ghost]

I like that (:

On Jan 22, 2017 5:08 PM, "Claudio Prezzi" notifications@github.com wrote:

At the end I'd like to have a "supportet features" command that tells the frontend what to render.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/pull/223#issuecomment-274336297, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr28qXgbHJEh1TX9usWgeJ--UcVn5yks5rU3DUgaJpZM4LqRlD .

[cprezzi]

Today I have reworked the jogging and outline function. The frontend now just calls the jog command on the server, and the server decides the correct commands depending on the detected firmware.

For Grbl, we use the new $J= command now (for jogging and outline), which uses the entered jog feeds. This also allows to have the "laser test" switched on (if configured to toggle) while jogging or outline, which is very usefull on diode lasers.

[hchahine]

Great stuff! Thanks Claudio. I think this is a great update for this issue and keeps the grbl/LW union strong ;-)