Page MenuHomeAleph Objects Inc

Printer stops printing using OctoPrint and Marlin 1.1.5.55 (from 2.6.56)
Closed, ResolvedPublic

Description

The majority of my printing has been with 1.0.2.22 but now that 2.6 has been released, I've started using 1.1.5.55. Since then, I've had numerous cases of the printer just stopping in the middle of a print.

In all the cases I've investigated, I see the following (pattern) in the serial.log captured by Octoprint (1.3.6), OctoPi (0.14.0):

2017-12-24 20:49:57,403 - Send: N155404 G92 E0*118
2017-12-24 20:49:57,425 - Recv: X:147.90 Y:150.96 Z:44.07 E:0.00 Count X:13539 Y:15287 Z:71064
2017-12-24 20:49:57,433 - Recv: ok N155404 P1 B3
2017-12-24 20:49:57,436 - Send: N155405 G1 E-1.5000 F1800*37
2017-12-24 20:49:57,449 - Recv: ok N155405 P1 B3
2017-12-24 20:49:57,452 - Send: N155406 G1 X148.206 Y151.642 F4800*124
2017-12-24 20:49:57,466 - Recv: T:189.91 /190.00 B:50.13 /50.00 T0:190.00 /190.00 T1:189.91 /190.00 @:55 B@:3 @0:6N155406 ok N155406 P0 B3
2017-12-24 20:49:59,457 - Recv: T:189.89 /190.00 B:50.11 /50.00 T0:190.00 /190.00 T1:189.89 /190.00 @:57 B@:6 @0:66 @1:57
2017-12-24 20:50:01,456 - Recv: T:190.00 /190.00 B:50.05 /50.00 T0:190.03 /190.00 T1:190.00 /190.00 @:55 B@:14 @0:66 @1:55

Note the response for command N155406 embedded in the middle of an automatic temperature report and the line number repeated twice.

After stopping 3 times in a 4+ hour print, I manually sent an "M155 S0" and the rest of the print finished without incident.

Event Timeline

b-morgan created this task.Dec 25 2017, 6:12 PM
alexei added a subscriber: alexei.Dec 26 2017, 5:32 AM

@bmorgan,
We did a bugfix release for Marlin/CuraLE recently:
http://download.lulzbot.com/Software/cura-lulzbot/
http://download.lulzbot.com/Software/Marlin/1.1.5.64/
Could you please try CuraLE v2.6.63 (it has Marlin 1.1.5.64) ?
Please let us know if the problem is fixed there.

alexei triaged this task as Normal priority.Dec 26 2017, 5:32 AM
alexei changed the edit policy from "Custom Policy" to "Cura LulzBot Edition (Project)".
alexei added a project: Cura LulzBot Edition.
alexei added a subscriber: marcio.

Marlin 1.1.5.64 exhibits the same problem. Is there a way to capture the serial communications when using Cura 2.6.63 connected to the printer via USB? I'd like to try eliminating OctoPrint but I'd like to search the serial communications for the same pattern as seen in the OctoPrint serial.log.

@b-morgan: I suspect I can fix this issue by setting TX_BUFFER_SIZE in Configuration_adv.h, but I would need you to test the change. Can you let me know what printer and toolhead you are using so I can upload some custom firmware for you to try out?

The problem is seen on my TAZ 6 with a Dual Extruder V2.

@b-morgan: My guess is that Cura 2 will not exhibit this problem since it is able to recover from lost "ok"s by using the additional information that is provided by the ADVANCED_OK feature in Marlin. So, really, this could also be considered an Octoprint feature request, as adding the capability for error recovery using ADVANCED_OK would also solve this problem.

@b-morgan: Please flash the attached firmware and let me know if it makes a difference.

Are you still creating some firmware for me to test?

Opps... Missed a message.

The attached firmware didn't work but it changed the symptom just a bit:

2017-12-26 11:12:48,285 - Send: N5347 G1 X158.189 Y147.974 E0.6506*102
2017-12-26 11:12:48,328 - Recv: ok N5347 P0 B3
2017-12-26 11:12:48,331 - Send: N5348 G1 X153.016 Y153.147 E0.7940*103
2017-12-26 11:12:48,562 - Recv: T:190.03 /190.00 B:65.71 /60.00 T0:189.74 /190.00 T1:190.03 /190.00 @:58 B@:0 @0:67 @1:5N5ok N5348 P0 B3

Before the output was "N<line number> ok N<line number> P0 B3" embedded in the auto temperature report. Now the first copy of the line number is truncated (and the space is missing).

Okay, I had set the buffer size to 128, which I thought would have been enough, but maybe it still isn't. Here's another build with the buffer size as long as it can get (256 bytes):

Marcio,

I started a print using 1.1.5.66 but I changed the OctoPrint settings to not request auto temperature reports (M155 S0) but instead to poll using M105. This is a 4+ hour print if it goes to the end. I'll load your 1.1.5.67 after it finishes (or fails), set OctoPrint back to auto reports, and let you know how it goes.

b-morgan added a comment.EditedDec 26 2017, 4:11 PM

The print with "M155 S0" completed successfully (in 4 hours, 10 minutes). I loaded firmware 1.1.5.67, enabled auto temp reporting, and the print failed within the first 10 minutes.

2017-12-26 16:06:21,805 - Send: N7530 G1 X141.376 Y130.063 E0.3773*98
2017-12-26 16:06:21,816 - Recv: ok N7530 P1 B3
2017-12-26 16:06:21,820 - Send: N7531 G1 X138.650 Y127.336 E0.4529*99
2017-12-26 16:06:21,830 - Recv: T:190.26 /190.00 B:59.98 /60.00 T0:190.10 /190.00 T1:190.26 /190.00 @:64 B@:18 @0:65 @N7531ok N7531 P0 B3
2017-12-26 16:06:23,825 - Recv: T:190.23 /190.00 B:59.94 /60.00 T0:190.07 /190.00 T1:190.23 /190.00 @:66 B@:25 @0:66 @1:66

karrad added a subscriber: karrad.Jan 8 2018, 9:40 AM

@b-morgan Can you attempt this print directly from SD card, or USB without octoprint and let us know how it goes?

We are currently investigating a change we recently made of the Baud Rate to 250000, and it may not be playing well with octoprint and/or Pi.

I can't attempt "this" print because it was a dual extruder print and my dual extruder has been returned to the factory for a warranty repair. I'll try and find something that fails with a single extruder.

My 50+ years of experience in the software engineering profession tells me that it probably is not a 250000 baud problem. The communications failures would be more random if that was the issue. In my case, every failure shows the exact same pattern in the serial communications log (that apparently only OctoPrint can collect). The pattern is the response to the previous command is embedded in the auto temperature report. If I tell OctoPrint to turn off auto temperature reporting and poll for the temperatures instead, the print completes successfully.

The "M155" command is NOT in the GCode, it is inserted by OctoPrint before it starts printing. Printing from the SD card probably doesn't add an M155 to the GCode, so I don't expect to see the same failure and since I can't get Cura to create a serial communications log, I don't know if it uses auto temperature reporting or not. If it does not, then the problem should not appear.

