Smoothieware support

[arthurwolf]

Hi.

Smoothieware is a GRBL port originally, and uses essentially the same protocol to communicate ( with some things missing )

It'd be very nice to make bCNC compatible, that'd make plenty of Smoothie users happy.

We can probably even send a board for testing.

Tell us what you think.

Cheers.

[HomineLudens]

Hi @arthurwolf
Being a grbl derivate I think it can be done.

Recently there has already been a user here #123 that asked for support.
I gave a look a fast look that day but didn't find a how to stream gCode to Smoothie. Pronterface seems to use a different approach than grbl, uploading the whole file instead of send part of gcode untill the small atmega buffer is full.

I'm just curious to understand what differs from grbl.
I think @vlachoudis is the only one can decide for give support to another board.

[arthurwolf]

Hey.

Smoothie uses the same kind of "wait for ok before sending" buffer/communication.
But it doesn't have the non-gcode-standard stuff ( $, $$, Ctrl-X ) GRBL added.

Pronterface does both streaming ( and is compatible with grbl ), and uploading entire files, you choose which one you use.

Cheers.

[vlachoudis]

Hi @arthurwolf

I think that is possible to make bCNC compatible with the smoothie board at least for the basic things that are "equivalent" with grbl. I was just looking your website. I see that the board has a lot of extra features (more axis, sd card support etc..). If these additional features of smoothieware needs to be controlled by the interface then it would require more work.

Cheers
Vasilis

[arthurwolf]

@vlachoudis No you could ignore all those extra features, and just get it to communicate simply, and that'd already be a great help to Smootihe users.

[vlachoudis]

OK if I have something to experiment with, it should be doable.

[arthurwolf]

Can you contact me at wolf.arthur@gmail.com, with your shipping adress ?

I'll send you a 4XC board with a broken stepper motor driver or mosfet.
Should still be fine for testing communication, and will even be adequate
for a cnc router or laser cutter ( or 3D printer if you wire an external
driver or replace the broken one ).

Cheers !

On Sun, Oct 25, 2015 at 9:44 PM, Vasilis Vlachoudis <
notifications@github.com> wrote:

OK if I have something to experiment with, it should be doable.

—
Reply to this email directly or view it on GitHub
#143 (comment).

Courage et bonne humeur.

[vlachoudis]

Don't worry all is need is something to communicate with.

[vlachoudis]

I was thinking that since smoothie is grbl based that the communication would be similar. But reading your documentation I understand that there a lot of differences. Many of the features of bCNC depends on the grbl communication protocol eg probing, auto leveling, function evaluation, feed overrides.. If my understanding is correct it would imply a lot of changes in the code

[arthurwolf]

Hey there.

If some functions are not implemented right away, it's no problem. As long
as basic gcode sending and jogging works, it'll already be a lot of use to
Smoothie users. I'm sure other people will come in and contribute more if
the basic stuff is added.

Cheers.

On Wed, Nov 11, 2015 at 10:18 PM, Vasilis Vlachoudis <
notifications@github.com> wrote:

I was thinking that since smoothie is grbl based that the communication
would be similar. But reading your documentation I understand that there a
lot of differences. Many of the features of bCNC depends on the grbl
communication protocol eg probing, auto leveling, function evaluation, feed
overrides.. If my understanding is correct it would imply a lot of changes
in the code

—
Reply to this email directly or view it on GitHub
#143 (comment).

Courage et bonne humeur.

[arthurwolf]

Hey, sorry for the delay.

I just asked our shipping department to send a board to you.
Please don't feel obligated to do anything, it's just to help you in case you want to add Smoothie support.
Please know a lot of people would love to see that added, and @wolfmanjm the main Smoothie dev likes the bcnc software, and could probably help you implement whatever is missing in Smoothie.

Cheers !

[wolfmanjm]

FYI I am adding grbl-like responses to grbl-like commands, so things like $# will work $H etc. $$ won't as it makes no sense for smoothie.
Streaming you just send stuff, and consume the ok, the USB takes care of flow control so you don't need to worry about buffer sizes and stuff so it is easier than grbl., although I could add dummy buffer sizes if it makes it easier, as there is no buffer per se it'll always be big. Also I'll add ? responses although we have something similar, it just returns a different format.

PS I love bCNC I use it on my CNC running grbl at the moment as there is no equivalent for smoothie.

[vlachoudis]

Great. If responses are similar will make easier the integration. However I am thinking that is better to create a specific sender routine for smoothie inside bCNC, and the user on setup could choose the controller type.

[vinz1080]

Hello, Is smoothiware already supported? Just downloaded and tested last version of bCNC with my smoothieboard but I wasn't able to connect to my board. I selected the right COM port and smoothie type but no communication at all.

Thank you and greetings from Meyrin :)

[wolfmanjm]

It should connect, however there is a bug in streaming gcode which is being worked on at the moment.

[vinz1080]

Hi Jim,
thank you for your reply. Just a question : is this issue smoothie or bCNC related? Just to know which component I will need to upgrade when a fix will be available. I'm of course available to test if you need.

[wolfmanjm]

You need the very latest edge smoothie, and add a grbl_mode true # to the config.

The streaming issue is in bCNC and has not yet been fixed AFAIK.

[vlachoudis]

@vinz1080 there is some inconsistency on how grbl vs smoothie replies to the the streamed commands. So you can jog and send jobs, but in the end bCNC remains in a stalled state. I will try to fix it in the coming days. I am in Meyrin right now :)

[vinz1080]

@vlachoudis Thank you. Hope you can find a solution to this issue.

[wolfmanjm]

I tested this the other day and was able to dry run a relatively large CNC job, so I think it is mostly working already with the current master.
There are a few minor issues, but for the most part is seems t work.

[tuxun]

Hi everyone.
Just a word to note: I'm also pro-smoothie support.
I also would like to see an extension system allowing someone to create new gcode sender, for new board, even if not serial based. Here we have an "2D hotwire cutter CNC" (PWM friendly) http://www.cncfilchaud.fr/full-presentation/ , seen as a HID device, speaking "IPL5X". http://5xproject.dyndns.org/5XProject/tiki-download_file.php?fileId=389
I don't want bother you with that, but I would like a guide to start, on the wiki. I think everyone should try to fork bcnc and make it speak to their machine: there is plenty of CNC boards waiting to start again everywere :)

[vlachoudis]

bCNC was created as a grbl sender, so there are a lot of grbl specific parts in the code here and there. To make it speak to various controllers it would be better to organize the code before. Actually I've tried to split the sender from the gui but I never really complete the job.

[wolfmanjm]

I've been using this with smoothie, and for the most part it works quite well.

One issue I ran into is when you pause it will see it is in HOLD state but clicking pause again will not unpause. I can connect to smoothie with the second usb serial and manually type ~ and it continues. So for some reason BCNC is not sending ~ to smoothie when you click unpause.

On a side note smoothie currently cannot pause immediately safely, so it can take a long time to actually pause as it needs to clear the buffer, I plan to fix this ASAP.

[vlachoudis]

I believe this is similar with the '?' problem with Smoothie. For some reason after some time it requires a "new line" to accept the "?". Most probably the same happens with the second "~" that smoothie waits for a new line that never comes.

[uli99]

Hi,

does bCNC in combination with smoothie already support autoleveling?

I'm using bCNC with both GRBL (milling PCBs) and Smoothie (lasercutter) but haven't tried milling a pcb with smoothie.

Uli

[wolfmanjm]

I'm thinking that it should work, however smoothie has a builtin grid leveling system, it is called delta grid and should work for PCB milling as well as deltas.

[uli99]

ok. thanks, I'm gonna try this weekend and will report if it works.

Uli

[wolfmanjm]

The pause Issue is not related to the multiple ? issue, I actually seem to have fixed that (I think) it was an output issue not an input issue.
Right now clicking pause does pause sending but the status does not change to Hold, so clicking pause again does not clear it. it is basically locked up. Smoothie is in Hold mode though as can be seen by sending ? on another communication port.

?<Hold,MPos:-0.1250,-0.1250,-0.1200,WPos:-0.1250,-0.1250,-0.1200>

I can clear it by sending ~ on that other serial port. however bCNC is locked up at this point and the only solution is to abort.

[kg5000]

I wanted to try bCNC with my SmoothieBoard. Will the latest stable release (two months ago) work or do I need edge? Also, which bCNC release is needed for the latest Smoothie support.

Thanks for bringing the awesome bCNC to Smoothie.

[kg5000]

Couldn't figure out how to edit my precious connect with the mobile Git web site.

To clarify I was asking about Smoothie firmware version that works with bCNC.

[MoonCactus]

I wish I knew where to put this poor man implemention of M0 in bCNC in order to have Smoothieware purge its buffer (and respect the M0 command). Otherwise, it makes it mostly useless without an automatic tool changer, and the nice tool change macro fails badly.

I tried different places with no luck,

  if app.controller == Utils.SMOOTHIE and line[0] == "M" and line[1] == "0":
    # Smoothie ignores feed holds, we need to pause buffering further gcodes ourselves
    tkMessageBox.showinfo(_("Pause (M0)"),_("Press OK to resume. Last comment is %s"%(CNC.comment)),parent=app.self)

One of the best place would be in def compileLine(line, space=False) in CNC.py, but I failed to find the proper object instances to refer to in this static method (sorry, I am a noob in python).

Note that the comment may be useful to tell which tool to set (in the case of tool change). This is only a preliminary test.

[vlachoudis]

I don't think that compileLine is the right place, it is executed before sending to the controller anything.
The way it is done now is a bit more complicated, since all the monitoring is performed in a separated thread and tkinter is not multi threaded in several linux, the controlling thread communicated with messages with the main process.
I would prefer if it is possible to modify the existing CNC.py: def toolChange() and have the functionality somehow embedded there using what already exists.

[MoonCactus]

I realized it the hard way, and in the end I was was not able to get M0 implemented in a respectable way in bCNC. So I cowardly moved away from Smoothieware and switched to GRBL 1.1 on a Nano. I could try again as I left my SW board inside of the stepper driver enclosure, but I am unsure I want to get back to it...
Nb: I listed my issues with SW as a CNC controller here in case you are interested http://www.tridimake.com/2017/05/replacing-linuxcnc-with-smoothie-milling.html

[wolfmanjm]

@MoonCactus Ihave to say you are just plain wrong on at least two of the complaints you made in your posting.

1. G0 feedrate uses the last G0 feedrate specified NOT the last G1, this is plain wrong. G1 and G0 have their own feedrates. Maybe you never set your G0 feed rate? in which case it can be set as a default in the config set it fast and you have rapid G0 feedrates that are not affected by G1. This may be an issue with bCNC which may use G0 for jogs, in which case don't blame smoothie.

2. Alarm is NOT sticky in smoothie, it clears perfectly well with $X, the issue is a bug in bCNC again which I have an open issue for. For some reason bCNC does not clear the Alarm state for Smoothie by sending $X.
   Issue Stop does not unlock in Smoothie mode #558

[MoonCactus]

Hi @wolfmanjm

1. If I understand well, you are borrowing the last G1 feedrate when none was explicitly set for G0, right?

