Cura 14.01

I would point out that when using absolute extruder positioning, rounding errors will start to accumulate after about 500mm of filament have been extruded, until Cura issues a G92 command to reset the extruder position. This is because the Duet firmware uses 32-bit floating point arithmetic, which has only 7.2 decimal digits of precision, and AFAIR Cura outputs extrusion distances in mm with 5 decimal places. So the print quality may still be better with the plugin.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Today im having problems with Cura. It seems that extra lines are being added into the start.gcode

This is what is showing in the start.gcode in Cura-
;Sliced at: {day} {date} {time}
;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {fill_density}
;Print time: {print_time}
;Filament used: {filament_amount}m {filament_weight}g
;Filament cost: {filament_cost}
;M190 S{print_bed_temperature} ;Uncomment to add your own bed temperature line
;M109 S{print_temperature} ;Uncomment to add your own temperature line
G21 ;metric values
G90 ;absolute positioning
M83 ; use relative distances for extrusion
M203 X6000 Y6000 Z180 E3000 ; will allow 100mm/s sliced gcodes to work... if they have time/distance to get up to speed
M906 X800 Y800 Z800 E1000 ; Set motor currents
G1 Z5 F200 ; lift nozzle
G1 X2 Y50 F2000; Go to wait for warm position
M116; Wait for all temperatures





This is what it is saving to the .gcode file -
;Generated with Cura_SteamEngine 13.12
M140 S110.000000
M109 T0 S235.000000
T0
M190 S110.000000
;Sliced at: Mon 17-03-2014 17:05:44
;Basic settings: Layer height: 0.24 Walls: 1 Fill: 25
;M190 S110 ;Uncomment to add your own bed temperature line
;M109 S235 ;Uncomment to add your own temperature line
G21 ;metric values
G90 ;absolute positioning
M83 ; use relative distances for extrusion
G1 F1800.000 E-1.0
G1 Z180 E3000.00000 M203 X6000 Y6000
G1 F1800.000 E1.0
; will allow 100mm/s sliced gcodes to work... if they have time/distance to get up to speed
G1 F1800.000 E-1.0
G1 Z800 E-2000.00000 M906 X800 Y800
G1 F1800.000 E1.0
; Set motor currents
G1 Z5 F200 ; lift nozzle
G1 X2 Y50 F2000; Go to wait for warm position
M116; Wait for all temperatures

The machine goes crazy and tries to extrude filament REALLY fast

This may be due to what I found a few days ago. Whenever you change anything in Cura, or add an STL, Cura starts slicing it. While slicing, it brings up a progress bar near the top left of the render window. I didn't see this bar until I sliced a large print - it comes and goes too quickly to notice when slicing small prints on my PC. I found that if you change things while that progress bar is active, it can mess up the G code file. Did you perhaps load an STL or change a setting and then enable the plugin before the progress bar had disappeared?

