I've included the SLEEP to allow the read buffer to capture an entire line before the code starts to parse the data. Otherwise I was trying to parse a partial temperature line and then parse the rest later. If the SLEEP starts to be unreliable, I would have to build a buffer and monitor for an end of line prior to parsing.
I originally tried WAIT but as per Gambas manual in this instance SLEEP is more appropriate as it would prevent multiple SerialPort3D_Read() events firing for a single line.
I also get the messed up temperature reading lines when I try miniterm alone. And all other data retrieved is returned properly (no duplication - even M105 looks good). So I do believe my code is retrieving the data properly, just its not being sent properly. I would say it's almost like the M155 is double triggering the temperature report within my printer its self.
Yes that Marlin page was the reason I originally went with M155. That made sense to me. And now that I've switched, I've ran into a slight issue of a race condition when the user clicks a button on the screen just at the right time that my timer is asking for a temperature reading. So for example, if my program wanted to do a home with a G28, and the timer fires requesting a M105, I have had the printer see a command like this:
Which as you expect, the printer sends back a big Huh???
So I need to do some traffic control prior to sending data. This may also help if the user starts to button bash, sending all kinds of messages to the printer at once.
I've checked my printer's Marlin version: Ver. 1.0.1 dated 2020-04-25
After looking on Creative's website for updates, they appear to be a bit of a mess. So like you, I've been a little hesitant on doing the update.