temp.c print temperature

[RobertFach]

Hi, this is more a general question about who should change/fix ... I'm currently fixing ReplicatorG 0034 for RepRap5D driven hardware... And temperature readings is one of the issues...

if REPRAP_HOST_COMPATIBILITY >= 20110509

sersendf_P(PSTR("T:%u.%u"), temp_sensors_runtime[index].last_read_temp >> 2, c);

else

sersendf_P(PSTR("\nT:%u.%u"), temp_sensors_runtime[index].last_read_temp >> 2, c);

endif

ifdef HEATER_BED

uint8_t b = 0; b = (temp_sensors_runtime[HEATER_BED].last_read_temp & 3) * 25;

sersendf_P(PSTR(" B:%u.%u"), temp_sensors_runtime[HEATER_BED].last_read_temp >> 2 , b);

endif

RepG wants the temperature beeing reported as one line ... that means after the ok, whereas teacup (normally) reports it with a newline after the ok.

Is there a definition which states which reporting is okay? A standard :-) ? Anyway, from my first sight, I would vote for the first version... that means everything in one line? Are there any reasons why it should be different? In the end, should one fix replicatorG, fix teacup or adapt both?

Thx...

You can find my patched version at github https://github.com/RobertFach/ReplicatorG

[triffid]

every time we chose a way, we got pull requests and demands to put it the other way... it ended up flip-flopping back and forth several times before we got sick of it and told people to fix their hostware instead.

your hostware should accept either way and other ways too, like pronterface.

[Traumflug]

Is there a definition which states which reporting is okay? A
standard :-) ? Anyway, from my first sight, I would vote for the
first version... that means everything in one line? Are there any
reasons why it should be different?

Unfortunately, there is no standard. Also, this part of Teacup has
been changed many times. As soon as it was fixed for one, it was
broken for others.

More intelligent G-code senders, like Pronterface, adapt to firmwares
these days, instead of the other way around. This is good, but if we
change the default, they'll have to be adjusted.

So, if you change something to comply with RepG's idea of how the
world has to work, please wrap it in #ifdefs - and put a commented

ifdef in all of the config.h templates.

[RobertFach]

Thx for your replys, I decided to adapt ReplicatorG by making the parser more flexible... and hopefully nothing else gets broken because of that :)

I know that this is something that has been changed several times, I posted that issue a while ago when working with RepRap Host. I know that its impossible to make it right for everybody. That was the focus of my question, finding the right way to do it... Anyway, having something that defines how the gcode should look like would be nice... This way, one could implement extensions without having the risk of breaking other software (which also implements the standard...) - I know I'm dreaming ;)

[Traumflug]

Am 28.03.2012 um 19:48 schrieb RobertFach:

Anyway, having something that defines how the gcode should look
like would be nice

As you probably know, there's a wiki page about that, but nothing is
stopping developers to just ignore this page. If they ignore or
misinterpret it and their software is successful for whatever reason,
we have yet another standard.

[RobertFach]

Didn't know about that wiki page, thx for that...

This is the problem with standards, quasi standards and established best practices :)

[Traumflug]

Apparently resolved. If it still doesn't work, feel free to reopen this (or better bug the ReplicatorG people about it).