Page MenuHomeAleph Objects Inc

Bed Temperature 0
Closed, ResolvedPublic

Description

LulzBot Mini

When setting bed temperature to "0" in Cura 2.4 the print will never start. We suspect this is due to the bed temperature never dropping below ambient temp.

@mosborne Please try to verify this tonight, and post an update here.

Event Timeline

karrad created this task.Feb 22 2017, 3:31 PM

Foxglove Mini

Confirmed. Used the IC3D profile, modified the bed temp to 0 and it just sat there after performing the wipe and probe and auto leveling sequences.

Usually, if the temperature is set to 0, it needs to be ignored (leave it to whatever it has been set before the print started).
It's not possible though with the mini/taz6 because of the wiping+probing, and the temperature set command is hardcoded in the start gcode.
I've tested this with Cura Original though, and cura doesn't freeze, the print starts anyways, it will just set the temperature to 0 in the firmware, and it looks like marlin will know not to wait forever for it to reach 0 and will return 'ok' right away.
@victor_larchenko Do you know why it freezes, does usb printing via cura2 check for temperature and it does its own internal waits ?

No, cura2 don't have any checks for it. It's firmware problem, because after sending M190 R0 printer hangs up and doesn't return anything for any command.

jebba added a subscriber: jebba.Feb 28 2017, 9:40 AM

I think it is related to M190 R0 vs M190 S0.

victor_larchenko closed this task as Resolved.Feb 28 2017, 11:11 PM
karrad reopened this task as Open.Apr 5 2017, 3:09 PM

@victor_larchenko We had this issue pop back up today on the TAZ 6 Flexystruder machine settings. It appears we will need to make this change to each machine option within Cura 2

Taz6 flexystruder uses stangard taz6 gcodes for now, so printing can be dangerous. But this issue was fixed for taz6, so I don't know why it still present. Maybe there are difference in firmware, how they perform that command, I think needed to discuss it with firmware developers, because I don't have taz6 flexystruder for now to test smth.

@gralco is there anything within marlin that would affect this? We have double checked with support and around the building, it appears to be on the TAZ 6 Flexystruder only atm.

@victor_larchenko : technically this is not a firmware issue, the firmware should not be case specific, if for some crazy reason the ambient temperature is below 0°C then it could be reached (or even down to 0.0001K). This is part of the reason we implemented M108 (cancel heat and wait).

If anything we need to update the profiles which have a final bed target temp of 0°C.

Otherwise Cura could check for the condition when the target bed temp is set to 0 and actually moves the bed forward at ~35°C.

@gralco after M190 R0 or M190 S0, printer hangs and not respond on any command(includes M108), this is only on flexystruder firmware.

@victor_larchenko Marlin's buffer is getting filled by Cura.
Please refer to:
c926e341477f6bf4824ea175fee625105102edb0
310cd72ac8067fc86604e2196691b7c586fd5215
1ccac8841461eedb48e7034201f385d30ee5cc20

If Cura gives the TAZ three commands then it has filled its buffer and Marlin cannot escape the loop via M108.

From my recollection, Cura should maintain that no commands are sent to Marlin's buffer after sending M109/M190 so as to leave room for M108.

After testing this (again) in Pronterface, Marlin is certainly behaving as expected:

>>> M190 R0
SENT: M190 R0
RECV: T:46.75 E:0 B:38.0 W:?
...
...
...
RECV: T:46.75 E:0 B:38.0 W:?
>>> M105
SENT: M105
...
RECV: T:43.39 E:0 B:37.3 W:?
...
...
...
RECV: T:43.00 E:0 B:37.3 W:?
>>> M108
SENT: M108
RECV: ok
RECV: ok T:42.2 /0.0 B:37.1 /0.0 T0:42.2 /0.0 @:0 B@:0
RECV: ok

SUCCESSFULLY ESCAPED!!! (notice there are three 'ok's)

In the following case Marlin's buffer is filled and it's stuck in a loop waiting to reach 0°C:

>>> M190 R0
SENT: M190 R0
RECV: T:46.75 E:0 B:38.0 W:?
...
...
...
RECV: T:46.75 E:0 B:38.0 W:?
>>> M105
SENT: M105
>>> M105
SENT: M105
...
RECV: T:43.39 E:0 B:37.3 W:?
...
...
...
RECV: T:43.00 E:0 B:37.3 W:?
>>> M108
SENT: M108
RECV: T:25.56 E:0 B:28.8 W:?
RECV: T:25.56 E:0 B:28.8 W:?

STUCK!!! (in this case the cmdbuffer contains ["M190 R0", "M105", "M105"] and M108 never enters it)

Here's the code in Cura which should be preventing this situation:

timeout = time.time() + 30
# If we are heating up with M109 or M190, then we can't send any new
# commands until the command buffer queue in firmware is empty (M109/M190 done)
# otherwise, we will fill up the buffer queue (2 more commands will be accepted after M109/M190)
# and anything else we send will just end up in the serial ringbuffer and will not be read until
# the M109/M190 is done.
# So if we want to cancel the heatup, we need to send M108 which needs to be able to be read from
# the ringbuffer, which means the command queue needs to be empty.
# So we stop sending any commands after M109/M190 unless it's M108 (or until heating done) if we want
# M108 to get handled.
# the small delay that is caused by the firmware buffer getting empty is not important because
# this happens during a heat&wait, not during a move command.
# If M108 is received, it gets sent directly from the receiving thread, not from here
# because the _commandQueue is not iterable
if not self._heatupWaiting:
  # We iterate in case we just came out of a heat&wait
  for i in xrange(len(self._currentCommands), CMDBUFFER_SIZE):
    # One of the next 4 could enable the heatupWaiting mode
    if not self._heatupWaiting:
      if not self._commandQueue.empty():
        self._sendCommand(self._commandQueue.get())
      else:
        self._sendNext()
if len(self._currentCommands) > 0 and \
   ("G28" in self._currentCommands[0] or "G29" in self._currentCommands[0] or \
  "M109" in self._currentCommands[0] or "M190" in self._currentCommands[0]):
  # Long command detected. Timeout is now set to 10 minutes to avoid forcing 'ok'
  # every 30 seconds while it's not needed
  timeout = time.time() + 600

Thanks, @gralco. I've added this to cura2, but I can't test it, I can connect printer only with octoprint for now.

victor_larchenko closed this task as Resolved.Apr 27 2017, 4:28 AM