[2.0.x] Mesh export in Bilinear + UBL M503

[thinkyhead]

While reviewing M503 to answer a question from @dosono on #9724 I discovered that M503 was incomplete. The mesh data is included for MBL but not ABL or UBL.

This PR adds the current mesh to the M503 output so that it can be saved and restored later. To facilitate this, UBL code pertaining to both this and G29 S-1 was moved to the report_current_mesh method.

[Roxy-3D]

If we agree this should be included... We need to move it to the bugfix 1.1.x also.

[thinkyhead]

#9818

[Roxy-3D]

Oh! OK! That's a better place to fix it.

[thinkyhead]

If we agree this should be included

The only case I can make is that when I added the S0 flag to M503 it was in intermediate step in maybe having the EEPROM store just the G-code needed to restore settings. But that's easier said than done, without something like eeprom_printf. So in the meantime I still wanted to have the output of M503 S0 be a blob you could play back to restore all the settings. MBL was already spitting out its mesh, so it seemed good to complete the job.

[Roxy-3D]

If we agree this should be included

The only case I can make is that when I added

No... I meant the safe_delay(75) I edited into the Pull Request. If we agree that should be done I was saying we also need to move it to the other branch because I only added it to one Pull Request. But in the response I saw the lower level SERIAL_ECHO() functions had been modified to have safe_delay()'s in them...

[thinkyhead]

Oh, haha! Well a delay(2) was added to print_heater_state because that was the worst offender. But I was thinking later that the actual delay should be based on the BAUD_RATE. Something like delay(500000 / (BAUD_RATE)). That gives:

• 2 at 250000 and 230400
• 4 at 115000
• 6 at 74880
• 8 at 57600

If we know the temperature report will be 50 characters, or ~500 bits, then we know it will take 2ms to clock it out at 250000, so that's a reasonable formula.

We can't use safe_delay for these pauses because safe_delay calls things that may print more stuff, and even recurse into print_heater_state in that case.

If we know the approximate length of the output we can also tailor the delay for that and get a pretty exacting value.

Of course SERIAL_FLUSHTX is available for 2.0.x, but only for cases where our own TX buffer is used.

[Roxy-3D]

But I was thinking later that the actual delay should be based on the BAUD_RATE. Something like delay(500000 / (BAUD_RATE)).

As it turns out... I think that is not true. The problem is PronterFace connects across a psuedo serial port that is implemented as USB. I'm pretty sure setting the Baud rate won't fix the problem. The host program gets over run with data and can't keep up.

[thinkyhead]

I'm pretty sure setting the Baud rate won't fix the problem.

I'm only proposing a longer delay when the BAUD_RATE is lower, because it takes more time at slower transfer speeds to get the characters out to the host.

[thinkyhead]

So you're pointing out that Printrun has a bug and this is a workaround for that host's serial buffer implementation, eh? Is this a bug in specific versions of that software, because I've never run into the issue and I've flooded that host with serial output without any delays.

[Roxy-3D]

I think it is more complicated than that. I think the RS-232 emulation over USB is not complete. It doesn't really bring through the !RTS and !CTS signals that are on the 25 pin D connector. I think any thing that uses USB-'serial' can get over run very easily. I know I saw this problem on Cura 9 or 12 months ago.

[thinkyhead]

Weird. Is it only because of the laptop I use that I don't get these issues?

[Roxy-3D]

I know different AVR boards are better and worse too... The serial implementation (with external chips) varies between them. It depends on a lot of stuff.

[thinkyhead]

Most likely I see it less because I avoid using tethered printing unless I'm testing stuff, and then it's usually pretty small G-code.

[AnHardt]

I know different AVR boards are better and worse too... The serial implementation (with external chips) varies between them. It depends on a lot of stuff.

Have we ever tried to correlate the serial problems to the used USB-chip?
For example the Arduino Megas have originally a 'ATMEGA_16U2' but most of the Chinese clones have a 'CH340G' on board.

[Roxy-3D]

No... I don't remember anybody getting that level of detail.

[thinkyhead]