tinkergnome

Yep.. : #define DEFAULT_AXIS_STEPS_PER_UNIT ... but usually you don't need this. One can set the steps per mm for each axis with gcode command M92 (and store the settings with M500 to EEPROM) This applies to the UMO and to the UM2 as well.

Done.

Calum Douglas made this for the UMO Perhaps you can seize his suggestion....? @IRobertI - i can not believe that you missed the "The Ultimaker Spacer" resp. "The Ultimaker Table" (Adobe Inventor and dxf files included).... until now... Should be easy to adapt for the Ultimaker2 - if needed?

Probably you are running into this similar bug now? As a workaround you can prime the nozzle manually with the "Move material" function (as needed).

If you Run as Admin there is. Ok, i tried it with "Run as Administrator" - same behavior. And now? You may agree that such a start is not very promising... It's a german Windows 7 and the very first dialog leads to this: ..and the output from the details section: The content of cura.log looks inconspicuous to me The tailing lines from today: Good luck!

Unfortunately, 15.06.1 doesn't work for me on Windows 7. The first dialog appears, i select Ultimaker 2 - click on 'Next' and Cura crashes after a few seconds... :( Is it a known problem? Is there a logfile on windows too? I'm afraid the whole thing is just another public beta test at the moment... and only good for scaring new customers... :(

@gr5 - you are very beady-eyed... I think it's worth to put this under a microscope...

Updates... The tinker firmware 15.07 for the Ultimaker2 is ready for testing! For a short list of changes take a look at the release page on Github. Keep in mind, that this version is only tested by myself so far - but give it a try, if you like... Any feedback is welcome.

Interesting stuff, but this branch is obviously not intended for the current printers... i read terms like: - two extruders... - experimental ultimainboard... - automatic bed leveling with capacitive sensor.. ..and some more stuff to screw up competitors...

The value is a bit weird... M92 sets the steps per mm AFAIK. I'm afraid that Marlin ist not prepared to control more than one extruder at the same time. It supports only one active extruder at a time. How did you achieved this? If i get you wrong, and the extruders are used successively - the right place for this command would be the toolchange sequence (right after "T0" resp. "T1"). But to be honest: i never used Repetier Host...?

AFAIK - there are no commits relating to the fan control - at least not during the last year... That's why i ask... I just try to enlighten the rumours that this feature is somehow dependent on the firmware version... If you're right - it isn't. Let's see, if @SandervG confirms this.

Acknowledged. ...and as a footnote: From my perspective...not in any case. Anders (for example) always makes "posts of interest" - regardless of the topic...(honestly) - and there are a few other users too. That's what the "friends" function is good for.

While reading this, a feature request crosses my mind... Can we have a "Follow this user" function? That means: get a notification for every new post of hand selected users (or "friends" - if you like) I apologize in advance if this is announced already and i missed it...

Hi Sander, a supplementary question: If i am not mistaken these changes are not published as open source yet, but it will be made available later (in a couple of months - as always). Can you attest this?

http://wiki.ultimaker.com/CuraPlugin:_XYZshift ...but read the comments carefully.

Just some personal thoughts... To make a new forum - and to make it this way - was a lonesome decision of the Ultimaker heads. Ultimaker did not asked the community and there was obviously no interest to consult the community prior to that. But hey... Ultimaker is a business concern and not our playground... The company in question made all decisions for the new forum, they pay for it and it runs on their servers. They made a change because they wanted to - nothing else. It's their forum and not (longer) ours... :( We - the community members - just have to learn to accept these facts. (finally - the Ultimaker company is the appropriate authority for support, but not the community...) On the other hand: As far as i can see - the community members are making their own decisions. I see much less activity, much less contribution and a lot of knowledge has even leaved the forum completely. I think, these are facts that Ultimaker just has to learn to accept (and to live with...). I assume, the intention was a bit different.. It's just a "lose-lose situation" for everyone at the moment. Stuff it, my life doesn't depend on this, i don't make a living from this forum. It's a pity, but it is like it is.. Like i said: just some personal thoughts - and now: hurt me...

First: i'm afraid that we relegate the UI-changes to the fringe a bit... Although i "hijacked" this thread myself (in the past), may i suggest to open a new topic for the sensor project? I must admit that i don't want to tinker with the electronics part in the near future, because i'm a little bit pinched for spare time atm... I'm afraid this whole topic will be (mostly) your turn. I will try to assist with the firmware changes if needed. If i understand aright you want to extend the "Tinker firmware" to interprete the sensor readings. It should be easy to contribute and merge these things via GitHub. The first question that crosses my mind: is it possible to detect a connected sensor automatically or will this modification require a separate branch/fork? I think, the (sensor triggered) response could be quite easy: pause the print, switch off the nozzle heater and allow changing of filament - basically: trigger the existing pause function. To answer your second question: Primarily i use Code:Blocks because i'm lazy and the project file is included in the master branch... The script package.h is used to compile the *.hex files for releases. It can be started out of GitBash and (basically) uses the existing Makefile. I'm always open minded for simpler solutions - so please keep me updated if you find one...

A few suggestions: Feeder: use as less contact pressure as possible, too much pressure will deform flexible filaments to an oval and it will get stuck in the bowden fairly often...(the |Robert|-Feeder can really be a great help with this) Slicer: switch retractions off (and accept the stringing... ) - your chances are much better this way - my experience: retractions are nearly impossible to use with flexible filaments on a bowden feeder Speed: start with slow speeds (20mm/s or even slower) - you can raise it later if it works Flow: just increase the flow rate until the lines touch each other, 130% is fairly common for flexible materials (alternatively: reduce the configured filament diameter to 2.70 or even lower) Temperature: AFAIK recommended for InnoFlex is 210-250 °C - i would start with a medium value (i don't know the specs - it was just a quick google search, so maybe i'm wrong...) a drop of oil is the "golden doorknob" - i usually use this dust filter and humidify the sponge with a few drops of sewing machine oil P.S.: diesen Thread hier hast Du gefunden?

Besser... Mein Stundenzähler ist zwar "kaputt" (Fachbegriff ), aber bei mir hält die Platte seit mindestens 300 Druckstunden durch (eher mehr...). Sie hat zwar inzwischen ein paar "Kampfspuren", das liegt aber eher daran, das (z.B.) XT und FlexiFil manchmal zu gut darauf halten... (auch nach dem Abkühlen). Wichtig scheint zu sein, dass die Druckplatte wirklich fettfrei ist - das gilt aber genauso für die Glasplatte (oder alles andere, was es so gibt). Ich wische die Platte vor jedem Druck mit Bioethanol ab. Das hatte ich "grad zur Hand", als ich mit der Druckerei anfing und bis jetzt scheint es zumindest nicht zu schaden. Also bin ich dabei geblieben. Bevor ich jemals wieder zur Glasplatte zurückkehre, werde ich wahrscheinlich erstmal die Rückseite der Aluplatte benutzen... ...oder aus Bequemlichkeit diesen hier eine Chance geben: http://www.buildtak.eu ...bisher ist aber dafür noch kein Bedarf.

Sure..., but although it is not recommended... one can use the printer without sd card... So - you would need a "fallback scenario" anyway... I assume it is not ever a good idea to use dynamic memory allocation in a firmware, but probably it has some benefits for this purpose... (just a rough idea atm...)

Regarding to the Marlin simulator you can follow the links in this post. You need SDL 1.2 and the easiest way would be to use the project file for Code::Blocks (it's included in the folder "MarlinSimulator"). Good luck!

Many thanks for the explanation, so i must admit that removing this part was not my best idea... The buffer for 10 settings allocates permanently 700 Bytes of RAM. This are nearly 10 percent of the available 8kB only for this single thing - and irrespective of the use of these commands. This topic needs definitly a close look again - i put it on my todo list... Greetings to Zurich!

Basically Marlin should be able to use any pin the Arduino offers (read and write). You have to define the correct pin number in "pin.h" and make use of the corresponding functions from the Arduino libs ("analogread" resp. "digitalread"). If i remember correctly there exists at least one unused "safety connector" with an open (unconnected) cable near the printhead....? A very nice solution would be a combination of a cheap sensor like this and these (introduced) resurrection system. Looking at your skills - i am confident...

The problem in this scenario is usually the heated printbed. As long as it stays hot and the printed object doesn't come loose it is often possible to recover the print.One can simply measure the current height and restart from there... The latter is the solution that i'm trying to achieve with this new firmware function. But once the object no longer sticks to the build platform the print is ruined anyway... I'm just a software guy and have nearly no clue about electronics, but it seems that some enthusiasts are working on filament sensors. I cannot find the example that i have in mind, but there are others here and here (for example). These solutions are perhaps a bit exaggerated for this purpose, but it looks promising.

I see... I heard that rumor too, but there are no commits on GitHub related to this (as far as i can see...). Perhaps it's completely handled by the hardware, or it's a secret firmware change that is not published (yet). I have no clue...