Print over USB fail

[BAUBLITZ]

I have an Tenlog TL-D3S

When i print over USB then the print fails, In the log comes many resends from printed lines. The print fails because the X-axis drive to home position and the active extruder eject the Filament. Then the print continues without filament. This happens in any print over USB. The same G-Code printed from SD-Card works fine .

[tenlog]

We tested USB print from Ultimaker Cura 4.4, Cura 15.02 and Repetier Host 1.0.6 on the latest formware version.

[BAUBLITZ]

the print over usb seems to work. In one print the active extruder moved to its home position within the print but continued to print correctly. Only in the logs are there still a lot of error messages with resends. It's just a beauty flaw because the print seems to continue to run smoothly, but it leaves an uneasy feeling when printing.

[BAUBLITZ]

I have found this code in configuration_adv.h an i have activate it and configure it and adjusted the values as I thought, but the print fails. What would be the right values for you that should be entered here? I search for configurations that improve the print quality

// extruder advance constant (s2/mm3) // // advance (steps) = STEPS_PER_CUBIC_MM_E EXTUDER_ADVANCE_K cubic mm per second ^ 2 // // hooke's law says: force = k * distance // bernoulli's priniciple says: v ^ 2 / 2 + g . h + pressure / density = constant // so: v ^ 2 is proportional to number of steps we advance the extruder

define ADVANCE

ifdef ADVANCE

define EXTRUDER_ADVANCE_K .0

define D_FILAMENT 1.75

define STEPS_MM_E 92,6

define EXTRUTION_AREA (0.25 D_FILAMENT D_FILAMENT * 3.14159)

define STEPS_PER_CUBIC_MM_E (axis_steps_per_unit[E_AXIS]/ EXTRUTION_AREA)

endif // ADVANCE

[BAUBLITZ]

Hallo with the Firmware from 20200114 the lastest the error comes back. Not resolved

[levelfifty]

Found the issue, get_command() was sending extra MSG_OK back to terminal and causing issues with the command buffer.

Line 1203 in marlin_main.cpp needs to be commented out.

    if((strchr(cmdbuffer[bufindw], 'G') != NULL)){
      strchr_pointer = strchr(cmdbuffer[bufindw], 'G');
      switch((int)((strtod(&cmdbuffer[bufindw][strchr_pointer - cmdbuffer[bufindw] + 1], NULL)))){
      case 0:
      case 1:
      case 2:
      case 3:
        if(Stopped == false) { // If printer is stopped by an error the G[0-3] codes are ignored.
      #ifdef SDSUPPORT
          if(card.saving)
            break;
      #endif //SDSUPPORT
          //SERIAL_PROTOCOLLNPGM(MSG_OK); // Bug found by levelfifty to fix USB printing
        }
        else {
          SERIAL_ERRORLNPGM(MSG_ERR_STOPPED);
          LCD_MESSAGEPGM(MSG_STOPPED);
        }
        break;
      default:
        break;
      }

[Mushmuch]

@levelfifty Have you tried to print from PC or Octoprint with this change? There is another instance of SERIAL_PROTOCOLLNPGM(MSG_OK); line 1024.

[levelfifty]

@levelfifty Have you tried to print from PC or Octoprint with this change? There is another instance of SERIAL_PROTOCOLLNPGM(MSG_OK); line 1024.

@mushmuch That occurance appears to only apply to commands coming from the LCD controller. (Get_command1())Since it doesn’t send full on Gcode files and only initiates SD printing, it doesn’t cause issues. Not sure it’s entirely needed though.

I’ve printed more than 50 hours through Octoprint since removing line 1203 under the Get_command() function, since this function is responsible for external USB printing. With previous firmware, it would request a resend due to checksum errors every 10th or so line and eventually fail before getting 1000lines in. After making the change, I see basically 0 resends. That line doesn't exist in Vanilla Marlin 1.0.X, so I assume it was bug fixed out long ago from the man branch. It was causing G1 commands to send duplicate OKs, and you know how often G1 commands happen...

[Mushmuch]

I commented line 1203, burned the bootloader with a USBasp and uploaded the custom firmware. It's been printing from Octoprint for a couple of hours without issue :D Thanks @levelfifty! I hope that @tenlog will update to Marlin 1.1.9 one day ...

[chrigu70]

May i ask @levelfifty what Arduino version you use to compile the source code? Or a complete different Software?

[levelfifty]

@chrigu70 I used Arduino IDE to compile and XLoader to burn the non-bootloader version. Arduino IDE was set to Mega2560 as board type.

Also make sure the configuration file has your model defined before you compile and flash. This firmware is built for all tenlog versions.

[chrigu70]

@levelfifty Thank you so much! I was now able to raise max_bedtemp and so far my printer (Tenlog TL-D3 pro) works fine with my modified Heatbed (220V 750W max 170°C with a 6mm Glass). I used Arduino IDE 1.8.8 and all looks good so far... Thank you!

[tenlog]

@levelfifty Thank you, i will take your advice and fix this bug in the next version. ;-)

[Totoleheros]

@levelfifty How do you know which configuration file corresponds to your model, their names are not really informative. I have the Tenlog TL-D3 Pro (https://www.tenlog3d.com/tenlog-tl-d3-pro-independent-dual-extruder-dmp-3d-printer-with-touch-screen-support-pva-tpu-abs-pla_p11.html), which configuration file is appropriate for it? Many thanks for your help.

[Totoleheros]

I have installed this firmware on my Tenlog TL-D3 Pro but it did not resolve my connection issues with my Raspberry. I have this message when I try to connect Octoprint to the printer:

There was a timeout while trying to connect to the printer Changing monitoring state from "Connecting" to "Offline" Connection closed, closing down monitor

Any clue?

[Dane809]

My printer shut down while printing. The message on the touch panel is: "Shutting down" Why? Same Raspberry works perfect with my Anycubic i3 Mega

[matthew-tracy]

@levelfifty @tenlog I'm still having issues printing over USB (specifically OctoPrint). I tried installing the newest firmware, and I tried commenting out every SERIAL_PROTOCOLLNPGM(MSG_OK) line, just to be safe, but I'm still getting communication errors and timeouts due to resending lines. Any fix?

[WebSpider]

This seems to be fixed here: https://github.com/tenlog/TL-D3/blame/4300e3fb1788c24551f2ffe47ffac0a36c946852/Marlin/Marlin_main.cpp