OctoPi Tutorial for Zim

#104

Interesting to note as well, before a print is started the response is slightly different:

Send: M105
Recv: ok T:25.7 /0.0 B:0.0 /0.0 T0:25.7 /0.0 T1:25.9 /0.0 @:0 B@:0

and after (this is not the M105 but the M109 set and wait command):

Send: N4 M109 T1 S200*43
Recv: T:153.8 E:1 W:? T0:30.5 /0.0 T1:153.8 /200.0 B:0.0 /0.0

Once it reaches temp it’s not waiting any more and starts sending M105’s again (last 4 lines here)… which it apparently knows how to process just fine:

Recv: T:199.6 E:1 W:8 T0:36.2 /0.0 T1:199.6 /200.0 B:0.0 /0.0
Recv: T:200.1 E:1 W:7 T0:36.2 /0.0 T1:200.1 /200.0 B:0.0 /0.0
Recv: T:200.5 E:1 W:6 T0:36.2 /0.0 T1:200.5 /200.0 B:0.0 /0.0
Recv: T:201.0 E:1 W:5 T0:36.3 /0.0 T1:201.0 /200.0 B:0.0 /0.0
Recv: T:201.5 E:1 W:4 T0:36.3 /0.0 T1:201.5 /200.0 B:0.0 /0.0
Recv: T:202.0 E:1 W:3 T0:36.4 /0.0 T1:202.0 /200.0 B:0.0 /0.0
Recv: T:202.5 E:1 W:2 T0:36.6 /0.0 T1:202.5 /200.0 B:0.0 /0.0
Recv: T:203.0 E:1 W:1 T0:36.7 /0.0 T1:203.0 /200.0 B:0.0 /0.0
Recv: T:203.2 E:1 W:0 T0:36.6 /0.0 T1:203.2 /200.0 B:0.0 /0.0
Recv: 
Recv: ok
Send: N5 G17*26
Recv: Unknown command: "N5 G17*26"
Recv: 
Recv: ok
Send: N6 G21*28
Recv: 
Recv: ok
Send: N7 G90*23
Recv: 
Recv: ok
Send: N8 M82*17
Recv: 
Recv: ok
Send: N9 M107*44
Recv: 
Recv: ok
Send: N10 M203 X10000 Y10000 Z600 E250*12
Recv: 
Recv: ok
Send: N11 G28*35
Recv: 
Recv: ok
Send: N12 G1 Z15.0 F(travel_speed)*60
Recv: ok
Send: N13 T1*9
Recv: echo:Active Extruder: 1
Recv: 
Recv: ok
Send: N14 G92 E0*114
Recv: 
Recv: ok
Send: N15 G1 F200 E10*44
Recv: ok
Send: N16 G92 E0*112
Recv: 
Recv: ok
Send: N17 G1 F200 E-16*5
Recv: ok
Send: N18 G1 F7200*114
Recv: ok
Send: N19 M107*29
Recv: 
Recv: ok
Send: N20 G0 F7200 X49.671 Y49.658 Z0.250*33
Recv: ok
Send: N21 G0 X49.347 Y50.075*17
Recv: ok
Send: N22 G1 F1800 X49.671 Y49.658 E0.01647*50
Recv: ok
Send: N23 G1 X52.620 Y47.393 E0.13241*95
Recv: ok
Send: N24 G1 X56.065 Y45.966 E0.24868*92
Recv: ok
Send: N25 G1 X59.759 Y45.480 E0.36486*80
Recv: ok
Send: N26 G1 X63.455 Y45.966 E0.48110*83
Recv: ok
Send: N27 G1 X66.901 Y47.392 E0.59739*85
Recv: ok
Send: N28 G1 X69.857 Y49.662 E0.71360*81
Recv: ok
Send: N29 G1 X72.128 Y52.620 E0.82988*87
Recv: ok
Send: N30 G1 X73.555 Y56.065 E0.94615*95
Recv: ok
Send: N31 G1 X74.041 Y59.761 E1.06239*85
Recv: ok
Send: N32 G1 X73.622 Y62.948 E1.16262*80
Recv: ok
Send: N33 G1 X73.547 Y63.470 E1.17907*95
Recv: ok
Send: N34 G1 X72.328 Y66.417 E1.27851*83
Recv: ok
Send: N35 M105*17
Recv: ok T:200.0 /200.0 B:0.0 /0.0 T0:37.9 /0.0 T1:200.0 /200.0 @:0 B@:0
Send: N36 M105*18
Recv: ok T:200.0 /200.0 B:0.0 /0.0 T0:37.9 /0.0 T1:200.0 /200.0 @:0 B@:0

I tried installing the YamlPatcher plugin and applying this option with no change:

Screen Shot 2015-09-14 at 2.20.17 PM.png1205×862 156 KB

#105

Temperature for M109 is fixed in 1.1.0.19. I tried adding the target temperature to the “active” extruder as suggested, but this still didn’t fly with OctoPrint. I ended up removing active temperature for M109 altogether, and that solved it due to parsing for T0 and T1 only. This is what I didn’t like about the reporting anyway, since T0 and T1 are already there for both extruders… It appears the OctoPrint guys agreed in our absence :smile: , though it is not what the original Marlin does (e.g. appears OctoPrint isn’t compatible with Marlin and dual extruders without some modifications).

Btw, this version also shortened the button hold required to turn off the printer. It never felt very responsive to me with a 2 second hold required. I changed it to 500ms. I understand the whole accidental push an all, but that button is pretty hard to accidentally push. You can change it back on Configuration_adv.h -> MAX_TIME_PUSHING_MS if you are so inclined (changed the value to milliseconds, so 2000 for the original timing).

So in all, heres the changes in 1.1.0.19 JPod

  • Added T0 and T1 temperature readings for M105 and M109 commands for
    OctoPrint.
  • BLOCK_BUFFER_SIZE changed from 4 to 16 to reduce short move pauses.
  • Increased serial receive buffer from 4 to 8 to reduce short move pauses.
  • Added OCR1 workaround for newer compiler described here to correct for short move overrun.
  • Removed references to RFID and PVA code.
  • Added filament used output to terminal when print completes.
  • Removed “active” extruder temperature to correct OctoPrint temperature tracking of T1 for M109 commands.
  • Shortened button hold required to turn off machine to 500 ms (from 2 seconds).
4 Likes
#106

I just found this really good page for configuring OctoPi if Joe’s tutes don’t get you all the way there. I was having trouble enabling wi-fi, and that got me sorted:

Note that he says to edit /etc/network/interfaces but it’s looking at boot/octopi-network.txt so continue using that as directed.

#107

There is this really nice in Simplify3D.
It saves me from prints not starting after everything is heated up and my personal “killed Zim”-Problem in mid-print.

Does anybody know how to make this instant kill and connection reset with reconnect and what else, in Octoprint?

#108

Creating a macro with M112? This might be stupid but is the code that appear on S3D for emergency stop…

#109

I made a G-Code Handbook some days ago (original source of information: Reprap Wiki).
If anyone likes to take a look, here´s the Link:
https://onedrive.live.com/redir?resid=B2A53EE4BB8C1B66!2098&authkey=!AI-FOv8hsb0DrOA&ithint=file%2Cpdf

1 Like
#110

This is a really valuable resource. Thanks for sharing it with us.

#111

Hm, I get that same command after I press the button.
But what I really get is this:
RECEIVED: Unknown command: “M112”
Afterwards the reset, disconnect and reconnect happens. But there are no visible commands in the console.
So something else is going on.

No ideas?

#112

Hey, I found this github repo where a 3d printer owner of a craftbot printer created a python script for Octopi to prevent the extruders from turning off while heating up if it took too long to heat them up to your targeted temp. I haven’t tried/tested it but something to look into.

I know a few of us are frustrated that it shuts down on us when heating up the print head.

From what i quickly gathered is that it simply queries for temp. and sets it again. I do that manually now.

github repo: https://github.com/krisp/staywarm

#113

Okay this is strange:
Two weeks ago @Darki88 contacted me via PM with some issues with his ZIM, including one problem with his heaters. He wasn’t able to heat up his second extruder from the UI, although everything seemed to be configured correctly. At some point I wasn’t able to help him.
Yesterday, I got a new SD card, re-downloaded octoprint, and installed it on my new card. And from that moment… I’m not able to heat up my second extruder from the UI anymore… Any Ideas?

#115

What the Fu**k? Today, I started up my ZIM and the issue is gone…?! :grin:
Thats cool, but on the other hand, I don´t know what caused the issue and what was the solution.

#116

I added some special ZIM M-codes to the G-Code handbook… Here´s the link.
http://1drv.ms/1OfdHEI

#117

This item might not exist or is no longer available

Could you please check on that?

#118

Okay… strange… here we go:
https://onedrive.live.com/redir?resid=B2A53EE4BB8C1B66!2150&authkey=!ALQ26QgJkpsGmf8&ithint=file%2Cpdf

or

http://1drv.ms/1ZcHrXO

I´ll open an extra thread for that.

EDIT: The new link can be found HERE

1 Like
#119

Hey guys! It’s been quiet around here for a while…
my today’s question is:
is it possible to set travel speeds for each axis independenty? Becuse when i slice with cura, the first move is set to {travel_speed}, and that seems to be too fast for my Z-axis. It makes strange wiou-wiou-wiou sounds probably of a too high speed setting.
Can the max speed if the axis been set in the firmware at all, or do I have to dig around in cura? I haven’t found an adequate setting in cura so far…

#120

Yes you can.
See the configuration.h at Marlin and look for:

define HOMING_FEEDRATE
define DEFAULT_MAX_FEEDRATE
define DEFAULT_MAX_ACCELERATION

Here you get the latest Firmware (adapted by @jpod - thank you by the way for that!!)

#121

Thanks, but that´s not exactly what I wanted. My problem seems to be that the Z axis has a significantly lower max speed than the others. So when Cura gives a command like G1 X… Y… Z… {travel speed}, the printer seems to try to travel at the speed of the X or Y axis (about 12000mm/min). That is way too much for the Z axis (about 600mm/min), that begins to travel in slow “hops” making an awful Wiou-wiou-wiou-sound. At least, ti seems not to loose steps while doing that, because the positions is always right. Is there a way to independendly set the Z speed from the X/Y speed?

#122

I had some time last night. And normally I have strange ideas when having free time :smile:

It is a pain to see my beautiful ZIM with loose wires coming out of the back, and knowing that I have to open the case remove the network cable (W-Lan is too weak in my basement).
So I ordered some pigtail connectors some time ago and last night was the night to install them:

Pasted image662×654 877 KB

Mark the new cut-outs:

Pasted image1168×680 1.5 MB

Installed the pigtails:

Pasted image1109×666 1.65 MB

Happy:

Pasted image1144×800 1.94 MB

Pasted image909×525 829 KB

Some matte black color for the cut edges, and that´s all.
And in near future, it´ll get a keyboard, mouse and a display :smile:

OOPS: This is in the software-category… sorry

1 Like
#123

Hey, that looks great!

#124

I think I have a problem when heating the nozzle before printing. Each time, the printer (well, OctoPi) stops the process because of the timeout (even set to 600 sec). The temperature raises quickly then slow down at around 170°C. Then progression of the temperature raising becomes slow as hell.

When I’m using Jpod script to load and unload filament, I don’t have this issue where the temperature goes far higher. But if I’m not wrong, the difference is the second fan in the ZIM head which starts when launching a print, and not when launching a filament load/unload.

Does anyone know if the second fan running is the cause?

And FYI, I’m using Simplify 3D as a slicer.

Thanks!