I export gcode from MakerBot Desktop. It has a Tool 0 temp (210), Temp 1 temp (not set), and the bed Temp (50). When I run the print from OctoPrint, it Preheats the Tool and Bed to the same temp (50). Once Tool 0 hits 50, then it starts working towards 210 (like it should). This is really a problem when I go to load filament before a print. I preheat the Tool to the right temp (210), then I load the filament. Now when I go to print, it has to cool down from 210 to 50, once it cools down to 50, it jumps back up to 210. Sometimes if I don't preheat the bed to 50 through the Control tab, sometimes the gcode doesn't preheat the bed at all, which causes my prints not to stick.
OctoPrint 1.3.7rc1 running on OctoPi 0.13.0
FlashForge Creator Pro / PowerSpec 3D Pro
Did you have this same problem with a previous version of octoprint, or really, has this always been a problem?
Does it do this with Makerbot desktop when you directly control the printer (I do not know it if can, just assuming it can, as I never used it).
Have you tried with another control program such as pronterface?
It almost sounds like a start gcode issue. I do believe there are two temperature commands, one waits for it to get to that temp while the other I think will let the printer move while heating up. That should be M109 to wait and M104 to set and proceed. I am wondering if you are using M109 and it waits to drop and stabilize the temps before going to the next temp.
I would see if you can either set the first to M104 then the second to M109, or see if you can set the bed and end temps independent, so that the hotend doesn't need to hit 50 first.
I just updated to 1.3.7 to see if it fixed it, which is did not. So it has been happening for a while now.
No, straight from MakerBot Desktop it preheats the bed first then starts the nozzles (but it doesn't put the nozzle at the bed temp).
I just opened up the gcode:
M109 S50 T0
M134 T0
M135 T0
M104 S210 T0
M133 T0
According to SoftSolder.com, it looks like the "M109 S50 T0" is either:
M109 MF Wait for extruder current temp to reach target temp.
M109 RR Set Extruder Temperature and Wait
M109 RR Snnn set build platform temperature in degrees Celsuis
So it looks like the M109 S50 T0 is both to set the build platform as well as the extruder to 50, then the M104 S210 T0 sets the extruder to 210.
I wonder if I reorder the code like so if it'll heat the nozzle first then the bed:
Either way, the code change didn't work. It put the extruder up at 210 then wanted to bring it down to 50. It seems the problem is the m109 does both the bed and the extruder. I wish I could specify (like T0 and T1) to do only the bed (maybe something like B1). Some places said the T# isn't necessary for the bed, so I tried it just M109 S50 but that didn't work either.
What firmware is this running?
It looks like the bed can be controlled with M140 as well.
so Perhaps removing the M104, and setting M109 S210 T0 and M140 S50
I am just taking a wild stab in the dark right now.
The gcode flavor for the startup script shared is definitely MakerBot, but it doesn't look like your FlashForge understands that dialect or GPX isn't translating it or something along those lines. (I don't know anything about GPX.)
Here's how a MakerBot interprets the gcode:
M109 S50 T0 ; Set the target temperature of the first build platform to 50C
M134 T0 ; Wait for the first build platform to reach its already-assigned target temperature
M135 T0 ; Select the first tool
M104 S210 T0 ; Set the target temperature for the first tool (hot end / extruder) to 210C
M133 T0 ; Wait for the first toolhead to reach its target temperature
Here's how pretty much anything else other than a MakerBot would interpret it:
M109 S50 T0 ; Set the target temperature of the first extruder to 50C and wait for it to reach temperature
M134 T0 ; Not supported by many firmwares. Teacup uses M135 to write PID values to EEPROM
M135 T0 ; Not supported by many firmwares. RepRap uses M134 to set PID sample interval
M104 S210 T0 ; Set the target temperature for the first extruder to 210C and wait for it to reach temperature
M133 T0 ; Not supported by many firmwares. Teacup uses M133 to set PID I limit value
In the scenario described, it sounds like you're getting the latter interpretation. You set the temp to 210 manually, then it waits for it to get down to 50 before bringing it back up to 210. I bet your "sometimes" when you don't preheat the bed is actually "all the time" because there's nothing in the gcode provided that tells anything that isn't a MakerBot to heat up the bed.
If you want to heat the bed and the tool at the same time, try this:
M140 S50 ; Set the bed temperature to 50C and continue
M109 S210 ; Set the extruder temperature to 210C and wait for it to reach temperature
M190 S50 ; Set the bed temperature to 50C and wait for it to reach temperature
If you want to heat up the bed first, then the extruder, try this:
M190 S50 ; Set the bed temperature to 50C and wait for it to reach temperature
M109 S210 ; Set the extruder temperature to 210C and wait for it to reach temperature
The GPX plugin has a setting in the settings panel for the gcode flavor. It attempts to use the gcode flavor only when printing, but it means that there's a conflict between the control panel behavior (always RepRap flavor) and the print file (MakerBot flavor).
So if you're using files from MakerBot Desktop, you have to set the setting to "MakerBot", but never use the temperature buttons during a print. Until at some point when I'll take advantage of the new gcode label feature.
I am using Cura for slicing and had this same problem with MakerBot replicator 2x.
What helped me was changing Start G-Code, section for plafrom preheat from M109 to M140.
If you need the machine to wait for heat of platform (as M140 desn't wait), you can try M70 (M70 P{time} Message).
I guess you mean 1.3.7rc2? 