dc42/PanelDue

Smoothie support

arthurwolf opened this issue · 39 comments

arthurwolf commented

Hey !

Could you tell me what you think is needed for Smoothie to support this ?

Thanks :)

dc42 commented

Hi, and thanks for your interest. It would be good to get PanelDue
supported by other firmware, that would increase the volume and allow a
substantial reduction in the price.

To drive the PanelDue from other boards and firmware, this is what you
need to do:

  1. Identify a spare serial port on the board, to which PanelDue can be
    connected.
  2. Add firmware code to initialize that port, accept gcodes from it,
    and send responses to those gcodes to it. PanelDue currently defaults to
    57600 baud, but this is configurable and the default may be increased to
    115200 baud in future. It uses 8 data bits, 1 stop bit, no parity bit.
  3. Preferably, add the facility to ignore commands received from the
    serial port that do not include a valid checksum, in order to increase
    the immunity to noise. PanelDue always sends a line number (which is
    currently always zero) and a checksum when it sends commands.
  4. Implement support for the following gcodes, as documented at
    http://reprap.org/wiki/G-code:

M20 S2
M36
M105 S2
M105 S3

It is not essential to return all the variables listed, but missing
variables may cause the functionality to be reduced.

Any characters with values outside the ASCII range 0 thru 127 (e.g.
accented character in filenames) are sent and received in UTF-8 format.
Currently, PanelDue supports code points 0 thru 255 only (i.e. Latin-1).
If Smoothieware uses the fatfs library to access the filing system on
the SD card, then fatfs already does the necessary UTF8 encoding and
decoding, provided you configure an appropriate code page in the fatfs
config file.

Please let me know if you need further information. The source code for
PanelDue firmware is at https://github.com/dc42/PanelDue.

Best regards

David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

On 31/03/2015 20:53, Arthur Wolf wrote:

Hey !

Could you tell me what you think is needed for Smoothie to support this ?

Thanks :)

—
Reply to this email directly or view it on GitHub
#5.

arthurwolf commented

Hey !

Thanks for answering so fast.

On Tue, Mar 31, 2015 at 11:51 PM, dc42 notifications@github.com wrote:

Hi, and thanks for your interest. It would be good to get PanelDue
supported by other firmware, that would increase the volume and allow a
substantial reduction in the price.

To drive the PanelDue from other boards and firmware, this is what you
need to do:

  1. Identify a spare serial port on the board, to which PanelDue can be
    connected.

Have that.

  1. Add firmware code to initialize that port, accept gcodes from it,
    and send responses to those gcodes to it. PanelDue currently defaults to
    57600 baud, but this is configurable and the default may be increased to
    115200 baud in future. It uses 8 data bits, 1 stop bit, no parity bit.

Have that.

Defaults to 115200, but it's configurable in the config file.

  1. Preferably, add the facility to ignore commands received from the
    serial port that do not include a valid checksum, in order to increase
    the immunity to noise. PanelDue always sends a line number (which is
    currently always zero) and a checksum when it sends commands.

We have checksums.

  1. Implement support for the following gcodes, as documented at
    http://reprap.org/wiki/G-code:

M20 S2
M36
M105 S2
M105 S3

I have a problem here with the S2/S3 extensions.

M105 is "get extruder temperature". Firmwares already have a way to answer
to that that is very standard.
There is no clean way to add all the other information to the output that
would be coded in a clean fashion.
Using M105 for this complexifies things enourmously if the firmware is very
partitionned like Smoothie.

Why didn't you use another G-code like M408 or something ? That's what's
usually done for new functionality.
That would have been easier and even trivial to implement in other
firmwares then, and wouldn't interfere with existing functionality.

The cleanest way I see to implement this in Smoothie ( which is not really
clean at all, but less wrong than others ) is to implement a "PanelDue
compatibility" module that answers if S2/S3 is present, and teach the other
modules to ignore M20/M105 if S2/S3 is present.
But I don't like that at all ...

Are those S-extensions set in stone ? You are the only one to implement
them as far as I can see.
Could you use new G-codes for this ? ( and still keep your firmware
answering to the S-extension for backwards compatibility ) ?
Would that be very difficult ?

I like the idea of answering JSON, it's going to help a lot for the web
interface :) But the syntax you have now to ask for it is problematic.

Tell me what you think.

Cheers !!

It is not essential to return all the variables listed, but missing
variables may cause the functionality to be reduced.

Any characters with values outside the ASCII range 0 thru 127 (e.g.
accented character in filenames) are sent and received in UTF-8 format.
Currently, PanelDue supports code points 0 thru 255 only (i.e. Latin-1).
If Smoothieware uses the fatfs library to access the filing system on
the SD card, then fatfs already does the necessary UTF8 encoding and
decoding, provided you configure an appropriate code page in the fatfs
config file.

Please let me know if you need further information. The source code for
PanelDue firmware is at https://github.com/dc42/PanelDue.

Best regards

David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

On 31/03/2015 20:53, Arthur Wolf wrote:

Hey !

Could you tell me what you think is needed for Smoothie to support this ?

Thanks :)

—
Reply to this email directly or view it on GitHub
#5.

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

Courage et bonne humeur.

dc42 commented

The reasons I chose M105 S2 are:

  1. There was already a proposal to use M105 S1 to send back additional
    status information, see the wiki.
  2. Some firmwares already treat M105 specially, in that they allow M105
    requests to be processed even while other gcode commands are stalled
    waiting for something to happen, e.g. waiting for temperatures to
    stabilise. This same functionality is useful for the status information
    requests made by PanelDue.

I am not against moving the status poll to another M code, however there
should still be an S parameter to indicate the format requested. The
JSON response returned by M105 S2 is almost identical to the response
returned by the web interface until about a month ago. However, the web
interface has moved on since then, and the response for the new web
interface is a much more complex JSON structure. It is likely that I
will eventually change PanelDue firmware to request this more complex
structure, in order to increase functionality. So the M408 (or whatever)
code should take an S parameter to indicate the version of the response
required, just as the web interfaces does. See
http://reprap.org/wiki/Proposed_RepRap_Duet_Status_Responses for the
new-format status responses.

btw if you are thinking of doing work on the web interface, then I
strongly suggest you look at
https://github.com/zombiepantslol/DuetWebControl to avoid re-inventing
the wheel.

Regards

David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

arthurwolf commented

On Wed, Apr 1, 2015 at 12:47 AM, dc42 notifications@github.com wrote:

The reasons I chose M105 S2 are:

  1. There was already a proposal to use M105 S1 to send back additional
    status information, see the wiki.

People tend to just pick whatever pops into their mind when adding bits to
the communication protocols like this :)
Which is why we have several G-codes with dual meaning, or differing
outputs ...
I really think "return general information about the machine as JSON" is
different enough from "return temperatures as short string" to warrant it's
own M-code.

  1. Some firmwares already treat M105 specially, in that they allow M105
    requests to be processed even while other gcode commands are stalled
    waiting for something to happen, e.g. waiting for temperatures to
    stabilise. This same functionality is useful for the status information
    requests made by PanelDue.

Yeah it'd make sense that M408 ( or whatever ) behave the same way.

I am not against moving the status poll to another M code,

Yay !

however there
should still be an S parameter to indicate the format requested.

Yes that's definitely a good idea.

The
JSON response returned by M105 S2 is almost identical to the response
returned by the web interface until about a month ago. However, the web
interface has moved on since then, and the response for the new web
interface is a much more complex JSON structure. It is likely that I
will eventually change PanelDue firmware to request this more complex
structure, in order to increase functionality. So the M408 (or whatever)
code should take an S parameter to indicate the version of the response
required, just as the web interfaces does. See
http://reprap.org/wiki/Proposed_RepRap_Duet_Status_Responses for the
new-format status responses.

There should also be a M-code to ask what formats are supported by a given
board ...

I think the proposed Reprap Duet status responses should be renamed
proposed Reprap status responses :)
Then we get those implemented into Smoothie, and we have a standard :)

btw if you are thinking of doing work on the web interface, then I
strongly suggest you look at
https://github.com/zombiepantslol/DuetWebControl to avoid re-inventing
the wheel.

We already have something much more complex in the works ( it's called
Mousse, and it's built with modules like Smoothie ), with lots of crazy
features planned
But it'd be nice to get the communication protocols as close as possible
together, so that Mousse could talk to a Duet, and DuetWebControl could
talk to a Smoothie ...

https://github.com/arthurwolf/Mousse
https://www.youtube.com/watch?v=NKwcuq5O-mc

Cheers.

Regards

David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

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

Courage et bonne humeur.

arthurwolf commented

Hey !

Got my panel yesterady.
Tried it just now. The panel itself works, but when connected to the
Smoothieboard, it always says "connecting" but never actually connects.
Is this something to be expected from not having the M105 S implementation ?
Or is the panel waiting for some specific "welcome message" from the
Smoothieboard ? ( that's a problem we often have with GRBL-centric host
applications that expect the board to say "grbl" when it boots )

Cheers !

On Wed, Apr 1, 2015 at 12:47 AM, dc42 notifications@github.com wrote:

The reasons I chose M105 S2 are:

  1. There was already a proposal to use M105 S1 to send back additional
    status information, see the wiki.
  2. Some firmwares already treat M105 specially, in that they allow M105
    requests to be processed even while other gcode commands are stalled
    waiting for something to happen, e.g. waiting for temperatures to
    stabilise. This same functionality is useful for the status information
    requests made by PanelDue.

I am not against moving the status poll to another M code, however there
should still be an S parameter to indicate the format requested. The
JSON response returned by M105 S2 is almost identical to the response
returned by the web interface until about a month ago. However, the web
interface has moved on since then, and the response for the new web
interface is a much more complex JSON structure. It is likely that I
will eventually change PanelDue firmware to request this more complex
structure, in order to increase functionality. So the M408 (or whatever)
code should take an S parameter to indicate the version of the response
required, just as the web interfaces does. See
http://reprap.org/wiki/Proposed_RepRap_Duet_Status_Responses for the
new-format status responses.

btw if you are thinking of doing work on the web interface, then I
strongly suggest you look at
https://github.com/zombiepantslol/DuetWebControl to avoid re-inventing
the wheel.

Regards

David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

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

Courage et bonne humeur.

dc42 commented

Hi Arthur,

The PanelDue is waiting for the response to the M105 S2 command. I can
do you a variant that uses M408 instead (I think that's what you
suggested) if it helps.

Best regards

David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

On 05/04/2015 10:10, Arthur Wolf wrote:

Hey !

Got my panel yesterady.
Tried it just now. The panel itself works, but when connected to the
Smoothieboard, it always says "connecting" but never actually connects.
Is this something to be expected from not having the M105 S
implementation ?
Or is the panel waiting for some specific "welcome message" from the
Smoothieboard ? ( that's a problem we often have with GRBL-centric host
applications that expect the board to say "grbl" when it boots )

Cheers !

On Wed, Apr 1, 2015 at 12:47 AM, dc42 notifications@github.com wrote:

The reasons I chose M105 S2 are:

  1. There was already a proposal to use M105 S1 to send back additional
    status information, see the wiki.
  2. Some firmwares already treat M105 specially, in that they allow M105
    requests to be processed even while other gcode commands are stalled
    waiting for something to happen, e.g. waiting for temperatures to
    stabilise. This same functionality is useful for the status information
    requests made by PanelDue.

I am not against moving the status poll to another M code, however there
should still be an S parameter to indicate the format requested. The
JSON response returned by M105 S2 is almost identical to the response
returned by the web interface until about a month ago. However, the web
interface has moved on since then, and the response for the new web
interface is a much more complex JSON structure. It is likely that I
will eventually change PanelDue firmware to request this more complex
structure, in order to increase functionality. So the M408 (or whatever)
code should take an S parameter to indicate the version of the response
required, just as the web interfaces does. See
http://reprap.org/wiki/Proposed_RepRap_Duet_Status_Responses for the
new-format status responses.

btw if you are thinking of doing work on the web interface, then I
strongly suggest you look at
https://github.com/zombiepantslol/DuetWebControl to avoid re-inventing
the wheel.

Regards

David Crocker, Escher Technologies Ltd.
http://www.eschertech.com
Tel. +44 (0)20 8144 3265 or +44 (0)7977 211486

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

Courage et bonne humeur.

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

chrisbrent commented

Hi David,
My PanelDue arrived (well it's at DHL waiting for me to pick it up :) and I've been working on the M408 code for Smoothie. Can you do me a variant that asks for that instead of M105 S2?
Chris

dc42 commented

Hi Chris, the current firmware (1.13) already uses M408 instead of M105. I made this change several months ago at Arthur's request.

arthurwolf commented

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:

Hi Chris, the current firmware (1.13) already uses M408 instead of M105. I
made this change several months ago at Arthur's request.

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

Courage et bonne humeur.

dc42 commented

Arthur & Chris, any news on how the Smoothieware support is progressing?

arthurwolf commented

I think Chris is nearly done, and just needs to figure out some multi-extruder stuff. I'd expect to see something soon :)

dc42 commented

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.

AHHams commented

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:

  1. PanelDue starts using M104 to set temp, rather than G10
  2. Smoothie implements the G10 code same as RepRapFirmware.
  3. PanelDue adepts to the firmware in the M408 response (not yet in the old S1 output spec though). And PanelDue adapts it behaviour according to the firmware it is dealing with (e.g., more elegantly deal with Smoothie not supporting a "standby" temperature).
  4. Other?

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?

arthurwolf commented

M104 is standard Reprap Gcode, G10 as retract too, so breaking that is out
of question.
http://reprap.org/wiki/G-code#G10:_Tool_Offset

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:

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:

  1. PanelDue starts using M104 to set temp, rather than G10
  2. Smoothie implements the G10 code same as RepRapFirmware.
  3. PanelDue adepts to the firmware in the M408 response (not yet in the
    old S1 output spec though). And PanelDue adapts it behaviour according to
    the firmware it is dealing with (e.g., more elegantly deal with Smoothie
    not supporting a "standby" temperature).
  4. Other?

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?

—
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/AAGpFahWdqiNNIa6sqGPWZo_atZRvWb-ks5q8OcWgaJpZM4D4B1X
.

Courage et bonne humeur.

chrisbrent commented

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.

dc42 commented

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:

  1. Use a separate PanelDue firmware build for Smoothieware. Not a good option for users.
  2. Add a firmware configuration option in the Setup page to specify which firmware is being used. Better than (1) but still not good.
  3. Change Smoothieware to handle G10 the way RRF does, i.e. treat it as a retraction command if there is no P parameter, and a command to set tool offsets and/or temperatures if there is.
  4. We add a field in the M408 extended status response to identify the host firmware. When Smoothieware is detected, the behaviour is changed to send M104 instead of G10. I presume you would also want the standby temperature fields hidden if you don't support them. There are a few decisions you will need to make, e.g. if the user tries to change the temperature on a head other than the one selected, what should be the response? Also it might be wise to change Smoothieware to ignore a G10 command with a P parameter, in case the user tries to change temperatures before the firmware type has been established.

I suspect that #4 would work best for you.

AHHams commented

@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?

arthurwolf commented

On Wed, Nov 9, 2016 at 9:29 AM, dc42 notifications@github.com wrote:

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.

Actually we do, that's a big part of the problem.

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.

Sure there, is, the T command ... no ?

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:

Use a separate PanelDue firmware build for Smoothieware. Not a good
option for users.
2.

Add a firmware configuration option in the Setup page to specify which
firmware is being used. Better than (1) but still not good.
3.

Change Smoothieware to handle G10 the way RRF does, i.e. treat it as a
retraction command if there is no P parameter, and a command to set tool
offsets and/or temperatures if there is.
4.

We add a field in the M408 extended status response to identify the
host firmware. When Smoothieware is detected, the behaviour is changed to
send M104 instead of G10. I presume you would also want the standby
temperature fields hidden if you don't support them. There are a few
decisions you will need to make, e.g. if the user tries to change the
temperature on a head other than the one selected, what should be the
response? Also it might be wise to change Smoothieware to ignore a G10
command with a P parameter, in case the user tries to change temperatures
before the firmware type has been established.

I suspect that #4 #4 would work
best for you.

—
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/AAGpFSJKUNn1TXqdnRKi81cXiy9IROjQks5q8YR9gaJpZM4D4B1X
.

Courage et bonne humeur.

dc42 commented

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:

@dc42 https://github.com/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
http://reprap.org/wiki/RepRap_Firmware_Status_responses 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?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/ACmEbO26qxcYZhNBQ3zrSEYeg3rFXG1zks5q8ZnxgaJpZM4D4B1X.

dc42 commented

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 9:29 AM, dc42 notifications@github.com wrote:

...

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.

Sure there, is, the T command ... no ?

arthurwolf commented

On Wed, Nov 9, 2016 at 11:43 AM, dc42 notifications@github.com wrote:

Hi Arthur,

The T command is for selecting a tool. I don't see how it can be used
for setting temperatures,

It's not.
M104 is used for setting the temperature for the heater associated to a
specific tool.
This is standard Reprap gcode as far as I know. It's what the slicers do,
it's what we do, I believe other firmwares do this too.
Nobody asked us to have several heaters associated with a single tool yet,
but I don't see why that couldn't be done with an extension to M104 ...

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 9:29 AM, dc42 notifications@github.com wrote:

...

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.

Sure there, is, the T command ... no ?

—
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/AAGpFbO2BBzBnP-m2_Gy35Xlxwc3QyYVks5q8aPbgaJpZM4D4B1X
.

Courage et bonne humeur.

dc42 commented

Hi Arthur,

Kindly point me to the documentation that describes how M104 is supposed
to be used for setting the temperatures of different tools. According to
http://reprap.org/wiki/G-code#M104:_Set_Extruder_Temperature it has a
single parameter S, except that Teacup supports a P parameter as well. I
have seen one slicer emit M109 commands with a T parameter, but again I
can find no documentation for what this is supposed to mean.

Some people treat Marlin as a de-facto standard, but Marlin is effectively
undocumented since the Marlin documentation site went offline many
months ago. Recently when I wanted to find out how Marlin behaved in
response to the M280 command, I had to look at the code, because the only
documentation for that command was too vague to be useful. Even the
comments in the source code describe a behaviour that is different from
how the code actually behaves.

Whereas Adrian Bowyer - the founder of the RepRap movement - documented
all G- and M-codes he implemented at reprap.org, usually before he
implemented them. I have followed his example.

In the absence of an accepted and documented standard, M104 is IMO not
fit for purpose for multi-head machines. RRF does support M104 of
course, but only a subset of the full features are available. That's why
we use G10 to set temperatures from DuetWebControl and PanelDue.

I have no objection to having PanelDue use M104 to set temperatures when
it is talking to Smoothieware, but you will need to provide a clear
definition of how multiple tools should be handled, including
whether/how you can set the temperature of a tool that is not currently
the active one without also selecting it. You might also want to improve
the documentation at http://reprap.org/wiki/G-code to cover how
Smoothieware deals with setting temperatures for multiple tools.

Cheers

On 09/11/2016 10:47, Arthur Wolf wrote:

On Wed, Nov 9, 2016 at 11:43 AM, dc42 notifications@github.com wrote:

Hi Arthur,

The T command is for selecting a tool. I don't see how it can be used
for setting temperatures,

It's not.
M104 is used for setting the temperature for the heater associated to a
specific tool.
This is standard Reprap gcode as far as I know. It's what the slicers do,
it's what we do, I believe other firmwares do this too.
Nobody asked us to have several heaters associated with a single tool yet,
but I don't see why that couldn't be done with an extension to M104 ...

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 9:29 AM, dc42 notifications@github.com wrote:

...

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.

Sure there, is, the T command ... no ?

—
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/AAGpFbO2BBzBnP-m2_Gy35Xlxwc3QyYVks5q8aPbgaJpZM4D4B1X
.

Courage et bonne humeur.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/ACmEbIdq2BsMsp1d8jkAoLvoQ4teWj9Xks5q8aSrgaJpZM4D4B1X.

arthurwolf commented

The Reprap Gcode documentation is just de-facto and is often behind the
actual usage.
On this sort of stuff, it's slicers that decide what's going to be used,
and in this case that's how slicers use T and M104 ...
We just implement whatever is going to work out of the box with the slicers
...

On Wed, Nov 9, 2016 at 12:16 PM, dc42 notifications@github.com wrote:

Hi Arthur,

Kindly point me to the documentation that describes how M104 is supposed
to be used for setting the temperatures of different tools. According to
http://reprap.org/wiki/G-code#M104:_Set_Extruder_Temperature it has a
single parameter S, except that Teacup supports a P parameter as well. I
have seen one slicer emit M109 commands with a T parameter, but again I
can find no documentation for what this is supposed to mean.

Some people treat Marlin as a de-facto standard, but Marlin is effective
undocumented since the Marlin documentation site went offline many
months ago.. Recently when I wanted to find out how Marlin behaved in
response to the M280, I had to look at the code, because the only
documentation for that command was too vague to be useful. Even the
comments in the source code describe a behaviour that is different from
how the code actually behaves.

Whereas Adrian Bowyer - the founder of the RepRap movement - documented
all G- and M-codes he implemented at reprap.org, usually before he
implemented them. I have followed his example.

In the absence of an accepted and documented standard, M104 is IMO not
fit for purpose for multi-head machines. RRF does support M104 of
course, but only a subset of the full features are available. That's why
we use G10 to set temperatures from DuetWebControl and PanelDue.

I have no objection to having PanelDue use M104 to set temperatures when
it is talking to Smoothieware, but you will need to provide a clear
definition of how multiple tools should be handled, including
whether/how you can set the temperature of a tool that is not currently
the active one without also selecting it. You might also want to improve
the documentation at http://reprap.org/wiki/G-code to cover how
Smoothieware deals with setting temperatures for multiple tools.

Cheers

On 09/11/2016 10:47, Arthur Wolf wrote:

On Wed, Nov 9, 2016 at 11:43 AM, dc42 notifications@github.com wrote:

Hi Arthur,

The T command is for selecting a tool. I don't see how it can be used
for setting temperatures,

It's not.
M104 is used for setting the temperature for the heater associated to a
specific tool.
This is standard Reprap gcode as far as I know. It's what the slicers do,
it's what we do, I believe other firmwares do this too.
Nobody asked us to have several heaters associated with a single tool
yet,
but I don't see why that couldn't be done with an extension to M104 ...

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 9:29 AM, dc42 notifications@github.com
wrote:

...

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.

Sure there, is, the T command ... no ?

—
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/AAGpFbO2BBzBnP-m2_
Gy35Xlxwc3QyYVks5q8aPbgaJpZM4D4B1X>
.

Courage et bonne humeur.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment), or
mute the thread
<https://github.com/notifications/unsubscribe-auth/
ACmEbIdq2BsMsp1d8jkAoLvoQ4teWj9Xks5q8aSrgaJpZM4D4B1X>.

—
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/AAGpFS5_6lL0K8NOvcTO_L-TYTpkrwjKks5q8auWgaJpZM4D4B1X
.

Courage et bonne humeur.

AHHams commented

Done. Just added "firmwareName":"Smoothieware" to output (when static output is requested: i.e., M408 S1 ) of code in my pull request (for Smoothie).

AHHams commented

@dc42: what do you expect "probe" to send? I am trying to figure out if there is a meaningful Smoothie equivalent I could implement.

dc42 commented

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.

dc42 commented

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.

AHHams commented

I just added "numTools" support to the pull request against Smoothie.

AHHams commented

@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:

  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.
arthurwolf commented
dc42 commented

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.

AHHams commented

@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?

AHHams commented

In an attempt to save a few bytes, I propose Smoothie return "Smoothie" as firmwareName, rather then "Smoothieware" as I suggested prior.

dc42 commented

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?<

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.

dc42 commented

Some news:

  1. I am doing some major refactoring of PanelDue code to make it easier to use a totally different UI as some of our OEMs want. Also I have switched to building it in Eclipse for greater flexibility. The new repo for the source code is https://github.com/dc42/PanelDueFirmware.
  2. I intend that all new production PanelDue will have 256Kb flash and 48K RAM instead of the current 128Kb flash and 32Kb RAM. This is mostly to provide more room for OEM logos etc.
  3. Now would be a convenient time for me to integrate the changes needed to support Smoothieware and Repetier. When the host firmware name is or begins with "Smoothie" I plan to change the behaviour as follows:
  • Suppress display and setting of tool standby temperatures
  • Use M104 T# instead of G10 to set the active temperature, where # is the tool number (0, 1, ...)
  • Initial directory for SD card files on card 0 is 0:/ not 0:/gcodes. On SD card 1 it is already 1:/.
  • Send M408 S20 instead of M20 S2, and M408 S36 instead of M36.

Is the above correct? Anything else?

AHHams commented

Hi David,

Great stuff. Sorry for slow response. I only just got a little time again to work on this. Reacting to your points:

Suppress display and setting of tool standby temperatures

Great!

Use M104 T# instead of G10 to set the active temperature, where # is the tool number (0, 1, ...)

Correct. OctoPrint works this way as well.

Initial directory for SD card files on card 0 is 0:/ not 0:/gcodes. On SD card 1 it is already 1:/.

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.

Send M408 S20 instead of M20 S2, and M408 S36 instead of M36.

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.

AHHams commented

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?

dc42 commented
dc42 commented

Closing this issue because firmware development for PanelDue was moved to the PanelDueFirmware repository some time ago.