ValueError: could not convert string to float: line 1995 pronterface.py

[otede]

Hi!

Since the Ethernet connection on my noname 3D printer is nonfunctional USB + Pronterface seems to be my last hope of getting any PC integration and control. When I tried it for the first time however I get the following errors in loop after hitting the connect button:

Printer is now online.
Traceback (most recent call last):
  File "printrun\pronterface.py", line 1995, in update_tempdisplay
ValueError: could not convert string to float: ''

Traceback (most recent call last):
  File "printrun\pronterface.py", line 1995, in update_tempdisplay
ValueError: could not convert string to float: ''

Traceback (most recent call last):
  File "printrun\pronterface.py", line 1995, in update_tempdisplay
ValueError: could not convert string to float: ''

Traceback (most recent call last):
  File "printrun\pronterface.py", line 1995, in update_tempdisplay
ValueError: could not convert string to float: ''

Disconnected.
Connecting...
Traceback (most recent call last):
  File "printrun\pronterface.py", line 1995, in update_tempdisplay
ValueError: could not convert string to float: ''

Printer is now online.
Traceback (most recent call last):
  File "printrun\pronterface.py", line 1995, in update_tempdisplay
ValueError: could not convert string to float: ''

I tried all the available ports with combinations of Baud rates of 9600 115200 and 250000. No luck, same error.

Windows 10 x64
LUME Plus printer based on MKS SBASE v1.3 and smoothieware
Smoothieboard shows up in my windows devices and I can see the files on the board micro sd card (the one that holds firmware and config).

[DivingDuck]

Guess, you are running an old version of Pronterface. Please update to the latest version.
https://github.com/kliment/Printrun/releases/tag/printrun-2.0.1
Smoothieware runs fine with MKS Sbase 1.3 and Pronterface. Default baud rate should be set to what you have set in your configuration file under -->## System configuration -->uart0.baud_rate (usually 115200 baud)

[otede]

Guess, you are running an old version of Pronterface. Please update to the latest version. https://github.com/kliment/Printrun/releases/tag/printrun-2.0.1 Smoothieware runs fine with MKS Sbase 1.3 and Pronterface. Default baud rate should be set to what you have set in your configuration file under -->## System configuration -->uart0.baud_rate (usually 115200 baud)

I'm running 2.0.1 from the official site. x64 package. As for the Baud value I checked pretty much every possible one. It's 250000 in my firmware config (on the MKS SBASE system microsd card).

[DivingDuck]

Try lower the baud rate to 115200 on both, Smoothieware config and Printrun. You need to reboot the controller.

Btw, I was never able to get this controller to run smoothly without errors at such a high baud rate.

[otede]

Try lower the baud rate to 115200 on both, Smoothieware config and Printrun. You need to reboot the controller.

Btw, I was never able to get this controller to run smoothly without errors at such a high baud rate.

Thanks for chiming in. No luck though. I tested by setting values both in the config of the printer board as well as in Pronterface, always resetting the printer after config value change. This way I tested both 115200 as well as 9600 bits per second in combinations with both available USB ports (COM3 and COM4). Why 9600? Because I noticed that in Control Panel > Devices>...>Port settings the bitrate for the 3 and 4 ports keeps reverting to 9600. Still no luck.

[otede]

Well, scratch that. I have noticed something weird. After config edits my printer is paralyzed. So we won't even know if it isn't connecting due to comms problem or due to its paralyzed state.

It boots and allows me to browse the LCD menus but won't respond to any commands. Motors quiet, bed and hotend temps at 0/0. Specifically it does that when I dare to touch ANYTHING in the port section of the config! Despite being able to succesfully change steps per mm for extruder. I even read the documentation on the touchyt nature of Smoothieware, didn't use Npp, saved as - ANSI encoding, everything.
http://smoothieware.github.io/Webif-pack/documentation/web/html/configuring-smoothie.html
I give up. I truly give up.

[otede]

Smoothueware guys say the baud rate is irrelevant when connecting via USB
Smoothieware/Smoothieware#1531

[otede]

Update:
I was able to connect via COM3@9600 (250000 baud rate value in the smoothieware config is still untouchable). Not only that, it seems that the whole MONITOR tab in Cura has gone live with all the functionality!

What I did: Run as Administrator

My very first G-Command issued:

M503
SENDING:M503
; No config override
;Steps per unit:
M92 X200.00000 Y200.00000 Z3200.00000
;Acceleration mm/sec^2:
M204 S3500.00000 Z300.00000
;X- Junction Deviation, Z- Z junction deviation, S - Minimum Planner speed mm/sec:
M205 X0.05000 Z-1.00000 S0.00000
;Max cartesian feedrates in mm/sec:
M203 X166.66667 Y166.66667 Z8.33333
;Max actuator feedrates in mm/sec:
M203.1 X300.00000 Y300.00000 Z8.33333
;WCS settings
G54
;Digipot Motor currents:
M907 X0.25000 Y0.25000 Z0.25000 E0.30000
;Home offset (mm):
M206 X0.00 Y0.00 Z0.00
;E Steps per mm:
M92 E196.1200 P57988
;E Filament diameter:
M200 D0.0000 P57988
;E retract length, feedrate:
M207 S3.0000 F2700.0000 Z0.0000 Q6000.0000 P57988
;E retract recover length, feedrate:
M208 S0.0000 F480.0000 P57988
;E acceleration mm/sec²:
M204 E500.0000 P57988
;E max feed rate mm/sec:
M203 E50.0000 P57988
;PID settings:
M301 S0 P10.0000 I0.3000 D200.0000 X255.0000 Y255
;Max temperature setting:
M143 S0 P300.0000
;PID settings:
M301 S1 P10.0000 I0.3000 D200.0000 X255.0000 Y255
;Max temperature setting:
M143 S1 P300.0000

M115 still gives no return.

[rockstorm101]

Smoothueware guys say the baud rate is irrelevant when connecting via USB Smoothieware/Smoothieware#1531

Thanks for sharing your progress. It seems the firmware would not accept the M115 command, hence, no output. Do you still get the ValueError: could not convert string to float: '' error? If yes, please enable debugging and paste here the output to see what's going on. I suspect your firmware gives temperature feedback in a way Pronterface is not used to.

[otede]

Smoothueware guys say the baud rate is irrelevant when connecting via USB Smoothieware/Smoothieware#1531

Thanks for sharing your progress. It seems the firmware would not accept the M115 command, hence, no output. Do you still get the ValueError: could not convert string to float: '' error? If yes, please enable debugging and paste here the output to see what's going on. I suspect your firmware gives temperature feedback in a way Pronterface is not used to.

That error prevented the printer from connecting. After using the Administrator mode for running the executable I am able to connect, use the printer and I do not get that "value error" anymore. M115 is not accepted due to ancient firmware version (early 2017 at best).

[rockstorm101]

I am able to connect, use the printer and I do not get that "value error" anymore.

Happy to hear that. Could we consider the issue as resolved then?

[otede]

I am able to connect, use the printer and I do not get that "value error" anymore.

Happy to hear that. Could we consider the issue as resolved then?

In my opinion this kind of software should not require to be Run as Administrator for basic functionality.

[DivingDuck]

Hi,
I just read the comments.
Some remarks:
a) Pronterface usually need no admin rights for connecting with this controller via USB except your user profile do restrict it (what is not a default setting for Windows 10, at least for my computers).
b) MKS board and touch screen (MKS as well?) need the same baud rate setting as I mentioned.
c) 250000 baud: This will not work reliable with your board and, I guess your touch screen is a MKS-TFT 2.8" or 3.2" as well.
d) You really should update to the actual firmware version of Smoothieware. (same for your touchscreen I guess)

Why do I say this? Because of one of my self build printers has a MKS Sbase 1.3 as print controller and is doing the job quite well with all Pronterface versions so fare. I use this printer usually for big prints with up to 72 hours print time.

Anyway, this won't help you. Best advice I can give you is updating your printer firmware and config file and in case your touch screen is from mks as well you should update the firmware and config file for this device too.

Edit:
I just took a look on your comment "Smoothueware guys say the baud rate is irrelevant when connecting via USB"

Guess I need to explain how this works. We are talking about different things here:
a) USB connection for connecting the MKS Sbase to your computer: For this there is no setup in the config file. This is correct. Computer and the printer port do negotiate the speed normally itself to the max rate that is possible. This does not mean that this is a speed rate is error proof all the time while you are printing. This is why I mentioned to reduce 115200 baud for Pronterface. This works usually for most printers with a normal USB cable up to 3 meters. Side tip: Don't activate ports that are not connected.
b) Serial connection between MKS Sbase and your touch screen: For this connection you need to set the communication speed and port on both devices. For MKS Sbase this is uart0 (config) and for the MKS TFT you do not need to set the port number but you need to set the speed. Both devices need to have the same speed setup.
Speed can be (file mks_config.txt):

 #baud rate (9600:1; 57600:2; 115200:3; 250000:4)
>cfg_baud_rate:3

Here as well: I would suggest don't use 250000. This speed is not reliable and you will notice that the screen module will sometimes crash during a print in an unpredictable way. You will have a bad day if that happen during long prints (Guess, why I know that...)
So in the end you need to check / edit two config files, the one for the printer and the one for the touch screen (in case both devices are from MKS)

[otede]

