Cura 2.4 beta is here!

[Melka 57]

Actually changing to RepRap gcode could be a good thing for the mark2 IMHO, I like to have an experience close to the UM3, so including setting temp in Cura, and ignoring material profiles on the machine.

 

Poor Tinkergnome!!

[bagel-orb 61]

I have another nr1 request:

With version 2.4 all the dual extrusion "temperature magic" is omitted for UltiGCode. This is a huge step back for us... or should i say: a KO criteria?

 

UltiGcode was designed back in the days when you would set one temperature for the whole print. The idea was that you choose your material on the printer (where you just installed the new filament) and then the printer would control the bed temperature and nozzle temperature for you. If Cura inserts temperature commands then the preferences you set in your firmware are overwritten, which means that some user settings are ignored.

Since you you have a dual extrusion UM2, you already are a tinkerer, so I think you should tinker some more and move over to the RepRap gcode flavour. If I recall correctly then the UM2 firmware defaults to RepRap behaviour when the Ultigcode header is not present. You will then have the full benefits of temperature controls in Cura again.

Edited December 27, 2016 by Guest

[tinkergnome 927]

I think you should tinker some more and move over to the RepRap gcode flavour.

 

Yes, i see, UltiGCode is out of date and soon.... out of use.  

Since we are at it...

Is there a (quick) reference anywhere with all possible {placeholders} that can be used in start- and end-gcode?

Or more specific: Is it possible to insert the printing temperatures from the current Cura project there? Sometimes a specific heatup sequence is crucial...

[zerspaner_gerd 383]

With version 2.4 all the dual extrusion "temperature magic" is omitted for UltiGCode. This is a huge step back for us... or should i say: a KO criteria?

I now use the gcode flavor type "RepRap (Volumatric)" because the "temperature magic" works again and is all the same as with the UltiGCode, only the program head must be changed.

But where is the setting for the overlap for the dual extrusion.

These ones:

 

