Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creality 3D printers shouldn't sit with their extruders at 140 deg C when idle #1257

Open
amcewen opened this issue Sep 23, 2019 · 63 comments

Comments

@amcewen
Copy link
Member

commented Sep 23, 2019

When I was moving the power connection to @MatthewCroughan and @ajlennon's 3D printers I noticed that two of the three of them had the extruder sat at ~140 deg C. Neither of them have been printing for hours now, so I don't see why they'd still need the extruder to be hot.

Given that they seem to be on all the time at present, it would be good if we weren't running a couple of small heaters 24x7... (now I've power-cycled them, the extruders have cooled down to room temp, so presumably it's a bug in how they finish a print?)

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

We were printing on the three printers during the day today. I've printed a lot on the CR10-S with Marlin 1.9 and a little on my Ender3 with Matt's customised Martin 1.9 firmware.

Thus far every time they've dropped back to room temperature after a print.

I think the difference is that today I operated each locally to enter the "Preheat PLA" mode to enable me to remove the filament which I did.

I thought that when in "Preheat PLA" after a short while it timed out and stopped heating, and you get a "press button to heat" message.

Thus I left the printers in that state.

It may be that they only drop back as far as 140C in which case my apologies, my bad.

Next time I'm in I'll check this.

I am almost certain that it's not a general problem with the firmware, although there are a few other bugs around and about that we could clean up....

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

Hmmm - another comment is that at some point today the Orange Pi's controlling the printers tripped out which seems to be linked to electrical noise and seems to be triggered when people put on the Laser Cutter or the CNC machine.

I don't think this caused the 140C issue but it might have somehow...

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

Octoprint should be monitoring the temperature and automatically turning it off if it is high for an unexpected period of time, as a watchdog. The problem is that this can't take place because of the serial being interrupted by serial connections tripping.

I think this is a protocol error, in that if a print is running and it fails on the octoprint end, I believe the Marlin firmware thinks it is still printing, which means that the firmware sees no reason to stop heating the extruder. This doesn't trigger thermal runaway protection, because this is not a thermal runaway event, it is a different event that isn't accounted for.

In order to prevent this I really want to set up a system with the Espurna POW2s in which the Octoprint Pi is powered separately from the printer and still has a serial connection with it. When a print is sent, the POW2 should then turn on the printer and begin printing. If there is any sort of error, the POW2 should be off, and this can be implemented with Octoprint's simple api and mqtt support that allows you to read the status of a print or serial connection.

Alternatively, there may be some obscure settings in the Marlin firmware to detect this event that doesn't fall into thermal runaway.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

I believe the Marlin firmware thinks it is still printing, which means that the firmware sees no reason to stop heating the extruder.

This shouldn't cause it to sit at 140C

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

@ajlennon Yeah, it should be at the full temperature of 210. We need to monitor the crashes that happen, we can trigger them by turning on the Laser cutter, so at least it's repeatable. The Ender's screen should tell us if the firmware thinks it is still printing. And the Octoprint terminal shows us the last submitted command.

Either way, I really dislike the fact that printers sit idle, that wears out the fan anyway. The problem would be solved by implementing something with the POW2s that cuts power to the printers when they aren't printing anything, they don't need to be on at all when a print isn't being executed.

It's also worth noting that this wouldn't be a problem at all if we could rely on the Pi's not getting killed by electrical noise, as proven by your CR10s running a Pi3 that isn't quite as fussed about the electrical noise at DoES.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

It may be that they only drop back as far as 140C in which case my apologies, my bad.

This is trivial to test. Let's do the easy things before we do the hard things.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

/**
 * Thermal Protection provides additional protection to your printer from damage
 * and fire. Marlin always includes safe min and max temperature ranges which
 * protect against a broken or disconnected thermistor wire.
 *
 * The issue: If a thermistor falls out, it will report the much lower
 * temperature of the air in the room, and the the firmware will keep
 * the heater on.
 *
 * The solution: Once the temperature reaches the target, start observing.
 * If the temperature stays too far below the target (hysteresis) for too
 * long (period), the firmware will halt the machine as a safety precaution.
 *
 * If you get false positives for "Thermal Runaway", increase
 * THERMAL_PROTECTION_HYSTERESIS and/or THERMAL_PROTECTION_PERIOD
 */
