Support for Smoothieboard? #43
Comments
|
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. |
|
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>
.
|
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 ? |
|
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>
.
|
|
We do have plans to have "instantaneous" ( it never really is, it's really "as fast as possible stop" ) stop. |
|
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>
.
|
|
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 ). So, with Smoothie in it's current state, you have two choices to pause :
So, lots of options, including options where you can both pause fast, and not loose position, even without endstops. |
|
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. |
|
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>
.
|
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.
But we do have it ... |
|
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>
.
|
|
I'm really exited about the possibility of chilipeppr supporting Smoothieboard. |
|
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>
.
|
|
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. |
The smoothieboard now emulates GRBL for GCode syntax, is there any way you could add support for the Smoothieboard ping pong serial connection?
The text was updated successfully, but these errors were encountered: