RC5 - Print don't start with pre-heated bed #3624
Comments
|
Thank you for your report about RC5. |
jbrazio
changed the title
jbrazio
added
Bug: Potential ?
Needs: More Data
|
It still hangs with RC6 - but in a slightly different way. |
|
I accidentally closed this. |
|
Here's from the log of a cold start. It looks like the problem is when the extruder is already preheated to temperature. From a cold start, the bed is heated first and the W:? countdown is initialized. When the extruder gets to temperature W: counts down and the print starts OK. |
|
Are you sure you are on RC6 or newer? Also tested M109 and M109 with pre heated bed. All without problems. Or, maybe, you just copied your old config over to RC6? |
|
I'm on I'm not sure how I switched back to bang-bang on the bed - missed a change on Configuration.h I presume. However, when I tried to do an autotune, I got: which puzzles me. |
|
I'll go back to PID on the bed and see what happens. |
|
If your bed is in bang-bang mode you can't tune PID for the bed. |
|
OK. I had failed to enable PID on the bed when I was editing |
|
A missing or 0 |
|
What is your Arduino IDE version? |
|
Arduino 1.6.8 #define TEMP_BED_RESIDENCY_TIME 0 // (seconds)
#define TEMP_BED_HYSTERESIS 3 // (degC) range of +/- temperatures considered "close" to the target one
#define TEMP_BED_WINDOW 1 // (degC) Window around target to start the residency timer x degC early. |
|
Here's some "correct" behavior with no preheating. |
|
I've had several tries reproducing the non-start behavior with PID bed heating with RC-6 and so far it hasn't shown up. I'll let you know if/when it happens again. |
|
I had sent commands to preheat the bed and the extruder, then started the print. This time it locked up when the bed reached target.
|
|
A lockup is strange. Usually a crash will reboot or give screen trash. And a |
|
Could the communications be deadlocked somehow? There seem to be way more "echo:busy processing" messages than I used to get. In particular, I get them during the print. Before, I only got them during the initialization phase. |
|
Communications seem to be okay. Do you have an LCD controller attached that also locks up? Busy messages are the new normal. You'll get those messages during any long wait. They used to be 10s apart, now they are 2 by default.. You can disable them with |
|
I have a Rigidbot LCD attached. I was running from S3D on my Mac and didn't test to see if the printer would respond to the LCD. It wouldn't respond to S3D. |
|
A lockup is a more serious issue, which could be due to a buffer overrun possibly, or stack overflow. Have you customized any strings in your setup? What language are you using? |
|
English. Author: (EAW, 16t single ex RC6) |
|
If it's too long, that could cause a crash. We don't sanity-check for long strings. |
|
Is that too long? How many chars am I allowed? |
|
Actually, from what I can see, any length is fine for that setting. Hmm… where to look next? |
|
In both cases above, the lockup occurs exactly when both bed and extruder have reached target temperature. |
|
@edwilliams16 I don't think we've changed too much since RC6, so your RC6 configuration should be fine. |
|
Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required. |
|
This issue has not gone away even with today's RCBugfix. The problem occurred this time when I started the print, when the bed and extruder were nominally exactly on temperature. It just hung. |
|
@edwilliams16 I assume that it just kept looping and printing the temperature report. Were you watching the output, and did you notice whether it was stuck on waiting for the bed or waiting for the hotend? Also, what are your settings for I'm reviewing the logic of |
|
In my case, it stops printing the temperature report and becomes unresponsive. I'll try to get a log next time. It has scrolled off by the time I get to it. Sent from my iPad
|
|
I captured a log here. I'm using Simplify3D. — hangs here Filament heats up to 220 according to the LCD, but control never returns. Have bed heated message. |
Your host does not send. Did the file end here? |
|
The filament heated up to 220, but the log ended. An S3D bug? |
Nevermind, not relevant options for this. |
|
No BED_WATTS or EXTRUDER_WATTS |
|
I mean the "W:" at the end of the line you get when The problem with edited logs is - the relevant information might be edited out. You can't trust them. |
|
There were no lines with W:? - including those I edited out. I indicated where I edited out the lines that were identical in form to those that followed and preceeded them. |
|
Here is another example. (no edits!) I can get it to happen about 50% of the time. At the end I have "bed heating done", the extruder goes to 220C and stabilizes (on the LCD), but the print does not start and the printer is unresponsive to the S3D machine control panel. |
Is the temperature only ever getting to |
No worries. They only appear if you have |
|
The log ends with 174.6 /220. According to the LCD the temperature gets up to 220 and holds it. However, the print doesn't continue and the the S3D machine panel has no effect. I have to disconnect and reconnect to restart the print. |
|
|
@edwilliams16 Probably getting closer to the answer soon. If you're not using |
|
With |
|
@Blue-Marlin I see that we are comparing ints to floats in some of these temperature comparison functions. static float current_temperature[HOTENDS];
static int target_temperature[HOTENDS];
. . .
return target_temperature[HOTEND_ARG] > current_temperature[HOTEND_ARG];But I don't think a comparison like this |
|
There is nothing Marlin could do better. M190 exited with an ok. The host should continue to send, but it does not. Even if Marlin had crashed the host should at least try to send the next line. But there is no hint in the log. So likely the host crashed. But who knows. The user is ether not able to give us a correct config.
or does not use RCBugFix. Several test with other hosts (RH, Pronterface, Octoprint) have already be done by me. Works. int float compares do work in C since K&R. (forever) |
|
I gave you the TEMP_BED_RESIDENCY_TIME etc. three days ago and pointed out I'd changed to RCBugFix five days ago when I reopened the issue. |
Of course. Just trying to cover all bases, in case weird rounding could be happening outside of my ability to visualize. But of course it up-casts to
Sorry, some days we have the memory retention of a goldfish. |
|
If the error persists with the updated S3D, I'll ping them - being unable to reproduce the error with other hosts is a smoking gun. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Gets up to temperature, but then won't count down to start. I preheated for a while before I told S3D to start the print. This is with RC5.
Possible duplicate: #3585
The text was updated successfully, but these errors were encountered: