tinkergnome

As rigs said: this are two different topics. We want to use the house for the (recently added) "Move axis" menu. And the bed temp icon is intended for the "Heatup screen" (== priming screen) - this weird thing that you probably rarely take notice of - because it's shown only for UltiGCode during the heatup stage.... :wink: Till later!

Fortsetzung: 1x Martin Hillenbrand Orange 1x Erri, farbe egal 1x Chris123, Farbe egal 1x TinkerGnome, Natur oder Orange

Correct, there is no pull request for this topic yet. I think this were too many little changes in a lot of files for a single pull request (at the moment). I consider to make several step by step suggestions (via pull request) instead. This will take some time and effort, but is probably a better approach. (and as a side effect: one can notice earlier wrong directions - and if the master it likes or not... :roll: ) We will see...

There is no explicit pushing from my side - i'm too prejudiced... David made a statement in this thread. That's not a categorically reject - i think. ...and the pm_dude seems to have more "insider" knowledge ... ?

Cool, seven at one blow... B) I think the little house is the most intuitive and deserves closer attention, would you agree? A trick question this is...isn't it...? :rolleyes: (you are right - let's put it on the virtual todo list) I hope so... - that would be the next logical step. :arrow: :arrow: :arrow: todo list... Something like the X/Y/Z Shift plugin * - but not restricted to Cura. * - This plugin is fairly old (that means... older than the Ultimkaer 2) - but with a small modification it could still do it's job - even for recent Cura versions.

Well, there are minimal temperatures defined in the firmware - could this be related to this...? Seems to be another security feature... From Configure.h: // The minimal temperature defines the temperature below which the heater will not be enabled It is used // to check that the wiring to the thermistor is not broken. // Otherwise this would lead to the heater being powered on all the time. #define HEATER_0_MINTEMP 5 #define HEATER_1_MINTEMP 5 #define HEATER_2_MINTEMP 5 #define BED_MINTEMP 5 If the printer works fine after it is "warmed up" this could be an explanation...

You are talking about the small 25mm fan behind the extruder? Then you should follow http://umforum.ultimaker.com/index.php?/topic/5442-feature-request-allow-to-turn-off-fan-behind-extruder/ There are some recommendations for a replacement.

Some iterations later... I have redesigned the new menu "Move axis". I think, reliability and user interface are much better this way. I'm not sure, if everyone will find this as intuitive as i do, but you can just try it out now. There are three functions for each axis. With the left one (the axis name) you can control the movement in both directions, with the second option you can move slowly to a specific location - for fine tuning or measuring. The function of the "home" at the right side should be obvious. ... ... yes ... i know ... i'm still not an artist... Those stuff is still a little bit dangerous, because we have the endstops only on one side and the printer is not always aware of it's current position. But if you don't forget to home all axis before any other move it works pretty save. The last commits of the master branch are also merged. We are at V15.01-RC10 already... (as time goes by....) If you want to have a look, download it from GitHub - feedback is always welcome.

I'm not David... ...but in case of Windows7 (or later) it should be a subfolder of %USERPROFILE%\.cura

I've merged the current master branch into the tinker firmware. Daid has not tagged it yet, but i think it should be 15.01-RC9. The Ultimaker masters have reduced the speed during the new filament change procedure, so this can be retested. Other changes of the master branch are described in the Cura thread. Edit: You should use the "Move axis" menu with caution - and with a hand near the power switch... I found a bug this morning - If the axis position is already known (for example by a former buildplate move) this leads to an immediate move to the zero position if you select the menu. Better avoid the move menu until the next iteration... Ok, i've added a first attempt for a "Move axis" menu. To borrow some words from master daid: still a bit experimental, but it works.... I want to achieve some sort of smooth moving (as less stuttering as possible). My poor UM2had some blackouts during my testing when i moved the encoder wheel (and the z-axis) very fast. I don't know the reason yet... Moderate moving speeds are working fine, could this be a problem with the interrupt handling...? (i have not much clue about electronics...) One can really make interesting sounds with the z-axis.... (you know it from the bed leveling wizard) Unfortunately the axis moving stuff can't be tested with the simulator, my Ultimaker2 had a lot of firmware updates this weekend... Now: it's your turn - download the new release here - comments are welcome.

In Cura there is an option "Fan full on at height (mm) (in the "Cool"-section of the expert-settings). Can you check the value (the tooltip gives a short explanation)?

You can try to "fine tune" the size of the printhead in the Cura machine settings. Cura should take this into account for the positioning if the objects (i think).

Another example: I've printed the snap-on-guide in normal PLA and all other parts in XT. Wall- and top/bottom thickness 1.2mm and 20% infill (Robert suggested this somewhere in the comments on Youmagine). More then 400 printing hours later there is nothing weak or broken. IMHO: relax...