1a) But why not set G0 to the maximum machine speed by default (instead of seek speed as stated in http://smoothieware.org/g0)? This would make more sense ("rapid" move) and it would improve compatibility overall, and may be respect the different maximum speed according to the axis.

1b) And no, I am not talking about jogs in bCNC, but real G0 gcode commands (check, e.g. how I "fixed" the probing procedure #576 / ef0086a to have Smoothieware stop overriding G0 unspecified feed rate with that of the latest G1)

2. Yes, I already have stated that sticky alarms may be due to bCNC. But there is no such problem with other firmware like GRBL, so at least they do not cooperate well and some bug is triggered in bCNC by something special to Smoothieware. Since sending manual reset command fails from the command line from within bCNC it appears like the link is down.

[MoonCactus]

Now to be honest, I think I remember seeing something like a switch to "override feed rate" in bCNC, along a comment that states it was for debugging though (I would certainly not have activated it willingly!). @vlachoudis certainly knows better how bCNC behaves when no feed rate is specified on G0 moves, and if it could be done after the command is sent to the log (that would be viciously unsafe!)

[vlachoudis]

There is no setting anywhere in bCNC for setting the G0 feed rate.
I presume that if one sends from the command line G0 F### it will send the rapid-feed rate for smoothie.

[wolfmanjm]

@MoonCactus No G0 feed rate is NEVER taken from G1 ever. G0 has its own feedrate and only takes its feedrate that is specified on a G0 command. If an Fxxx is never specified for G0 then it uses the default seek feed rate from the config. so just set that to your max speed.
If bCNC never issues a G0 with Fxxx then it will not set the G0 speed.

[chamnit]

For the record, @wolfmanjm and I established on a separate issues thread that G0 should not have a programmable feed rate. This is something that Smoothie uniquely does (and possible some other hobby CNC firmwares) and goes back to the NIST standard that is vague about this rule. It can be interpreted as being allowed.

That said, LinuxCNC, Grbl, and other major CNC controllers do not allow the F word to program G0 rapids and only use it to program G1/2/3/38.x and other normal feed rates. G0 rapids are established in settings and always move at the maximum rate, primarily to reduce job time, unless scaled down with overrides. Sometimes overrides can be programmable through g-code, depending on the controller, but not by using the F word.

AFAIK, it's done this way to reduce operator error and crashes, because F can't be mistaken in terms of context to a G0 or G1/2/3/38.x.

[MoonCactus]

Given what @vlachoudis & @wolfmanjm say, G0 in bCNC should always run at the same (default) feedrate then? But why did I have to set a bare "F" before G0 in bCNC leveling procedure then (btw it worked inline also, but this is less portable AFAIK). One way or another, the G0 were otherwise re-set to the probing feedrate. My fix may be in the wrong place.

Note: If I understand well, the "feed" field in the control tab reflect the last F feed rate (or inline G1 F). I am fine with it, except that IIRC it also impacted the rapid moves with a smoothieboard. I will triple check whenever I can.

@chamnit all you say make sense.

I also understand partly why G0 could have its own feedrate. But this seems to be particular, and not really occam's razor though: the maximum machine feed rate is set for a reason, and having one single rapid feedrate for all axes is probably not optimal either.

[chamnit]

@MoonCactus : At least in Grbl,G0 does not have a "feedrate". It did in older versions of Grbl as a setting and was removed because it was wrong. Grbl v0.9+ moves at the maximal rate that a given direction can go. That is limited purely by the max speed of each axis by vector addition. That's about as optimal as you can get.

[wolfmanjm]

@chamnit G0 having a speed being "wrong" is your opinion and is not fact!

[chamnit]

@wolfmanjm : For production milling, the preference is to reduce job time, since time is money. The machine should travel as fast as it can during 'G0' rapid motion. So in that view, having a simple rate magnitude on G0 is wrong. For example, if you move diagonally in two axes, you can move up to 1.414 times the max rate of the individual axes. Again, Grbl follows the standard set by LinuxCNC and other production controllers.

[MoonCactus]

I think the real practical issue is not which interpretation is "better", but that Smoothieware in grbl_mode true should behave, well, like GRBL. It does NOT make sense to have such a flag otherwise :/

[wolfmanjm]

@MoonCactus the issue here is that I think yo used G38.2 to probe, and that in fact uses G0 behind the scenes and therefore sets the G0 seek rate to very slow. that has since been fixed so it does not change the seek rate for future G0. SO the G0 will use the seek rate set in config unless you specifically override it.
As for grbl_mode.. it is impossible to be 100% compatible, I did the bare minimum to allow bCNC to work. and as GRBL and I have very specific disagreements on how some things should be done, we will never be more than barely compatible.

[MoonCactus]

@wolfmanjm may be, but this fix would not have been required in the first place if you had used GRBL paradigm in GRBL compatibility mode (!): you added this flag, but you keep on refusing some of GRBL interpretations precisely because yours differ? I then disagree on your interpretation of the word "compatible"... ;)