Now I could manually edit the GCode to add an explicit "M155 S2" command (OctoPrint's default interval) and then print from SD and over USB directly (without OctoPrint) but if/when it fails, I won't have a "smoking gun" to determine the cause.

Should I proceed and search for a print that fails using a single extruder? Should I wait until you return my dual extruder? Should I try the manually inserted "M155 S2"?

marcio added a comment.Jan 9 2018, 7:46 AM

@b-morgan: I agree with you that this is at the root a Marlin issue. The command acknowledgement should not be embedded in the temperature report. But this could also be considered an Octoprint issue, since the host *should* be robust enough to tolerate a missed "ok". I did a lot of work in Cura 2 to make it tolerant to all sorts of communications issues and Cura 2 is unaffected by this Marlin bug.

The situation right now is that our version of Marlin is already several versions behind upstream Marlin (1.1.5 vs 1.1.8), so I would not be able to report this as an issue in upstream Marlin until I was able to get our FW on a more recent Marlin version. At that point, if I were able to confirm the bug, I would be able to report this bug and perhaps the Marlin developers could come up with a fix. All this will take time, unfortunately. If you are able to do your prints without auto-temperature reports, that might be the best workaround for now.

marcio added a comment.Jan 9 2018, 7:50 AM

@b-morgan :

I don't know if it uses auto temperature reporting or not. If it does not, then the problem should not appear.

Yes. Cura 2 uses M155, but Cura 2 uses Marlin's ADVANCED_OK functionality to re-synchronize itself if an occasional command acknowledgement is missed. Because of this, it is unaffected by this bug.

marcio added a comment.Jan 9 2018, 8:06 AM

Even though it is generally a faux pas to post bug reports on older versions of the FW, I reported the bug in upstream Marlin, in the hopes someone has a quick fix. @b-morgan: Feel free to add additional comments to that ticket if you have more information you feel is necessary.

https://github.com/MarlinFirmware/Marlin/issues/9111

marcio added a comment.Jan 9 2018, 8:59 AM

@b-morgan : It's starting to appear as if this is not a Marlin issue. See the discussion above. Perhaps OctoPrint does not have a serial buffer that is long enough for storing an auto-report message and an ADVANCED_OK string.

In T1598#28512, @karrad wrote:

We are currently investigating a change we recently made of the Baud Rate to 250000, and it may not be playing well with octoprint and/or Pi.

I'm a bit confused. I reloaded 1.0.2.22 on my TAZ 6 and the serial communications appears to be at 250000 baud. This matches the value in configuration.h in my downloaded copy of Marlin (gitdir: ../../../.git/modules/software/firmware/Marlin_Oliveoil_Tilapia_v1.0.2.22_60d344d)

The USB cable between the Raspberry Pi 3 and the printer is short (6 feet or so), the USB cable between my desktop and the printer is 35+ feet. I would think that if there were baud rate related communications problems, they would show up when the printer was connected to my desktop more often than when the printer was connected to the Raspberry Pi 3.

OK. I'm not completely convinced but I'll look for a single extruder print that fails with OctoPrint using auto temperature reporting and open a git issue against OctoPrint.

marcio added a comment.Jan 9 2018, 9:31 AM

@b-morgan: I've just recently got OctoPrint installed on my workstation. I might be able to run some independent tests.

I'm beginning to believe that the problem only occurs with a dual extruder. I had a failure with a dual color 3DBenchy, but the single color 3DBenchy is printing without a problem (so far). The auto temperature report for a dual extruder is significantly longer than the auto temperature report for a single extruder. I've told OctoPrint to set the auto report to 1s instead of the default of 2s.

@b-morgan: It's possible that as a workaround we could shorten the auto-report string in our version of Marlin, although that might introduce incompatibilities with host software that expect it to be a certain way. Do you have anything else happening on your RaspPi that might be tying up resources and keeping OctoPrint from reading the serial data often enough?

@b-morgan: When you get a chance, please try the following FW for the dual. What I did was insert a 100ms pause right in the middle of sending the temperature autoreport string. This is just a trick to see if it gives Octoprint enough time to catch up. If it makes a difference, then we likely are looking at a buffering issue. 100ms is a rather long delay, if it makes a difference, we can try reducing that value (as I don't want an unusually long delay to affect the print).

Sorry, I think you may have a V2 dual. Try this instead:

From day 1 I've had a Raspberry Pi camera installed. Capture of time lapse movies is turned off, however. Nothing else other than OctoPrint is running.

You bring up an interesting point about shortening the auto-report string. Since I don't have my dual extruder (you could send me a V3 to test with, lol), what about lengthening the string instead. Since I don't tell OctoPrint that I have a single or dual extruder, how about sending a dual auto-report in the single extruder firmware?

@marcio : My dual extruder is on its way to Loveland for a warranty repair. Should arrive by end of today. Since I can't get the single extruder to fail, we will have to wait until mine is repaired and returned to me (or, as I mentioned before, you could send me a V3 to test with, rofl).

b-morgan added a comment.EditedJan 9 2018, 11:52 AM

If you set the pin numbers for the second extruder to be the same as the single (first) extruder, could you run that hacked firmware with a single extruder attached?

marcio added a comment.EditedJan 9 2018, 12:14 PM

@b-morgan: It can wait, I don't think Marlin would let me remap the pins like that. Alas, I don't have the authority to send you a V3. I'm just the software guy :)

Can I setup a build environment on my Windows 10 Professional (64-bit)? with the Ubuntu Linux stuff? On a LinuxMint system?

I have Arduino 1.8.3 installed as well as Visual Studio Community 2017 with Arduino for Visual Studio 1.0 so I can look at code but I'm not sure what magic is needed to generate a .hex file that the TAZ 6 will like.

I have Git installed but I'm not sure if I have it pointing to the right place to get up-to-date Marlin source files.

@b-morgan: Make sure you use the "devel" branch. For compiling using the Arduino 1.8.3 IDE, just edit "Configuration_LulzBot.h" with the following values:

#define LULZBOT_Oliveoil_TAZ6
#define TOOLHEAD_Javelin_DualExtruderV2

You should then be able to compile and upload the hex file.

marcio added a comment.EditedJan 9 2018, 12:56 PM

The code for generating the temperature autoreport is the following in Marlin_main.cpp:

  void print_heaterstates() {
    #if HAS_TEMP_HOTEND
      print_heater_state(thermalManager.degHotend(target_extruder), thermalManager.degTargetHotend(target_extruder)
        #if ENABLED(SHOW_TEMP_ADC_VALUES)
          , thermalManager.rawHotendTemp(target_extruder)
        #endif
      );
    #endif
    #if HAS_TEMP_BED
      print_heater_state(thermalManager.degBed(), thermalManager.degTargetBed(),
        #if ENABLED(SHOW_TEMP_ADC_VALUES)
          thermalManager.rawBedTemp(),
        #endif
        -1 // BED
      );
    #endif
    #if HOTENDS > 1
      HOTEND_LOOP() print_heater_state(thermalManager.degHotend(e), thermalManager.degTargetHotend(e),
        #if ENABLED(SHOW_TEMP_ADC_VALUES)
          thermalManager.rawHotendTemp(e),
        #endif
        e
      );
    #endif
    SERIAL_PROTOCOLPGM(" @:");
    SERIAL_PROTOCOL(thermalManager.getHeaterPower(target_extruder));
    #if HAS_TEMP_BED
      SERIAL_PROTOCOLPGM(" B@:");
      SERIAL_PROTOCOL(thermalManager.getHeaterPower(-1));
    #endif
    #if HOTENDS > 1
      HOTEND_LOOP() {
        SERIAL_PROTOCOLPAIR(" @", e);
        SERIAL_PROTOCOLCHAR(':');
        SERIAL_PROTOCOL(thermalManager.getHeaterPower(e));
      }
    #endif
  }
#endif

I suppose it might be possible to fake having multiple extruders by unrolling the HOTEND_LOOP() . Something like:

  void print_heaterstates() {
    #if HAS_TEMP_HOTEND
      print_heater_state(thermalManager.degHotend(target_extruder), thermalManager.degTargetHotend(target_extruder)
        #if ENABLED(SHOW_TEMP_ADC_VALUES)
          , thermalManager.rawHotendTemp(target_extruder)
        #endif
      );
    #endif
    #if HAS_TEMP_BED
      print_heater_state(thermalManager.degBed(), thermalManager.degTargetBed(),
        #if ENABLED(SHOW_TEMP_ADC_VALUES)
          thermalManager.rawBedTemp(),
        #endif
        -1 // BED
      );
    #endif
print_heater_state(thermalManager.degHotend(0), thermalManager.degTargetHotend(0),
        #if ENABLED(SHOW_TEMP_ADC_VALUES)
          thermalManager.rawHotendTemp(0),
        #endif
        0
      );
print_heater_state(thermalManager.degHotend(0), thermalManager.degTargetHotend(0),
        #if ENABLED(SHOW_TEMP_ADC_VALUES)
          thermalManager.rawHotendTemp(0),
        #endif
        0
      );
    SERIAL_PROTOCOLPGM(" @:");
    SERIAL_PROTOCOL(thermalManager.getHeaterPower(target_extruder));
    #if HAS_TEMP_BED
      SERIAL_PROTOCOLPGM(" B@:");
      SERIAL_PROTOCOL(thermalManager.getHeaterPower(-1));
    #endif
   
        SERIAL_PROTOCOLPAIR(" @", 0);
        SERIAL_PROTOCOLCHAR(':');
        SERIAL_PROTOCOL(thermalManager.getHeaterPower(0));
        SERIAL_PROTOCOLPAIR(" @", 0);
        SERIAL_PROTOCOLCHAR(':');
        SERIAL_PROTOCOL(thermalManager.getHeaterPower(0));

  }
#endif
marcio added a comment.Jan 9 2018, 1:05 PM

If you do this, and you are able to reproduce a stall in Octoprint using that code, then try to resolving the issue with this:

safe_delay(100);

Right before:

SERIAL_PROTOCOLPGM(" @:");

That will insert a delay prior to printing the second half of the temperature report line, which I suspect may fix the problem for you.

marcio added a comment.Jan 9 2018, 1:07 PM

I suppose if you want to run this test using your existing toolhead, you will need the following in "Configuration_LulzBot.h"

#define LULZBOT_Oliveoil_TAZ6
#define TOOLHEAD_Tilapia_SingleExtruder

You can then "fake" the longer temperature report as I indicated above.

Stupid question... In Arduino 1.8.3, I do a Sketch, Export compiled Binary and I get two .hex files, Marlin.ino.mega.hex (406 KB) and Marlin.ino.with_bootloader.mega.hex (417 KB). Since neither one of them matches the size of Marlin_TAZ6_SingleExtruder_1.1.5.64_6353ccb.hex (409 KB) I'm not sure which one to use. Can you help?

marcio added a comment.Jan 9 2018, 2:13 PM

Not a stupid question at all. I once asked the exact same thing :) The version you want is the one without the bootloader since a bootloader is already programmed onto the board.

marcio added a comment.Jan 9 2018, 2:15 PM

As far as I know, the only occasion you would use the bootloader version was if you were using a hardware programmer. If you load software via USB, then you are in fact making use of the bootloader code that was pre-programmed into the chip by someone else.

One more stupid question... I went to this URL, https://code.alephobjects.com/diffusion/MARLIN/repository/devel/ and I did a git clone of https://code.alephobjects.com/diffusion/MARLIN/marlin.git. If I browse the repository from my browser, Conditionals_LulzBot.h contains:

#define LULZBOT_FW_VERSION ".70" // Change this with each update

but in the directory on my desktop created by the git clone command I see:

#define LULZBOT_FW_VERSION ".34" // Change this with each update

Obviously, my (lack of) knowledge about git is failing me. Can you help again (and I hope I'm not bothering you too much)?

marcio added a comment.Jan 9 2018, 2:28 PM

I think you may be in the wrong branch. Go into the git checkout directory and type "git checkout devel"

Success (at least with building and uploading a firmware version)! OctoPrint doesn't mind the longer temperature report so I've started a 3DBenchy and we will see what happens...

I ran two 3DBenchy prints (about 2 hours each) with my "extended auto temperature report" firmware and OctoPrint setup with M155 S1 without a failure.

I got my dual extruder V2 back (a new one actually) and spent last night doing all the calibration stuff. I started a dual color 3DBenchy this morning and it has failed twice with firmware 1.1.5.64 within the first 15 minutes.

@b-morgan: Did you try with .71 that I attached above? I think it will solve your problem.

First you have to have a (repeatable) failure before you can determine if you have a fix! I'll try that firmware next.

foosel added a subscriber: foosel.Jan 12 2018, 2:16 AM

Chiming in to just quickly clarify that OctoPrint itself doesn't have any limits on its rx buffer (well, apart from system memory) but relies on PySerial and the OS underneath that. It might be interesting to put a logic analyzer on the lines and see what is actually send over them physically, but I'm not sure if that's an option.

Do I understand it correctly that this issue so far only manifests with a) AUTOREPORT_TEMP enabled in the firmware and b) more than one extruder present? What happens when the firmware's config is changed to simply disabled AUTOREPORT_TEMP (I just noticed that I did not enable an override flag in OctoPrint to ignore this capability, so changing the firmware's capability report is the only option right now to test this scenario).

