For anyone in the future who comes across the above error.  I fixed it by upgrading to the latest version of Gambas.  See Scrollview Display Error thread.

Released version 2.0.4.

This new release now:<LIST>

• <LI>
• Controls and monitors the printer's bed and hot end temperatures.</LI>
  <LI>
• Supports extruder retraction.</LI>
  <LI>
• Has many suggestions Steve offered within it.</LI>
  <LI>
• Improved form resizing.</LI>
  <LI>
• First time run check.</LI>
  <LI>
• Other minor bug fixes/tweaks.</LI>

</LIST>

I've updated the first post of this thread to attach the latest version as well.

 I'll be interested to see if the temperature monitoring works for you Steve.  I am rather surprised at the 'mess' of a response my printer gives me.  So I'm not too confident that this will work with very many printers.

For some reason when I turn on temperature reporting, I get information send back to me doubled up.  Yet when Cura starts up reporting its nice and clean.  I'm going to have to see if I can sniff the communications and see what its doing differently.

PartierSP said

Released version 2.0.4….

I've downloaded this version and will check it out when time permits

…I've updated the first post of this thread to attach the latest version as well.

I would recommend that you keep updating/replacing the zip in the first post and add a new post just to give update information only (i.e. don't post twice).

OK Mike, I've looked at your code but it wont run with my printer because I don't have the stuttering serial link problem that you clearly have.

Instead of getting doubled-up characters for temperature, I just get this with my code:-

(Click to enlarge)

So I think you need to track down this comms problem first, before proceeding.

 Thanks for the quick test run.  I now see how Cura is doing the temperature monitoring.  Its sending a M105 periodically instead of setting up automatic temperature reporting with a M155 Sxx command.  I managed to snoop this by starting up miniterm and sending a M111 S7 (this turns on echo, extra info, and extra debugging) and then start up Cura.  So this is easily fixed using a timer.

I have a feeling that there's a bug in my printer and I need to flash an update.  This is possibly a common issue and why Cura does it with M105 instead.

PartierSP said

…I now see how Cura is doing the temperature monitoring.  Its sending a M105 periodically…

Like you, I'm also using M155 S5 (5 sec interval) but without any apparent problems.

I have a feeling that there's a bug in my printer and I need to flash an update.  This is possibly a common issue and why Cura does it with M105 instead.

From the Marlin web site (Report Temperatures | Marlin Firmware):-

Some hosts may hide the reply from M105.

A better way for hosts to get regular temperature updates is to use M155 (requires AUTO_REPORT_TEMPERATURES and EXTENDED_CAPABILITIES_REPORT). Hosts then no longer need to run an extra process or use up slots in the command buffer to receive temperatures.

SerialPort3D_Read() is a Callback so should return the data that it has. Did you have a reason to include this Sleep?

Does your printer double-output everything, or only the temperature report?

I suggest you try a terminal app like "minicom" to check responses from your printer (e.g. M155 S5) before you update your firmware, as it seems unlikely (but possible) that its a printer firmware problem.

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.

stevedee said

Re: bed warping; if the bed is not substantially flat, the only option is to 'map' the surface and to correct the g-code Z values to compensate. I guess this could be done manually, but the best approach is with something like a BLTouch sensor mounted on the extruder. (I've got one, still in its box, but never had the courage to update the printer software and install it...too many horror stories on the forum!).

I'm the fool that rushed in as soon as I got my BLTouch.  I had no issues whatsoever making the necessary mods and flashing new firmware.  I badly needed that fixed as I couldn't get anything to stick to the bed of my Wanhao i3 Plus.  That fixed it permanently and I've been printing happily since…

 Since I put the glass bed on my printer and have been using my current method of rough setting the printer with this program, and then printing, measuring, and adjusting, it has been working fairly reliably.  I usually only have to do the last step once or twice if the printer has sat for a few days.

But in the past month I have had some serious issue with lack of adhesion.  I'm planning on taking it apart and checking everything.  I have seem to occasionally loose my Z-height when homing.  Its as if the Z-stop or the hot end loose and moving leading to inconstant homing.

I haven't released a new version of my program recently.  But I have still been working on it.  I'm currently working on generating a test STL file that could be loaded in your slicer of choice to create test prints.  I thought of generating the G-Code directly and sending it straight to the printer, but by making an STL file and using your regular slicer would produce a result more inline with your day to day production.

I have also have the Joystick control working much better now too.  I burned out a few too many brain cells getting the user defined motions to work.  Now the user can decide what each axis and each button does.  There are still a few bugs in it (mainly if the Joystick connected after the program has started).  But I may pull the git branches together and release it anyways.

So yeah, I don't know who all would be interested in this program.  Devices like BL-touch has eliminated most of its need.  But the Joystick operation is SO HANDY!  It is easier to move around then the CNC machines at work are.