"multiple_mesh_overlap":               {                   "label": "Dual Extrusion Overlap",                   "description": "Make the models printed with different extruder trains overlap a bit. This makes the different materials bond together better.",

 

Excerpt from Cura 2.3.1

The advantage for me at UltiGCode, is the Retract!

Edited December 27, 2016 by Guest

[TheQuestor 0]

Won't load for me at all. The splash screen comes up and then it just closes. :(

[rexipus 0]

Won't load for me at all. The splash screen comes up and then it just closes. :(

Same was happening for me. I uninstalled 2.3 and then moved out the directory under Users/name/appdata/local/cura (or whatever, I'm going from memory). Then it came up fine.

I'm still not seeing cubic subdivision infill show up though in the layer view. This is a bummer, because this feature is the only reason I uninstalled 2.3 and installed 2.4 beta to begin with.

[bagel-orb 61]

But where is the setting for the overlap for the dual extrusion.

 

It's now called Merged Meshes Overlap and it's under the Mesh Fixes category.

[bagel-orb 61]

Is there a (quick) reference anywhere with all possible {placeholders} that can be used in start- and end-gcode?

Or more specific: Is it possible to insert the printing temperatures from the current Cura project there? Sometimes a specific heatup sequence is crucial...

 

Yes.

Here you can view all settings: https://github.com/Ultimaker/Cura/blob/2.4/resources/definitions/fdmprinter.def.json

Here's an example of how BQ Hephestos printers use it:

"machine_start_gcode": { "default_value": "; -- START GCODE --\nM104 S{material_print_temperature} ; Heat up extruder while leveling\nM800 ; Custom GCODE to fire start print procedure\nM109 S{material_print_temperature} ; Makes sure the temperature is correct before printing\n; -- end of START GCODE --" },

[tinkergnome 927]

Here's an example of how BQ Hephestos printers use it:

"machine_start_gcode": { "default_value": "; -- START GCODE --\nM104 S{material_print_temperature} ; Heat up extruder while leveling\nM800 ; Custom GCODE to fire start print procedure\nM109 S{material_print_temperature} ; Makes sure the temperature is correct before printing\n; -- end of START GCODE --" },

 

Mmhhh, but this are not the same values that are configured for the current material settings...

It seems not possible to choose the print temperature of a specific extruder?

[JohnK 30]

Just noticed on the UM3, when trying to print with the second extruder only, it will still prime the first extruder after the first layer and then keep that extruder at the standby temp (100C) through the whole print... with 2.3, It would just print as a single extruder printer.

[LePaul 322]

Looks like the Beta has been removed? Links show 404 etc.

[nallath 1,122]

Looks like the Beta has been removed?  Links show 404 etc.

 

It was moved ofline as we found a pretty nasty bug with support meshes. These could in some cases result in g-code with no Z values (eg; all layers printed on z0), which can do pretty massive damage to the machine.

We already have a fix, so it should be up again today. Sorry about this!

[LePaul 322]

OKay good to know! (I'm glad I missed it, then!)

I saw mention of a new infill type that might help me

[scrid2000 0]

Looks like the beta is back up.

[Tezmo 0]

But still no manual control? Still staying pre 2.X then.. :angry:

[gr5 2,178]

"manual control"? What does that mean? You can override any setting in cura 2.X. It will show a little icon next to whatever setting you change so you know which settings are not default. Clicking the icon brings it back to default. It's a pretty good design.

[Tezmo 0]

Manual control: moving motors manually.. It's there with Pronterface UI in 15.0.4.6 and I really like Cura.. But I still can't upgrade to 2.x just because I have to manually level my printer :/ It's really a big miss...

[gr5 2,178]

I see. I think Cura 15.X was a slicer *and* a printer controller. Cura 2.X is just a slicer. The programmers are concentrating on just the slicing aspect as it is so complicated. Especially with features like support and multi color. jerk control and so on.

So I think the idea is you have cura *and* you have pronterface (or similar). Cura for slicing. Pronterface to control the printer. Sometimes merging 2 programs into one makes for one program that does neither well. So maybe it's best this way? Cura 15.X really wasn't that good of a printer controller. Pronterface is so much better.

[Tezmo 0]

Though I get your point, I don't agree. I love Cura and right now I'm staying with the old version because it simply offers me everything I need.. But then, I see the new Cura - and it's really great - I fell in love with it..

and then, like any love story i guess, it fell apart, only because it's missing this silly little thing.

All I'm saying is, I see no need for any other software, if I can just get manual controls back / the pronterface UI directly in Cura.. It would make it a one stop shop.. I hate having to switch apps just because 1 is better at one thing, and the other is better at that.. I just want a program that does a full job.. Who ever stops after just slicing?

[Tomatburk 0]

I have to agree with @Tezmo. I really like Cura and have been using it as my main slicer since I entered the world of 3D-printing. Right now I'm running 15.04.6 and it works good, although I would love to migrate to the newer versions.

I've heard so many good things about Cura 2.3 and forward so I decided to give it a try. Although, based on how I use my printer, and I know many others do as well, there is no good way to use the newer versions, and it's all because it's lacking one simple feature - Manual Control. In the old version it was called "Pronterface UI" and it showed up in the print window as you pressed print. This feature allowed me to control axes, send Gcode, preheat my bed and also helped if I needed to swap filament quickly. Without this feature there is no way I will use the newer versions.

So, please, bring back Manual Control in some fashion. It needs to have basic axis control, option to send manual Gcode, fan speed control and heat control.

Thanks for making great software.

[neotko 1,417]

Cura is made by UM for UM printers, and only umo (discontinued) had usb printing (officially supported) . So is normal that UM doesn't add usb printing, hence no need for usb control from the software. Any other printer maker is free to work and code a usb pronterface if they see it fit.

Anyhow I would also like a pronterface, but using the free pronterface/printeun program is just so easy that I don't see the problem on using two programs.

Edited January 8, 2017 by Guest

[DaHai8 74]

Cura is made by UM for UM printers, and only umo (discontinued) had usb printing (officially supported) . So is normal that UM doesn't add usb printing, hence no need for usb control from the software.

 

So...you're saying that manual control over WiFi or Ethernet is impossible with any interface (Pronterface or otherwise)....

[neotko 1,417]

 

Cura is made by UM for UM printers, and only umo (discontinued) had usb printing (officially supported) . So is normal that UM doesn't add usb printing, hence no need for usb control from the software.

 

So...you're saying that manual control over WiFi or Ethernet is impossible with any interface (Pronterface or otherwise)....

 

When did I said that? I said it makes sense that UM doesn't add it by default since isnt officially supported.

[DaHai8 74]

 

 

Cura is made by UM for UM printers, and only umo (discontinued) had usb printing (officially supported) . So is normal that UM doesn't add usb printing, hence no need for usb control from the software.

 

So...you're saying that manual control over WiFi or Ethernet is impossible with any interface (Pronterface or otherwise)....

 

When did I said that? I said it makes sense that UM doesn't add it by default since isnt officially supported.

 

Ok, perhaps I'm reading too much in your comment. But you seemed to imply (and I inferred) that the reason 'manual control' was dropped was because USB support was dropped, so therefore I followed that Manual Control was only possible over USB - othewise why would it not have been implemented for Wifi/Ethernet connection (as on the new UM printers)

[neotko 1,417]

 

 

 

Cura is made by UM for UM printers, and only umo (discontinued) had usb printing (officially supported) . So is normal that UM doesn't add usb printing, hence no need for usb control from the software.

 

So...you're saying that manual control over WiFi or Ethernet is impossible with any interface (Pronterface or otherwise)....

 

When did I said that? I said it makes sense that UM doesn't add it by default since isnt officially supported.

 

Ok, perhaps I'm reading too much in your comment. But you seemed to imply (and I inferred) that the reason 'manual control' was dropped was because USB support was dropped, so therefore I followed that Manual Control was only possible over USB - othewise why would it not have been implemented for Wifi/Ethernet connection (as on the new UM printers)

 

I did ask for a wifi/etherned gcode connection since the first beta, I think is a must-have to control the um3, but I tried to stay on topic since noone mentioned wifi, but usb.

Latest firmware on um3 has a 'python 3 command_util.py' on the um3 (/usr/share/griffin/) that allows to 'sendgcode' directly to the printerboard (the name it has now the white board). I use it quite a lot to fine tune my experiments. Also, IMHO, wifi/ethernet gcode control should be from day one since the USB port of the white board is blocked by the printer frame, but for now at least we have something to control it.