No luck with the material name... there is no name stored for the current setting. I think, that makes sense.... After selecting one of the presets one can change the material settings at any time without the need to give them a name... Although one could store the name of the last selected material preset together with the other settings, this would break the compatibility with the stock firmware... i have doubts ... i think this had more drawbacks than benefits...? mmhhh, additional informations about the current file (if we are printing from the sdcard)... I think this could be an option in the tune menu - but i have to check the available informations from the SDCard first. If i understand this correctly, this are two similar dangerous approaches... i like the idea... somehow... At first - the possibility to move the xyz-axes with the encoder wheel (new option in the maintenance menu). Including the option to save the current position as a persistent offset to the home position. Probably dangerous and not very useful... but cool... And second - "instant tuning" of the z-position during a print (Probably useful for the fine tuning of the first layer height). This would be an additional offset to the current z-position and resets after the current print completed. We have the need to take all offsets into account during the Marlin command processing - but this would be a challenge - not an obstacle... I knew it - no time to rest for the next weekends... BTW: what about the stability of the current "tinker" release. Are there really no further issues so far...?

At first: a small update... I had broken the initialization of a new print for the RepRap flavor.... again Many thanks to EldRick for reporting (and for the test file)... again I resolve to test a new release always also for the "other" GCode flavor... again The bugfix is published on GitHub... again

Which version of Cura do you use? Menu "Tools->Print all at once" - if you don't see it you should consider to update to a recent version. BTW.: how did you find this old thread...?

This is really weird...interesting... but weird... good that you don't give up This sounds like a job for tomorrow... i will check repair this.

The fan settings in Cura are a good starting point. I suggest to carefully read the tooltips for the other options in this section too. The presets for temperatures, fan and material flow can be found on the material settings menu directly on the printer. Some finetuning can be done during a print - just use the options in the TUNE menu. A good advice seems to be to change only one option at a time and only by a small amount. During this - observe the ongoing printing process and expand your experiences... I suspect the latter we will do altogether for the next few years or so... Good luck!

A very healthy attitude...

In case of the temperatures - you mean something like "current temp. / target temp." - right? The name of the material profile can be quite long in recent versions - but this should be possible. Only display the name - or are there further intentions? A wizard for the atomic method should be possible - but this would be a little bit exaggerated, wouldn't it? Moving the printhead by hand is not soooooo complicated and you have to do some hand work anyway... ...and i have doubts if a semi-automatic temperature regulation would be so much helpful....? Anyway - it is worth an open discussion... The idea of fine-tuning the z-stage is also a little bit.... uncommon... isn't it? The axes moves are "hard coded" in the gcode file, but of course it should be possible to add an offset in any direction - if we perform a little surgery wihin the Marlin event processing... Of course this would only affect prospective moves that are not already in the command queue - but this applies to most of the other tuning options too. The question is: would it be worth the efforts? I've never missed something like this so far... Last but not least: I knew it... This was unavoidable... I thought the printing screen _is_ the screensaver...? You're right - the period of time should be adjustable, but i'm unsure about the idea of an extra wallpaper...? So far my monday meditation... Let's see!

I'm not bundled with Ultimaker - the following are only my personal thoughts...: If you're interested in such details - you can inspect the list of commits (with the detailed changes in each file) on the GitHub page. Or clone the repository and inspect the git log messages and changes from there. That's the great benefit of open source. Although...probably you will have some exhausting weeks this way... What is your intention with this? As daid mentioned earlier - you can download the current release candidate from here - for testing purposes. If you really want... you can test it and report the outcoming here (for instance). Of course you also can clone the git repository (and regularly pull the latest changes) - you will find the URL on the GitHub page. But keep in mind that this is always the current development snapshot - a somehow intermediate version, usually with it's own issues. Build instructions are on the GitHub page or in the readme file.

The firmware just reads a value from a pin on the electronics board and it seems that this always gives the signal: "endstop is pressed". You can check the cables and connectors for yourself (with the help of the assembly manual) Or just do what the displayed message recommends: contact support... Sorry - no better news...

Yep (probably). rigs has explored this issue recently. You have to downgrade the firmware (if i recognize your post correctly - you don't have done this yet?). A factory reset is not sufficient. Just use the Cura V14.12.1 and select "Machine -> Install default firmware..." from the menu. And afterwards - make a new video..

I guess it is normal. Such large objects cannot be printed exactly in the center of the buildplate because the nozzle is not exactly centered in the printhead. Otherwise the printhead would probably crash into the walls... Cura takes this into account but doesn't visualize it (AFAIK). I assume the offset you noticed is equivalent to the difference of the values in the machine settings of Cura. Take a look into the section "Printer head size". One can also say: there is reserved space in anticipation of the second nozzle...

That's the wrong approach if you want to survive 1000 years of 3D-printing... I've published the Tinker V15.01-RC7 just now: Merge branch 'master' of Ultimaker/Ultimaker2Marlin (V15.01-RC7) into geek_mode reverted to the previous variant of material loading/unloading calculation of the current flow corrected binaries removed from the repository Have fun!