#if ENABLED(THERMAL_PROTECTION_HOTENDS)
  #define THERMAL_PROTECTION_PERIOD 40        // Seconds
  #define THERMAL_PROTECTION_HYSTERESIS 4     // Degrees Celsius

  /**
   * Whenever an M104, M109, or M303 increases the target temperature, the
   * firmware will wait for the WATCH_TEMP_PERIOD to expire. If the temperature
   * hasn't increased by WATCH_TEMP_INCREASE degrees, the machine is halted and
   * requires a hard reset. This test restarts with any M104/M109/M303, but only
   * if the current temperature is far enough below the target for a reliable
   * test.

We need to determine what the printer thinks it's doing when the serial is cut from Octoprint. 140C isn't a constant in my firmware file anywhere, so we need to find out where 140C is derived from, but the thermal runaway code probably wouldn't have a problem with this, since thermal runaway is measuring temperature increase over time, I don't believe it cares about leaving the extruder on, it only cares about the rate at which it increases, or varies from. That's being defined as "hysteresis" here.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

so we need to find out where 140C is derived from

No. We need to understand what the use case was when the failure occurred. Which I did above.

Then we need to test the low hanging fruit to see if we can solve the problem easily.

If we can't solve the problem easily we look for the next most complicated solution and proceed that way.

Otherwise we end up chasing our tails and getting nowhere.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

@ajlennon 140C Is oddly specific though. If we can determine that this is a number in a configuration for "What to do if serial fails" and it happens to be a simple constant in the configuration, then we can just reduce that to 0 and be done with it. I don't really see what else we can do other than give the Pi's less noisy power.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

@ajlennon After re-reading everything, I think I understand. This doesn't happen on your CR10s because Octoprint always kicks it back down to 0. Whereas when you select "Preheat PLA" from the Marlin firmware, it never returns on its own, and Octoprint wouldn't have had a successful connection to those machines because of these electrical problems.

Even if it's not a bug in the firmware, there should be a way to make sure the printers aren't on unless they need to be, POW2s can make that happen. But more generally, the firmware really should have a timeout built in, it shouldn't be Octoprint's job to make that happen.

@amcewen

This comment has been minimized.

Copy link
Member Author

commented Sep 23, 2019

@MatthewCroughan please note the ~ in front of the "~140 deg C" in the original description. I only noticed after I'd power-cycled the printers, so it might have been a bit higher, but it was somewhere around that. @ajlennon's suggestion seems like a good starting point.

(and having the printers switched off when idle seems like a decent approach to me - can we just turn them off manually if they're not printing?)

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

@amcewen Well I logged in earlier to check that my printer was off via a vpn. So I'm handling mine, but this can be done without people having to remember anything, so I'm more in favour of that. I'll make a new issue about setting this up with the POW2s and Octoprint when I get it working on my Ender and refer back to this.

It should just be as simple as it is now, but the printer is always off unless it's printing. An mqtt message turns on the POW2 when the printer wants to start printing, the print begins, then when the print ends a message is sent to turn off the POW2.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

If it was "~185 deg C" on the Enders then it was likely just sitting there at the "Preheat PLA" hot end set-point.

ajlen@MSI MINGW64 ~/git/Marlin/Marlin/example_configurations/Creality/Ender-3 (1.1.x)
$ grep -r PREHEAT_1_TEMP_HOTEND *
Configuration.h:#define PREHEAT_1_TEMP_HOTEND 185
Configuration_adv.h: #define USER_GCODE_2 "M140 S" STRINGIFY(PREHEAT_1_TEMP_BED) "\nM104 S" STRINGIFY(PREHEAT_1_TEMP_HOTEND)

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

Whereas when you select "Preheat PLA" from the Marlin firmware, it never returns on its own

Indeed. If it doesn't, this would ideally time-out. More pertinently I'll have to make sure I turn the thing off after I take out the filament

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

(Would have been faster just to test it on site ;) )

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

@ajlennon Right, so we think it will stay at 185 unless told otherwise? Would this not also be true of the Ultimakers if they were left preheating? I recall that being rather difficult on them because of something in the firmware that timed out the manual control screen, although I'm not sure.

I have definitely done this on your CR10S before, and it has been safe because your Octoprint instance automatically returns its target to 0C after 10 minutes.

The solutions are:

  • VERY Stable Octoprint instances
  • Responsible turning on/off of printers on the part of users
  • POW2 auto on/off when printing
@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

It should just be as simple as it is now, but the printer is always off unless it's printing. An mqtt message turns on the POW2 when the printer wants to start printing, the print begins, then when the print ends a message is sent to turn off the POW2.

What would the POW2 power? Just the printer? So when the POW2 isn't powering the printer the OrangePi USB is powering the printer at some intermediate level? That seems like it might cause a problem?

Or does the POW2 power both the printer and the OrangePi? Not sure we want to be turning the OrangePi on and off willy-nilly?

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

Right, so we think it will stay at 185 unless told otherwise?

I am inferring this from my grepping through the code, but I am also trying to make the point that I've spent time grepping through the code and am still having to guess, when the absolutely definitive answer can be had by twiddling a knob.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

@ajlennon The POW2 would power just the printer. The Pi would be powered separately and orchestrate the events. The Atmega 1284P in the printer accepts power and serial from the Pi even when all the other circuitry is off, and doesn't attempt to power the steppers. It still accepts serial and you can send it print commands. The firmware is unaware of the fact that anything is off, but it will simply try and heat up the bed and nozzle until it is complete. Which won't happen unless the POW2 is on and powering the motors, bed, nozzle, etc.

So, using this, we can see if the state of octoprint is "PRINTING".

If printing, then check the state of the POW2 and turn ON if OFF.
If print done OR not-printing, then check the state of POW2 and turn OFF if ON

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

The Atmega 1284P in the printer accepts power and serial from the Pi even when all the other circuitry is off

Do we know if this a clever engineering feature or something that really shouldn't be happening?

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

To expand - powering things in ways the designer didn't anticipate them to be powered can often be a "bad thing"(tm)

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

Well it seems reasonable if you look at the board. It's just a chip with firmware on it that takes commands. These commands are then sent to stepper motor drivers, and those stepper motors, etc are powered separately. I don't think this is unintended or bad for business. If it's a problem then it's a problem with the ATMEGA accepting 5v from USB, it's just a controller that's sending stuff to another controller. The power is out of the picture in this context.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

I'm stretching but this has worried me for a while and does make me wonder if it's related to why the last CR10-S broke

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

Well I'm willing to test it on mine for quite some time. I've seen no evidence or weirdness to suggest that the board itself is trying to power the stepper motors, or draw current from the Pi, into the 1284P to power other parts of the machine that cannot possibly be powered like that.

The Pi can power the display, the auto bed leveller, but that's about all it actually does. If we take a look at the board maybe we can determine if it actually is managing to power other parts that it isn't capable of.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

The Pi can power the display, the auto bed leveller, but that's about all it actually does. If we take a look at the board maybe we can determine if it actually is managing to power other parts that it isn't capable of.

I'd much prefer a simple solution to prevent the Pi powering the device :)

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

image

The 12v/24v DC input is separate and responsible for powering the motors, and anything that isn't the motor isn't going to be powered by the Pi as a result. And the only things here that are NOT the motors, are what I have mentioned. The auto bed leveler, the screen and that's it. Not even the fans are on the 5v line, they're powered by the separate PSU. I think it's completely fine.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

What you're asking for, I don't think is possible. You need to power it somehow, and if you're worried about the Pi powering the device, why wouldn't 5V from any other source be a problem? You can't get data out/in if you don't provide it with power.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

Well, yes, when powered by 12/24V, which means the machine is ON. What I'm wanting to do is not have the 12V, noisy, bed/nozzle heating component be on until the 5V part (1284P) confirms a print has been sent.

@ajlennon

This comment has been minimized.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

No idea. But we can power the specific chip without USB if you want. We can just use the GPIO of a Pi and speak directly to the serial line, and power the chip via 5v, cutting out USB. Even though I'm fairly certain that's all we're getting via the USB anyway.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

One. Ergo the MCU is powered by the main power supply, which is just common sense.

Next there is a USB to serial IC in there. It is possible this isn't powered by the main power supply but that would be crazy engineering and stupid unless there was a very good reason, which I can't think of.

Goes to look at the schematic again...

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

So it looks to me as though the FTDI232 is powered from the local regulated 5V source which is just good sense

image

The above being true there is no reason to need to power the device from the USB connector as it is all already powered

Now we have to be careful what we believe on the Interwebs but the link I have given you about the removal of the Vcc line on the USB or the (easier) use of the hub power control utility is something that they say works

So why not give the easy solution a try?

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

I don't understand what the solution is? What's the problem with powering it from a pi? That's convenient. Did you find a problem?

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

I am not a hardware engineer. But my many, many, many years of making hardware work with hardware engineers makes me strongly averse to the idea that devices should be powered in ways they were not designed to be powered. This is a device that has design deficiencies, we know. This device does not have a clever PMIC to make all this work and you wouldn't expect one on this kind of device. My experience tells me that the device should not be powered from the USB.

And everything is simpler if it is not powered from the USB

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

Again, I want the fans to not be spinning, the bed to not have the possibility of heating up, and the extruder to not be possible to heat up.

The power would then be applied by turning on the espurna, and then all the mechanical functionality of the printer will be turned on.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

I think that what you're suggesting is complicated, and that what I am suggesting is easy. So I'll try my theory out on my printer, and if it doesn't work you can point at me and laugh. Deal? :)

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

I just want a simple solution that works and isn't likely to damage my hardware.

Which I seem to have found.

Which (assuming it works) is what will be happening on my hardware.

You of course are free to pursue other solutions :)

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

You're entirely wrong. But come back to me when you figure it out :)

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

@ajlennon Just so I'm clear on what you're saying. Are you saying that you believe it's bad to power the 1284 via the USB 5v power from the Pi?

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

In case there's any confusion I want this -

The power would then be applied by turning on the espurna, and then all the mechanical functionality of the printer will be turned on.

So I can turn the device on and off without parasitic power being sucked out of the controlling Pi...

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

Just so I'm clear on what you're saying. Are you saying that you believe it's bad to power the 1284 via the USB 5v power from the Pi?

Yes.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

And it is not needed and it is easy to fix if my reading tonight is correct.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

@ajlennon Well you can already do what you want just with the Espurna. I already have this set up on my Pi with Octoprint and MQTT.

The difference in what I want now is that I want the 1284P to still recieve serial, even when the 12v mechanical parts of the printer are unpowered.

At this time, Octoprint is still connected over serial, and can still send files to be printed. You could then use Octoprint's API to submit an MQTT command when the printing process has begun to turn on the Espurna.

Your solution doesn't allow me to do that smart bit in the middle, since the 1284P will never be powered unless the 12V mechanical element of the printer is ON, which is exactly the part I want to be OFF when sitting idle. That's if I'm reading you correctly.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

The difference in what I want now is that I want the 1284P to still recieve serial, even when the 12v mechanical parts of the printer are unpowered.

Why? There's no point. The controlling Pi stays on. The Creality stays off until needed. The controlling Pi can turn on the Creality via MQtt->Sonoff and print.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

Also allowed by having the 5V part be on all the time and Octoprint being able to read and write serial, is to turn the printer off when the print is done. How would you do that in your suggestions?

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

See above.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

Right. The only difference between what I'm saying and what you're saying is that the Pi in my scenario would always be able to talk to the 1284P. Your suggestions leave it disconnected, until the Espurna turns on the printer. At which point you have to manually go into Octoprint and reconnect it to the printer.

Your solution is better, though we need to find a way of auto connecting Octoprint all the time. I've been continually annoyed that it can't just auto-connect on serial all the time. If we can do that, you're absolutely correct.

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

In fact I'm absolutely convinced it's better now, considering the parasitic power is probably contributing to the electrical noise on the Pi Zeros. I wonder if it'll go away entirely if we got some powerless cables..

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 23, 2019

@ajlennon Well, like I mentioned. I already have this set up on my Octoprint. There's a button that toggles the espurna power on the top. Now all we need is a way of the printer turning itself off at the end of prints.

This is where the difference between what I want and what you want shows though. The reason I wanted the 1284P to be on is so that I could simply click "Print", there's no need to turn the machine on manually, check whether the machine is on manually. This means the machine cannot be left on accidentally if all the user wants to do is print.

They would click print, as they usually would, then the print would turn on the espurna, print, then turn off. Rather than having to turn on the printer manually (making sure to turn it off if they don't end up using it).

I can't really think how this would be done without just having the 1284P on all the time recieving serial, without designing our own elements in the Octoprint user interface, which we certainly can do.

I still think that your method is better, generally though.

Button in Octoprint

image

MQTT configuration in Octoprint

image

MQTT publishing configuration for MQTT Publish plugin

sends 2 to ESPURNA-547CD9/relay/0/set in order to toggle the power state.
image

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2019

At which point you have to manually go into Octoprint and reconnect it to the printer.

Yes but my assumption was that the plugin to turn on a device with an Espurna must also have a way to reconnect to it, because you'd have to.

Your solution is better, though we need to find a way of auto connecting Octoprint all the time. I've been continually annoyed that it can't just auto-connect on serial all the time. If we can do that, you're absolutely correct.

Good. Glad we got there :)

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2019

I can't really think how this would be done without just having the 1284P on all the time recieving serial, without designing our own elements in the Octoprint user interface, which we certainly can do.

I still think that your method is better, generally though.

The plugin should do this. If it doesn't if the maintainer is sensible then they should want it to do this as it needs to in order to be useful...

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2019

Looking briefly here it looks like the plugin does exactly what I expected.

  • autoconnect is an option

  • executing arbitrary commands before turn on / after turn off is supported.

This is where we put the hub power control command...

ref; https://plugins.octoprint.org/plugins/tasmota_mqtt/

@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 28, 2019

@ajlennon I've found that using a docker-compose image and passing through ttyUSB0 (or whatever your printer is using) to that container works fine to autoconnect the printer, and makes sense since in my case you wouldn't want Octoprint to be active if the printer wasn't on.

version: '2'
services:
  octoprint:
    build: .
    image: nunofgs/octoprint
    restart: always
    container_name: octoprint
    ports:
      - 80:5000
    devices:
     - /dev/ttyUSB0:/dev/ttyUSB0
    volumes:
     - ./config:/home/octoprint/.octoprint
     - ./octoprint-data:/data'

If /dev/ttyUSB0 goes missing, the container restarts until it is present again. This is the default behaviour of the devices: directive in docker-compose. Octoprint has been configured to connect to this upon startup, so this works surprisingly well.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 30, 2019

I've added an Espurna programmed Sonoff Pow R2 to the Creality CR-10S printer.

This is ESPURNA-B1DB1E and is documented at

https://github.com/DoESLiverpool/somebody-should/wiki/Sonoff-switches

In the future I'd like to use a modified version of the Tasmota MQtt control plugin to turn the printer on and off. See here

https://plugins.octoprint.org/plugins/tasmota_mqtt/

However for now the format of the MQtt commands is Tasmota specific and won't work with ESPurna which is what we use as standard for Sonoffs.

So in the meantime I've modified another plugin, PSU control.

https://plugins.octoprint.org/plugins/psucontrol/

This gives a little power icon in the top of the web interface

image

You can click the icon to turn the printer on and off.

Similarly you should be able to turn the printer on by pushing the Sonoff button (as with other devices in the space).

The PSU control plugin is configured to automatically turn the PSU off after a print has finished (currently 1 minute timeout).

The commands used are standard ESPurna form MQtt publications using the mosquitto client utility

image

On

mosquitto_pub -h mqtt.localdomain -t ESPURNA-B1DB1E/relay/0/set -m 1

Off

mosquitto_pub -h mqtt.localdomain -t ESPURNA-B1DB1E/relay/0/set -m 0

I've tested this and it seems to work.

@MatthewCroughan might want to enhance OctoScreen so when the printer is powered disconnected we have an option to turn it on via the touchscreen?

I'll leave this open for a while to see how well this solution works.

If it seems ok for the Creality CR-10S I'll do the same with my Creality Ender-3

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 30, 2019

Also this works if a user turns on the printer using the Sonoff button.

So my anticipated work flow is

  • users turn on the printer with the sonoff button (or if they know about it via the web page)
  • users print their design either via the Octoprint web page or directly from Cura with the Creality plugin
  • the printer will switch off automatically after timeout or users can turn it off with the sonoff button
@MatthewCroughan

This comment has been minimized.

Copy link

commented Sep 30, 2019

@ajlennon I think timeout after no commands sent is sensible, avoids frustration if we're trying to figure something out or genuinely do something with the printer.

@ajlennon

This comment has been minimized.

Copy link
Contributor

commented Sep 30, 2019

I'm glad you agree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.