Sure, 100% may be impossible, but the issue with G0 is not a technical one. You probably lose both customers, would-be contributors and a few CAM authors who do not care about interpretations that differ from mach3 & linuxcnc. You also would not have to explain and justify your choices again and again... Everyone would be happy, and legacy mode would be kept unchanged.

Instead of polluting bCNC, I was about to fork smoothieware and fix it on its side for my own need (with no pull requests - I tried once, was not welcomed). But I ended up using 100% pure GRBL and it was a breeze. I will give MachineKit or GRBL-LPC a try when I need more power. As for my smoothieboard, it will go back into a printer where it does shine.

[wolfmanjm]

You are the ONLY one wanting the G0 to change. Arthur made G0 the way it is for a reason, changing it would break backward compatibility, and to be honest I dislike the way GRBL and linuxcnc handle G0 so I have no interest in "fixing" it as it is not broken

I think you need to be able to specify feedrate for G0. Just because some other firmware do not is not a reason for smoothie to be considered broken. The NIST spec even shows an example of F being used with G0 so please don't try to tell me this is not in the NIST gcode spec. Your use case is one out of a ton of others that prefer it the way it is.

[MoonCactus]

No biggie & will not talk about it further and especially if I am the only one to complain.

Just note I was only focusing of the explicit "GRBL compatibility mode" and never said Smoothieware is broken (I just say that GRBL compatibility mode could be improved). If you read me correctly for the last years, you know how much I promoted the Smoothieboard & ware for 3D printing. Cheers & over.

[chamnit]

@wolfmanjm : As in our previous discussions on this (and others have complained including myself), I would love to see where in the NIST document that it explicitly states F being used for programming G0 traverse/rapids rates. I've scoured it in the past and just now and there is nothing that supports your argument, except for two things.

First, there is a set of test code in the NIST document (pg 36) that shows an F word being programmed with a G0, but this is interpreted as setting up the feedrate for the following probe motion, not the G0 motion itself. There isn't proof to support your argument. In fact, everything in the NIST document that talks about G0 is explicitly in terms of 'traverse' rate. Not 'feed' rate. No where does it state that the 'F' word alters the 'traverse' rate. Only 'feed' as it should.

Second, there isn't anything written explicitly in the NIST document that explains how 'traverse' rates are set. It never states that it is set with 'F'. It only is shown as a function call, which is to be set by the UI. Not g-code. It's arguable that this is unclear.

Just to be clear to argue part of your point is that 'traverse' rate can technically be an arbitrary vector magnitude like Smoothie does, but it also can be set to infinity/max, where axes limits constrain it, which Grbl does. As I said before in prior conversations, there is no problem with setting 'traverse' speed lower than the maximal speed of the machine to have a set point-to-point rate. LinuxCNC does this also as a setting. Grbl will too in the next version, but neither allows programming of the G0 'traverse' rates via the 'F' word.

I also talked with a our machinist at work about this. He's been around the industry since the first CNCs with tape reels and punch cards. He's taught classes, run several shops, and is the go-to guy for making the most complex of prototype parts at my lab. I trust him fully. He stated that G0 implementations have changed over the years, but, he's never seen, ever, a controller that allows G0 to be programmed by an 'F' word. This is a standard.

I would love for you to prove me wrong. I will gladly declare that I was wrong and you were right, if you can point me to something that shows that you can alter G0 'traverse/rapid' rates with an F word. It's always either rapid overrides or some setting. Never F.