tinkergnome
-
Posts
2,774 -
Joined
-
Last visited
-
Days Won
61
Content Type
Forums
Events
3D Prints
Posts posted by tinkergnome
-
-
3 hours ago, lordnimon said:
3. How do I specify these limits in the JSON file?
I found out that most of the settings can have a "minimum_value_warning" and a "maximum_value_warning".
Here is an example:
https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json#L652
-
Well... you said you made a fresh install of Cura on a new hard drive and this subfolder appeared by magic - through no fault of one's own...?
Whatever: i doubt that Cura has interactive import or export functions for these kind of files.
I have no clue, where these files come from or how Cura assigns settings from there, sorry.
-
12 minutes ago, berndjm said:
But if you have a unknown model (let's take this for example, which could be a nice multicolor print with one extruder) it is much easier to scroll through the layer view and say: "o.k. at layer x is the first color change on layer y the next", and so on...
Ok, with other words - one can use the layer view as a tool to measure the model...
I had never thought to use it this way... thank's for the explanation - i accept this as a valid use case
-
1
-
-
18 minutes ago, AbeFM said:
Saying "layer number", or being more explicit about where the stop will happen, would be a huge upgrade to a useful tool
Sorry, i have an exact opposite opinion... Why the "layer number"?
If i have a need to pause a print at a certain point - i always know the exact z-position. Who cares about what layer this is?
Why should someone want to calculate a layer number every time?
The layer number will change every time i modify the layer height, but the z-coordinate is always the same - that's much more convenient, reliable and save.
If i don't know the z coordinate (for whatever reason) - it would be nice, if the layer view would display the z-position, ok, but that's it.
Perhaps i understand something completely wrong - i just don't see a use case where i need a layer number as a pause "position"...?
(all above is IMHO of course).
9 hours ago, cajodo said:But you had to enter 7.8 mm (7.95 - layerheight 0.15) , to stop at the last layerheight to enter something. Then while printing (in real life) 7.95 mm is displayed when the pause is done.
@cajodo One weird thing is, that the post processing script subtracts the first layer height to calculate the current height in the gcode. There's a comment:
# use offset to calculate the current height: <current_height> = <current_z> - <layer_0_z>If i were you - that's a question i would ask the developers on Github at the next opportunity.
-
I may be wrong, but AFAIK CuraEngine always generates (at least) one pass per shell. It doesn't matter, how thick the wall is designed in your model, it will ever have two shells (an inner and an outer face). That's not a bug, it's just the way the CuraEngine works.
The only way to get a single pass for the outer wall is a completely solid model that you slice with "Wall line count"=1 (or "Spiralize") and with zero top and bottom layers and zero infill.
That should be easy for simple geometries like shown here.
Of course that's no solution for your "single pass" requirement if your models are getting more complex. In this case you can try different slicers (or re-write the CuraEngine...
)
-
1
-
-
56 minutes ago, gr5 said:
@tinkergnome ??
Nope - i'm lost...
@CCA1 you wrote "Resources" - that's in the Cura program folder on your harddrive, right? Wait... doesn't matter: there are no predefined .cfg files in the Mark2 definition files.
If one creates a custom profile in Cura, it will get this extension, but those are not stored in the program folder, but in the config folder of the current user. And the config folder has no subfolder "Resources"...? I must admit, that I've only experiences with the Windows version of Cura, it seems to me that you're talking about something completely different....
How about one or another screenshot? That could be helpful....
-
8 hours ago, Klee said:
I need to know the line in the file wich tells the software to no check for updates, in order to disable it.
probably this one:
[info] automatic_update_check = False
-
1
-
-
43 minutes ago, Tom Herd said:
Checked both Origin at Center & Heated Bed
Are you sure that this printer has the origin of its coordinate system in the center?
That would be very unusual for this kind of printer...
What happens if you uncheck "Origin at center" in the machine settings?-
1
-
-
-
@Daid have a look at this pull request - i think it is also important:
https://github.com/Ultimaker/Ultimaker2Marlin/pull/134
The int() conversion for the second part of the term is missing - you'll get a warning about the wrong datatyp for "printf" during compiling.
I'm curious how the generated G92 command looks...?
BTW: fun fact that a few comment lines have hidden the bug until now, and only because of another bug...
-
@bradley the firmware should always wait for the target temperature of the particular extruder. You don't need to change the start script or the gcode.
The question is: what is the target temperature? It should be displayed in the upper line, if you scroll to the temperature on the display at the printer (just to be sure).
My suspicion: take sure that you use the correct definition files for Cura. There was a change in Cura 3.2, by default it initializes the target temperature of the inactive nozzle with the standby temperature now. There are new definition files for 3.2 (and upwards) in the folder "cura-3.2-resources" - take sure that you use these for Cura 3.2.
-
1
-
-
12 hours ago, Futz34 said:
I've used the default travel speed of 120 and print speed of 50. I have retraction checked but I've never seen any customized settings for this.
If you use an UM2+ with Cura, the retraction settings are configured on the printer.
I would check the retraction speed and length. In newer firmware versions you find it here:
MATERIAL -> SETTINGS -> Customize -> Retraction
For 0.4 mm nozzle and PLA the defaults are 6.5 mm retraction length and 25 mm/s speed.
-
On 2/26/2018 at 2:20 AM, Toeskneez said:
I see there is no ability to control the temp of the extruder or the enabling of extruding or retracting filament when starting a print? Isnt this a helpful tool when changing filaments and starting new prints?
Those things are depending on the selected printer, resp. the GCode flavor (this can be changed in the machine settings).
For an UM2(+): temperatures and start procedure are handled by the firmware. That's why these settings are hidden by default in Cura.
For all other printers it should be possible to change these settings at will.
About which printer are we talking and which specific settings do you miss?
Edit: i read it again... are you talking about manual controls?
-
Have a look at this thread, and please report back, if it makes a difference
-
AFAIK your custom-made scripts should reside in your local configuration folder, subfolder "scripts".
Or more specific:
$USER/.local/share/cura/<Cura version>/scriptsIf your script does not appear in the list, there are perhaps some hints in the log file:
$USER/.local/share/cura/<Cura version>/cura.log -
On 2/25/2018 at 2:31 AM, zerspaner_gerd said:
@tinkergnome kannst du für neugierige Leute erklären was da genau falsch programmiert wurde
- Für UltiGCode wird die E-Koordinate als Volumen (in mm³) generiert, die Firmware rechnet das je nach konfiguriertem Materialdurchmesser um.
- Für die "quickstop"-Funktion (M401) wurde kürzlich hinzugefügt, das die aktuelle Position nach dem Quickstop neu berechnet wird
- Leider wurde dabei der Umrechnungsfaktor für die E-Achse vergessen
- M401 wird nach Druckende (nur bei UltiGCode) von der Firmware automatisch aufgerufen
- danach erfolgt die "end-of-print" Retraction
- je nachdem, was die aktuelle E-Position am Druckende war, hat das den "Blob-Effekt" (wenn E sowieso grad auf Null steht, merkt man es hingegen überhaupt nicht)
- M25 schließt die Datei vorzeitig, dann ist der Ablauf am Ende etwas anders, das kann evtl. "zufällig" den Fehler verstecken
Evtl. kommt noch hinzu, das in früheren Cura-Versionen die E-Koordinate am Ende auf Null steht, und mit Cura 3.2 nicht mehr..., aber das habe ich nicht kontrolliert.
-
2
-
On 2/21/2018 at 8:05 AM, DidierKlein said:
Thanks @harbaum for pointing out that this topic also exists in German
we are having a user in the french community with the same issue. No real solution so far.
All we know is that it was sliced in UltiGCode with Cura 3.2 on a MAC.
Any idea from here (sorry i don't speak german)?
https://github.com/Ultimaker/UM2.1-Firmware/issues/2
-
5 hours ago, aero3d said:
I am suspecting firmware and it does not matter whether I have sliced the file using S3D or Cura, same issue.
Any ideas?
My suggestion: temporary re-install the firmware version that came with Cura 2.5
-
1
-
-
On 2/22/2018 at 5:58 PM, piphil said:
This sort of initial inaccuracy is something I've noticed before on other FDM/FFF printers. I could get rid of it by rounding or chamfering the bottom edge, but is it not possible to correct for it in the printer settings? As it's quite a common thing to see, does the effect have a name?
In Cura you can influence this with the setting (Shell ->) "Initial Layer Horizontal Expansion" (read the comments).
-
@jerooney i think the reason is this commit (read the comments):
https://github.com/Ultimaker/Ultimaker2Marlin/commit/aa89f34a056a5192923e06842e4919ceedc933fd
(the quickstop function is called at the end of an UltiGCode print)
-
On 2/22/2018 at 1:59 AM, yyh1002 said:
I’ve had some succesfull dual color and pva prints with UltiGcode which seems to have 100 degree standby temp. What temp magic would marlin do
The standby temperature for UltiGCode is a (fixed) calculated value - it depends on the printing temperature and the time of inactivity:
- after 30 seconds -> printing temp - 5%
- after 90 seconds -> printing temp * 0.8 (rounded down)
- after 5 minutes -> printing temp * 0.5 (rounded down)
- after 12 minutes -> 80°C
I don't think that this is documented somewhere, it's just not the intended use.
On 2/22/2018 at 1:59 AM, yyh1002 said:Nozzle 2 only print would need dedicated start code for Marlin flavor. I wonder whether the extruder 1/2 start code settings could do the intelligent start code generation for the two nozzles.
Interesting idea. It's worth a try.
-
That's a very old thread and a different issue. I'm pretty sure that this is a firmware glitch.
Someone on the german forum solved it by re-installing the older firmware that came with Cura 2.5 -
- resource files for Cura 3.2 (and upwards) are in a new folder on Github: https://github.com/foehnsturm/Mark2/tree/master/cura-3.2-resources
- For GCode-Flavor "Ultimaker 2" Cura does not generate the "temperature magic" - because this is quite important for dual color prints i recommend the "Marlin" flavor
- for single extrusion prints just use the stock Ultimaker 2+ machine in Cura as before (and remove the second printhead from the dock to free up the build area if necessary)
Glad that you like it - Have fun!
-
2
-
12 minutes ago, remars said:
Was bedeutet auf Marlin umstellen? ist das eine andere Firmware oder statt Cura?
Nur ein anderer "GCode Flavor". Das kann in den "Machine Settings" umgestellt werden.
Muss man natürlich nicht machen, ich wollte nur darauf hinweisen, das es eine wachsende Anzahl Benutzer gibt, die das umgestellt haben und damit Temperaturen undRetracts nur noch in Cura einstellen und die Materialeinstellungen am Drucker nicht mehr benutzen.
...und wer das so gemacht hat, merkt von dem Fehler erstmal nichts, weil die entsprechende Funktion der Firmware gar nicht mehr verwendet wird.
)
Tinker firmware - introduction
in Firmware
Posted
How do you compile it? Here is a great description from @gr5 - in case you missed it.
The "ArduinoAddons" folder is not needed for the Ultimaker firmware, i think it is a relict from the originally Marlin.
Which directions? Where does those come from? That sounds odd... whatever you have done - i would revert this step.
AFAIK "sanguino" is a hardware variant that has nothing to do with the Ultimaker mainboard.
"SdFile" inherits from "Print" ("Print.h"), which resides in a subfolder of the Arduino compiler installation (.../hardware/arduino/avr/cores/arduino)
BTW: which compiler version do you use? I use 1.8.1 at the moment, this works like it is described in the link from above.