Dave
(#106)

Quote
dc42
I would point out that when using absolute extruder positioning, rounding errors will start to accumulate after about 500mm of filament have been extruded, until Cura issues a G92 command to reset the extruder position. This is because the Duet firmware uses 32-bit floating point arithmetic, which has only 7.2 decimal digits of precision, and AFAIR Cura outputs extrusion distances in mm with 5 decimal places. So the print quality may still be better with the plugin.

The plugin is still necessary anyway, because Cura puts Z moves in the same command as X & Y moves, and these need to be separated.

Dave
(#106)

The part im silcing is only small.
so i know that its done working it out before i click save.

I just deleted the plugin, put a old backup in there. sliced it and it worked fine.
when i put the new plugin back in it all goes wrong.

it was fine yesterday!!

Quote
dmould
The plugin is still necessary anyway, because Cura puts Z moves in the same command as X & Y moves, and these need to be separated.

Dave
(#106)

interesting Dave - I partially printed a couple of things from Cura back in Feb before Frank did his plugin, and now you mention it, they were a little shallower than I'd expected. I just ran a plug-in free test cube with fast X and Y moves, and Z pretty much got stuck on some of the moves (depending on which direction Z was sent - I had it lifting for cooling, it lifted but didn't descend - making just a grinding noise instead).

It loos like the duet is presuming that x/y moves are mutually exclusive with Z when setting maximum feedrates, and it's leting x/y speed override the Z max speed, doesn't look hard to fix (presuming this is the only problem, and from the behaviour, it IS). It lies in this code taken from move::spin -

    // Restrict maximum feedrates; assumes xy overrides e overrides z FIXME??
    
    if(movementType & xyMove)
      nextMove[DRIVES] = fmin(nextMove[DRIVES], platform->MaxFeedrate(X_AXIS));  // Assumes X and Y are equal.  FIXME?
    else if(movementType & eMove)
      nextMove[DRIVES] = fmin(nextMove[DRIVES], platform->MaxFeedrate(AXES)); // Picks up the value for the first extruder.  FIXME?
    else // Must be z
      nextMove[DRIVES] = fmin(nextMove[DRIVES], platform->MaxFeedrate(Z_AXIS));

if instead of trickling down to Z it explicitly checked for Z at the beginning and set the maximum feedrate accordingly (ie YES!!! in answer to the question " // Restrict maximum feedrates; assumes xy overrides e overrides z FIXME??" , it would slow down X and Y for that move, but Z would be able to keep up. Something like this:

    if(movementType & zMove)
      nextMove[DRIVES] = fmin(nextMove[DRIVES], platform->MaxFeedrate(Z_AXIS));
    else if(movementType & xyMove)
      nextMove[DRIVES] = fmin(nextMove[DRIVES], platform->MaxFeedrate(X_AXIS));  // Assumes X and Y are equal.  FIXME?
    else if(movementType & eMove)
      nextMove[DRIVES] = fmin(nextMove[DRIVES], platform->MaxFeedrate(AXES)); // Picks up the value for the first extruder.  FIXME?

This logic may need to be repeated elsewhere and there look to be another couple of issues generally with the speed control (based on this-move/next-move confusion that should also be fixed, but aren't probably relevant to the X/Y/Z issue. RRP have apparently been looking at all of this for some time and dc42 has avoided move.cpp for this reason (though he did step in and fix the small-Z increment problem and the acceleration over small distances problem with a little cajolling ) maybe he could fix this too,

Cheers

Ray

Ray, from this commit [github.com] in the Duet branch of the official RRP firmware, it appears that Adrian thinks that more changes are needed than than just the one you suggest. I haven't looked at his changes in detail, I was waiting for him to finish them.

Edited 1 time(s). Last edit at 03/17/2014 04:06PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
I haven't looked at his changes in detail, I was waiting for him to finish them.

fair enough dc42 Lets hope that it performs as well as the piecemeal improvements you've made so far when it's finished

Ray

Hi Paul,

I am sorry, but I think there is something wrong if M-Codes are included in the lines that contains also X Y and Z values. I thought I changed this already!
Please try the attached version of the Plugin, I will commit the changes this evening to Github!

Cheery, Frank

Edit: Ok, I used a wrong version for the github repository, sorry again!

Edited 1 time(s). Last edit at 03/18/2014 05:53AM by Cash.

Quote
Cash
Hi Paul,

I am sorry, but I think there is something wrong if M-Codes are included in the lines that contains also X Y and Z values. I thought I changed this already!
Please try the attached version of the Plugin, I will commit the changes this evening to Github!

Thank You, that made a change



Erik

Quote
Cash
Hi Paul,

I am sorry, but I think there is something wrong if M-Codes are included in the lines that contains also X Y and Z values. I thought I changed this already!
Please try the attached version of the Plugin, I will commit the changes this evening to Github!

Cheery, Frank

Edit: Ok, I used a wrong version for the github repository, sorry again!

Thanks ill give it a go later.

Why would it start to cause problems on Monday night? When I have been using it without problems for a couple of weeks now?

Cheers
Paul

Possibly you changed something inside the start-gcode (added M-Commands)?

Cheers, Frank

No nothing. I finished printing on Sunday and everything was fine.
Got home from work on Monday and sliced a part. and realised it was going all funny on me.

hmm

Quote
Cash
Possibly you changed something inside the start-gcode (added M-Commands)?

Cheers, Frank

If you were referring to me, no change to settings in Cura whatsoever, just substituted old EAtoR.py with the newly posted one and sliced the same file again (zombies.stI)

Erik

Quote
ormerod168

Quote
Cash
Possibly you changed something inside the start-gcode (added M-Commands)?

Cheers, Frank

If you were referring to me, no change to settings in Cura whatsoever, just substituted old EAtoR.py with the newly posted one and sliced the same file again (zombies.stI)

Erik

Quote
PaulHam
Why would it start to cause problems on Monday night? When I have been using it without problems for a couple of weeks now?

I meant Paul!

I have frequently come to the conclusion that software behaviour is dependent on the phase of the Moon.
I wonder if there is any possibility that the plugin is looking at the date/time line and getting confused? Just thinking out aloud - I've not looked at the plugin code.

Dave
(#106)

I have udated the Github repository!

Hope it is all correct now! Sorry again!

[github.com]

Cheers, Frank

hey again, thanks for all the input
created the g-code KP reccomended i should try... only thing is, through force of habbit when i opened Cura today and there was an update available (14.03), i clicked ok and installed only to realise after it may cause problems with the plugins created for this... -.- .. such a melon sometimes...

before i opened the new version of Cura, I dragged the;
current_profile.ini
Prefrences.ini...
files to the new 14.03 file (the plugins folder remains the same even after the update)


still this resulted two different g-codes.. any thoughts?
going to try to print each..

Edited 2 time(s). Last edit at 03/20/2014 03:53PM by 88Zombies.

Quote
88Zombies
.. any thoughts?..

Not much ;-)



Erik

Nope didn't work, did the same as before

As soon as I click print it, the feed tries to move (retract I think) before it's even attempted to heat.
There is a seriously loud sqealing sound.
Then I panic as it sounds like the printer is going to blow up so I jump to switch off at the mains..
This happened with both the geodes attached above..

really want to print off cura, can't get decent enough supports of slic3r

Well, your problem is here:

The line

M203 X6000 Y6000 Z500 E3000 ; Allows 100mm/s speeds

is getting mangled by the plugin to

G1 F1800.000 E-1.0
G1 Z500 E3000.00000 M203 X6000 Y6000 
G1 F1800.000 E1.0

That is a 3 metre extrude at high feedrate, it'd make anyone squeal.

Make sure you have the latest version of the plugin here, the easiest way to get it is with the 'Download ZIP' button in the bottom right corner.


Kev.

Something is funky. As mine did exactly the same. I had to revert back to a older version of the plugin to fix it.
Haven't updated to the newest version yet though

I think Frank may have accidentally uploaded an old version to GitHub as the version I made my change to had the fix he made here already.

I'm having little success with this.

Randomly, it just starts extruding in mid air 5mm above the print bed. Stopping and restarting the job fixes it.

When it does work, it's leaving large blobs everywhere which the nozzle just smears all over the place. I must be missing something here as other people are having success.

Using the plugin and settings from GitHub.

Hi again,

I'm so sorry, I found out that i did made another bug! I don't know how my tests are passed! I did only a quick view on the generated g-files and they looked correct, but today I looked again and I have seen a problem. I think the original plugin was still in the buffer at my last testing or so.

Please try the actual file on Gitub: https://github.com/Cash70/EAtoR

Sorry for any inconvenience, unfortunately I have no time at the moment to test it on the real hardware. So any feedback will be highly welcome.

Cheers, Frank

Aha... I deleted Cura 14.03 and found 14.01 in the 'old versions' section.

Printing is working fine now - so it does look like something may be broken in 14.03.

I like Cura - the GUI is really nice, and the printing seems a lot more 'intelligent' with far fewer unnecessary movements - in particular when filling. The 'combing' feature is neat to watch.

Not sure if I am doing things correctly here but here goes.
I have printed successfully using SlicR3 for the few weeks I have had my Ormerod.
I am beginning to try and print models that require Support.
I have found that SlicR3 creates support built of concrete!
I read somewhere on the Ormerod forum that Cura produces support that is much easier to deal with.

I thought I would try Cura but I am having problems trying to print the resulting gcodes.

I have downloaded Cura 14.03,
downloaded Franks Ormerod plugins and copied "current_profile" and "preferences" to "programs/Cura_14.03/Cura"
copied "EAtoR" to "programs/Cura_14.03/plugins"
Made sure the EAtoR plugin is enabled. It is showing a "Retraction at layer change (mm) of 1.0.
Loaded a simple file - I am using the 0.5mm-thin-wall.stl calibration file.
and then saved the GCode.

I then loaded the gcode file into my Pronterface and got the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the print goes from 999999999.000000 mm to -999999999.000000 mm in X
and is -1999999998.000000 mm wide

the print goes from 999999999.000000 mm to -999999999.000000 mm in Y
and is -1999999998.000000 mm wide

the print goes from 0.000000 mm to 15.000000 mm in Z
and is 15.000000 mm high
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think the stl file has an actual size of 16 x 16 x 10.

I am assuming I have set Cura wrongly somehow or forgot to change something.

Can anyone help

Thanks
Tim

Quick update on my previous post
I just noticed that Frank had posted an update a couple of days ago.
I loaded those to the appropriate places and now get the following in Pronterface:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3.0 mm of filament used in this print

the print goes from -20.000000 mm to -20.000000 mm in X
and is 0.000000 mm wide

the print goes from -20.000000 mm to -20.000000 mm in Y
and is 0.000000 mm wide

the print goes from 0.000000 mm to 15.500000 mm in Z
and is 15.500000 mm high

Estimated duration (pessimistic): 1 layers, 0:00:01
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As before, any help gratefully received.
Thanks
Tim

Hi,

It looks like Cura 14.03 has changed the headers ( [profile] to [profile_0] ) and ( [alterations] to [alterations_0] ) in the "current_profile.ini" file and therefore ignoring the settings. Changing this headers would help, I think.
I have changed this in the attached file! By reviewing the generated gcode file it look ok for me now with Cura 14.03. Could someone please test it on the real hardware?

Cheers, Frank

Edit: Please use the other 2 files from the github repository https://github.com/Cash70/EAtoR . If it works I will move the files to Cure version specific subfolders!

Edited 1 time(s). Last edit at 03/25/2014 12:42PM by Cash.

Hi Frank

Either I am missing something here or I am going mad!

Downloaded your files from Github; placed them in the appropriate Cura folders and tried again.
Still got the result following result in Pronterface.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the print goes from -20.000000 mm to -20.000000 mm in X
and is 0.000000 mm wide

the print goes from -20.000000 mm to -20.000000 mm in Y
and is 0.000000 mm wide

the print goes from 0.000000 mm to 15.500000 mm in Z
and is 15.500000 mm high
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I then checked the contents of the current_profile in the Cura directory and it had profile_0 and alterations_0. I changed these (taking off the _0) and tried again. Same result.
I looked in current_profile again and again it had profile_0 and alterations_0.
It seems to like changing profile to profile_0 etc.

So this time I copied your current_profile file and renamed it "my_profile.ini" and then loaded it from the drop down menu. Success in the sense that It loaded and it did not change profile or alteration line by adding a _0,
but then saved the gcode and this was the result in Pronterface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0 mm of filament used in this print

the print goes from 999999999.000000 mm to -999999999.000000 mm in X
and is -1999999998.000000 mm wide

the print goes from 999999999.000000 mm to -999999999.000000 mm in Y
and is -1999999998.000000 mm wide

the print goes from 0.000000 mm to 15.000000 mm in Z
and is 15.000000 mm high

Estimated duration (pessimistic): 2 layers, 0:00:10
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I tried moving the model around in the Cura "bed" but got just the same result.
This might be me and my use of Cura though rather than anything wrong with your files, I am no expert just a dangerous amateur with little knowledge.

Would you like to see the gcode file?
Tim