Marlin: New Capabilities Protocol

[repetier]

This is more a proposal than an issue. In the latest Repetier-Firmware I added some features that the next server/host release will support and might be of interest.

First I added a simple and extensible protocol, to tell hosts that some features are available. I'm not aware of such a protocol already existing, so here's my solution documented on reprap wiki:

http://www.reprap.org/wiki/Firmware_Capabilities_Protocol

I think it would be a good idea to support the same protocol across several firmwares to make it easier for hosts.

I got the requirement for this as I added 2 features that the host needs to know about to use it as older firmwares just do not support it.

1. M155 S1 now automatically enables submission of temperatures, so hosts do not need to poll every second with a M105. This even sends updates when the host would not be able to request updates (e.g., due to G4 S100). So a big plus for all hosts. M155 is documented in wiki.

2. Print progress view. Currently firmware can not offer much useful information when hosts are printing a file. With this extension, firmware can show model name, progress in percent, and layer x/y. Status line can then contain time sent with M117 from host. See commands M530, M531 and M532 on reprap wiki.

I explicitly selected free M codes, so we have the chance to define them identical simplifying host support. As soon as I know if Marlin will join these changes I will also enable them for Marlin in our Host/Server. Currently host/server do not support M531 as it contains a string and these cases need special care.

A Raspberry Pi server preview with support of these commands is available here:
http://download.repetier.com/files/server/debian-armel/Repetier-Server-0.80.1-Linux.deb
If you edit the firmware definition (firmware/marlin.xml see repetier.xml for exact syntax) you can even test Marlin with that feature.

[thinkyhead]

All great ideas. I'll implement these ASAP.

[repetier]

Ok, so for now I assume you use the same syntax/M codes, so I add the detection routines for 0.80.1 from repetier so it will will be supported even sooner from server side.

[thinkyhead]

@repetier I've moved the existing M155 (send i2c data) out of the way, along with M156. They're now M260 and M261. I've added these to the RepRap wiki for safety. I've implemented M155 and the extended M115 and will post a PR shortly. I've extended M155 so that S specifies the delay in seconds between temperature reports.

I'm not totally sold on M530 because the host might send S1 and then never send S0 leaving Marlin in a bad state (assuming the "print in progress" flag changes behavior). Anyway, these last 3 codes require more work, so I'm leaving them till later.

Anyway, the others will be merged soon.

[stigjoergensen]

@thinkyhead An idea for the M530 - how about useing stepper poweroff to take it out of S1 state and revert to "not printing"??? so even if the host goes offline, after a timeout the printer will revert to a known state..

[thinkyhead]

@stigjoergensen Marlin internally already uses temperature states to decide if it's in a print job. I'm not in a mood to overhaul that right now, but maybe in the near future. I'd like to get RC8 out the door as soon as issues with Dual X mode are cleared up. It's been delayed far too long as it is.

[thinkyhead]

@repetier Does this automatic temperature report need a prefix? I'm assuming "echo:", but did you have something else in mind? Obviously it can't be "ok".

[Blue-Marlin]

What we currently send during M109, M190, M303 is the answer to M105 without the 'ok' in front (print_heaterstates()).
This seems to be well understood by all the hosts i know about.
I don't see a reason for altering the format - only against.

I'd place it in 'idle()'.
The 'format' we use in M109, M190 is a bit extended. Maybe we should stop the new report during M109, M190. (TEMP_RESIDENCY_TIME)
The current frequency for the reports in M109, M190 is now 1Hz, 2Hz in M303 - probably should then be determined by the S-parameter of M155.

Edit:
Seems to be simpler to omit print_heaterstates() in M109, M190, M303 and making an extra report for 'TEMP_RESIDENCY_TIME' when we have relevant data (Not '?') (ECHO) - if we need it at all.

[repetier]

In repetier-firmware we never had it after ok anyway. ok is for ack and not really anything else. But since it is old behaviour our hosts understand it with and without ok, so as @Blue-Marlin said, just use what you did for M109/M190 and it should be ok. In our firmware we have fixed 1s interval, which is fast enough to see changes and slow enough to not flood communication.

@thinkyhead I assume with temperature for printjob you mean the progress support? Well the feature protocol allows to add any part, so it is no problem to omit one and implement only temp. feature. The difference with progress protocol is that you will get additional informations from server which you could display.

[repetier]

@thinkyhead Just read your extension to the capabilities. For M355 I'd suggest P for intensity with P255/0 if omited depending on S. Not really sure If I'd make it a dim light at all. Without hardware PWM it tends so easy to flicker.

[thinkyhead]

I don't see a reason for altering the format - only against.
In repetier-firmware we never had it after ok anyway

So, no "echo:" prefix either. NP.

[thinkyhead]

Without hardware PWM it tends so easy to flicker.

Without hardware PWM any brightness other than 255 will turn the light off and make S appear to be ignored.

[Colin1DN]

I have just implemented an I2C link to a Speed Controller to change speeds when there is a tool change, however the set of M155 commands are not sequenced with the G1/G0 codes, and the speed changes occur out of sequence, i.e. the spindle stopped while the mill was still moving.... another bit gone...
How can I only send these commands once the Pause comes into affect - Im using Repetier to send the Gode - Thanks

[Blue-Marlin]

M400?

[Colin1DN]

Many Thanks - Worked just fine, a reference to this in the M155 documentation would be helpful for other "would be" experimenters though. I now have another MEGA2560 with a bunch of pins to control cameras / lights / End of Job - Tool Change Messages etc. Very Useful. Thanks Again

[foosel]

I know I'm a bit late to the party but I only just got around to tackling this particular TODO on my never ending list...

I see that the extended capability report is disabled by default in the merged PR by @thinkyhead - that way the vast majority of printers will probably never enable it (vendors won't, they usually don't care about these things, and contrary to what a lot of people might believe most of today's 3d printer owners do NOT compile their own firmware). And disabled it will be pretty much useless since hosts cannot even query if the (awesome) features discussed in this tickets are supported by the firmware :/ Can we maybe have it so that even if the extended capability report is not enabled an additional parameter to the M115 (your choice) will still report it back to hosts who support parsing it? Or even just enable the extended M115 report by default, I don't see why that would be a problem?

[Roxy-3D]

@foosel @ThinkyHead has dropped off the grid for the last month. Let's see if replies. I think your reasoning makes sense and it would help the host programs to have more complete information. If a person really doesn't want it (because of tight memory space for example), they can turn it off.

Let's see what ThinkyHead's thoughts are on this. But if he doesn't reply, I'll change the default of that for you. And for sure... If we are going to change the default for this option, we should do it prior to promoting RCBugFix to a 'Stable' release. A lot of vendors will grab the 'Stable' release and start shipping that on their printers. If we make this change now, you will catch a wave of printers with the extended capability report.

[foosel]

Sadly it looks like EXTENDED_CAPABILITIES_REPORT was shipped turned off by default after all in the current release. Was this simply forgotten or was there a particular reason for that?

The way it is shipped now, most users (and vendors!) will never turn it on and having it available in theory only sadly doesn't help anyone.

[bgort]

FWIW, I think it should be enabled by default, too.

I have no problem enabling it if there are no objections; progmem use is virtually nil.

[repetier]

I never saw a reason to disable it so for repetier-firmware it is always enabled, no switch at all.

[foosel]

Temperature auto reports appear to also be disabled by default.

[fiveangle]

The only reason I see that this should be disabled, is if someone compiling their own firmware is trying to fit features into a limited MCU and has to decide on something that they can live without. I also vote for enabled by default.