Hi, I just read the comments. Some remarks: a) Pronterface usually need no admin rights for connecting with this controller via USB except your user profile do restrict it (what is not a default setting for Windows 10, at least for my computers). b) MKS board and touch screen (MKS as well?) need the same baud rate setting as I mentioned. c) 250000 baud: This will not work reliable with your board and, I guess your touch screen is a MKS-TFT 2.8" or 3.2" as well. d) You really should update to the actual firmware version of Smoothieware. (same for your touchscreen I guess)

Why do I say this? Because of one of my self build printers has a MKS Sbase 1.3 as print controller and is doing the job quite well with all Pronterface versions so fare. I use this printer usually for big prints with up to 72 hours print time.

Anyway, this won't help you. Best advice I can give you is updating your printer firmware and config file and in case your touch screen is from mks as well you should update the firmware and config file for this device too.

Edit: I just took a look on your comment "Smoothueware guys say the baud rate is irrelevant when connecting via USB"

Guess I need to explain how this works. We are talking about different things here: a) USB connection for connecting the MKS Sbase to your computer: For this there is no setup in the config file. This is correct. Computer and the printer port do negotiate the speed normally itself to the max rate that is possible. This does not mean that this is a speed rate is error proof all the time while you are printing. This is why I mentioned to reduce 115200 baud for Pronterface. This works usually for most printers with a normal USB cable up to 3 meters. Side tip: Don't activate ports that are not connected. b) Serial connection between MKS Sbase and your touch screen: For this connection you need to set the communication speed and port on both devices. For MKS Sbase this is uart0 (config) and for the MKS TFT you do not need to set the port number but you need to set the speed. Both devices need to have the same speed setup. Speed can be (file mks_config.txt):

 #baud rate (9600:1; 57600:2; 115200:3; 250000:4)
>cfg_baud_rate:3

Here as well: I would suggest don't use 250000. This speed is not reliable and you will notice that the screen module will sometimes crash during a print in an unpredictable way. You will have a bad day if that happen during long prints (Guess, why I know that...) So in the end you need to check / edit two config files, the one for the printer and the one for the touch screen (in case both devices are from MKS)

Ad your remarks
a) how do you know it's the specifics of my Windows profile?
b) as I mentioned already, I checked multiple times that the baud rate section of the MKS SBASE config.txt is untouchable, even when matched with the TFT
c) it says on the PCB my TFT is MKS TFT32_L V2.0 T There are two problems with that:
c1) The current firmware file (as provided by the manufacturer) is... MKSTFT28
c2) github makerbase-mks/MKS-TFT-Hardware only contains firmware for V3.x and V4.0_003

Updating firmware is risky, knowing that my printer is fully functional and, as of this week, finally connected and controled via USB! Hell, https://github.com/makerbase-mks/MKS-SBASE doesn't even provide firmware and smoothieware.org is down. Only by my guess this is supposed to be the right place for firmware https://github.com/Smoothieware/Smoothieware and this https://github.com/Smoothieware/Smoothieware/tree/edge/ConfigSamples/Smoothieboard for config file

EDIT:
And what the hell is the difference between
https://github.com/makerbase-mks/MKS-TFT-Hardware
and
https://github.com/makerbase-mks/MKS-TFT
? :D

EDIT2:
Looking into TFT config - do I even use Smoothieware?!
#mainboard firmware setting(marlin:1; repetier:2; smoothie:3)

cfg_firmware_type:1

[DivingDuck]

This seems to end in a MKS and Smoothieware session. :)

Here you will find all TFT2.8/3.2 firmware releases:
https://github.com/makerbase-mks/MKS-TFT/tree/master/MKS-TFT2.8-3.2
MKS-TFT-Hardware means this is hardware related. Includes schematics, BOM etc.

Btw, I saw, your MKS Sbase config files are ANSI coded. My files are all utf-8 coded and is the correct coding as fare I know. Had you open and save the file as txt in a text editor? You should not do that. This is a well known source of trouble. Use a coding editor like notepad++, VSC etc for editing the file. In addition you don't need the extension .txt. This will prevent to open the file with an normal text editor as well.

"Looking into TFT config - do I even use Smoothieware?!"
You should know. Did you maybe copy the wrong config file and firmware to your touchscreen sd card and then accidentally update the device?

Regarding risky update:
This is only risky if you do not have the original setup and firmware files. For both, Sbase and touch screen you can go for- and backward between versions. You only need to check for changes in the config file between versions. For touch screen you need to be aware that there is more then only the config and firmware file, there is a complete set of folders and files. You should take care you have a complete set of original files for fonts and images too.

Regarding firmware for MKS Sbase from MKS:
Forget those versions. Use the version from github Smoothieware, the firmwareBin folder include the the latest official version. https://github.com/Smoothieware/Smoothieware/tree/edge/FirmwareBin (firmware-latest.bin). You need to rename the copy at your SD card to firmware.bin
You need to compile yourself in case you want to install the latest software changes (simply follow the instructions (Quick start and Building Smoothie).

Regarding config file:
Use this as template with the new firmware (and update the settings to your original values as they will not match, eg. pin definitions are partly different between Smoothie- and MKS hardware):
https://github.com/Smoothieware/Smoothieware/tree/edge/ConfigSamples/Smoothieboard
Again, take care you have a backup of your original config and firmware. You should always have this kind of backup for each version you install. This makes it easy to switch between versions :)

Regarding smoothieware.org:
This is a pitty and isn't a good sign. The site is down for more than a month. I told them but no reaction. Their homepage was a mess too and error prone with a lot of wrong links to detail pages. Anyway, luckily you can use two possible ways to come around this:
Via Wayback machine:
https://web.archive.org/web/20230131192853/http://www.smoothieware.org/
and an old alternative link (from 2016, outdated):
http://smoothieware.github.io/Webif-pack/documentation/web/html/index.html
You will find out that some of the links at their homepage are not working. Like "http://www.smoothieware.org/supported_g-codes". Change to underscore to a dash like "http://www.smoothieware.org/supported-g-codes". Then you will have access to the link. (A well known error since years).

So, I guess this is all I can do for you for now.

[otede]

@DivingDuck Please baer with me a litle bit longer :) Our firmware and config sources do match. What I did:

1. Updated the TFT firmware (\TFT28_32_v3.0.6 Release file\Examples\Classic_En_Blue, version 3.0.6), verified working with the old firmware, printed a test print fine after normal bed leveling. Yes, I know the update process needs a set of files and folders :)
2. Grabbed the Smoothieware/Smoothieware/tree/edge/ConfigSamples/Smoothieboard config and copied to it all the values (by hand) from the latest smoothieware config from the LUME manufacturer. Firmware update seem to went fine because the firmware.bin turned into firmware.CUR file.

Unfortunatelly the printer seems to be config-zombified. It boots, doesn't respond to commands and shows 0/0 temps for bed and hotend - exactly as it behaves when it deems the config file as 'corrupted.' I'll try to fiddle with the encoding etc. but note that there are conflicting directives on editing of the config. Unix end of line format and ANSI is what I got form smoothieware.org wiki!

Anyway, if you could take a look at the files and maybe share some tips in the meantime, that would be really awesome.
Files attached:
Smoothieware-edge git by wolfmanjm firmware for LUME MKS.zip

config - copy clean from LUME manufacturer 2023-09
config - copy clean from git 2023-12-13
config - copy frimware update 2023-12-13 values from LUME manufacturer as of 2023-09
some screenshots
firmware.bin and config - files fed to MKS for the purpose of the FW update today

[otede]

I've just tried saving as config.txt and UTF/ANSI plus EOL Win/Unix in all 4 combinations. No success. That's why I'd really appreciate if you could take a look at my files or share your config.

[otede]

I went a different route. Took:
A: the ancient LUME manufacturer's config (2023-09)
B: smoothie git config with values copied over from LUME manufacturer as of 2023-09

1. Used the A unaltered -> printer works
2. Started replacing section by section, taking lines from B to A -> printer works

Guess what. During the process I had to STAY AWAY from the section of the devil!

# Serial communications configuration ( baud rate default to 9600 if undefined )
uart0.baud_rate                              250000           # Baud rate for the default hardware serial port
second_usb_serial_enable                     true            # This enables a second usb serial port (to have both pronterface
                                                              # and a terminal connected)
#leds_disable                                true             # disable using leds after config loaded
#play_led_disable                            true             # disable the play led
pause_button_enable                          true             # Pause button enable
#pause_button_pin                            2.12             # pause button pin. default is P2.12
#kill_button_enable                           false            # set to true to enable a kill button
#kill_button_pin                              2.12             # kill button pin. default is same as pause button 2.12 (2.11 is another good choice)
#msd_disable                                 false            # disable the MSD (USB SDCARD) when set to true (needs special binary)
#dfu_enable                                  false            # for linux developers, set to true to enable DFU

Even though the github file has its own equivalent lines touching anything in the section above zombifies the printer! So I went around that section, qiute literally. I think I've got 99% transfered. Beeper on the TFT killed with a screw :D I wish I could get rid of that useless RepRap splash screen logo during the TFT startup as well.

[DivingDuck]

Sorry for my late answer.

Regarding UTF-8:
You need to create a new empty file in notepad++ (np++) first. Then check the coding and set it to UTF-8 in case it is not set automaticly. The next step then is copying the default entries from github. Open st github the config file via browser in raw mode (https://raw.githubusercontent.com/Smoothieware/Smoothieware/edge/ConfigSamples/Smoothieboard/config) and copy all entries and paste them into the newly created file in np++. Then edit the entries as needed. Do not delete any entries, just deactivate not needed entries with the # sign. Add entries that are not in the template.

I did this for you (hopefully I did not forgot an entry...). The zip file includes 3 files:
config-new -->your new config for the actual edge firmware. You only need to rename it as config (w/o the extension .txt)
config-template -->the new template file
config.-.works.txt --> an old version from you

config.zip

You will find in the new config file remarks from me like:
#add --> I add this entry
#was activated --> I deactivate this entry
beta_homing_direction home_to_max #home_to_min #... --> I change the original entry to an new value

Edit:

Regarding splash screen logo:
You can do that. This PDF is maybe helpful for you :) :
MKS TFT28 32 DataSheet(modifiziert).pdf

[otede]

@DivingDuck I don't know if you read my latest post before doing all that :) but except for the Satanic Serial section I got 99% done and working with the printer. My plan now:

1. Get rid of the Satanic Serial section using the section from your config (done and tested!)
2. Trim the config junk!!! I'm doing a clean copy of your config as well, possibly to match the line numbers.
3. Compare with your config.
4. Well... Test the Printrun connection without Run as Administrator :)

Regarding splash screen logo: From what I've read getting rid of it only gives you blank screen, no additional boot info.

Re the following:
EPCOS100K Honeywell100K deactivated See http://smoothieware.org/temperaturecontrol#thermistor
temperature_control.bed.beta 4120 3974 activated Or set the beta value
nowy termistor EPCOS B57620C104J162 ????????# Question: same thermistor as for hotend???????
temperature_control.bed.rt_curve 20.0,129700,150.0,1479,240.0,243 # add #TEN EPCOS TO INNY MODEL, DLATEGO LINIA ZAKOMENTOWANA

No, it's not the same. It's an SMD thermistor. I used the datasheet Beta 4120 value instead of the rt_curve because the smoothieware wiki listed the curve for a different EPCOS100K variant, i.e. not B57620C104J162 I'm using. I had to replace it after accidentally cracking the original one.
The hotend thermistor model is unknown model, of the "glass enclosure" type. If you can guess a replacement, now's the time to share, because its wires are already at the end of the life. The heater element voltage is also unknown to me.

One quality of life impro I'm after is having the hotend fan not spin all the time while not printing. I might hack it with an actual manual switch.

EDIT:
The main issue in question tested and still present with the latest TFT and board firmware. I still have to run the program As Administrator.

EDIT2:
M115 is now supported

>>> M115
SENDING:M115
FIRMWARE_NAME:Smoothieware, FIRMWARE_URL:http%3A//smoothieware.org, X-SOURCE_CODE_URL:https://github.com/Smoothieware/Smoothieware, FIRMWARE_VERSION:edge-cf1a3ac, PROTOCOL_VERSION:1.0, X-FIRMWARE_BUILD_DATE:Dec 30 2022 12:08:54, X-SYSTEM_CLOCK:100MHz, X-AXES:5, X-GRBL_MODE:0, X-ARCS:1, X-CNC:0, X-MSD:1, X-WARNING:deprecated_MCU

.

[otede]

@DivingDuck Unfortunately, I ran into a problem with overzealous Smoothieware thermal runaway protection for the hotend. It keeps halting my prints on layer 2 or 3 (Z=0.5 at 0.2 layer height), some 60 seconds after the hotend cooling fan comes on. There is no way to disable that "feature" and testing with the following extreme values did not help a bit. Any ideas, Duck?

temperature_control.hotend.runaway_heating_timeout      2040  # def 90 How long it can take to heat up, max is 2040 seconds.
temperature_control.hotend.runaway_cooling_timeout        60  # def 0 How long it can take to cool down if temp is set lower, max is 2040 seconds
temperature_control.hotend.runaway_range                60   # def 20 How far from the set temperature it can wander, max setting is 63°C

EDIT:
I did one run with Printrun connected. The message I got was
ERROR: Temperature runaway on B (delta temp 27.468994), HALT asserted, TURN POWER OFF IMMEDIATELY - reset or M999 required

EDIT:
This entire section is copy-pasted from the current config and the values are identical to the manufacturer's provided firmware config:

temperature_control.hotend.enable            true             # Whether to activate this ( "hotend" ) module at all.
temperature_control.hotend.thermistor_pin    0.24             # Pin for the thermistor to read
temperature_control.hotend.heater_pin        2.7              # Pin that controls the heater, set to nc if a readonly thermistor is being defined
temperature_control.hotend.thermistor        RRRF100K        # See http://smoothieware.org/temperaturecontrol#toc5
#temperature_control.hotend.beta             3950             # Or set the beta value
temperature_control.hotend.rt_curve	     20.0,129700,150.0,1479,240.0,243
temperature_control.hotend.set_m_code        104              # M-code to set the temperature for this module
temperature_control.hotend.set_and_wait_m_code 109            # M-code to set-and-wait for this module
temperature_control.hotend.designator        T  

[DivingDuck]

You can deactivate the runaway protection by setting the timeout to 0. It is a bit risky, but for testing ok as long as you are near by your printer in case something goes really wrong. Better you find out why smoothie is thinking there is a thermal runaway fault.
Check if in Pronterface the temperature is not reported or if there are huge temperature jumps etc. Maybe you have a faulty wire, connector, crimp etc. ...

Here can you find some more details:
https://web.archive.org/web/20220524101136/https://smoothieware.org/temperaturecontrol#safety

[otede]

You can deactivate the runaway protection by setting the timeout to 0. It is a bit risky, but for testing ok as long as you are near by your printer in case something goes really wrong. Better you find out why smoothie is thinking there is a thermal runaway fault. Check if in Pronterface the temperature is not reported or if there are huge temperature jumps etc. Maybe you have a faulty wire, connector, crimp etc. ...

Here can you find some more details: https://web.archive.org/web/20220524101136/https://smoothieware.org/temperaturecontrol#safety

I read the wiki and tried the 0 value already. This is what pisses me off to be frank. The entire module should be disablable for the exact reason of 0% of probability it will never need troubleshooting. It's sad that after all this work (yours and mine) I'm going to have to get back to the old firmware. On the other hand, I consider it a lesson. I also get why you asked whether I have the same type thermistors on hotend and heatbed. I accidentally changed the name of the hotend thermistor. The mistake only affected commented-out lines, so had no effect.

No, Pronterface readings are smooth and the printer immediately goes zombie in cases where there's a disconnection of a cable. I know from experience.

[otede]

Wait. The error says Thermal runaway on B. Isn't it the heatbed?!

[DivingDuck]

Hm,
did you get a error message in the console window?
Maybe an additional point, You did change the thermistor, correct? Are you sure you have set the correct type? It is maybe worth to make a pid tuning

[DivingDuck]

Ha, cross posting. B is the bed thermistor then

[otede]

Ha, cross posting. B is the bed thermistor then

WTH?! There are no bed related thermal runaway settings in the config!

Yes, I'm pretty sure. I used the 4120 Beta value for exactly the part number
https://www.alldatasheet.com/datasheet-pdf/pdf/505051/EPCOS/B57620-C104-J162.html

Most importantly, it worked before the firmware upgrade :)

[otede]

I think I might have a clue here. I always set my Bed temp in Cura to be 60 for the first 2 layers and immediately drop to 30 right after that, and that silly Smoothieware identifies it as alarming. The screenshot below shows the state seconds before false runaway halt.

[DivingDuck]

WTH?! There are no bed related thermal runaway settings in the config!

It is by default on for all kind of heaters.
You can add similar settings for the bed thermistor as this are all universal modules.

temperature_control.hotemperature_control.hotend.runaway_heating_timeout      2040  # def 90 How long it can take to heat up, max is 2040 seconds.
temperature_control.hotend.runaway_cooling_timeout        60  # def 0 How long it can take to cool down if temp is set lower, max is 2040 seconds
temperature_control.hotend.runaway_range                60   # def 20 How far from the set temperature it can wander, max setting is 63°C
tend.runaway_heating_timeout      2040  # def 90 How long it can take to heat up, max is 2040 seconds.
temperature_control.hotend.runaway_cooling_timeout        60  # def 0 How long it can take to cool down if temp is set lower, max is 2040 seconds
temperature_control.hotend.runaway_range                60   # def 20 How far from the set temperature it can wander, max setting is 63°C

Instead of "hotend" use "bed"

[otede]

We did it man! We fooken did it! I edidet the xyz cube G-Code and changed the second bed temp from M140 S30 to S55, then to S40 somewhere around line 1000. Yesss! L:D Thank you!

I'll check the runaway section cloned for bed temp later.

Now my problem is the same as pre-FW update. Changing E steps per mm has no effect (changed in MKS config). In fact, after comparing the 25 mm XYZ cubes of various E steps per mm, pre and post FW update, they are identical down to a ripple, down to a smidge. The printer is ready in general but in some detailed prints that slight underextrusion bites back. There are also small holes in infill and supports sometimes.

Take a look
https://1drv.ms/f/s!AvyUQyNGJs9mk8R8aRXt1evR4LZvIw?e=CzLJ9d
I used 0.4 nozzle for all of those.

Here are some photos with my 0.6 nozzle (please disregard the already fixed first layers problem)
https://www.reddit.com/r/FixMyPrint/comments/17y2rfc/first_and_top_layers_on_some_prints_others_perfect/

[DivingDuck]

Congratulation!

Well,
changing E-steps because of ripple is maybe not the correct way to go. You will define E-Steps in general for your major filament. The differences between different materials / -blends and colors will be adjusted usually with flow rate settings for a specific mateial. The E-Steps usually will only be calibrated once (exept if you are using materials like TPU in case you have huge differences by feeding those materials and you can not fix that with a flow rate adustment.
Small holes in infill: You are slicing with Cura if I remember correct. There are some discussions at Ultimaker forum regarding this for the actual releases 5.6 and 5.5. I would suggest to check in addition with an different slicer like PrusaSlicer, Superslicer etc.

Ripple can be introduce with temperature changes of the print bed. This is why I suggest not to change the bed temperature in general especially for those printers with thin beds. An other source for ripple is too fast printing for infill and only one outer wall. Wet filament can also introduce those effects. And so on.
I would suggest in addition to run PID tuning for heater and bed. Then add the values to your config file.

Regarding your cubes. There is a little bit ghosting. Try to play with acceleration and junction deviation settings. Top layer seems to have a little bit too much filament. There is a setting in Cura for reducing the flow in the material section (since Cura 5.6).
Over all your cubes are not bad. :)

[otede]

Can you recommend an article on PID tuning?

By ripples I meant the natural ripples (very slight variations in layering), present in even far more expensive printers. With the E steps, lack of response to changes is what worries me. Any hints? I mean going from the default 180 up to 196 should be well visible. I used the 200 mm extrusion feed method to obtain ~195, then I increased to 196. Tomorrow I'm going to slap it with 220 or something like that.

I'll try an extreme value tomorrow, along with making sure it's not Cura's fault to some degree (I'll post on the forums).

Ghosting on Y axis that's pretty much the only flaw there, isn't it? Acceleration and junction deviation settings is sometyhing I've never dived into. I'll put it on my to-do.

For info: The bed on my printer is rather thick.

EDIT:
Tomorrow, re ghosting:
[ ] increase Y belt tension

[DivingDuck]

PID:
Easy to do. I have custom buttons in Pronterface for this :)
Information and instructions pls. see: https://web.archive.org/web/20230608053408/http://smoothieware.org/temperaturecontrol
Example for PETG:
Extruder (240°C): M303 E0 S240
Bed 81°C (in case you have only one extruder): M303 E1 S81

E-step callibration: https://reprap.org/wiki/Calibration#Extrusion is a good source. Or: https://www.youtube.com/watch?v=0ImurmbV5pE

Edit:
I had forgotten to give you an example for the config file entries for PID:

# PID configuration 
# See http://smoothieware.org/temperaturecontrol#pid
temperature_control.hotend.p_factor         29.4              # P ( proportional ) factor
temperature_control.hotend.i_factor         1.808             # I ( integral ) factor
temperature_control.hotend.d_factor         119                # D ( derivative ) factor

# PID configuration 1. bed
# See http://smoothieware.org/temperaturecontrol#pid
temperature_control.bed0.p_factor          199.8               # P ( proportional ) factor
temperature_control.bed0.i_factor          7.945              # I ( integral ) factor
temperature_control.bed0.d_factor          1256                 # D ( derivative ) factor

# PID configuration 2. bed
# See http://smoothieware.org/temperaturecontrol#pid
temperature_control.bed1.p_factor         142.9               # P ( proportional ) factor
temperature_control.bed1.i_factor         17.323              # I ( integral ) factor
temperature_control.bed1.d_factor         295                 # D ( derivative ) factor

I have more than one bed, so my numerator is bed1, bed2 ...
You have one bed --> numerator is bed (same as your temperature_control definition named it).

[otede]

@DivingDuck Thanks for the PID examples. I'll get to it.

In the meantime I confirmed changing E steps per mm has no effect, even with extreme values like 240 instead of 180.

[otede]

@DivingDuck I don't know how much more of babysitting do I get but posting my process anyway. FYI, I've got only one hotend, one bed, and one Z screw :D
PID autotune runs / last is value used for config:
hotend
Kp: 43.1 / 44.0 / 43.0
Ki: 3.001 / 3.080 / 3.040
Kd: 155 / 157 / 156
bed
Kp: 252.4 / 256.4 / 252.5 / 245.0(from30deg) / 248.0
Ki: 34.103 / 32.500 / 34.193 / 32.369 / 31.308(from30deg) / 32.500
Kd: 467 / 481 / 492 / 479(from30deg) / 472

The hotend runs were pretty consistend. Not so much for the bed. Much bigger mass, maybe that's why. Anyway, I'm going with those values for now.

I don't know how to decypher the return from M503 to compare to the original values:

M203 E50.0000 P57988
;PID settings, i_max, max_pwm:
M301 S0 P10.0000 I0.3000 D200.0000 X255.0000 Y255
;Max temperature setting:
M143 S0 P300.0000
;PID settings, i_max, max_pwm:
M301 S1 P10.0000 I0.3000 D200.0000 X255.0000 Y255
;Max temperature setting:
M143 S1 P300.0000

EDIT:
OK, comparing the new M503 return I can see what goes where:

M203 E50.0000 P57988
;PID settings, i_max, max_pwm:
M301 S0 P43.0000 I3.0400 D156.0000 X255.0000 Y255
;Max temperature setting:
M143 S0 P300.0000
;PID settings, i_max, max_pwm:
M301 S1 P248.0000 I32.5000 D472.0000 X255.0000 Y255
;Max temperature setting:
M143 S1 P300.0000

[otede]

ERROR: Temperature took too long to be reached on B, HALT asserted, TURN POWER OFF IMMEDIATELY - reset or M999 required

again, this time with 3DBenchy, even with

temperature_control.hotend.runaway_heating_timeout      0  # def 90, 0 is disabled | How long it can take to heat up, max is 2040 seconds.
temperature_control.hotend.runaway_cooling_timeout        2040  # def 0, 0 is disabled |  How long it can take to cool down if temp is set lower, max is 2040 seconds
temperature_control.hotend.runaway_range                63   # def 20, 0 is disabled |  How far from the set temperature it can wander, max setting is 63°C

temperature_control.bed.runaway_heating_timeout      0  # def 90, 0 is disabled | How long it can take to heat up, max is 2040 seconds.
temperature_control.bed.runaway_cooling_timeout        2040  # def 0, 0 is disabled |  How long it can take to cool down if temp is set lower, max is 2040 seconds
temperature_control.bed.runaway_range                63

One detail tells me this firmware is a no keeper. The bed temp dropped (as commanded) after the frist layers. At Z around 5mm it was already at stabilized 30 deg C. The error occured at Z around 22.5mm.

EDIT:
Notably (?) it happended with 3DBenchy printed with commented out tuned PID configs. The 3DBenchy with tuned PIDs did not got interrupted.

[DivingDuck]

A remark on temperature_control.bed.runaway_range 63:
when you lower the bed temperature to below 63 °C during a print you need to adjust this value because if not, the condition is true for a runaway in case temp goes below 63 °C.

PID tuning have nothing to do with runaway conditions ;)

[otede]

A remark on temperature_control.bed.runaway_range 63: when you lower the bed temperature to below 63 °C during a print you need to adjust this value because if not, the condition is true for a runaway in case temp goes below 63 °C.

PID tuning have nothing to do with runaway conditions ;)

I get that PID/noPID might have been a coincidence.

As for the 63: How can it be when the default value is 20? Even the comment says it's allowable delta, not a threshold.

[DivingDuck]

because of:
temperature_control.bed.runaway_range 63
This entry mean you do set the it to 63°C and this means there isn't a default value any longer.

Edit: You may be correct.

Please set the bed control values back to the default values (deactivate with #) and then make a new print with Pronterface. Observe the terminal window and check if there is a error message when the print stops again. In addition you can take a look in the log file of Pronterface Printrun.log. It should be located in your user root folder c:\users\Your_Username.

In addition it is maybe worth checking the gcode file as well.

I still wonder why you have those problems. I'm running the actual Smoothieware firmware w/o any problem. I guess there is something wrong with your configuration or hardware and we need to find out what the problem is.

[otede]

because of: temperature_control.bed.runaway_range 63 This entry mean you do set the it to 63°C and this means there isn't a default value any longer.

I think we got tangled in the conversation :) I don't claim it's the default. I claim that:

1. It's an allowable discrepancy, not a threshold => the bigger the better in my case
2. The default per git config was 20.
3. Additionally, all the config lines pertaining to runaway are commented out by default.

I'll stop disabling bed heating after first layers from now on. I don't know what else I could do apart from this and leaving the value at 63.

[DivingDuck]

Sorry, I was editing my comment above while you was answering.
As I mentioned, print via Pronterface. Smoothieware usually print errors via console. Maybe this can help to identify the problem.

[otede]

Sorry, I was editing my comment above while you was answering. As I mentioned, print via Pronterface. Smoothieware usually print errors via console. Maybe this can help to identify the problem.

There's not much to expect from future occurrences. It's always like this
ERROR: Temperature runaway on B (delta temp 27.468994), HALT asserted

[DivingDuck]

What happen if you set temperature_control.bed.runaway_cooling_timeout 0 ?

You can measure, how long it take to cool down the bed from/to what ever temperature you want to set it and then take the values that matches with your bed under real conditions. A bit of trial and error :)

[otede]

What happen if you set temperature_control.bed.runaway_cooling_timeout 0 ?

I have it like that from the start (when I added the bed section), uncommented:
temperature_control.bed.runaway_heating_timeout 0

[otede]

-- deleted--
I re-read your recent posts and had a facepalm. Will return after a proper check not to waste your time!

[DivingDuck]

@otede,
hope, you solve the problems with your printer. Can we close the issue?

[otede]

@otede, hope, you solve the problems with your printer. Can we close the issue?

Pronterface still keeps shooting at me with this and siomilar errors but it works, so you tell me ;) I thank you again for your assistance before. All the best in New Year!