Cura 14.01

Frank - I used your original plugin over usb today - it worked great, thanks again. I got my replacement duet from rrp today too so over the next day or two I'll hopefully get Matt's web interface up and running somwhere local and will try the latest plugin on that (I've been running on a think3d print3d duet for a while, and will now pop it out and make a new home for it on my seemingly working development system!!!)

Cheers

Ray

I am very happy the hear that the plugin is also useful for certain people!

Today I found out, that inside the preferences file was a wrong "active_machine" number (2 instead of 0). This could cause Cura to prompt you the "first run wizard" every time when you start Cura. Also the machine settings could not be executed and the preset values (filament size and so on) are not correct.

I fixed it in the attached package.

Cura will work normal again if you delete the preferences.ini before staring Cura or replace it with the file attached!

Frank

Really impressed.

Tonight ive printed a part which required support material, i tried using Slic3r many times but the support sticks on the part solid. In Cura it pops out easily.
The print quality isn't as good as Slic3r but i think that will be a matter of tweaking settings and print speeds.

One problem i do have is that the part show in Cura view pane is black without any shading. Before the screen was totally black till i updated some video drivers (openGL i think?)
I get shading and colour when using the layers view mode, but all the other modes are the same and do not change from black. Any ideas how to fix?

Cheers
Paul

Thank you very much Frank,
Cura-plugin is working great. I like to have the choice between Cura and Slic3r. I also recognized that some support structures are better done with Cura.

Last print (a small clamp) with Slic3r was a desaster because it makes some silly moves and scrambled the perimeter of my object (needed two seperate moves for one closed perimeter). Cura on the contrary made the complete perimeter in one move.

Happy to hear that!

I'm using Cura all the time at the moment! You should also take a look at this thread: forums.reprap.org to archive best results. With that modified firmware I am using 15mm/s for perimeters and 100mm/s for infill and the results are very good. Better quality with less printing time!

Frank

Edited 1 time(s). Last edit at 02/18/2014 02:33PM by Cash.

Quote
Cash
Happy to hear that!

I'm using Cura all the time at the moment! You should also take a look at this thread: forums.reprap.org to archive best results. With that modified firmware I am using 15mm/s for perimeters and 100mm/s for infill and the results are very good. Better quality with less printing time!

Frank

Hi Frank.

Which setting is perimeters?

I have -
Print Speed (basic tab)
Travel Speed (Advanced tab)
Bottom Layer Speed (Advanced tab)
Infill Speed (Advanced tab)

Cheers
Paul

Hi Paul,

Print speed is for perimeters (the surface), if you set another speed for infill.

I set print speed to 15, infill to 100, bottom layer to 30 and travel speed to 100! But you can change this to match your requirements!

Cheers,

Frank

Edited 1 time(s). Last edit at 02/18/2014 04:45PM by Cash.

Frank - one other thing that will affect the speed that the head reaches (but will cause slippage/missed steps if you take it too far) is of course the acceleration - you can control acceleration with gcodes, in the same way that you can control the maximum speed (I'd overlooked this until today):
M203 sets the maximum speed (by default this is capped at 50mm/s or 3000 mm/minute in the firmware - I increased this limit in the version of firmware I uploaded:

M203 X6000 Y6000 Z500 E3000 ; will allow 100mm/s sliced gcodes to work... if they have time/distance to get up to speed

M201 X1600 Y1600 Z50 E1600; will double the default acceleration and allow the machine to arrive at top speed over shorter distances/times(maybe doubling the acceleration is too much though other machines have acceleration settings up to 8000 - mine skipped on X at 2000 with a top speed of 100mm/s - you need to find what level of acceleration your machine can achieve without losing steps)

to give the motors more power ,so they can produce more torque and help them achieve the increased acceleration, you can use M906:

M906 X1200 Y1200 Z1200 E800 ; (defaults are 800mA, setting 1200mA may cause overheating of the motors or the driver chips - again increase from 800 slowly making sure that you don't overdo it!).

by the way, dc42 has produced a more rational modification of the code I altered, and it'll be worth using that I think

Cheers

Ray

Hi Ray,

thank you for the explanation! I will try the other firmware and the M-Codes this evening!

It is not my goal to get the maximum speed out of my machine, but the best quality and an acceptable speed with no step loss!

Frank

@Cash - Thanks very much for the Cura settings and plugin, I had a chance to try them last night and was very pleased with Cura's results, the programmed path seems to be a lot smoother with less unnecessary moves, and the support material is much better, i'm also keen to try the "Minimal layer time" setting further. It does seem to have an issue with thin walls, might be just a wrong setting somwhere, it quits printing the thin wall test right after finishing the base layers. Also is there any way make the selected plugin persistent?, it keep disabling itself after a new .stl is added.

All-in all minor issues/annoyances but really great to have other viable alternatives to Slic3r.

Matt

---

Limited Edition Red RS Ormerod 1 #144 of 200 - RRP 1.09fw
iamburnys Ormerod Upgrades Github
Follow me on ThingiVerse My Designs

Matt the ormerod plugin is always on and doesn't dissapear on my cura.

Ii tried the thin wall test too and only got the 1st layer?


The support material from cura is brilliant, it just pops out. Compared to the slic3r which sticks to everything.

I found out also, that if the walls are too thin, Cura does not print anything sometimes. You can verify this in the layers view.
Possibly Cura removes structures that are smaller than the 0,5mm that the extruder is able to print.

Frank

Quote
rayhicks
M203 sets the maximum speed (by default this is capped at 50mm/s or 3000 mm/minute in the firmware - I increased this limit in the version of firmware I uploaded:

M203 X6000 Y6000 Z500 E3000 ; will allow 100mm/s sliced gcodes to work... if they have time/distance to get up to speed
Ray

I have added this line to my settings inside Cura (start g-code) and found out, that the plugin will handle this in a wrong way, because of X Y and Z is inside one line and the plugin tries to divide this into 2 seperated G1 commands that the Ormerod firmware can handle.
Now I have modified the plugin again, i forgot that the line must also contain a "G1"!

In the attachment you will find the new plugin and my actual setting (for quality) with the above line included into the start g-code to enable printing at 100mm/s!

@dc42: Your 057n firmware is working great so far. Thank you very much!

Cheers,

Frank

Great - I'll try it out tomorrow At the moment I'm storing the accel/speed settings in Repetier Host's gcode"printer scripts", that way i can quickly change during printing (quick and dirty for the first 5mm of layers of a large print which are mainly a structural support for the fine detailed optical mounts on the top 20mm). If I get time tomorrow (and can find my camera) I'll have a go at videoing a print that used to bang with the old and new firmware - it's quite an incredible change.

CHeers

Ray

Quote
Cash

Quote
rayhicks
M203 sets the maximum speed (by default this is capped at 50mm/s or 3000 mm/minute in the firmware - I increased this limit in the version of firmware I uploaded:

M203 X6000 Y6000 Z500 E3000 ; will allow 100mm/s sliced gcodes to work... if they have time/distance to get up to speed
Ray

I have added this line to my settings inside Cura (start g-code) and found out, that the plugin will handle this in a wrong way, because of X Y and Z is inside one line and the plugin tries to divide this into 2 seperated G1 commands that the Ormerod firmware can handle.
Now I have modified the plugin again, i forgot that the line must also contain a "G1"!

In the attachment you will find the new plugin and my actual setting (for quality) with the above line included into the start g-code to enable printing at 100mm/s!

@dc42: Your 057n firmware is working great so far. Thank you very much!

Cheers,

Frank

Hi Frank,

I obviously have an Ormerod and currently have used Slic3r (8kg of printing) and not so impressed by the random errors I get and the awful support structure.
I will also soon get an Ultimaker as well which comes with Cura as default. How can I use Cura for both printers? Can the plugin be started/stopped when slicing for different printers?

Thanks,
Arnaud

Quote
Cash

Quote
rayhicks
M203 sets the maximum speed (by default this is capped at 50mm/s or 3000 mm/minute in the firmware - I increased this limit in the version of firmware I uploaded:

M203 X6000 Y6000 Z500 E3000 ; will allow 100mm/s sliced gcodes to work... if they have time/distance to get up to speed
Ray

I have added this line to my settings inside Cura (start g-code) and found out, that the plugin will handle this in a wrong way, because of X Y and Z is inside one line and the plugin tries to divide this into 2 seperated G1 commands that the Ormerod firmware can handle.
Now I have modified the plugin again, i forgot that the line must also contain a "G1"!

In the attachment you will find the new plugin and my actual setting (for quality) with the above line included into the start g-code to enable printing at 100mm/s!

@dc42: Your 057n firmware is working great so far. Thank you very much!

Cheers,

Frank

First try using your settings and its a fail

The Z axis moves down so quickly that it stutters and looses its position. then starts printing in the air.

what can i change to slow down the Z axis to normal?

Also i have noticed that Cura heats the hot end and bed before moving back to the home position to wait? is that the same as everyone else?

Thanks
Paul

Hi Arnaud,

Yes, you can add or remove the plugin as you like. It is also possible to select a different machine, but i think you have to add or remove the plugin seperately. I'm not sure how the other settings are affected if you select a different machine, i use only one at the moment!

Cheers,

Frank

Hi Paul,

are you using the actual 057n firmware from dc42? You could also try my V2.3 settings above at this thread, this was using slower settings! 30 minutes ago i finished a print with this settings without any problem. Ok, i think the bottom layer could be printed at a litte bit lower speed.

I have also this heating issue, but it's no problem for me...

Frank

Edit: I think you could also try to reduce the Z500 value after the M203 command to limit the Z Axis speed.

Quote
Cash
Hi Paul,

are you using the actual 057n firmware from dc42? You could also try my V2.3 settings above at this thread, this was using slower settings! 30 minutes ago i finished a print with this settings without any problem. Ok, i think the bottom layer could be printed at a litte bit lower speed.

I have also this heating issue, but it's no problem for me...

Frank

Edit: I think you could also try to reduce the Z500 value after the M203 command to limit the Z Axis speed.

Hi Frank.

I am using the 057n firmware, and i have used your 2.3 settings and it worked fine. its just when i started using your new firmware put up today.
I restarted my machine and it worked like normal, i could test it by raising the Z axis up to around 10mm and then pressing the G1 Z0 command, the Z axis dropped rapidly and skipped a few steps. this is after trying to to print a file using the newer cura files.

what is the normal Z value after the M203 command?

regards
Paul

Hi Paul,

i think Z180 should be the default value!

Frank

Edit: I remember that I had also problems with the Z-Axis at the beginning with vibrations. The bearing was not fixed inside the gearwheel and higher speeds of the Z-Axis caused a heavy vibration. Now I wound a little bit of isolation tape around the bearing inside the gearwheel (the hole for the bearring was too big) and it runs smooth also at higher speeds.

Edited 1 time(s). Last edit at 02/19/2014 04:41PM by Cash.

Ok thanks. I have just set it to 50 while waiting for your reply and the Z dropped slower and more controlled. ill change to 180 anyway

Thanks Paul

Any idea on the heating before going to the home position though?

Edited 1 time(s). Last edit at 02/19/2014 04:42PM by PaulHam.

Doing this inside the start-gcode is not possible, because Cura is setting the temperatures ahead of the start-gcode. But I think at least the plugin can do the trick. I will see what I can do!

Cheers,

Frank

Quote
Cash
Doing this inside the start-gcode is not possible, because Cura is setting the temperatures ahead of the start-gcode. But I think at least the plugin can do the trick. I will see what I can do!
Cheers,
Frank

That is automatically disabled if you reference the temperature in the start code as far as I can tell ...

I've just downloaded and installed the latest Cura and Cash's latest plugin and had a look. Not done any prints yet, but I noticed that if I reference the temperatures in the start g code, Cura will not set a temperature at the start. If the temperatures are not referenced (or the lines are commented out as they are in Cash's sample ini file), then Cura does indeed set the temperatures right at the start as you say.

While the Cura version I installed is 14.01, I note that the generated G code starts with the line:
;Generated with Cura_SteamEngine 13.12"

I copied the start code from my latest Slic3r code to Cura (changing the fixed temperatures I use in Slic3r to Cura's variable names):

G21 ;metric values
G90 ;absolute positioning
M83 ; use relative distances for extrusion
M203 X6000 Y6000 Z500 E3000 ; Allows 100mm/s speeds
G1 Z5 F200 ; lift nozzle
G1 X2 Y50 F2000; Go to wait for warm position
M140 S{print_bed_temperature} ; Set bed temp
M116; Wait for bed temperature
T0 ; Select extruder 0
M104 S{print_temperature} ; Set extruder temp
M116; Wait for extruder temperature as well

This should park the head and heat the bed with the hotend cold (provided you started the print with the hotend off), and only when the bed has reached its set temperature will the extruder heat up. This avoids cooking plastic while the bed heats. That's how it works in Slic3r, and the generated G code is the same in Cura, so I see no reason why it won't do the same thing. Cura will substitute the correct temperatures for the parameters in curly brackets and not set temperatures at the start.

Edit
If you don't want to set any temperatures in the G code, I found that you can reference the variables in the start code somewhere it won't matter, and Cura won't set them.
e.g.

G21 ;metric values
G90 ;absolute positioning
M83 ; use relative distances for extrusion
M203 X{print_bed_temperature} Y{print_temperature} Z500 E3000 ; Dummy to referent temps where it won't matter
M203 X6000 Y6000 Z500 E3000 ; Allows 100mm/s speeds, overwriting dummy line above
G1 Z5 F200 ; lift nozzle
G1 X2 Y50 F2000; Go to wait for warm position
M116; Wait for temperatures


Dave
(#106)

Edited 2 time(s). Last edit at 02/20/2014 06:59PM by dmould.

are those underscores entries not cura's internal variables though Dave? I've only used it for slicing and not for running the machine, but I guess that the ormerod firmware would ignore "insert name here" style gcodes if sent as-is. Personally I don't use slicers for setting temps so I can feel in control (actually so I can slice once and run with both ABS and PLA and see who gives the best results, even though it means I need to remember to push a couple of buttons to set temps before running a gcode)

Ray

Quote
dmould
Not done any prints yet, but I noticed that if I reference the temperatures in the start g code, Cura will not set a temperature at the start. If the temperatures are not referenced (or the lines are commented out as they are in Cash's sample ini file), then Cura does indeed set the temperatures right at the start as you say.

Good to know that! Also a good workaround I think.

Frank

Quote
rayhicks
are those underscores entries not cura's internal variables though Dave? I've only used it for slicing and not for running the machine, but I guess that the ormerod firmware would ignore "insert name here" style gcodes if sent as-is. Personally I don't use slicers for setting temps so I can feel in control (actually so I can slice once and run with both ABS and PLA and see who gives the best results, even though it means I need to remember to push a couple of buttons to set temps before running a gcode)

Ray

Cura substitutes the temperatures you have set in the "print settings" tab for the underscore parameters when it generates the G file, so the print file it creates contains the right numbers and Ormerod never sees the parameter names. It allows you to change your temperature settings in just one place rather than needing to change in both the settings and the start G code (which I have to do in Slic3r). As said, if you don't want any temperatures in your G file at all, then using Cura you will have to reference the parameter names somewhere in the start G code where it won't matter, otherwise Cura will insert temperature setting commands at the start of the G file - and you cannot reference them in a comment because Cura will determine that it is a comment and still insert its own setting commands.

Of course, you can also easily delete the temperature setting commands in the print file with a text editor instead - they are right at the start so easy to find. But that's not so elegant!

I note that Cura does not appear to have any way of changing the temperature between first and subsequent layers like I do in Slic3r. I will have to find a temperature that works best for all layers, or insert the appropriate command by hand (Cura comments each layer change with the layer number in the G file, so it's not difficult to find where to put extra commands). On the plus side, Cura allows you to set a minimum layer time and if the layer prints faster it will pause so that the plastic gets time to cool between layers when printing very small features. With Slic3r, a single tall narrow column ends up as a misshapen blob unless you add something else outside the desired part that is just as tall - or print with a full height skirt. I don't know if Cura moves the extruder away from the print during such pauses between layers - if not it would not work!

I'll try a print using Cura over the weekend. I've been annoyed at times with Slic3r's failure to optimise its non-printing moves to the shortest distance, often going back and forth over a large design to print features on opposite sides alternately rather than moving to the next closest feature - on some prints most of the time is spent on non-print moves and it seems to find the longest route possible!

Dave
(#106)

Ah interesting, I thought that was output code (I should have read more carefully) -I get this in the gcode output of Cura (on the mac)

;Generated with Cura_SteamEngine 13.12
;Basic settings: Layer height: 0.24 Walls: 1 Fill: 25
;Print time: #P_TIME#
;Filament used: #F_AMNT#m #F_WGHT#g
;Filament cost: #F_COST#
;M190 S0 ;Uncomment to add your own bed temperature line
;M109 S0 ;Uncomment to add your own temperature line
G21        ;metric values
G90        ;absolute positioning
M83 ; use relative distances for extrusion
;G1 Z5 F200 ; lift nozzle
;G1 X2 Y50 F2000; Go to wait for warm position
;M116; Wait for all temperatures

(The above is using Frank's initial plugin - hence the hash signs that I think he removed in later versions for compatibility with Matt's web interface )
I set printing temperature and bed temperature to zero in the "Basic" settings tab - might not work on the PC version, (btw, in the start.gcode those temperature lines are commented by default, I think I commented out the last three lines myself)

Cheers

Ray

OK, so referencing temperatures in the start G code or setting the temperature to zero in the settings menu stops Cura from outputting temperature settings at the start of the file. It's probably in the manual somewhere :-) Ray, note that all except the first line of the output you quoted comes from the start G code that you can change to whatever you like - and Cash has since added a line that removes the speed restriction to his suggested start G code. (M203 X6000 Y6000 Z500 E3000)

Dave
(#106)

Hi Dave - I've got the speed commands (and accelerations too - which lets the speed really kick in if you don't overdo it) as macros in Repetier, so I can change them on the fly during a print (the duet still listens to the host when printing from SD or over USB, so a bit more flexible than having it in the print gcode for me),

Cheers

Ray

Hmmm - well I've done a few prints with Cura, and found that some layers are inexplicably printed at very slow speed (looks about 20mm/s or less) whilst others print at the 100mm/s I have set. That's both perimeters and infill. The parts I've been printing printing have 2 different sections, and on some layers the perimeter & infill of one section prints fast, and the other slow. I've tried setting all the speeds in Cura to 100mm/S (even the extruder retract speed!), but the slow layers still occur at random, about 3 out of every 5 layers - nothing special in the slow layers. I'm not sure at this stage whether it is Cura or the firmware that is the cause - I'll have to look into the G code, and try the same part sliced with Slic3r.

Dave
(#106)