I've been having that trouble myself occasionally since I started using RCBugfix. The bed heater seems to stall out, then the print cancels and the printer disconnects from OctoPi. I'm glad to hear it's a known issue, and that there's a workaround.Quote:
Originally Posted by printbus
We are near the end of RC-7. I'm not sure that I remember any thermal issues in RC-7. I do remember some issues in RC-6.Quote:
Originally Posted by AbuMaia
The only thing concerning thermal issues lately is this thread speculating there may be a bug in the way the PID algorithm works:
https://github.com/MarlinFirmware/Marlin/issues/4881
If you are having problems with your heaters doing the right thing, please let us know!!!
Where does one post these issues? I am relatively new to the debugging process. before I used the Bec release with great success. I think it may be a PID issue. As soon as the fan is on and anywhere close to the nozzle the temps drop like a rock without the sock on. I have had issues before with air cooling the nozzle down but the printer could usually keep up and the temp only would drop a few degrees.
I took off the silicone E3D sock heated the nozzle to 210 and then turned on the fan. The temps dropped to below 148 in less than 30 seconds. As soon as the air hit the nozzle it was as if the PID had no idea what to do. With the sock on and the fan set to full the temp drops a little, about 10 degrees or so.
So far my only problems have been with the print bed heater, and I (think I) have it on a bang-bang setup, not PID. I have my bed heater connected through a relay, so I don't think PID or PWM would be a good option. The issue is somewhat rare, though. Maybe only once in 7-8 prints.Quote:
Originally Posted by Roxy
Right! Bang Bang mode is separate from PID. But still... You shouldn't be seeing any problems. If you are running RC-7 and see an issue, please click the 'Issues' button (at: https://github.com/MarlinFirmware/Ma...3Aupdated-desc ) and describe the problem.Quote:
Originally Posted by AbuMaia
Hi
Yes, it's duplicate info, but it's probably worth posting here.
If you are running the Arduino app that MakerFarm recommends (1.06) on a Mac, the latest OS update to Sierra brakes it. You re-install Java after the update. After that the app simply locks up. The solution is stupid. You delete the app and re-install it. Once you do, all is well again.
Bob
Just had the bed throw an error again.
That was all the error message OctoPrint gave me. Doesn't say if it was a thermal runaway or not.Code:Recv: Error:Heating failed, system stopped! Heater_ID: bed
Changing monitoring state from 'Printing' to 'Error: Heating failed, system stopped! Heater_ID: bed
'
Recv: Error:Printer halted. kill() called!
HiQuote:
Originally Posted by AbuMaia
That looks like thermal runaway to me. Simply put, it's calling for heat for to long a period of time and deciding the thermistor is not responding. Simple answer is to stretch out the timeout, if you do it in firmware. Putting a solid state relay on my printer was a < $15 decision. With PWM the problem has never occurred. To fix it without new hardware, bumping up your power supply voltage might do the trick. Obviously, each of these approaches has its own drawbacks.
Bob
The Thermal Parameters are (in my opinion) overly tight. The people that wrote the Thermal Protection wanted to make them even tighter! I have mine currently at these numbers, but I think I'm going to have to bump the 20 up to 30.
Code:#if ENABLED(THERMAL_PROTECTION_BED)
#define THERMAL_PROTECTION_BED_PERIOD 20 // Seconds
#define THERMAL_PROTECTION_BED_HYSTERESIS 2 // Degrees Celsius
#define WATCH_BED_TEMP_PERIOD 60 // Seconds
#define WATCH_BED_TEMP_INCREASE 2 // Degrees Celsius
#endif
Hi
A heated bed is a much different animal than a hot end. The numbers you need for one are not what you need for the other. A bed isn't going to kill it's self in a minute or three. A hot end easily could get into big trouble in that amount of time. ....
Bob
I am trying to get my 8" i3v going again after several months of neglect. I have the hardware for ABL.. what is the address of the latest/best marlin RAMPS build?
HiQuote:
Originally Posted by Chips
https://github.com/MarlinFirmware/Marlin is always the "right" way in. RC7 appears to be the latest.
Bob
Actually... RC-7 is a very stable point in time. But RCBugFix is always more up to date than the frozen RC-# Unless you have a real reason for not using RCBugFix, that is usually the best choice.
Is there a configuation.h that you have built? After I uploaded rc7, my LCD is blank... I looked over the configuation.h, but nothing jumped out at me.
HiQuote:
Originally Posted by Chips
You probably have the wrong display enabled.
Bob
I am getting ready to update my firmware and noticed the RC-8 is available. Should I use this or RC-7?Quote:
Originally Posted by Roxy
For sure... RC-8 is much better than RC-7. But you really should be using RCBugFix. Right now, RCBugFix is very close to RC-8. But over time... RCBugFix will be much better than RC-8.
Hi
What's the status of mesh bed leveling in RC-8 / RCBugFix?
Bob
It works. But the RC-8 / RCBugFix version does not allow you to save the mesh. The UBL Branch lets you save the mesh and it also provides very nice Mesh Validation Pattern and Editing commands for the Mesh.
Hi
It's the mesh pattern validation stuff that I'm waiting for .... trust but verify :) ... I've dropped the median filter back to 3 samples on the BLTouch and need to check things from time to time.
Bob
I apologize for all the questions, but I do appreciate your knowledge and time.Quote:
Originally Posted by Roxy
This morning I started modifying the RC Bug Fix and then I read this comment. In the future I am planning on using the BL touch to implement ABL/Mesh Leveling. if I understand your comment correctly, with RC Bug Fix it won't save the Mesh but will run at the start of every print to create that mesh. Is this correct?
I just want to ensure whatever firmware I use I will be setup for success with my planned upgrades.
Hi
You have two simple choices:
1) Auto bed leveling, (bilinear or whatever) that just does it's thing with a G29 gcode. It resets when any G28 (X,Y,Z) comes in.
2) Mesh bed leveling, this runs with a sequence of G28 commands (or at least it used to). There is a bit more to the startup script as a result.
The BLTouch has it's own issues, but seems to be "good enough".
Bob
So I am working through the firmware and am getting compile errors.
https://www.dropbox.com/s/sjafx44u4d...arlin.rar?dl=0
That is a RAR of my firmware, can someone look at it and let me know what I did wrong? Thank you!
Hi
Start from scratch and do a compile. It should compile without errors. If it does not, re-install your toolchain and re-download the code. Next, add your changes one at a time and do a compile. The one that makes it puke is suspect :) Multiple definitions for a feature are the most common issue (You can only have one display etc). If you are a "bulk change" sort of person, make notes on each line you change. Do the process in reverse, comment out each change and compile after each reversal.
That may sound like a lot of time and a lot of work. It is enormously faster than waiting for somebody else to download your config and then find the time to check it out. There is inevitably a bit of back and forth with that process:
The first layer issue with your config is that it is defining ULTIPANEL as the display and then looking for the data structures that are associated with it. Do you have a normal MakerFarm or have you modified the display?
Bob
Thank you for your input!Quote:
Originally Posted by uncle_bob
I have been copying a lot of settings from the original Marlin 1.02 that is provided by Colin. So I will keep digging through it and see what happens.
Yes I do have the original Graphical LCD.
Hi
There are only a handful of settings that matter:
1) The display
2) The heater Kp, Ki, Kd numbers
3) The steps per mm on each axis
4) The thermistor types
5) End stops polarity
6) Home directions
7) The bed size
8) The speed and acceleration stuff
9) the temperature limits
Past that it's things like enable (or not) on the eeprom and bed leveling / probes. There is also some fluff like giving it a name. Get the first set of items above working and then add the other stuff a bit at a time. If you want to cut the list above in half and just do 1 through 6, the printer should work in that state. It won't be perfect, but it will boot and home.
Bob
So I have movement, PID, thermistor's, etc working. The only thing I cannot get to work is the LCD. I keep getting that compile error.Quote:
Originally Posted by uncle_bob
I have the following two things defined:
#define DOGLCD
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
If I undefine those two lines then it will compile and upload. But then I cannot use the LCD. Any idea's?
Hi
Dump DOGLCD.
Bob
I have tried that and just left "#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER". It still gives me a compiling error, I am attempting to use Marlin 1.1 RC8 Bug Fix.Quote:
Originally Posted by uncle_bob
I also have the UG8lib in my libraries folder.
What is your compile error?
I did a debug build for someone a long time ago, and what it boiled down to was this (from configuration.h at the time)
// ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: https://github.com/olikraus/U8glib_Arduino
Without that library, the graphic stuff won't build.
EDIT: Ah. Just saw your comment that came in while I was typing.
Hi
Start from a scratch compile, undefine their default display and define the graphics controller. Unless there is a very new bug, it should compile.
Bob
Quote:
Originally Posted by printbus
I got it working! I found a typo in the following section:Quote:
Originally Posted by uncle_bob
"#define PREHEAT_1_TEMP_HOTEND 180
#define PREHEAT_1_TEMP_BED 70
#define PREHEAT_1_FAN_SPEED 0"
So when it was trying to compile it couldn't match those values with another .h file. All is fixed for now. Thank you!
Glad it's working !!!
Yes... Your understanding is correct. And incidentally, the BL-Touch stuff was added after UBL forked from RC-7. So you can use a BL-Touch with UBL, but you have to set it up as manually instead of just saying you have a BL-Touch probe. I'm off skiing in Taos. As soon as I get back I'm going to be doing a 3-way merge to get UBL running on top of RC-8. At that point, the simple BL-Touch support will be in UBL also. Realistically, it will be a week or two into January before that happens.Quote:
Originally Posted by BLKKROW
But if you are going to do Mesh Bed Leveling... You really should consider bringing up the UBL system. You will get 100% adhesion across the entire bed every time.
I use Sketchup pro to design my models and I just export the STL file into simplifying 3D and boom chicken soup I can create 2 color prints any shape I want really easy if you're interested I have included a link to YouTube showing the process https://youtu.be/TXpJW1RhCA4
HiQuote:
Originally Posted by techinout
The problems come when you have multiple colors (say 4) and they are all present on a layer (think Rubix cube). Unlike simple color change past this layer stuff, that sort of thing is not easily handled at several levels in our existing tool chains. Brewing up 4 interlocking STL's and getting them all set up is the way it's done. Not a lot of fun ....
Bob