Smoothie support #5
Comments
|
Hi, and thanks for your interest. It would be good to get PanelDue To drive the PanelDue from other boards and firmware, this is what you
M20 S2 It is not essential to return all the variables listed, but missing Any characters with values outside the ASCII range 0 thru 127 (e.g. Please let me know if you need further information. The source code for Best regards David Crocker, Escher Technologies Ltd. On 31/03/2015 20:53, Arthur Wolf wrote:
|
|
Hey ! Thanks for answering so fast. On Tue, Mar 31, 2015 at 11:51 PM, dc42 notifications@github.com wrote:
Have that.
Have that. Defaults to 115200, but it's configurable in the config file.
We have checksums.
I have a problem here with the S2/S3 extensions. M105 is "get extruder temperature". Firmwares already have a way to answer Why didn't you use another G-code like M408 or something ? That's what's The cleanest way I see to implement this in Smoothie ( which is not really Are those S-extensions set in stone ? You are the only one to implement I like the idea of answering JSON, it's going to help a lot for the web Tell me what you think. Cheers !!
Courage et bonne humeur. |
|
The reasons I chose M105 S2 are:
I am not against moving the status poll to another M code, however there btw if you are thinking of doing work on the web interface, then I Regards David Crocker, Escher Technologies Ltd. |
|
On Wed, Apr 1, 2015 at 12:47 AM, dc42 notifications@github.com wrote:
People tend to just pick whatever pops into their mind when adding bits to
Yeah it'd make sense that M408 ( or whatever ) behave the same way.
Yay !
Yes that's definitely a good idea.
There should also be a M-code to ask what formats are supported by a given I think the proposed Reprap Duet status responses should be renamed
We already have something much more complex in the works ( it's called https://github.com/arthurwolf/Mousse Cheers.
Courage et bonne humeur. |
|
Hey ! Got my panel yesterady. Cheers ! On Wed, Apr 1, 2015 at 12:47 AM, dc42 notifications@github.com wrote:
Courage et bonne humeur. |
|
Hi Arthur, The PanelDue is waiting for the response to the M105 S2 command. I can Best regards David Crocker, Escher Technologies Ltd. On 05/04/2015 10:10, Arthur Wolf wrote:
|
|
Hi David, |
|
Hi Chris, the current firmware (1.13) already uses M408 instead of M105. I made this change several months ago at Arthur's request. |
|
Yep, you'll want to update the firmware on the paneldue. On Tue, Mar 1, 2016 at 9:53 AM, dc42 notifications@github.com wrote:
Courage et bonne humeur. |
|
Arthur & Chris, any news on how the Smoothieware support is progressing? |
|
I think Chris is nearly done, and just needs to figure out some multi-extruder stuff. I'd expect to see something soon :) |
|
Sounds good. BTW if you don't want to buffer up command responses to wait for the next M408 poll command to pick them up, you should be able to push them to PanelDue instead. Just send a JSON message similar to a M408 response but with only the seq and resp fields present. |
|
Hi David, Arthur, Chris, I picked up Chris' pull request and progressed it and have the basics working well. I did not know how to contribute to Chris pull request for Smoothie directly, so I am about to just create new pull request from my fork of Smoothieware (my version now moved on from Chris' code quite a bit). There are a couple of things that do not work yet, marked with "TODOs" in the code (for which I will need some of expertise of the Smoothie dev community, I will address in another place). There is one problem, that relates to the PanelDue/RepRepFirmware's tight coupling. To set the extruder temperature, PanelDue does not use M104. Rather it use G10 code, which Smoothie takes as a retract command (took me a while to figure out this was the root cause). I see a couple of options to address this:
Option 3. seems most elegant to me as it also future proofs it a little for PanelDue to deal with other differences in firmware. What do you think? |
|
M104 is standard Reprap Gcode, G10 as retract too, so breaking that is out I think 1 is the only reasonable solution. David : Why are you doing that ? On Tue, Nov 8, 2016 at 10:18 PM, AHHams notifications@github.com wrote:
Courage et bonne humeur. |
|
Good idea on the new pull request. The old one is a mess anyway. I'll update to this when I finally get time to come back to it. The panel might be a bit nicer to use if it could be configured by the M408, i.e if there is no standby temp pass back from the firmware don't show that. It feels a very proprietary right now. |
|
Hi all, First a little bit of history. G10 is the standard CNC NIST code for setting tool coordinate offsets. See e.g. http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374. Adrian Bowyer implemented it as such in RepRapPro's fork of Marlin. So it was really dumb of other Marlin devs to hijack it as firmware retraction. As you guys are big in controlling CNC machines, I am a little surprised that you don't support setting tool coordinate offsets using G10 already. Adrian Bowyer subsequently extended G10 to set tool temperatures too. The M104 command (see http://reprap.org/wiki/G-code#M104:_Set_Extruder_Temperature) is not really adequate for printers with multiple heads because there is no documented way of how to handle multiple heaters, whether on different tools or belonging to a single tool. Likewise M104 does not provided any way of setting standby temperatures, which are highly beneficial for ooze suppression in multi-head printers. So for firmware supporting flexible configuration of tools as RRF does, G10 is the only sensible command to use for setting temperatures. Regarding PanelDue/Smoothieware compatibility, I can see a few options:
I suspect that #4 would work best for you. |
|
@dc42: your 4. is my 3. I guess it would not be too difficult for me to work on a pull request for PanuelDue to deal with this, since you already have the GUI react to geometry. Does it make sense to start adopting the new M408 output as shown here on both ends (as it includes firmwareName in the spec). Or first just add "firmwareName=Smoothieware" to the current output and get that to work first? |
|
On Wed, Nov 9, 2016 at 9:29 AM, dc42 notifications@github.com wrote:
Actually we do, that's a big part of the problem.
Sure there, is, the T command ... no ?
Courage et bonne humeur. |
|
Currently the JSON parser in PanelDue firmware does not support parsing the nested objects that the other status responses use. So for now I suggest adding "firmwareName=Smoothieware" to the existing type 3 status response. On 09/11/2016 10:01, AHHams wrote:
|
|
Hi Arthur, The T command is for selecting a tool. I don't see how it can be used for setting temperatures, let alone for setting the temperatures of multiple heaters on a tool. Cheers David On 09/11/2016 10:06, Arthur Wolf wrote:
|
|
On Wed, Nov 9, 2016 at 11:43 AM, dc42 notifications@github.com wrote:
It's not.
Courage et bonne humeur. |
|
Hi Arthur, Kindly point me to the documentation that describes how M104 is supposed Some people treat Marlin as a de-facto standard, but Marlin is effectively Whereas Adrian Bowyer - the founder of the RepRap movement - documented In the absence of an accepted and documented standard, M104 is IMO not I have no objection to having PanelDue use M104 to set temperatures when Cheers On 09/11/2016 10:47, Arthur Wolf wrote:
|
|
The Reprap Gcode documentation is just de-facto and is often behind the On Wed, Nov 9, 2016 at 12:16 PM, dc42 notifications@github.com wrote:
Courage et bonne humeur. |
|
Done. Just added "firmwareName":"Smoothieware" to output (when static output is requested: i.e., M408 S1 ) of code in my pull request (for Smoothie). |
|
@dc42: what do you expect "probe" to send? I am trying to figure out if there is a meaningful Smoothie equivalent I could implement. |
|
RRF supports both analog- and digital-output Z probes. For analog probes we display the probe output in the range 0 to 1000. For digital probes we use 1000 for triggered and 0 for not triggered. However, as that field is defined as a text field, you could send e.g. "no" and "yes" or "trig" if you prefer. PanelDue does nothing with that value other than display it. |
|
I have just added a new field "numTools" to the extended (M408 S1) status response in RepRapFirmware. This specifies the number of contiguously-numbered tools there are starting from 0. So a value of 3 would indicate that T0, T1 and T2 are available. The next revision of PanelDue firmware will use this field to suppress the tool icons for tool numbers that are not present. You may wish to add this field to Smoothieware's M408 response. |
|
I just added "numTools" support to the pull request against Smoothie. |
|
@dc42: The opinion on the Smoothie side appears to be against supporting enhancing M20 and M36 with JSON output (see comments on the pull request I am working on). On the one hand, I think these JSON outputs are a good way forward, also to support web interfaces better. On the other hand, rather then enhancing existing GCODES with S-switches for JSON output, would it not be better to have one switchable M-code (e.g., 408) to handle all JSON output through various S-switches? This would have several advantages:
|
|
Definitely a +1000 on this.
Reprap messed up Gcode so bad, it's hell to fix things now when trying to
support both reprap and cnc gcode.
So we really don't need even more gcodes to change meaning. M408 is a nice
contained way of adding everything json one would need.
…On Fri, Dec 9, 2016 at 10:53 AM, AHHams ***@***.***> wrote:
@dc42 <https://github.com/dc42>: The opinion on the Smoothie side appears
to be against supporting enhancing M20 and M36 with JSON output (see
comments on the pull request
<Smoothieware/Smoothieware#1059> I am working on).
On the one hand, I think these JSON outputs are a good way forward, also
to support web interfaces better. On the other hand, rather then enhancing
existing GCODES with S-switches for JSON output, would it not be better to
have one switchable M-code (e.g., 408) to handle all JSON output through
various S-switches? This would have several advantages:
1. Consolidation of the JSON output to one module makes is easier to
keep consistent / maintain.
2. People who don't need JSON at all would have easier option to not
include module at all -- avoiding feature bloat for those not interested.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAGpFQZldN2o4MfSGIJXGJX3XH4I8y6hks5rGSUigaJpZM4D4B1X>
.
--
Courage et bonne humeur.
|
|
The current responses are well established in RRF, also some branches of Repetier support them. So we won't be changing them any time soon. M20 has long been the code used to return SD card file information, and using a parameter to specify the reply format is a natural thing to do. The NIST standard does not assign a meaning to M36, and as all the other file-related codes are in the 20s and 30s, that was a natural place to put the file information call. However, if you want to define additional versions of the M408 command for Smoothieware instead, then that's up to you. Be aware that if you need to make changes to PanelDue code that require a lot of extra code to support Smoothieware, then we may end up having to maintain two separate source code trees, because flash space is getting tight in the 5" and 7" builds. That said, just sending a different command according to the host firmware type to elicit exactly the same response should require very little additional code space. |
|
@dc42: I have M20 S2 and M36 almost working, as a temporary setup in my Smoothy pull request, to test. To comply with the design Arthur (and I, to be honest) prefer, I would like this move to M408 S20 and M408 S36, for M20 S2 and M36 respectively. With the M20 S2, I stumbled upon a bit of additional RepRep "propriety" code in PanelDue. It first tries to read from "0:/gcodes". For Smoothie, best would be "/". Perhaps PanelDue should simply leave path empty for first call, so the firmware simply starts from its "default" path? |
|
In an attempt to save a few bytes, I propose Smoothie return "Smoothie" as firmwareName, rather then "Smoothieware" as I suggested prior. |
We could do that, although there might still be a problem when you navigate into a subdirectory. If so, I will change it to start at / instead when the host firmware is Smoothie or Repetier. |
|
Some news:
Is the above correct? Anything else? |
|
Hi David, Great stuff. Sorry for slow response. I only just got a little time again to work on this. Reacting to your points:
Great!
Correct. OctoPrint works this way as well.
Actually, Smoothie's absolute paths start with '/'. My suggestion would simply be to leave the path empty in the initial call of "M20 S2". Let the firmware give back its "default" absolute root path in the "dir" section of the JSON output. Then, for all subsequent calls, insert whatever the printer gave back previously in "dir". This way, your code becomes completely firmware independent in this respect.
Great! For now I am "hijacking" the M20 S2 option in the Smoothie pull request, to make sure I control the output. As soon as I have your new firmware working, I will change it back. |
|
I have one (small) issue in addition: whenever I reset Smoothie, I have to separately (with some delay) also manually reset the PanelDue. PanelDue does not seem to recognise it lost connection and tries to reconnect. Perhaps this is connected to a comment made by wolfmanjm on my Smoothie pull request:
Does PanelDue correctly ignore everything that is not structured JSON output? |
|
Hi,
PanelDue will ignore bad data, but it needs to see a new line character to resynchronise on.
How will Smoothieware react to receiving a command with a high line number in it? I understand it is fussier about line numbers than RRF.
Best regards David
…On 29 January 2017 11:19:31 GMT+00:00, AHHams ***@***.***> wrote:
I have one (small) issue in addition: whenever I reset Smoothie, I have
to separately (with some delay) also manually reset the PanelDue.
PanelDue does not seem to recognise it lost connection and tries to
reconnect.
Perhaps this is connected to a comment made by wolfmanjm on my Smoothie
pull request:
>I presume the Paneldue connects to the serial uart? If so how does it
handle the data we spit out of the serial port on occasions, especially
when we boot up? There is random out of band data sent to the serial
uart for debugging and monitoring purposes.
Does PanelDue correctly ignore everything that is not structured JSON
output?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#5 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
Closing this issue because firmware development for PanelDue was moved to the PanelDueFirmware repository some time ago. |
Hey !
Could you tell me what you think is needed for Smoothie to support this ?
Thanks :)
The text was updated successfully, but these errors were encountered: