Support for Smoothieboard?

[funinthefalls]

The smoothieboard now emulates GRBL for GCode syntax, is there any way you could add support for the Smoothieboard ping pong serial connection?

[arthurwolf]

http://smoothieware.org/grbl-mode should make Smoothie very close to GRBL in terms of what commands it accepts.

However, there is only one main difference you need to take care of : Smoothie and GRBL do not exactly have the same serial protocol ( how they say when to send new lines, what a line is etc ).

If somebody wants to add Smoothie supports to CP ( I sent three free Smoothieboards to various people claiming they would do this over the years and it never happened ), I can find out what the exact differences are for them.

I really hope this can happen, Smoothie now has a very large userbase, and those users would really like to be able to use CP.

@wolfmanjm might have some info on this.

[chilipeppr]

Cool. Couple questions then. 1) What is the difference to the OK response that Grbl sends to indicate a line has been processed? That's the core of how Serial Port JSON Server does character counting. 2) Do you still have to poll the device every 250ms for position reports, or does Smoothie's version dish those up automatically? 3) What is the state of feed hold / wipe / resume? Can you feed hold a job, wipe it out, and then jog around to fix it, and then resume it without losing position?

…

On Tue, Feb 21, 2017 at 1:27 PM, Arthur Wolf ***@***.***> wrote: http://smoothieware.org/grbl-mode should make Smoothie very close to GRBL in terms of what commands it accepts. However, there is only one *main* difference you need to take care of : Smoothie and GRBL do not exactly have the same serial protocol ( how they say when to send new lines, what a line is etc ). If somebody wants to add Smoothie supports to CP ( I sent *three* free Smoothieboards to various people claiming they would do this over the years and it never happened ), I can find out what the exact differences are for them. I really hope this can happen, Smoothie now has a very large userbase, and those users would really like to be able to use CP. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbfEai57HPkVO_GmDoLJr_kxNHXxYks5re1bYgaJpZM4MH4Vv> .

[arthurwolf]

1. I don't have the answer off the top of my head, but these two scripts are the "reference" for how to talk to Smoothie :
   https://github.com/Smoothieware/Smoothieware/blob/edge/smoothie-stream.py
   https://github.com/Smoothieware/Smoothieware/blob/edge/fast-stream.py
   I believe those answer that question

2. It is the same as GRBL in that regard, it has the same polling commands ( "?" I believe ? ) as GRBL ( unless GRBL has implemented "pushing" since last time I looked )

3. Yes, see for example http://smoothieware.org/stopping-smoothie, we have suspend/resume commands if playing from the SD card, and if the host is sending the Gcode ( like chilipeppr does ) then you just need to stop sending Gcode.

More generally, the idea is that there was quite a lot of work done to make Smoothie "mostly" compatible with grbl's coms in grbl mode. bCNC for example, which was written for grbl, had very little to modify to get it to work with Smoothie, maybe you can ask it's author about what they had to do, that would probably save you a lot of effort. @vlachoudis ?

[chilipeppr]

Hi Arthur, Per your answer on question 3, are there any plans for Smoothie to allow instantaneous stop with deceleration where software like ChiliPeppr can send in the command? If ChiliPeppr just stops sending Gcode, that would seemingly take a while for Smoothie to stop moving as it works through its planner buffer. When I'm doing CNC work on aluminum or acrylic, the most critical thing I have found is when a problem happens and I have to feedhold quickly. I will have to do something like crack melted acrylic off my endmill. I want to then be able to resume the job without problem meaning if I did a feedhold, and then cancel, do you lose your XYZ position because you have to reset the device? I heard you have a physical kill button on Smoothie, but that you sort of lose your XYZ position on a kill. Another way of looking at this is I think laser and 3D printing jobs tend to not need an iterative feedhold process like CNC for hobbyists does. I wish I didn't have to feedhold so much, but any time I'm doing a new project I tend to feedhold constantly because I screwed something up over and over, but being able to seamlessly resume is then a critical step.

…

-John

On Thu, Jun 15, 2017 at 5:05 AM, Arthur Wolf ***@***.***> wrote: 1. I don't have the answer off the top of my head, but these two scripts are the "reference" for how to talk to Smoothie : https://github.com/Smoothieware/Smoothieware/ blob/edge/smoothie-stream.py https://github.com/Smoothieware/Smoothieware/blob/edge/fast-stream.py I believe those answer that question 2. It is the same as GRBL in that regard, it has the same polling commands ( "?" I believe ? ) as GRBL ( unless GRBL has implemented "pushing" since last time I looked ) 3. Yes, see for example http://smoothieware.org/stopping-smoothie, we have suspend/resume commands if playing from the SD card, and if the host is sending the Gcode ( like chilipeppr does ) then you just need to stop sending Gcode. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbYtha-t-JPJCX9LKVDTi7ZgsHwpmks5sER4NgaJpZM4MH4Vv> .

[arthurwolf]

We do have plans to have "instantaneous" ( it never really is, it's really "as fast as possible stop" ) stop.
Technically, by tuning some parameters ( segments per millimeters and queue length ), you can actually get it down to under half a second ( by reducing the length that is actually buffered to a mininum ), but that's a bit of cheating. You can also just use kill ( which stops instantly ) then home the machine.
I don't think how fast it stops is a critical part of making chilipeppr compatible with Smoothie though. To answer your question : It's a planned feature.

[chilipeppr]

This sounds excellent if that feature is on its way. As part of that though, can you resume your job without re-homing? I (and I think many others) still don't have end stops and thus re-homing is not an option to get back a known position. Even if you have end-stops they're not perfectly accurate. So the challenge is making sure on a kill, or instant stop, to not lose position. If you're milling a 4 hour long acrylic job, you'll end up feedholding like 20 times to fix things, and losing position is so devastating it defines which CNC controller you pick.

…

On Thu, Jun 15, 2017 at 9:39 AM, Arthur Wolf ***@***.***> wrote: We do have plans to have "instantaneous" ( it never really is, it's really "as fast as possible stop" ) stop. Technically, by tuning some parameters ( segments per millimeters and queue length ), you can actually get it down to under half a second ( by reducing the length that is actually buffered to a mininum ), but that's a bit of cheating. You can also just use kill ( which stops instantly ) then home the machine. I don't think how fast it stops is a critical part of making chilipeppr compatible with Smoothie though. To answer your question : It's a planned feature. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidba2W7i66zIdfsP-R7KL9-hL3DUMwks5sEV4tgaJpZM4MH4Vv> .

[arthurwolf]

I don't mean to be the "just do that" guy, but endstop cost only a few $, are in fact precise enough, and take only very little effort to install and wire. There's a reason pro machines all have them, you really really want to install endstops. We really don't, on Smoothie's side, intend to support "I don't have endstops" as a normal use case for the controller ( though it happens that there are ways to use it that way anyway ).
And trust me, I know where you are coming from, I've assembled DIY machines and spent years using them without endstops, I know how you feel. But as a controller board editor, we have to make some choices, and one of those is "you are supposed to have endstops on your CNC mill".

So, with Smoothie in it's current state, you have two choices to pause :

1. Use suspend/resume ( or stop sending gcode ), which takes a long time to stop with the default config, but under a second to stop with some config tuning, and allows to jog and then resume without homing or loosing position.
2. Use kill, which is instantaneous but requires you home using the endstops before starting again.

So, lots of options, including options where you can both pause fast, and not loose position, even without endstops.

[wolfmanjm]

I will add a pull request soon which adds the ! and ~ feed hold. However they are not instantaneous, but if you set the segments to 1mm then the maximum it will travel after a feed hold is 32mm, if you set the segment to 0.1mm then the maximum travel after a feed hold is 3.2mm. This is the best we can do for now, as instant hold is extremely difficult to implement.

[chilipeppr]

I hear ya on getting endstops. It is the right way to do it, but even then, just having to re-home doesn't sound great if you feedhold 20 times during a 4 hour job. The challenge here is in the TinyG world we really do have instant stop, jog around, redo your touch plate process if you broke an endmill, and then resume without ever losing position. It's really nice and as far as I can still tell no other controller supports this. I never thought this would be as big of a deal as I have found it to be. So every time somebody says "hey, you gotta try Smoothie for CNC" it's this issue that makes it not workable for me and I think others who focus on milling. I will add though that when I'm laser cutting, I never really end up needing the feedhold and so it's made me realize that when you prioritize features for a controller and you focus on the use case, the use cases tend to define what gets priority. So I totally understand where you're coming from.

…

On Thu, Jun 15, 2017 at 11:23 AM, Jim Morris ***@***.***> wrote: I will add a pull request soon which adds the ! and ~ feed hold. However they are not instantaneous, but if you set the segments to 1mm then the maximum it will travel after a feed hold is 32mm, if you set the segment to 0.1mm then the maximum travel after a feed hold is 3.2mm. This is the best we can do for now, as instant hold is extremely difficult to implement. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbbJKWnAWFoV0M0SpPrDg1OLL5unhks5sEXapgaJpZM4MH4Vv> .

[arthurwolf]

« we really do have instant stop, jog around, redo your touch plate process if you broke an endmill, and then resume without ever losing position. It's really nice »

Well, Smoothie has that too, as I said. It's just not perfectly instant, but if you edit your config it can be very fast ( few millimeters, barely more than your hand takes to get to the stop button ... ). Working on making it closer to instant.

« it's this issue that makes it not workable for me »

But we do have it ...

[chilipeppr]

I think a few millimeters is workable. So this sounds exciting.

…

On Thu, Jun 15, 2017 at 12:02 PM, Arthur Wolf ***@***.***> wrote: « we really do have instant stop, jog around, redo your touch plate process if you broke an endmill, and then resume without ever losing position. It's really nice » Well, Smoothie has that too, as I said. It's just not perfectly instant, but if you edit your config it can be very fast ( few millimeters, barely more than your hand takes to get to the stop button ... ). Working on making it closer to instant. « it's this issue that makes it not workable for me » But we *do* have it ... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbVpyrucwrr7B4NY9IY3s5We8lsARks5sEX-5gaJpZM4MH4Vv> .

[arthurwolf]

I'm really exited about the possibility of chilipeppr supporting Smoothieboard.
Jim has done a ton of work on the grbl compatibility stuff so that we can get compatible with more software, and the community as a whole has done a lot of thinking on this too.
I've sent 3 smoothieboards over the years to various people saying they would make CP compatible with Smoothie but nothing has come of it yet, which has been a bit frustrating. If you need one I can send you one. We just want smoothie users to have access to CP :)

[chilipeppr]

I only recall one guy getting a board from you, Jarrett Luft, who ported the TinyG workspace to Grbl. He did a great job on the Grbl workspace and was a brilliant programmer. It would have been great if he was able to get a Smoothie workspace way back then. Sadly I don't think he does much CNC anymore. I never heard of any other folks mentioning it in the CP Google+ page or Google group. So, not sure what/where on those. For me, I am worried my schedule right now won't result in me having time to help, so I'd hate for a board to go to waste. I'm trying to think of some other active folks who might be open to building out a workspace. One question for you to determine amount of work and feasibility. Does Smoothie send back JSON (or other parseable text) when it thinks it needs to, rather than the approach Grbl always used of you having to ask it the "?" command over and over? My understanding was that Grbl ran out of timers on the Atmel and thus you had to query it on a constant basis (i.e. 250ms) because there wasn't enough RAM, ROM, or timer slots to make it auto-send out updates on change of data. With Smoothie being on new bad-ass chips, can you act more like TinyG does where it tells you everything whenever it thinks you need to know it? I say this because the Grbl serial port buffer algorithm in SPJS has de-duping code in it so that asking ? every 250ms doesn't generate massive text traffic back to the browser and bog down the websocket with otherwise redundant data like X:0, Y:0, Z:0 coming in every 250ms while your machine sits idle. The de-duping code creates a lot of traffic on the serial port of redundant info, but there was no way around it, because it was still important to try to get updated info quickly so the ChiliPeppr is showing near real-time data.

…

On Thu, Jun 15, 2017 at 1:07 PM, Arthur Wolf ***@***.***> wrote: I'm really exited about the possibility of chilipeppr supporting Smoothieboard. Jim has done a ton of work on the grbl compatibility stuff so that we can get compatible with more software, and the community as a whole has done a lot of thinking on this too. I've sent 3 smoothieboards over the years to various people saying they would make CP compatible with Smoothie but nothing has come of it yet, which has been a bit frustrating. If you need one I can send you one. We just want smoothie users to have access to CP :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbUji9Ask3BZ5h0vwlf9-9z20Y9Paks5sEY8HgaJpZM4MH4Vv> .

[arthurwolf]

I'd have to look quite hard to find who the other two were, I believe they were pointed out by people from the LW community as people who had contributed to CP and would be ready to work on a SB workspace.

We don't have a feature where we send data every X second, you have to ask with ? like with grbl.
However, one thing we do have, is that you can have two serial ports ( over the same USB cable ) instead of one, which makes life much much easier : you use one to stream gcode, and the other to ask ? whenever you want. Would that work ?