Closed VanessaE closed 5 years ago
Did you try increasing the value of THERMAL_PROTECTION_GRACE_PERIOD as I mentioned in the other thread?
No, not yet. Besides, it's not in either config file (had to grep, found it in src/HAL/HAL_LPC1768/HAL.h and src/module/temperature.cpp).
Not sure it would help, as it takes a good 3 seconds worth of rapid beeping before Marlin dumps out.
I did point you at the HAL.h file in the other thread. What makes you think it will not help? Anyway please try it as it may confirm what is causing the problem and make it more likely that it will get fixed correctly.
Oh and I would suggest you try increasing it to 5000 or 10000 for this test.
I ordered this 12864: [REPRAPGURU] 12864 LCD Full Graphic Smart Display Controller for RepRap RAMPS 1.4 3D Printer Mendel Prusa Arduino Mega Pololu Shield Arduino RepRap from Amazon recently. I'm also using the skr v1.3 on a delta printer, plus the tft 3.5 touch screen
If I:
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
display works no strange characters knows sd card present can't read sd card contents and cannot print from sd card
#define REPRAPWORLD_GRAPHICAL_LCD
display works but strange characters knows sd card present can read sd card contents and print from sd card
#define BQ_LCD_SMART_CONTROLLER
display works no strange characters knows sd card present can read sd card contents and can print from sd card
Have u tried defining another display controller??
Actually, too late now -- I was impatient to finish a project :smiley: (which was prompted by the purchase of the LCD), so now the whole shebang is set up and ready to print....and guess what? It boots fine now with both cards inserted.
I can only guess it's either because now I have the driver modules installed, or because 12v is hooked up now, both of which I assume could affect communications (since the TMC code needs a driver module to talk to, and it needs 12v to work properly, so maybe no modules and no 12v throws the comms code out of whack?).
True. If TMCs don't have their 12V there might still be bad behavior. The TMCStepper
library and integration into Marlin have been very active. Some updates are pending in the TMCStepper
project, so we might have a patch for the updated library soon.
I'm also using the skr v1.3 on a delta printer, plus the tft 3.5 touch screen
TFT at the same time as the other displays are enabled?
Interesting that BQ_LCD_SMART_CONTROLLER
worked where the others wouldn't. Was it that the display you received was more like that one, or do you think we probably have some wrong pin values?
@thinkyhead i have no idea why defining bq controller works. i thought it was discount graphics controller and thats what its sold as. And yes if i defined both serial ports you can run both displays at same time.
@mylife4aiurr and @thinkyhead That is very odd. Searching the source, as far as I can see there should be pretty much no difference between defining REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER and BQ_LCD_SMART_CONTROLLER (as defining BQ_LCD_SMART_CONTROLLER actually also defines REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER, see Conditionals_LCD.h) when using the skr V1.3 pins file. Maybe I've missed something, or there is some very subtle difference due to where the various defines get set?
As to the original problem (Marlin getting a spurious MINTEMP BED error in some circumstances), I am pretty sure this is down to the work around that was created by the use of THERMAL_PROTECTION_GRACE_PERIOD. Basically the LPC176x ADC code has a lot of additional filtering. It has a combination of a 23 slot median filter plus a low pass filter with K set to 6. According to the header file (HAL_LPC1768/HAL.h) this takes 565 samples to converge on a reading (though less will come pretty close). This really means that the temperature readings should not be trusted until several hundred readings have been made. In the past this was not a problem as the temperature checks did not kick in for some time after Marlin booted, but a few months ago this was changed so that the temperature min/max checks happen all of the time. When this change was made there were a lot of spurious halts with LPC1768 based boards. As a fix for this problem THERMAL_PROTECTION_GRACE_PERIOD was added which basically says ignore temperature readings until that many milliseconds after Marlin has started. The idea is that after this period Marlin will have performed enough ADC read operations and the filters will have converged. Unfortunately Marlin will only perform those read operations when the system is idle, so if something else (like reading and sorting the SD card filenames, or retrying TMC read operations, both of which are probably happening with the OP) takes up that time at Marlin startup then it may be that sufficient read operations will not have occurred and the temperature readings will still be invalid.
The "quick fix" for this is to simply increase the current setting of THERMAL_PROTECTION_GRACE_PERIOD from 1000 to something less marginal (according to the comments the time period needed for convergence of the readings is 1.13 seconds, so the 1000mS is already on the edge). I'd suggest raising it to at least 5000. But really a better fix would be to either seed the filters with better initial values, or to keep track of the number of samples taken and not trust the data until sufficient readings have been made.
There was a discussion about this issue in the following PR: https://github.com/MarlinFirmware/Marlin/pull/13778 @p3p @thinkhead any more thoughts on this?
If something is not done then I think we will continue to get reports of how various configuration options/hardware setups etc. cause a "crash" at startup (which on an LPC176x based board is not easily visible without a display as a thermal halt disconnects the USB serial port).
The amount of ADC filtering on the LPC is a somewhat extreme really, a good idea would be too reduce it by a lot, I don't find any noise problems by doing so myself.
@oneofnine That would probably help with this issue (at least for some users). But the current level of filtering was not an arbitrary choice. My understanding is that @p3p ended up adding the filtering because some users seemed to have high levels of noise (I have virtually zero on my own systems). Doing this was (at the time) a safe option as it did not really cause problems for those with clean readings and fixed problems for those that did not. The problem is that reducing the level of filtering now may cause problems for some unknown (possibly large) number of users.
Perhaps that would be an acceptable solution (at least we would get a better picture of the number of systems with the original noise issue), anyone with the noise problem could either fix the hardware issue, or increase the filtering (and probably also increase the value of THERMAL_PROTECTION_GRACE_PERIOD as well). But this may mean that for some number of users they would hit a problem and not be aware of the workaround (or not be capable of implementing it). If that number is large enough, then Marlin gets a reputation of not working, being unstable etc. I guess it depends how many of these things you want to try and allow for "out of the box".
Considering I have thermal protection disabled on the bed, and my power supply is not of the kind that can be turned off by Marlin, and I was not even trying to turn the bed on, I'm not sure I understand why any error should be possible (at least for the bed).
I don't think disabling thermal protection disables the min/max checks. However from looking at the code it looks to me like they should not trigger if the bed is off (well the min test shouldn't), but maybe there is more than one bug here (possibly you are actually getting a max temp error but the message is wrong?). It does look a little odd...
From configuration.h
Thermal Protection provides additional protection to your printer from damage and fire.. Marlin always includes safe min and max temperature ranges which protect against a broken or disconnected thermistor wire
#if HAS_HEATED_BED
#if TEMPDIR(BED) < 0
#define BEDCMP(A,B) ((A)<=(B))
#else
#define BEDCMP(A,B) ((A)>=(B))
#endif
const bool bed_on = (temp_bed.target > 0)
#if ENABLED(PIDTEMPBED)
|| (temp_bed.soft_pwm_amount > 0)
#endif
;
if (BEDCMP(temp_bed.raw, maxtemp_raw_BED)) max_temp_error(-1);
if (bed_on && BEDCMP(mintemp_raw_BED, temp_bed.raw)) min_temp_error(-1);
#endif
(possibly you are actually getting a max temp error but the message is wrong?)
I suppose that's possible, since at the time no thermistors were plugged in.
@gloomyandy I added the Median filter when the LPF proved to be insufficient and I decided that something more computationally / memory expensive was necessary, (The LPF is almost free no matter how high it is set) as it stands now the Median filter is the more important filter so its very possible that we can turn the LPF down considerably with no ill effect. According to my simulations anyway.
A unplugged thermistor, has like a thermistor with a broken wire a infinite resistance. We can't know what is what. We really want to test for broken and shorted wires. Maybe one day we should change the error texts. How about "ERROR: Unusual temperature detected. Likely the sensor is disconnected or shorted." that would unify min- and max-temp-errors and would avoid the nasty upper/lower end problem.
@AnHardt sure, if the heater's turned on, and thermal protection is enabled. That's not the case here.
@mylife4aiurr I have the same Problems but i solve this with a capicator on 5Volts Power. i make a PDF. Use a PDF translator to read. Add a capicitor to 5 Volts
As far as i can remember back to the beginning of marlin the heaters are never really switched off. It's just the set points are at 0°C - for any legal measured positiv temperature they try to cool the system down - means: do nothing until the temperature is that low, what will not happen. So if the measured temperature, by any error, should result in a negative temperature the heater would start to heat. Because the minimal allowed temperatures, where we get the wanted shutdown, are above zero the heater will not be on by a broken or unconnected thermistor. For the case of stuck ON MOSFET we can't switch it off. The heater will heat, the temperature will rise and after some time hopefully maxtemp-error is triggered That is unsatisfyingly late, but better than nothing. For the integration of the infamous high-temperature-thermistors (table 66 - 666 would have been more to the point), having very high resistances at room temperatures (you can't tell if connected or not) the max- & min-temp errors became switched off when the target temperature was zero. Later i reverted this for the max-temp-errors. They are detected again even if the target temperature is zero. Now, seemingly, someone !"improved" the tests to work on the wrong limit or throwing the wrong massage or something like that. I'll have a look into the code.
This used to be and is completely independent from 'thermal protection' and if you ask me, it will stay that way.
Long message short summary. As long the thermistors are not connected use tables 998 and/or 999 to measure fixed temperatures or define BOGUS_TEMPERATURE_FAILSAFE_OVERRIDE to get the errors but no reset.
Happy Independence Day.
@VanessaE is the issue still there?
I couldn't really say now, without tearing things apart.
i tried to read through this one again, was there any that had the same issue? i missed that even thou i read slowly
are the tmc's powered up correct? ie logic voltage (3.3/5) first and 24V last?
Check the title -- this is for when they're not powered at all (such as when first setting up a board, running entirely from USB, before hooking up the primary power supply) :smile:
hmm... just a wild guess here, could it be how the hardware is designed that is the real fault?
I wouldn't think so. Short of a catastrophic hardware failure, a crash in any piece of software almost always means bug in the software (or firmware in this case). I.e. failure to handle some corner-case or unexpected condition.
But, let's just close this. Marlin devs have other things to deal with.
almost always means bug in the software (or firmware in this case).
but you are not sure?
I am 100% sure it's a bug, because if you re-read the first post, you'll see where I noted that Marlin throws a "MINTEMP" error and explicitly tells the user to press reset. Elsewhere in this thread, workarounds have been posted (which are only needed in only-USB-powered setups).
I understand why this bug is closed and that 1.1.6 is no longer supported, but I've discovered another edge case with almost identical symptomology that might be good for reference. The differences I've noticed are that it doesn't require the absence of driver chips, and applying 12v power doesn't seem to have an effect.
Starting from the Creality CR-10S5 source for 1.1.6 with BLTouch, using ProjectIO in VSCode configured for Mega2560 on (pres.) the Creality V2.2 board...
In Configuration.h ...uncomment line 627: define FIX_MOUNTED_PROBE ...comment out line 638: define BLTOUCH ...comment out line 866: define AUTO_BED_LEVELING_BILINEAR ...uncomment line 867: define AUTO_BED_LEVELING_UBL ...change value in line 938 from 10 to 15: define GRID_MAX_POINTS_X 15
In ultralcd.cpp you will also have to correct several function calls to their equivalents from language_en.h to compile successfully.
Up to this point the firmware will flash successfully and provide a functional device.
Finally, back in Configuration.h ...uncomment line 948: define UBL_G26_MESH_VALIDATION
At this point, your firmware will flash successfully, but with a SD card present in the appropriate slot it will announce the following error message at the end of the boot sequence exactly: ERR: MINTEMP_BED PRINTER HALTED Please reset
Rebooting with 12v power via the switch on the back of the device with the SD card inserted does not bypass the error message. Removing the SD card prior to USB power-on does bypass the error message. I have not tested with 12v on and SD removed.
As stated above, this information is provided for reference, with no expectation of assistance.
@claws61821 — With MARLIN_DEV_MODE
enabled what does the bootup report look like in the current bugfix-2.0.x
branch?
@thinkyhead I assume this is what you refer to? I tried to keep all the equivalent options set identically in config and config_adv between the two builds even though 2.0.x has a few better options available, just to reduce variables for the test.
> Executing task in folder Marlin-bugfix-2.0.x: C:\Users\pokem\.platformio\penv\Scripts\platformio.exe device monitor <
--- Available filters and text transformations: colorize, debug, default, direct, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at http://bit.ly/pio-monitor-filters
--- Miniterm on COM4 115200,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
echo:start
echo:[1] HAL_init()
echo:[2] recovery.setup()
echo:[5] setup_killpin()
echo:[7] setup_powerhold()
echo:[9] esp_wifi_init()
Marlin bugfix-2.0.x
echo: Last Updated: 2020-04-29 | Author: (CR-10 S5 Nozzle Probe)
echo:Compiled: Apr 30 2020
echo: Free Memory: 2184 PlannerBufferBytes: 1264
echo:[24] ui.init()
echo:[26] ui.reset_status()
echo:[28] ui.show_bootscreen()
echo:[4263] settings.first_load()
echo:EEPROM version mismatch (EEPROM=? Marlin=V78)
Configuration files attached. Marlin.zip
EDIT: 2.0.x does not appear to exhibit the same problematic error at first glance.
EDIT 2: Both versions' config files for comparison and reference. Creality-116-vs-Marlin-20x.zip
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.
Using Debian Buster, Marlin at commit c28e08c8, running an SKR v1.3 with a brand new RRD 12864 display (BigTreeTech red PCB model with contrast pot, via normal cables that needed no twisting/flipping/rewiring)
Using the configs below, if I boot with the LCD's SD card inserted, the beeper first sounds its normal long tone while it boots (due to the nature of a stock RRD 12864), then as soon as the Marlin title card is replaced by the main info screen, it begins beeping rapidly for a few seconds, then throws a "MINTEMP BED" error, and tells me to reset (and sounds a long tone).
It doesn't matter whether or not the SKR's SD card is inserted when booting; if I leave the LCD's card out at boot, then insert it once Marlin's up, it behaves as it ought to, or so far as I've been able to test at this point, since I'm just tinkering.
Sounds like it's getting caught in a loop and triggering the watchdog, but note that I am running strictly on USB power, with nothing connected to the SKR but the LCD. There's no 12v power hooked up, thus I am NOT trying to turn on any heaters -- this "crash" happens before I can do anything.
I also have a custom thermistor table set up for the hotend, see #14258.
Configuration.h
``` /** * Marlin 3D Printer Firmware * Copyright (c) 2019 MarlinFirmware [https://github.com/MarlinFirmware/Marlin] * * Based on Sprinter and grbl. * Copyright (c) 2011 Camiel Gubbels / Erik van der Zalm * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, seeConfiguration_adv.h
``` /** * Marlin 3D Printer Firmware * Copyright (c) 2019 MarlinFirmware [https://github.com/MarlinFirmware/Marlin] * * Based on Sprinter and grbl. * Copyright (c) 2011 Camiel Gubbels / Erik van der Zalm * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see