Upgrading to Cura 3.3.1

Get Help
1

What is the problem? Too many to mention, but I will anyway. Cura doesn't seem to recognize proper bed size or that the printer is operational. More problems are assumed to follow

What did you already try to solve it? Well, I didn't hit it with a hammer like I wanted to. I checked to make sure that the setting of the bed size actually stuck, then I went downstairs and made sure that the printer was in fact operational and printing and reachable via the network. Verified by the fact that I saw it printing, and reached it by Octoprint via the network

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...) Octopi 15.1 Octoprint 1.3.8 Anet A8, (firmware version is another issue entirely which I was hoping to fix, but... that's just not working out) FIRMWARE_NAME:ANET_A8_20160525 http://www.anet3d.com/ VERSION:ANET V1.0 MACHINE_TYPE:ANET_A8 EXTRUDER_COUNT:1

With trepidation, I installed Cura 3.3.1, found the Octo-Plugin and the API. Cura found all 4 instances of Octpi on my network (only 2 of which actually have printers) installed the printer I was trying to install (I think) set the parameters (220x220x220) and tried to slice an stl file with a size of 201x93x27 and was told "nothing to slice because none of the models fit the build volume"

Now, I'm wondering if cura has some kind of safety boundary setting that I can set that I can't find amongst its million other settings that I have no idea what they do

I would have tried to set this for the printer that isn't currently printing, but, I'm using that for another project that's working quite well right now, and I didn't wanna add an unknown factor into an already untested environmentoctoprint (1).log (575.0 KB)

I've attached the logfile, but, I don't know how much good it's gonna do because it wasn't octoprint that failed. Does Cura have a logfile ? Is this a Cura issue, and I'm asking in the wrong place ? Sorry, first time for a program that's way too complicated for an old man like me. I should probably just go back to etching pictures of dinosaurs on the wall of my cave

2

Check the Settings -> Build Plate Adhesion section (or simply remove the checkmark next to Build Plate Adhesion in the Recommended tab), turning off whichever bed adhesion mode may be on (raft/brim/skirt). If it's trying to print a raft that's 10 millimeters bigger than your part then that's 201 + 10 + 10 > 220. This is usually why mine fail to slice.

If it then will slice, adjust the settings for the bed adhesion to make the raft slightly smaller until it will still slice.

3

I seem to recall a similar message to the effect that the model wouldn't fit on the bed size. It was a small model and was nowhere near the bed size. It gave me the option to ignore such warnings in future. I did so and haven't had a problem since. I'm only using one printer 300X300X400.

4

You'll get this if you've used a raft on a part that's bigger than its base. (Imagine an upside-down pyramid that's the maximum size for your bed.) Cura stupidly adds the raft width to the widest horizontal slice rather than to its footprint.

5

One, possibly related, issue is that once OctoPrint plugin is installed it doesn't matter what printer is selected at the top the only two options when sliced are "Print With OctoPrint" and "Save To File". The option to "Print with Printer" seems to have disappeared. I use a "One" into "Two" USB switch so that I don't have to keep swapping USB cables, just press a button to toggle between RasPi and printer. I'm printing at the moment so will check out that the printer option returns when I toggle the USB connection.

Screenshot01

Screenshot02

6

Yup, that was it. It had raft turned on, which I didn't want for this print anyway cuz it's all flat on the bottom anyway.

Yup, I have both options lit up and not greyed out. It is now, for some reason, saying that the printer that is already actively printing, is ready and waiting for a print job to be sent to it, or, I can save the file to disk

Does this version of Cura have some kind of print queue ? Is that why it's offering to send directly to printer even tho it's currently active ?

7

Cura doesn't but when you send it to OctoPrint it will join the files already there even though it is already printing.

8

And you want to be careful with printing directly from Cura, as I discovered.

9

Yea, um, that's confusing to me. What is Octopi doing if it isn't connected to your printer ?

Yea, no, I don't want to print directly from Cura. I need to save the file so that when I screw it up I can cancel and start again. I just saved a file to disk while it was printing. Maybe the file was locked cuz it was being used, cuz it seems to have put it in the folder it should live in along with it's corresponding STL file. Oh, I just looked, it's not in my printer at all, only in the directory

On a side note, the gcode it just created is only about 1/4 the size of the file that's printing now that was sliced with cura 15.04

10

When OctoPi is controlling the printer it is, of course, connected (through RasPi) to the printer but when I want to print direct from Cura on my PC I toggle the USB switch to connect PC to printer.

11

In the bottom right corner after slicing, there are two options sort of in the same button. Just select the action from the right side of that button then make it happen by clicking the left side of that button. Not sure if I love these types of buttons, to be honest.

12

Caught me out at first.

13

Yea, I found that. That's what I used

Now I just wish it knew enough to download my firmware for me so I could just edit it and shove it back in instead of installing a whole new thing that I have no idea what's in it so I have to read thru the whole thing character by character to make sure it isn't doing anything stupid like a robot configuration file, which is up and running BTW... and it's talking, although, I'm not entirely certain that I really want it talking to my printer right now. It's only 5 days old and dumb as a box of rocks

14

I made a slice with this new Cura, and it inserted a gcode line that seems to have stuck my printer into a pause mode

It gets up to desired printing temp, then it just sits there, waiting for something. I think it's right at the beginning here, cuz the slice I did of the same file with 15.04 doesn't have this extra line in it

Obviously removing that line is what I need to do, but, the question is, where in the Cura 3.3.1 do I go to stop it from inserting that line in the first place ?

3.3.1 gcode...

And then the Cura 15.04

The current gcode says "printing stuff" in cura, while it used to say "molecules bonding", so I'm not sure where that came from either. I do have a few cura ini files saved, but, the most recent one that I was using when I installed the 3.3.1 should have been what got imported

So, anyway, the M104 is in the 3.3.1, while it isn't in the 15.04. If that's the problem, why is it there, and how do I get rid of it ? IE, what setting in cura 3.3.1 should I uncheck ?

15

An M104 (heat hotend, no wait) followed immediately with an M109 (heat hotend, wait) is exactly the same as the M109 alone (i.e. the M104 is essentially a no-op).

If however, the M104 was followed by the M190 (heat bed and wait) and then the M109, then the M104 would cause both heaters to be working at the same time.

However, you don't want those lines so here is how to "remove" them:

CuraEngine checks if the start gcode contains commands to heat up the hotend and bed before the print is started. If the start gcode does not have command to do that, CuraEngine adds the three lines (M190, M104, M109) before your start gcode just to make sure that the hotend is not cold before starting the actual print.

If you don't want Cura to add these lines, make sure your start gcode contains lines which have {material_print_temperature} and {material_bed_temperature} in them respectively.

You must use the {} parameters and let Cura do the substitution (in Cura 15.04.6 the start gcode used {print_temperature} and {print_bed_temperature} macros).

16

Those came from the M117 commands at the end of your two examples.