@foosel: Yes, I took a quick gander at the Octoprint code and saw that you were using PySerial. I also noticed that PySerial does not provide an option to increase the receive buffer size. So the options are very limited at this point:

  1. You could optimize OctoPrint to read from the PySerial more often to keep the RX buffer from overfilling.
  2. We could reduce the baud rate to something lower, giving OctoPrint more time to respond without any code changes.
  3. Marlin could insert a delay in the middle of the temperature auto-report line, which also would give OctoPrint more time to empty the PySerial buffer.

Option 1 could be pretty hard to do, depending on how OctoPrint is structured. Option 2 is undesirable since 250000 baud is the only serial rate which does not introduce errors due to mismatch with the Arduino clock rate. Option 3 would be easy to implement in Marlin. Since the temp auto-report line is pretty much the longest line Marlin routinely spits out, simply splitting it up would effectively "lower" the serial rate such that it would not overwhelm the PySerial buffer.

I provided some FW to @b-morgan which does option 3 to see if it helps with the issue.

@marcio ,

I did a print with your firmware (1.1.5.71) with the delay inserted and it completed successfully.

To summarize:

  1. OctoPi 0.14, Octoprint 1.3.4, 1.3.5, 1.3.6 Marlin 1.0.2.22 Single extruder: no problems seen.
  2. OctoPi 0.14, Octoprint 1.3.5, 1.3.6 Marlin 1.0.2.22 Dual extruder V2: no problems seen.
  3. OctoPi 0.14, Octoprint 1.3.6 Marlin 1.1.5.64 Single extruder: no problems seen.
  4. OctoPi 0.14, Octoprint 1.3.6 Marlin 1.1.5.70.1 Single extruder: no problems seen (this is my private Marlin build with a faked dual extruder temperature report).
  5. OctoPi 0.14, Octoprint 1.3.6 Marlin 1.1.5.64 Dual extruder v2: multiple problems seen, all with the "missing response" shown to be embedded in the auto temperature report in serial.log (M155 S2 and M155 S1).
  6. OctoPi 0.14, Octoprint 1.3.6 Marlin 1.1.5.64 Dual extruder v2: no problems seen with OctoPrint set to poll for temperatures (M155 S0).
  7. OctoPi 0.14, Octoprint 1.3.6 Marlin 1.1.5.71 Dual extruder v2: no problems seen with OctoPrint set to autoreport (M155 S1). This firmware was provided by @marcio above on Tuesday Jan 9th.

