Make firmware grbl API compatible

[jbnimble]

To aid in allowing more control software compatibility implement the grbl interface and commands. Current grbl version is 1.1f.

[BarbourSmith]

I fully support this idea. Being grbl compatible would let us use a lot of standard CNC control programs out of the box.

[johnbenweber]

I found someone that forked GRBL to do polar plotting link. Maybe you could use that as a guide for transplanting the appropriate parts from Maslow into GRBL. I'm not too familiar with GRBL but it looks like you would need to implement the advanced kinematics and a motor library (GRBL seems to only support steppers) from Maslow. This route would be more work than just imitating GRBL output and responses but you might gain some refinement and more advanced features that they've developed.

[johnbenweber]

I looked into modifying GRBL. It would be easy to add the Maslow kinematics to GRBL (ala coreXY or the polar plotting fork I linked to previously). Unfortunately it would take almost a rewrite of GRBL to support the gear motors and encoders. I have a feeling you knew this already but I thought I'd record it here anyway for future reference. I am glad the Maslow firmware lives on though.

[BarbourSmith]

I kinda guessed as much for the code around the motors because grbl is written do do very precisely timed interrupt driven stepper motor control while we need closed loop control.

How difficult would it be to just use their serial communication code? That is the part which brings us the most value because it makes the interface to Maslow standard. Then any software used to control a grbl based machine (xcarve, shapeoko, Carvey...Etc) could control Maslow directly.

We might want to grab their gcode parser too, because I'm sure it's more refined than ours now. I think it makes sense to grab the serial code first, then the parser just so we don't break everything too badly in the process.

[BarbourSmith]

After a little digging into their protocol, it's nearly identical to ours. The docs are here which is nice. It shouldn't be too tough to emulate their behavior.

I think we want to be a little bit careful about what we borrow because grbl seems to borrow pretty heavily from the old school world of CNC being something that's pretty tech heavy, and I'd like to push Maslow in the other direction towards being something that uses with limited computer skills can use.

[davidelang]

the interface to the maslow itself is always going to be tech heavy (i.e. gcode), so at that layer, there's nothing wrong with borrowing heavily.

The only place to be concerned is in the possible retirement of Ground Control in favor of an existing grbl UI. That is what the user is going to be seeing.

On Sun, 2 Apr 2017, BarbourSmith wrote:

I think we want to be a little bit careful about what we borrow because grbl seems to borrow pretty heavily from the old school world of CNC being something that's pretty tech heavy, and I'd like to push Maslow in the other direction towards being something that uses with limited computer skills can use.

[johnbenweber]

@BarbourSmith I agree, they have some nice bits of code that have had time to mature and would save some headaches. There are a few somewhat related issues with Firmware and GroundControl that I think need to be prioritized and addressed in order to avoid causing a mess. It might be good to add some tags to issues to give everyone a better idea of the status or priority of specific issues.

@davidelang I don't think that GRBL compatibility will kill GroundControl. User choice is good but having control over GroundControl allows Bar more freedom to implement features how he wants and likely means that GroundControl will be the best option for most people. I think you are right that there is a certain unavoidable tech level. I feel like as long as things work out of the box having technical details that more advanced users can fiddle with provides them with the freedom to do cool stuff.

[davidelang]

to be clear, when I am talking about Ground Control being replaced, it's with the idea that there is a good grbl front-end already available, ideally one that's opensource, so that instead of fighting the basic stuff, any enhancements can be made on the existing project, helping people beyond just maslow users.

I am also thinking that bar is a limited resouce, and his time may be better spent on the parts that are unique to maslow rather than making yet-another-gui-machine-driver. So if there is a grbl compatible gui that is close in functionality to ground control, it may be better to use that than continue developing ground control.

[blurfl]

Here's a good demo of G28. The video is quite thorough about the benefits and sources of error.

[BarbourSmith]

I'm running into this error which from what I'm reading online seems to be a pretty messy one. I'll keep digging.

[blurfl]

Whew! That's been cooking for a long time, and seems to include multiple issues. Is there anything I can do to help?

On Apr 3, 2017, at 10:14 AM, BarbourSmith notifications@github.com wrote:

I'm running into this error which from what I'm reading online seems to be a pretty messy one. I'll keep digging.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[johnbenweber]

@davidelang definitely valid points. I wanted to write a firmware definition for Maslow in Universal G Code Sender a while back but I gave up because I have no java development experience.

