tinkergnome

Me too... :( My favourite "topic" view gives me a 404... https://ultimaker.com/en/community?topics=1&sort=latest&type=all ...and a click on the "Topic"-Button (from Category view) shows the blue circle forever... (...until the browser is closed...) (i tried it with Firefox 41.0.2 and IE 11)

Hi jeex, haha, this sounds a bit like a motion picture.... jeex eleven, jeex twelve... to be continued... Is Python included? You could try to reawaken the Cura plugin XYZshift - this would be very convenient ... afterwards... Or use Simplify3D and set the global offsets on the gcode tab... very convenient too... but not free....

Actually it's a firmware bug... I think the heater timeout prohibits USB printing at the moment. The (temporary) solution was to disable the timeout in the preferences. Who has programmed this nonsense? ... ... ... oh ...

Assuming that everything else is the same as before (esp. the gcode file), this indeed should not happen. Best would be to report a new issue on the GitHub page. You can attach additional files there. Though you would need to create an account first (it's free).

The best way should be: Go to support.ultimaker.com and submit a ticket to the sales department. They will make you an offer. You can find the part numbers in the BOM

Ok, it was i simple fix. The M42 command works like intended now. Here is the updated release of the tinker firmware. You can install it with Cura 15.04 (Machine -> Install custom firmware...) I also made a pull request for the standard firmware, but there was no activity for months - so this may take some more time...

AFAIK the last output is already the best approximation. But if you want to do some fine tuning, you can start the autotune several times (even with different target temperatures) and take the average of these.

I found some time today and made a short test. I can confirm that this command does not work properly. Your printers hardware is ok and Octoprint too, i'm pretty sure that you found a bug in the Marlin firmware. Honour to whom honour is due. I will take a closer look at it in the next days and fix it for the tinker firmware. Which firmware version are you using?

You should reconsider this - you are missing a lot of funny stuff.... Maybe coming soon... Until then - stick to pronterface and start the pid autotune by hand.

My suggestion: use the one from |Robert| - same benefits but more convenient to use. I use it from the first day on and never noticed any drawbacks.

Hi bob, i'm far away from being a feeder expert... but IMHO - you're actually heading to the right direction with the 38mm yoke. Regardless of the used feeder chassis the rule of thumb should be: put as less pressure on the filament as possible - respectively: put only as much pressure on it to avoid slipping - but keep the deforming of the filament as small as possible. The latter is even more important for flexible filaments. Regarding stringing: The heating zone is a bit longer on the Olsson block - i can print approx. 5°C cooler than with the stock one (same material) and i changed the retraction settings to 5.10mm at 35mm/s. That works great for me - but you probably have to experiment a bit with these settings. Don't give up - it's worth the effort! Edit: as a small addition - If you want to use flexible filaments: do yourself a favor, disable retractions and accept the stringing - any success with FlexiFil, a bowden setup and enabled retractions is very unlikely...

Looks like the screw of the ballbearing touches the wall. I think the "Yoke" is mounted in a wrong way? The screw head should facing you (if you look from behind the printer) - it's screwed directly into the plastic on the inner side. The screw hole is a bit smaller on one side - no nut needed. All other things are looking ok (to me) on the picture. ...but open the latch (and the arm) to feed material (by hand) - it's much easier. BTW: consider to upload your photo here (to your album) - those picture services are a bit annoying...

That's ok - you owe it to your printer to take a break from time to time. Now i have a reason to order a second extruder motor for myself... let's see... the christmas holidays are near...

mmmmmh, it seems so... I've only made dry runs, but Guglielmo (@gpb01) was (apparently) successful with it in real life... I think the tunell sensor is surprisingly expensive, but i probably could take a fancy to the tiny cheap optical sensor... Connect the three wires to the Ultiboard (EXT I/O aka J23) like here and you're done: Mmmhhhh - personally i think it's cheap enough to give it a try...

Hi tinkerers an printerers..., the October release of the tinker firmware is out now, the latest changes are: support for filament sensor on pin PC7 - see above revised menu for the motion settings, additional menu for axis steps/mm for the dual extruder version: swap primary/secondary extruder I could not test the first by myself, but i trust Guglielmo, that it works... The latter is also not tested in real life, because i don't have a dual extruder setup. If anyone has a need for it - please try it out and share your feedback. @ultiarjan - i count on you... That's it. A few pictures for illustration:

Hi Reiner, as far as i can see it goes in the same direction like discussed here lately. It monitors a specified arduino pin and enqueues a "M600" if the input is pulled down to LOW (by any sensor). That would be not a major change - i think. But there is no activity on the UM2 Marlin repository since July... personally i would not expect such things in the near future...

There are quite a lot of hard coded positions to consider... You will find the start position for the change filament menu in UltiLCD2_menu_material.cpp and for "Insert Material" in UltiLCD2_menu_maintenance.cpp, the x/y-position of the pause function in UltiLCD2_menu_print.cpp and several positions for the buildplate leveling wizard in UltiLCD2_menu_first_run.cpp If the print area is reduced you can also modify the appropriate values in Configuration.h A possibly easier solution is to switch over to the tinker firmware - the print area is adjustable without recompiling and it takes care of the customized min/max values for all those positions.

Actually LED_PIN is 13 on the UMO board and pin 8 (PH5) for the UM2... ...but never mind - the LED_PIN is the default for the M42 command. You can omit the pin number and everything between "M42 S0" and "M42 S255" should work with every Marlin version out there...

First: i like your design of the fan shroud anyway. ...but... i made some simple calculations... and the result is: i have to regret your reality... The distance between the side walls of the UM2 frame is 326.2mm (by design), the max. print area in x direction is stated as 230mm. At least at the time i bought it (230 x 225 x 205). Edit: I saw that this little detail has changed lately - now it's stated as only 223mm in x and y direction? Just another disappointing act from the Ultimaker marketing in my eyes... BTW: 230 x 225 x 205 is still the default area for the machine settings in Cura...? That means: Any fan mounting that exceeds a size of 96mm in x direction reduces the print area. It's not a big deal in my opinion but has to be considered thoroughly.

Arjan - calm down... The printerfan owns an UMO.... or do i missed something? If fiddling around with the gcode doesn't work - is swapping of the cables an option?

Auf dem letzten Bild hast Du doch eh' schon eine andere Firmware drauf... Lass das mal so, das sollte trotzdem funktionieren... Dein Hardware-Setup kann ich natürlich nicht nachvollziehen, aber im Simulator funktioniert Deine Datei. Ein bisschen unschön ist, das beide Extruder die ganze Zeit auf der hohen Temperatur bleiben, das können andere Slicer (glaube ich) besser. Aber Starten sollte der Druck trotzdem erstmal und auch bei verstopfter Düse sollten die Motoren zumindest den Versuch unternehmen, sich in die richtige Richtung zu bewegen... Im Moment hilft nur eingrenzen...: erste Voraussetzung wäre mal: Du druckst die Datei von der SD-Karte, über USB funktioniert das so nicht wird der "UltiGCode" korrekt erkannt, oder bekommst Du nach der Auswahl die "Classic Warning" ("...will override machine settings...")? sind die Extruder nach dem Start des Druckes auch wirklich auf der richtigen Temperatur? (bei unter 170°C hättest Du genau den beobachteten Effekt)

I borrowed some code from @NBroenner "filament_sensor" branch and published a test release right now. The compiled hex file monitors the PC7 input pin and triggers the pause menu if it is pulled down to LOW (during printing from sdcard *). Resuming the print is done manually via the menu. This version has survived a 3 hour print (without a connected sensor of course) - so at least the idea with internal pullup resistor seems to work pretty well. @gpb01 - now it's your turn! * during printing via usb one could probably also pause the print - and resume automatically if the state goes back to HIGH - but this is not implemented (yet).

Search for "extruder_swap_retract_length" - it's hardcoded to 16mm in Marlin_main.cpp... ....and can be modified only during printing (Tune -> Retraction -> Extruder change len). You should be able to modify it during the heatup stage to examine if it makes any difference. Oh...and it is only used if the gcode contains firmware retractions like this: "G10 S1". The postfix "S1" triggers the "extruder_swap_retract".

Hi Guglielmo, that's nice - i read about this months ago and couldn't find it anymore... now i have back the link It sounds like you have already bought one of these? Have you already made some explorations with it? It's basically the expensive (but complete...) version of the thoughts that Nils recently had (@NBroenner). He already discovered the right mapping for these pins on the ATmega2560 - it should be PC7 = 30; PD7 = 38 Setting the pinMode to INPUT_PULLUP and detecting the LOW-state sounds pretty simple and should be possible without harm to other users... like me.... I'm inclined to give it a try... @NBroenner: I think, this behaviour should even be compatible with your idea - because both sensors use the same pin with the same intention (your idea is a lot cheaper of course...). What do you think?

Just an idea... wouldn't it be easier to avoid UltiGcode for this kind of application? Personally i would add a new machine profile in Cura, set the gcode flavor to ‘RepRap‘ and change all temperature settings to zero. That should be all that's needed to skip the heatup stage at all, shouldn't it? The 'avoid cold extrusion' feature kicks in and prevents movements of the E-axis - actually a nice spin-off in this case... While you're at it: consider to deactivate combing and enable z-hop while retracting. @ultiarjan - i'm not sure with the latter - would this even have any effect for this use case...?