@foosel ,

While not exactly the scenario you asked for, isn't (my case 6) changing the autoreport interval to 0 in the OctoPrint settings sufficient? I see no failures in this case. @marcio 's Option 3 (my case 7) also did not fail.

This combined with the fact that the responses in the issue opened against Marlin (https://github.com/MarlinFirmware/Marlin/issues/9111) claim that the string with the response embedded in the auto temperature report shown in serial.log is impossible for Marlin to create sort of points to OctoPrint (or PySerial). I am using a Raspberry Pi 3 so compute power shouldn't be an issue.

I will do another test with OctoPrint in "Safe Mode" so that I can properly complete a bug report against OctoPrint and we can continue this discussion there. I'll add a pointer to this task after I create it so all interested parties can follow along.

I have opened an issue against OctoPrint (https://github.com/foosel/OctoPrint/issues/2370)

KC703 added a subscriber: KC703.Jan 15 2018, 9:46 PM

Not to derail the progress with the latest FW development. I was experiencing failed prints with the V3 and Octoprint. The workaround I found while following the Octoprint issues, Foosel recommended the use of "Simulate an additional ok for resend requests" under the "Advanced Configuration" of the Serial Connection tab. The advice was for similar disconnect issues on the Prussa machines (2285).

This helped my frustrations with failing prints after switching to the V3 and 1.1.5.xx (using the one currently flashed by CURA LE).

Hope this helps both sides, but it sounds more and more like an issue with Marlin.

@KC703: I recall having to put in code in Cura 2 to handle this. Not certain this is a Marlin bug, it just seems like Marlin chooses not to issue an "ok" for resend requests.

The missing ok after a resend request is a somewhat ancient Marlin bug, since fixed, but anything forked before this fix usually carries on that bug. I also spotted that in the BQ Marlin fork back when I was still with them, and currently it's also making a comeback in the Prusa fork. It being somewhat common (even though a bug) is also why OctoPrint has the aforementioned workaround in place.

That only relates to actually missing oks after a resend request is issued though, not an ok interspersed in a truncated former line like we have it happening here.

I'm a bit unsure how best to handle this to be honest. I'm already pretty much constantly reading from the serial line (the monitoring loop has its own thread and reads a line, parses it, then directly reads the next - sending happens in another thread), and I don't see a way to influence rx size in PySerial either. Besides the lost bytes here, the stall happens due to the ok not being recognized thanks to the swallowed up newline - that could be compensated easily by looking for ok not only at the start of a line, but that might then again cause unforeseen issues with firmware variants out there that produce messages that might also contain the string ok in something completely unrelated.

It would help if I was able to reproduce this issue, ideally reliably, so that I can see if I can improve anything from OctoPrint itself. Any ideas on how I might be able to accomplish this? I'd prefer testing against the actual affected firmware here, maybe even with identical electronics. What controller do you use? I could try setting up a test rig with some spare parts.

Apologies for the double post, just saw the comment by @b-morgan

Setting that interval to 0 disables auto reporting. And when I built auto reporting I was apparently a bit more defensive in my coding than I though because it turns out, setting this value to 0 in the settings will actually also tell OctoPrint to not switch to auto reporting either and stick to sending M105. Sometimes I surprise myself... well spotted!

So yeah, setting this to 0 here is a workaround, but it doesn't solve the underlying issue with the buffer overflow. Having some short delays in the output of long lines certainly can't hurt in general, still, I'd like to get a bit more to the bottom of this, hence the above desire to reproduce stands and any hints on how to accomplish a mirroring of the "test setup" without the need to cram another printer in my already too small office ;) would be appreciated :)

In T1598#28561, @marcio wrote:

The code for generating the temperature autoreport is the following in Marlin_main.cpp:

@foosel
An option to try might be to modify the firmware of a printer you do have to "fake" a multiple extruder auto temperature report like @marcio documented in the post referenced above. I created a version of firmware with the fake reporting of a second extruder but the resulting string was still shorter than the actual two extruder string and it did not fail so I'd suggest faking three extruders which should be long enough. I can try that if you would like.

In more recent versions of Marlin, the functions print_heater_state and print_heaterstates have been moved from Marlin_main.cpp to temperature.cpp

KC703 added a comment.Jan 16 2018, 5:02 PM

When I was having issues, prints longer than 15min would fail with the nozzle at temp on the print. Which seemed a hazard and almost caused me to return the toolhead. Using the "Simulate ok after resend" workaround, prints have been consistent with Octoprint and confidence was restored. I've been able to get through 10+hr prints with the Dual V3. This is with the 1.1.5.44 firmware flashed through Cura 2 LE on initial installation of toolhead.

I'm sure the Octoprint failures could be recreated, simply by flashing 1.1.5.xx and not using the "Simulate additional ok after resend". At the time, I was only printing single extrusion prints...

If Octoprint needs a workaround, Cura needed additional code and this wasn't happening on the 1.0.0.2 firmware (dual v2)... then logic would point Marlin as the culprit. :-)

Curious if this happens with single extruder machines running 1.1.5.xx... Or is it only dual extruder firmware. If so can it be related to processing information of the additional extruder?

karrad assigned this task to marcio.

Moving this back for next stable release as discussed today.

@b-morgan : Would you be able to test 1.1.5.71 and confirm whether it solves the issue for you?

Yes, I can test 1.1.5.71 as long as you provide a pointer, lol.

I successfully printed a dual color 3DBenchy in 3 hours, 39 minutes through OctoPrint with 1.1.5.71. The prime tower fell over about 85% of the way through the print but the ooze shield was 98% successful in protecting the last part of the print.

marcio closed this task as Resolved.Jan 23 2018, 7:13 AM

@b-morgan: Awesome, thank you for your help! I will close this as fixed, at least on the FW side of things.

I am having the same issue and upgraded to 1.1.5.71 and now it fails immediately when heating. I have a Lulzbot Taz 6 with the v3 dual nozzle. Raspberry Pi is BCM2708, 0010.

@FitzNYC Thank you for the report. We have opened T1624 to look into this. Please feel free to add yourself as a subscriber there for updates. In the mean time, can you reach out support@lulzbot.com they may have a couple hardware items to look into.