Use GRBL instead of TinyG

[metRo_]

Hi,
Did you change the TinyG firmware or you just send G-code commands to it? I'm asking that because I have a grbl shield for arduino so I can save some money here

thank you

[JuKu]

I'm using TinyG in JSON mode. I'm not familiar with GRBL, so I don't know if it has that, but the feedback of JSON is essential. I'm also using TinyG's settings down/upload, and individual settings set/read with JSON. So, it is much more than G-code that is going on.

[metRo_]

I'm using TinyG in JSON mode. I'm not familiar with GRBL, so I don't know if it has that, but the feedback of JSON is essential. I'm also using TinyG's settings down/upload, and individual settings set/read with JSON. So, it is much more than G-code that is going on.

Can you elaborate a little on what type of information you change between the desktop app and the tinyg because I can't think of thinghs diferent than move here or there.

[JuKu]

It is mostly moves, of course. Feedback is important, the software needs to know when movement has stopped. Also, the TinyG settings are done through the desktop app, but you might get away by doing settings outside the app. The z limit switches are reconfigured on the fly.

[metRo_]

I haven't look at your code yet but how hard do you think is to use g-code instead of Jason interface?

[JuKu]

Sending, not very. I don't know what and how GRBL reports back, but the feedback is important, you need to detect when machine has stopped moving. Using JSON, the status reports are automatically parsed, so you need to write a routine that gets the feedback and calls the required status variable update routines. You also need to handle the limit switches reconficuration and connect FET drivers to M commands.

[metRo_]

GRBL also has the feedback report. If someone needs to buy the tinyg vs (arduino + grbl shield) the price diference is only some $. I was thinking on that because I already got the electronics laying around :p

[Lars]

I would absolutely prefer to use GRBL / pure g-code instead of having to use a proprietary tinyG controller as the tinyG hardware is not Open Source
g-code with a feedback (machine move complete) is really more interesting, just imagine having more axis than tinyG or a servo system which can't be run with tinyG.

Best regards!

[bobc]

The problem with GCode is that it is a file format, not a comms protocol. So there is no standard for how a controller should respond to commands. In Reprap, the controller replies with "OK" (or an error message).

"OK" means that the command has been queued for execution, but provides no feedback when the command is completed. The simplest way I think is to add an M-code command "wait for all commands complete".

Either way, you would need to make a small modification to the controller firmware and PC software, it's a small mod, but means you probably couldn't use stock firmware.

I have a bunch of Reprap controllers, I had planned to use one for my PnP machine. I have spent some time working on Reprap firmware (Marlin, Teacup etc), so it would be easy for me to make modifications.

[metRo_]

The problem with GCode is that it is a file format, not a comms protocol. So there is no standard for how a controller should respond to commands. In Reprap, the controller replies with "OK" (or an error message).

"OK" means that the command has been queued for execution, but provides no feedback when the command is completed. The simplest way I think is to add an M-code command "wait for all commands complete".

Using GRBL you have that kind of feedback I just don't know if is automatic or you need to polling it but you definitively know when the machine is working, moving or stopped.