-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unwanted Tool Change - Delta, Rostock MAX v3, dual extruder, Using Single, OctoPi, USB Printing #3031
Comments
Thank you for reporting this! Sadly your report lacks some of the information that is needed in order to look into this issue:
(If you need help with locating this stuff, please take a look into the Contribution Guidelines which explains everything - and if anything is still unclear then just ask) Could you please provide that so this issue can be analyzed and ideally reproduced and fixed? Thank you! |
I was 90% sure that I provided the GCODE ... but it's not attached is it. Reattaching. (aaaah! It had disallowed it since it was a .gcode -- I zipped it this time) |
Attaching Octoprint.log that includes the timeframe this happened. |
I do not have a serial.log nor terminal capture from that point in time. Do you need me to start another print in the 'failure mode' and capture that? (Buh-bye $1 of filament, but worth it if you feel it will help debug) |
Yes, please. OctoPrint by default doesn't happily inject tool change commands into the ongoing print, so if that happened here, I need to see what happened around it and if there even was a tool change command sent by OctoPrint. Also, could you please specify the timeframe that happened in in your Side note: You run into an unusually high amount of resend requests according to your log which indicates noise on the line which might also cause misinterpretations on the firmware side (the checksum mechanism built into firmwares isn't exactly collision free). You should check your wiring setup, make sure Pi & printer are getting sufficient power and that the connection between the two is a good quality cable with shielding. It constantly running into |
nod
Good question. And that's why I didn't originally include it. Over the course of multiple days I kept trying to print, having the failure, assuming clogged nozzle or something else, etc. I wasn't looking at timestamps in particular because I assumed it was a machine issue - and was chatting with my Rostock forum about that. Looking at the log file actually, and realizing that my Pi is on GMT (and I'm on EST). I think the log I included only has the WORKING print (from SD card) in it. However looking at the older logs, during any period I would have been printing. It's just full of "server heartbeat" and "tracking event payload {}" messages. Literally nothing of interest. When I do a reprint-to-failure, I'll include a new log with timestamps..
I'll swap out a different USB cable, in case that's it. But this cable was one that I'd used for a long-time before without incident. It looks like all those resend requests were while I was uploading to the SD card? (that painfully slow process) |
Started print at 8:10pm -- Actually started by 8:20pm -- At 9:20pm I noticed via camera that the head was floating (probably by around double the height it went), and killed it. Log(s) attached |
Documenting some times in the serial.log: Started printing: 2019-02-07 01:11:04,469 |
The only tool change commands that I see anywhere in the commands sent to your printer through OctoPrint according to that I'm also still seeing some wrong checksum and format errors, hinting at some communication issues still being present. Sadly your firmware doesn't appear to report tool changes back via serial as far as I can see, or it would be possible to determine the precise moment things took a turn for the worse. Going by what I see in the Also, I forgot to answer that:
They definitely happened also while printing from the SD, and while streaming a file from OctoPrint through the printer for direct printing. |
To me this sounds like maybe a brownout issue, or problems with floating ground. |
So some additional testing I'm doing: Same USB-cable, works fine printing direct from S3D ... export the S3D and upload to Octoprint, and it has this happen, consistently. Print direct from Octoprint, and this happens. I did do a test, printing only on T1 ... that worked flawlessly. Print on T0, it switches to T1 at some point. Print on T1, it just works. Going to be switching to a different USB cable soon. To test that. |
@DanielJoyce Can you describe a bit more for me? Given this is consistent, I'm not sure it could be a brownout? (Unless you have a different definition than I do). Can you elaborate on the floating ground/etc as to where you think that would be? You talking about the printer and/or Pi not being grounded properly? Or the USB cable itself between them? etc. |
Could be that you Pi sinks power into the printer. Could be that you have the USB cable wired slightly differently so that it is more exposed to interference. Could be a grounding issue. Could be a ton of factors. The fact of the matter is, OctoPrint is not initiating that tool change according to your log. Which means it's either the printer, or it's the printer misreading what it gets sent over serial, possibly due to data corruption. In any case, it's not a bug that can be fixed or even mitigated in OctoPrint, it's an environmental issue. Which is why I'm now closing this, so I know this isn't an open task here. Comments are still open though if you want to discuss things - though, the community is probably better suited for that. |
Some updates:
So current summation of situation: SeeMeCNC - Rostock - Rambo board, Repitier code: Printing from SD Card:
Using Simplify3D to print directly connected:
Using OctoPrint directly connected, with Gcode from Simplify3D
I guess it could still be an environmental issue, but environment in this case being 'the machine', since it's affecting other people's machines as well. But the fact that Simplify3D can print successfully over a USB connection, and Octoprint cannot. Seems to imply that there is 'something' that can be changed in OctoPrint. -- Though tracking down the exact issue of course is the bigger task. |
It might be something in the firmware. But as I said - OctoPrint isn't sending a tool change command to your printer according to your logs. Maybe it's some combination of the (run of the mill) commands that it fetches from your file combined with regular temperature polls or something like that that makes the firmware decide "tool switch", but I sadly cannot do anything for you here considering that OctoPrint isn't sending any kind of tool change commands and the commands it is sending are also not looking suspicious in any way. I also know that OctoPrint runs without problems for a lot of people out there with multi extruder setups, so it's also not a general problem. It really sounds more like it's a problem specific to the SeeMeCNC printers, which makes it sound like firmware. |
Yup, understood @foosel ... Just so weird that it seems to be this specific issue. If I get a chance (Currently in production printing mode). I'll attempt another 'normal' print from T0 and sit there the entire time (and/or perhaps set up a video recording so I can rewind to the exact time when the change happens) ... so that I can see exactly the sequence of events that occur then. Isolate them, and then try to repeat it more to see what causes it. At least at the moment I can just keep printing on T1 all the time unless I'm doing a dual extrude anyway :) |
So, new twist. After my 'everythings is working great' discussion (on T1 only) ... I just had a communications failure on at 90% done on a 16hr print. The error was: State: Offline (Error: Printer requested line 276730 but no sufficient history is available, can't resend) I'll past the GCODE Viewer window below. But now my question is -- What's the chance that:
Just wondering where I should be focusing my debugging efforts? If you have any advice. (Not that I want to buy another Pi 'just for testing' mind you, but) It appears to my untrained eye that:
And the OctoPrint went 'wtf'.
/cc @foosel @DanielJoyce |
This looks really weird I admint:
The printer says its ok, then says wrong checksum, then tells it to resend 2767304 which octoprint seemingly ignores.
Plus this is weird. Is the firmware that wonky? Or is octoprint confused by the skip X followed by OK? If sent the wrong line I'd expect the firmware to reject it immediately. That said, given how your problems seem to come and go depending on who prints the file, I still think the first problem is a lack of sufficient power and possibly a bad cable.
|
Its weirdly infuriating that these protocols don't seem to send the line number with OKs, or a sequence number. If they did all of this nonsense would go away. Its what TCP/IP does. |
I've tried to annotate the log:
What I find weird is that OctoPrint indeed doesn't send N2767304 as asked but instead sends N2767305. That sounds like an off-by-one error, which I haven't seen in a while and don't understand. So this is definitely wrong on OctoPrint's side, but right now I don't understand how that could happen. The What kind of firmware is that? The |
@DanielJoyce wrote:
Hosted via an old desktop that I used to have. The desktop recently died (powersupply went boom). And I decided instead of buying a cheap $300 desktop to replace it. I'd switch over to running Octoprint on a Pi instead for a lot less, and get some benefits. (didn't expect the troubles of course).
I specifically went and bought one of the special 2.5a 'meant for pi' power supplies instead of running it off a phone charger, after reading a lots of troubles people had when doing that. This one: https://www.amazon.com/gp/product/B07GZZT7DN/
They are plugged into the same power strip
Well, just to re-clarify in case it helps.
|
@foosel wrote:
It is Repetier, but yes, the SeeMeCNC specific variant to work with their Deltas. You can find it here: Interestingly enough -- I just found that on their own Github ... they have a similar/identical bug being discussed: seemecnc/Firmware#16 - as recently as a couple weeks ago. With OctoPrint causing random tool changes after about an hour+ of printing. |
I find this comment quite eye opening:
I just wish there were more details there, as in, how far is that bug known, and in which firmware variants, and where is it documented, and and and... But it might just be referring to the ticket you already linked. There also this thread where @repetier also assumes it to be the cause of a communication error. As far as your |
Yes, I'd seen that as well (the random tool change over USB) comment. However what was interesting to me, was that I (originally) assumed that warning to be 'obviously old' because when I installed the dual extrusion addon -- I then tested with a direct print from S3D, had zero issues, and continued to print for a month solid without issues. (And I mean solid. This printer tends to be running 24/7 with only small breaks when I forget to start a new print for an hour or two). And it was only upon switching to Octoprint (on a Pi) vs S3D that the problems began. HOWEVER: A huge new twist. I've now been printing exclusively from the SD card (which is sad, as it removes a lot of the benefit of using Octprint & the Pi) ... And it's been working. Until: A couple days ago I came back to a long print, to find that the extruder had changed over mid-print . (again, while printing from SD card). I kept going on my SD card prints. Next few were fine. And then just this morning, it happened again after an overnight print. So now my printer is 'sometimes' making the extruder switch. even when printing from the SD card itself :( Now, I DO still have the USB connected to the Pi of course. So if the bug is purely caused by 'being connected'. That would happen. But #sigh ... At that point, it's definitely not an Octoprint bug. (Unless literally something by the fact that the Octoprint is listening to the USB traffic is causing the issue is a legit thing) I did notice in the other thread that someone mentioned they solved the problem by cutting the data rate in half. I might experiment with that. Or I might just consider my dual print/extrusion upgrade to be trash, and disable it to have a stable printer again. |
@foosel Attaching this here in case it means anything to this bug (or is another one). A few times now I've started prints from the SD card, with Octoprint attached just so I could control/monitor ... and Octoprint has disconnected for random reasons. Tonight, got a "Offline (Error: See octoprint.log for details)" error ... and the log itself says that "You should report this bug". Looks like even though we weren't printing from octoprint, just hanging out. That 'bad checksum' and resend requests started happening. |
The switch to offline sounds like it got something really unexpected back from the printer in a reply to The communication errors don't surprise me. A connection prone to these issues keeps being prone to it, no matter what and how much you send over it. Printing from SD just makes it less likely to ruin a print, but it's still an ongoing issue as you can see. |
What were you doing?
I recently had my connected old-windows machine that I used to use for printing on my Rostock Max V3 via Simplify3D die ... instead of replacing it, I decided it would be cheaper/better to just replace it with an OctoPi, and then use S3D from wherever I wanted, drop files up to the OctoPi, and go. Cheaper, and no separate machine to maintain. But my first prints are having these issues.
Steps to reproduce:
What did you expect to happen?
Expected complete print, of a single color filament.
What happened instead?
Four times I tried this and found that it just stopped printing after a certain height. (Did not measure but was consistent ... perhaps 2-3mm). After enough times, thinking that I had a clogged nozzle, but now getting suspicious about it stopping at a fairly consistent spot. I watched closer.
And I realized that it was doing a tool change at that point. And trying to extrude with the second extruder (which had no filament in it). I couldn't find any information about this via googling, to figure out why this would exist. But appears to have only been caused by using the OctoPrint.
I did reach out on a forum, where someone told me: "Oh yeah, it's a bug with OctoPrint, you can't use it with Y-based dual extruders". Being a computer programmer myself, my response to that was: "Well I hope someone told them, because that obviously should be fixable". And hence filing this.
Did the same happen when running OctoPrint in safe mode?
Did not run in Safe Mode, because I've not installed anything else. Just a stock install of OctoPi and then upgraded.
Version of OctoPrint
Operating System running OctoPrint
OctoPrint 1.3.10 running on OctoPi 0.15.1
Printer model & used firmware incl. version
Rostock Max V3 - Rambo board
Dual Extruder upgrade (Y-tube w/ Bowden)
Send: N135460 M115*19
Recv: ok
Recv: FIRMWARE_NAME:Repetier_0.92.2 FIRMWARE_DATE:20171204 MACHINE_TYPE:Rostock MAX v3 Dual
Recv: Printed filament:20458.52m Printing time:51 days 12 hours 9 min
Browser and version of browser, operating system running browser
n/a
Link to octoprint.log
Do not have one of exact failure point. Just finished a print from SD card instead of from Local, and that worked fine. So seems to be some issue with USB communication through OctoPi
Link to contents of terminal tab or serial.log
n/a
Link to contents of Javascript console in the browser
n/a
Screenshot(s)/video(s) showing the problem:
Do not have
I have read the FAQ.
The text was updated successfully, but these errors were encountered: