Open cmdrdeliver opened 3 years ago
Hi @cmdrdeliver,
Thanks for reporting these issues!
If I recall correctly, these 2 behaviours were reported previously and were due to the printer's somewhat unreliable interface. The plugin solves this by a sending redundant commands to the printer to set temperatures and start print, so that the experience is consistent.
Let me test this in Cura 4.10 to see if I can reproduce.
I was blaming Cura, but yeah, this has happened to me as well a couple of times in the last week or so (kind of since I started printing via Wifi) . Basically the fully heated hotend runs off to print before the bed is a temperature. Last time it was at 30 degrees instead of the requested 65. During the incident before that, the printer seems to actually have noticed that not everything was hot enough and froze after starting the first brim's line.
I am using 4.11.0 as well. Usually printing regular old PLA.
I tried to reproduce this issue but I could not. I may release a new version with more detailed logs so that we can determine whether the issue is caused by the printer or the plugin.
@cptSwing do you see any patterns when this occurs? Do you usually transfer large models (more than a minute)? Do you set temperatures before transferring models?
Something related I did notice is that the V2 printer seems to have a "target temperature timeout" while transferring models. For example, if the bed is preheated at 65ºC and a large model is transferred for a few minutes, the printer will unset the target bed temperature. The plugin overcomes this by always setting target temperature at the end of transfer.
Yeah, it's hard for me to reproduce as well - and hasn't happened to me since the above post, with either large (long transfer) or small (short transfer) files. It's very well possible that I preheated manually on those prints that it happened, so I'll be looking out for behaviour when I preheat next time (usually to remove blobs / excess filament from the nozzle before printing starts). Will update you here when it occurs again.
Thank you for the swift reply and thanks a ton for this plugin. It's nearly fully replaced my SD card switch-a-roo!
@loociano , I appreciate you looking into this. I'm using a V2 so that may be the issue. I know the firmware is "special" in lot of ways. Reproducing it is pretty straight forward. Start a print. About 5% of prints start immediately after either temperature reaches goal. If my hot end or bed is pre-heated, the print is much more likely to start. I didn't notice a relationship between file size and premature starts. I'm running Debian 11 Linux.
All that said, I recently switched to OctoPrint and haven't had any issues. All my prints are done with OctoPrint now. If you need to test, need logs, etc, I'm happy to help. I've got plenty of tiny items I can print for testing purposes.
I tried to reproduce this issue but I could not. I may release a new version with more detailed logs so that we can determine whether the issue is caused by the printer or the plugin.
@cptSwing do you see any patterns when this occurs? Do you usually transfer large models (more than a minute)? Do you set temperatures before transferring models?
Something related I did notice is that the V2 printer seems to have a "target temperature timeout" while transferring models. For example, if the bed is preheated at 65ºC and a large model is transferred for a few minutes, the printer will unset the target bed temperature. The plugin overcomes this by always setting target temperature at the end of transfer.
It happened recently again, stopping right after the nozzle prime and then reheating (the bed, I think) back to temp. Not very helpful I'm afraid since it was both a fairly large file transfer and I'm pretty sure I preheated the nozzle to get rid of filament. Will keep an eye on things.
Ok, me again, with more conclusive results. I started a print via Wifi today - very small transfer so transfer size can likely be ruled out - and I had printed something else just before, with the hotend and bed still being a little warmer than regular. Once the hotend was back up to desired printing temperature, the print started, low heatbed-temperature be damned! After about 2 brim lines it realized the errors of its ways and froze, gradually depositing a nice fat ooze-ball of filament where it stopped. Once the bed was up to actual desired temp, the print restarted (I was able to scrape off the failed stuff with the quickness and see things succeed, haha).
I'm also having the same issue that @cptSwing is having, when sent to the printer via Cura it seems to try to start printing before the hotend has heated up, and then freezes partway through the first skirt layer. It does automatically restart the print (maybe after it's reached temperature) but by then there's stuff on the printbed I have to clear off. (I can't say anything about printbed temps, because I haven't gotten around to fixing my printbed's cabling)
Hello There. I have exact the same issue. Print starts after nozzle temp reached, event bed temperature is still warming up. I own a Monoprice Select Mini Pro
I was able to reproduce this.
A few minutes after finishing printing one model, I transferred another file from Cura. Once the hotend temperature reached its target temperature, the print started, however the bed temperature did not reach its target.
I'm guessing that this issue is more likely to happen on second and following prints.
Need to try to reproduce without the Wi-Fi plugin, using only the SD card in order to find out whether the plugin or the printer causes the behaviour.
Take a look at your End-GCode if you have there some Timers which disable the Heating after x seconds, that could interference with starting an new print.
@Novae7 that's an excellent point. I use the defaults:
G0 X0 Y120;(Stick out the part)
M190 S0;(Turn off heat bed, don't wait.)
G92 E10;(Set extruder to 10)
G1 E7 F200;(retract 3mm)
M104 S0;(Turn off nozzle, don't wait)
G4 S300;(Delay 5 minutes)
M107;(Turn off part fan)
M84;(Turn off stepper motors.)
Is it possible that I did not experienced this issue because I wasn't usually reprinting within 5 minutes?
I believe I had this issue when I was retrying a print after a failed first layer, which would have happened within 5 minutes.
Cura 4.10, MPSM2 plugin installed from Cura Marketplace 5 days ago.
Two issues, possibly related.
In both cases, if I print the cache file from SD, it prints perfectly.
MPSM V2 versions 40.156.2
I've tried clearing the eeprom settings, reinstall Cura and MPSM2 plugin, disabling UM3 network printing. The files are well formed. Feels like an interaction between the monitors and the remote printing process, but I lack hard data to prove any connection.