@BarbourSmith I did this a while back but got rid of it when I started working on GroundControl. It wasn't fully working but did connect. I think your issue is is just getting the right string to UGS for it to be satisfied you are connected. Try making the initial string when you start up exactly the same as the GRBL one "Grbl 1.1f ['$' for help]" even though you haven't implemented the "$" help menu yet. If I remember right I had more luck with the older release 1.06 which you can get from the readme on their gitub page.

[BarbourSmith]

I think I'm at about the same place. I've got it to where it will connect and I can use the arrow keys to move around. The positional feedback is working too.

I had to ditch the error term from the positional feedback because open loop systems don't have any measure of their error so grbl doesn't report one. We'll have to find a way around that.

You can check out where I am here if you are interested in playing with it.

[BarbourSmith]

I've got it to the point that you can move the machine to the starting location, click "run" and it will start processing gcode. As soon as the z-axis changes depth and the machine returns a request for the user to set the depth on the router it stops working right which makes sense.

I think we're getting close.

I think we need a good way to transfer back information to Ground Control which doesn't break the grbl compatibility for things like setting the z-axis depth and reporting the feedback system error amount.

[mikberge]

i found something interesting about our questions, this is a 3d printer driven by dc motor encoded, all points we want more clearer is maybe here on this site they have all to bring good example ,arduino usb, firmware machine,gcode, https://www.stellamove.com/support/

[davidelang]

to they have an english version? (google translate has it's limits)

[mikberge]

I have installed google translate extension on chrome and I can read 90%

[mikberge]

Nope they don't have English Web site

[mikberge]

you say the z stopped working after one position , may be an error of encoding, if the voltage is too high in last moment it can make more steps than needed and was in error

[BarbourSmith]

I think I've figured out what is going on with the program running for a few lines and then stopping.

To clarify what's happening, I can move the machine around with the arrow buttons in universal gcode sender and I can read the machine's position, but when I try to run a program it executes the first few lines correctly, then stalls. It looks like this:

It will sit there an wait forever.

The problem is that the universal gcode sender is using the streaming protocol with character counting described here .

The universal gcode sender is assuming that the firmware has a 127 character internal buffer which our firmware does not. The extra characters are getting lost in transmission and the result is that we have a state where the gcode sender is waiting for the machine to execute those lines, and the machine has executed all the lines it knows about and is waiting for more lines to be sent.

I think that the solution is to add a 127 character buffer like grbl uses. We'll probably need it down the road anyway to add features like those described in issue #123

[BarbourSmith]

The ring buffer is in place and it seems to have fixed the issue. I can successfully run cuts from Universal Gcode Sender using this branch. I can't actually test cuts on the machine, just the electronics because of building inspections today, but I will test and merge tomorrow morning.

There is still a some clean up to do. I think I messed up the behavior of the stop button.

I am going to make a PR so that I can more easily see what's changed what needs to be cleaned.

[blurfl]

That's great news! 👍👍

On Apr 7, 2017, at 3:58 PM, BarbourSmith notifications@github.com wrote:

The ring buffer is in place and it seems to have fixed the issue. I can successfully run cuts from Universal Gcode Sender using this branch. I can't actually test cuts on the machine, just the electronics because of building inspections today, but I will test and merge tomorrow morning.

There is still a some clean up to do. I think I messed up the behavior of the stop button.

I am going to make a PR so that I can more easily see what's changed what needs to be cleaned.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[mikberge]

So happy to hear that!

[BarbourSmith]

I had issues with the serial buffer overflowing this morning, I think everything is being read smoothly now. This process has been a good way to push the serial parts of the code forward. We need to speed up the speed that gcode lines execute and grbl has laid a lot of the ground work to make that easier.

I will run some test cuts to be sure before we merge it in the morning if the cuts come out ✔️

[BarbourSmith]

I successfully ran a cut today from Universal Gcode Sender!

I'm going to close this issue. I'm sure there are still issues with the way that universal gcode sender works when controlling the program, but I would rather see issues filed for specific bugs than keep this open until the behavior is 100% perfect.

Great suggestion @jbnimble , thanks everyone for the advice along the way!

[blurfl]

Many kudos to you! 👍🏻👍🏻 That was amazingly quick for such a useful feature.

On Apr 9, 2017, at 5:51 PM, BarbourSmith notifications@github.com wrote:

I successfully ran a cut today from Universal Gcode Sender!

I'm going to close this issue. I'm sure there are still issues with the way that universal gcode sender works when controlling the program, but I would rather see issues filed for specific bugs than keep this open until the behavior is 100% perfect.

Great suggestion @jbnimble , thanks everyone for the advice along the way!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[BarbourSmith]

Thanks :)