Jump to content

Heat bed more slowly at print start


Go to solution Solved by Slashee_the_Cow,

Recommended Posts

Posted · Heat bed more slowly at print start

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

 

  • Link to post
    Share on other sites

    Posted · Heat bed more slowly at print start

    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…

  • Link to post
    Share on other sites

    • Solution
    Posted · Heat bed more slowly at print start

    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.

    • Like 1
    Link to post
    Share on other sites

    Posted · Heat bed more slowly at print start

    @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.

  • Link to post
    Share on other sites

    Posted · Heat bed more slowly at print start

    @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. 

  • Link to post
    Share on other sites

    Posted · Heat bed more slowly at print start

    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. 

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Our picks

      • UltiMaker Cura 5.8 Stable released 🎉
        In the Cura 5.8 stable release, everyone can now tune their Z seams to look better than ever. Method series users get access to new material profiles, and the base Method model now has a printer profile, meaning the whole Method series is now supported in Cura!
        • 5 replies
      • Introducing the UltiMaker Factor 4
        We are happy to announce the next evolution in the UltiMaker 3D printer lineup: the UltiMaker Factor 4 industrial-grade 3D printer, designed to take manufacturing to new levels of efficiency and reliability. Factor 4 is an end-to-end 3D printing solution for light industrial applications
          • Thanks
          • Like
        • 3 replies
    ×
    ×
    • Create New...