Heat bed more slowly at print start

[chriska416 0]

I have my printer (Artillery Sidewinder S1) and Rasp Pi connected to a UPS (backup battery) because I experience a lot of brown-outs and fluctuations. If there is an actual black-out, then the generator will turn on within a minute. While running, the UPS says it can sustain the equipment for about 9 minutes. 

 

The problem I am having is when the bed first starts to heat up, it overloads the UPS and after about 30 secs, the UPS shuts off. I have been manually increasing the temperature of the bed buy a degree or 2 and that works fine, but somewhat tedious. (When the printer is running, it's only using about 35% of the UPS capacity, so I don't want to buy a bigger UPS.)

 

I have just added this code to the "Start G-Code" of my profile, and it seems to be working, but I wondered if there was a cleaner/better way to do it.

 

M190 S15
M190 S17
M190 S19
M190 S21
M190 S23
M190 S25
M190 S27
M190 S29
M190 S31
M190 S33
M190 S35
M190 S37
M190 S39
M190 S41
M190 S43
M190 S45
M190 S47
M190 S49
M190 S51
M190 S53
M190 S55
M190 S57
M190 S59
M190 S61
M190 S63
M190 S65
M190 S67
M190 S69
M190 S71
M190 S73
M190 S{material_bed_temperature};
M104 S{material_print_temperature} T0
M105
M109 S{material_print_temperature} T0

 

[jaysenodell 18]

Look into using octoprint to intercept the bed heat ups and replace with the right macro. There’s a section in the octo configuration screen for just this purpose. 
 

a couple hints. 
* read up on storing a variable for the temp so you can put in logic to differentiate between raising and lowering temps.

* simpler is better for the above… I’d lower just drop it. 
* alternatively play with fire and create a hardware solution that switches between ups sourced power and direct line power for bed heating. 
 

I like fires. You should probably not do that…

[Slashee_the_Cow 438]

In theory that gcode shouldn't heat the bed any slower than just setting the target temperature initially - what it's basically saying is "wait for bed to reach 15°, wait for bed to reach 17°, wait for bed to reach 19°, etc." but it's not pausing when it waits (the difference may be if your printer uses a power curve to warm up the bed instead of just doing it linearly). Using hard-coded numbers like that in your startup gcode isn't a good idea in case you want to print at a different temperature, like the way you have it set up, if you only want the bed to be 60°, it'll warm up to 75° and immediately start printing before it cools - you need to use the R parameter instead of the S parameter if you want to wait for it to cool or heat (S only waits to heat, so since it's already above the target temperature it'll keep going immediately).

 

Unfortunately there isn't any gcode to control the rate at which the bed heats up. And while @jaysenodell means well and yes what they're suggesting can be done, OctoPrint is their solution to everything, and in many cases it's akin to using a sledgehammer to get a nail into wood (n.b. please don't try that).

 

I would try using startup gcode like this:

M190 S{material_bed_temperature_layer_0 * 0.1} ; Wait for bed to get to 10% of target
G4 S3 ; Wait 3 seconds
M190 S{material_bed_temperature_layer_0 * 0.2} ; Wait for bed to get to 20% of target
G4 S3 ; Wait 3 seconds
M190 S{material_bed_temperature_layer_0 * 0.3} ; Wait for bed to get to 30% of target
G4 S3 ; Wait 3 seconds
M190 S{material_bed_temperature_layer_0 * 0.4} ; Wait for bed to get to 40% of target
G4 S3 ; Wait 3 seconds
M190 S{material_bed_temperature_layer_0 * 0.5} ; Wait for bed to get to 50% of target
G4 S3 ; Wait 3 seconds
M190 S{material_bed_temperature_layer_0 * 0.6} ; Wait for bed to get to 60% of target
G4 S3 ; Wait 3 seconds
M190 S{material_bed_temperature_layer_0 * 0.7} ; Wait for bed to get to 70% of target
G4 S3 ; Wait 3 seconds
M190 S{material_bed_temperature_layer_0 * 0.8} ; Wait for bed to get to 80% of target
G4 S3 ; Wait 3 seconds
M190 S{material_bed_temperature_layer_0 * 0.9} ; Wait for bed to get to 90% of target
G4 S3 ; Wait 3 seconds
M190 S{material_bed_temperature_layer_0} ; Wait for bed to get to target

Okay that's still a lot of lines. But I get the feeling you're smart enough to figure out how to add/remove steps, change the target percentages or the wait times if you want it a bit more controlled than that. And yeah, those waits will add nearly 30 seconds to the process. But that's better the blowing the UPS in 30 seconds.

[chriska416 0]

@Slashee_the_Cow - yeah, the printer does seem to have a curve. if it's only set to heat about 1.5 deg, then I think it uses a lower power level, maybe more of a maintain, than heat to temp. 

 

so what I'm currently using is working, and since I only really print PLA, it works (i know 75 seems high for PLA, but I have the Fula-Flex mat from Fulament, and when i had it at normal temps, the prints kept coming loose. in fulament's documentation, it specifically says 75 deg. and ever since making that change, i haven't had issues)

 

i did try to use the variable with some subtraction math, but not multiplication. but i think my biggest problem may have been curly brackets instead of parenthesis. thanks for the code sample, i'll mess with it some more, now that i have a direction.

[jaysenodell 18]

@Slashee_the_Cow, the reason I recommended octo is that @chriska416 mentioned the pi in the original post. I assumed (dangerous) octo was involved but it is not mentioned explicitly. 
 

my concern with using startup is that it’s not a printer specific embed that might be lost due to an upgrade or system clean. Same is true on pi/octo but most folks are a bit better about backing up pi/octo. Also, you can also in any gcode that is known to work from any date/config without needing to reslice. 
 

so yes, sledgehammer, but a very useful one. Less of a sledgehammer if octo is already in the pipeline. 

[PCLoadPLA 0]

You could simply reduce the P and or I value of your bed's PID settings. It would take some testing but try cutting the values maybe 25% at time and see if you can keep the UPS from tripping.