About to try Marlin1.1.0RC4...

[printbus]

I found this thread which seems to be just like my issue.
http://forums.reprap.org/read.php?262,604700

(paragraph deleted. Even here I may have been misrepresenting how the thermal runaway protection algorithm handles a change in the temperature setpoint like that person was doing. I really don't know. )

BTW, the additional link in that thread, https://github.com/MarlinFirmware/Marlin/issues/2582, says the abstract '9' correlation to the bed has been replaced with descriptive text in newer versions of Marlin. What a thought. I think I'm out at this point. I've got to stop trying to help people with firmware updates I don't use and haven't even looked at.

[lakester]

First comment: On or around line 369 in Configuration_adv.h, it looks like you can uncomment "//#define LCD_PROGRESS_BAR" to restore the functionality I think you mentioned.

Second comment: Apologies if I missed something in the preceding discussion..., but it also seems at least possible that you have a genuinely failing bed heater relay. I missed if you mentioned that the firmware was actually reporting a runaway condition..., if it was..., were the HE and bed being successfully de-powered? ..., or did the bed just sit there and cook?

FWIW, I still run the mechanical relay, but I wired it with 10Ga from the start, AND I placed the relay board (and the RUMBA for that matter) on standoffs..., to ensure airflow underneath the board(s) as well. As I recall, MF's instructions just have you screw everything down flush to the wood.

[ROBOCOP]

Very good to know about disabling the progress bar . Thanks. It is possible the relay is failing. Its on my list to check before installing the new PSU. The bed wasnt cooking when it failed. Felt about the right temp .It was printing PLA so it was only at 60 degrees and the room was warm. It is weird that the thermal runaway was at the end of the print as the bed pulls more current in the beginning of the print. Still not sure the thermal runaway was because of the bed though. I do have both relay and Rumba on standoffs. The 12Ga silicone wire i use has very high strand count. I could barely fit the wire in the screw terminals.

[ROBOCOP]

UPDATE: So i got the new powersupply in . Before installing i went over all the printer wiring to make sure it was good . Tested the heat bed relay which all turned out good. I changed the thermister in the firmware to the correct 100k 3950 (11) . I had previously forgot to change it from 100k epcos (1) . In config.adv i also changed the thermal protection period from 30 to 60 on the hotend and 20 to 60 on the bed. I then did a test print while having it connected to the computer to watch for any error codes . Well turns out it printed fine. Both hotend and bed temps stayed with plus or minus 1 degree from the target. No problems . I printed a few more things and all is good.

I cant be sure what caused the problem originally but it had the be the thermister option or the thermal protection period and i dont think the powersupply failure was related to the thermal failures ,just coincidence . The bed Thermal protection period at 20 and 2degrees hysteresis is my guess for the thermal failures.

I did have one issue with mesh leveling in that at the end of the print the nozzle plunged down into the part instead of homing the x y first . In my endcode though i have G28 X0 Y0 so im not sure why it did that. What the best way in the endcode to have it lift up then home x and y ?

[lakester]

It'll be interesting to see what happens when I upgrade my y-bed to aluminum..., on the off chance that'll change thermal response in a way that triggers the default thermal runaway protection settings. Likewise when I eventually upgrade to a SSR for the bed.

Anyways, congrats on things working out!

As for the end-of-print z move behaviour..., hmm. Since I switched to the new firmware, I noticed that I tend to have a "z-positive" dimple (guess that's a pimple) at the pre-homing exit point. It's very small/minor. I can't honestly say I've been attentive enough to attribute it to any one thing..., i.e., I haven't noticed there's any Z movement at the end of a print at all..., but that doesn't there hasn't been.

I'll keep an eye out and report back. For the moment..., here is the tail-end of a typical print:

...
G1 X140.361 Y106.977 E2.63078
G1 X140.323 Y105.648 E2.65583
G1 E0.65583 F900.00000
G92 E0
M104 S0 ; turn off temperature
M106 S255 ; Turn on part cooling fan to help speed cool-down
G28 X0 ; home X axis
G28 Y0 ; home Y axis
M84 ; disable motors
M190 S0 ; wait for bed temperature to be reached

[ROBOCOP]

I may also change my bed to aluminum/kapton heater. Not a fan of the PCB type expecially at 12x12 which bows and warps so easy. If you go with a SSR make sure its quality like a Crydom SSR . The cheap Fotek style dont work to well and cant handle PIDs.

As for the plunging im not sure why its doing it .I think its something in the mesh doing it as it only plunges down a few mm before homing the x and y but i dont have anything in my end code in S3D relating to Z at all. Could it have something to do with the below line in the mesh leveling code

#define MESH_HOME_SEARCH_Z 2

What does that do?

[lakester]

I'll check out MESH_HOME_SEARCH_Z, in the meantime, I wonder if the z-correction is being inappropriately removed/discounted during the homing operation...

I may also change my bed to aluminum/kapton heater. Not a fan of the PCB type expecially at 12x12 which bows and warps so easy. If you go with a SSR make sure its quality like a Crydom SSR . The cheap Fotek style dont work to well and cant handle PIDs.

As for the plunging im not sure why its doing it .I think its something in the mesh doing it as it only plunges down a few mm before homing the x and y but i dont have anything in my end code in S3D relating to Z at all. Could it have something to do with the below line in the mesh leveling code

#define MESH_HOME_SEARCH_Z 2

What does that do?

[lakester]

Hmm (again). In ROBOCOP's case, the G28 X0 Y0, if that is the actual gcode being used, should not create any z-movement at all.

MBL is disabled during most homing moves, but even that should produce no Z movement due to the loss of a previous correction. MBL IS enabled when G28 implies or specifies a Z homing operation (though not during any XY homing moves with which it is possibly combined).

For G28 operations that imply or explicitly specify Z, then in MOST cases, the Z move will be done last, after any XY moves (which is opposite the behavior ROBOCOP describes).

FWIW..., G28 X0 Y0 is one of a couple special cases for homing. It MIGHT be worth trying uncommenting the line:

//#define QUICK_HOME //if this is defined, if both x and y are to be homed, a diagonal move will be performed initially.

in Configuration_adv.h

..., though I kinda doubt this will inhibit the z-move you're seeing..., since I'm thinking the G28 may NOT be the culprit.

Anyways..., 0.02USD...

Note: almost forgot: the MESH_HOME_SEARCH_Z is MOSTLY involved with the bed leveling procedure itself..., I don't think it actually is influencing anything seen during "print time".

[lakester]

Small update:

I paid attention to z-movement at the end of the past couple of prints.

There is no z-movement during the end-of-print homing operation. FWIW, I'm homing XY with separate G28 commands, i.e.,
G28 X0
G28 Y0

When I print next, I'll try it with G28 X0 Y0.

[ROBOCOP]

G28 X0 Y0 should be the same . I havent had a chance to print to check .Ill post up when i do.