tinkergnome

Mmmhhh, i'm wondering if there are potential mechanical issues with sdcard slots that have to maintain permanently "hop on - hop off" of sdcards...? Will it last ...forever... or will the flimsy "springy mechanical thing" give up sooner or later? Which one lasts longer - the PC or the Ulticontroller... There's always a way to find a reason... Doesn't matter - i'm still curious if it works...

The short answer is: The Arduino is just a schmuck - a poor devil - it has not enough resources (especially: RAM) to sort the folder content on the fly. Don't forget: it's still just a microcontroller without a huge operating system in the background... I found a good explanation of the FAT32 sort order and a possible solution at this code project site. Google says: there are quite a few (ready to use) tools out there that can sort files on the USB stick or the sdcard - but this depends on your OS and would be an additional step in the workflow. Maybe it's worth a feature request for Cura?

After a short look at the available gcode commands, i assume that the tools you need are already there. - Connect to the printer via USB - Create a new file on the sdcard with M28 - Send the content of the gcode file line by line, Marlin will write it to the file for you - Close the file with M29 - Select the file with M23 - Start printing from sdcard with M24 - Disconnect USB Test it with pronterface and a simple file content (e.g.. G28 ) an see if it works. Report the result here. For convenience: Write a script that can do these steps at once. Done.

Assuming you are using Cura 15.04, you should take a look at "File -> Preferences". Remove the base path (leave it empty) and it should act like in older versions of Cura. (i don't know if there is an equivalent setting for the "new Cura")

The latter (more or less..). It resides out there as a simple spacer between two other parts (wood and aluminium) that are mounted together with screws. There's a little bit of pressure but no mechanical motion. It simply does the job and is very uv stable - still black and shiny like on the first day.

At least i can confirm that Colorfabb XT (black) was able to survive the last summer without any deformation or visible degration. Continuous outdoors and exposed to the sun since April (and the summer was fairly hot in Europe this year...) I recommend to give it a try...

At least this part should be pretty easy - it will need a tiny bit of reconfiguration and a recompile, but i'm sure you can do it! (Or send me PM if you need help with this...)

We are talking about an UM2, don't we...? I somehow cannot bring together the two terms UM2 and Ulticontroller... The UM2 firmware menu has no options for the steps/mm, but pronterface and M92 can do the job.

I appreciate your bravery... First - there are menu options for "Preheat ABS", "Preheat PLA" and "Cooldown" on the Ulticontroller (of the UMO) - and some of the veterans missed it on the UM2. Basically it's a "shortcut" to "Heatup nozzle" and "Heatup buildplate". Especially heating up the buildplate can take a while before a print starts and there are quite a few experienced users that have integrated a "manual preheat stage" in there workflow already for example: select "Advanced -> Heatup buildplate" turn the encoder wheel until the favored target temperature is displayed go back and select "Heatup nozzle" again turn the encoder wheel to about 180°C take the sdcard out of the slot and went over to the computer slice the desired object and save the gcode to the sdcard after a few minutes: go back to the printer, insert the sdcard, select the file ...and the print starts in a few seconds because the target temperatures are almost reached The new "Preheat" menu is just a more convenient way to pass the first four steps. If it does not match your workflow - just keep on ignoring it... Hope that helps...

Actually - there are such limitations too. The Marlin firmware on Arduino can open only one file at a time for a reason. Each file access needs a separate buffer and memory is pretty scarce already (is this the right word...?). And keep in mind that you would have to backup (and restore) all axis positions, the current print settings and the file position too. In addtion: if you're using the heated buildplate the print is ruined anyway, if it cools down on a power fail. At least some thoughts about a resurrection system are existing, here is an example. But this also implies that the printed object does not loses the adhesion to the buildplate. My conclusion: Probably saving the printer status is feasible this way, but the whole effort is useless if you're not able to keep the buildplate hot...

At least it is intended this way... BTW: this applies also to the parking position (during pause) and the positions of the bed leveling wizard. And keep in mind that the x/y "home" position is x_min / y_max if you calculate the values.

Updates... I have published the 15.09 release of the UM2 tinker firmware. The most visible change is the advanced main menu. It has now room for the new preheat menu and the most used material options. The preheat menu needs a bit of explanation: The "circles" are switches to switch the heating of nozzle and buildplate on and off. The target temperature for the buildplate is copied from the selected material setting. The heating of the nozzle is switched off by default - if you switch it on the (pre-) heating of the nozzle starts if the buildplate temperature has reached a value of (at least) 10°C below the target temperature. The preheat temperature of the nozzle is calculated - depending on the material setting. Default is 80% of the material temperature (rounded down). Also new (probably useful for other tinkerers...) The print area is now adjustable without recompiling (Preferences -> Print area). Be careful with those changes... and don't forget to relevel the buildplate if you change the max z position... As always: give it a try if you like - but on your own risk... Comments are welcome - here or on the github page.

with regard to the primary question: I've never printed via usb, but it seems that you are trying to print without a proper start-/end gcode. I don't know how usb printing is handled by the new Cura, @nallath should be the insider... For example: the gcode flavor "UltiGCode" is only useful if you print from the sdcard. Maybe that could be an explanation?

Hi Duke i'm afraid that the 5V connector is just what it's name says... a 5V connector... Perhaps there is a spare 12V source somewhere that could be accessable with a little help of a soldering iron or such things... I think there are some electronic engineers here on the forum - perhaps with some helping ideas...? Regarding the firmware changes: There are some links in this page for a (probably) more convenient development environment. The min/max positions are defined in Configuration.h but this is only the beginning... There are several (hard coded) x/y positions for the bed leveling wizard, the change material wizard and the heatup position. The challenge is to find and adjust these positions accordingly... Arjan (ultiarjan) is already on this path - there are posts about this one or two pages back in this topic. There are also some good news about this: I have already done most of the work for you... There will be a new release of the tinker firmware in a few days. It will have a simple preferences menu to adjust the print area. If you can wait until next week... this would probably be a better starting point.

AFAIK these are changes of the Marlin development tree. Those things are not ported to any of the Ultimaker firmwares. Neither for the UM2 nor the UMO. And i don't expect that this will ever happen...? Anyway- the main idea seems to be: limit the acceleration to the minimum allowed value of all moved axis, right? The (old and new) code looks a bit over complicated..., perhaps the developers tried to optimize it for performance or such things...?

So - you changed the default settings and compiled it into your firmware. That's not wrong, but those settings are stored in eeprom and can be changed via gcode commands. The new defaults will only be used after a "Factory reset"...

Your're quite insistent, aren't you? Solution1 is obvious - use Cura 15.04 for now (GCode flavor is editable in previous versions of Cura) - and jangle Nallaths nerves until it is integrated in the new version... Solution 2: Add the "Ultimaker Original+" as printer and generate your gcode with this one. Solution 3: edit the settings manually - find the file ".../resources/settings/ultimaker2.json" and change "machine_gcode_flavor" from "UltiGCode" to "RepRap (Marlin/Sprinter)" Pleased? Edit: i'm always too slow...

@ultiarjan some news: I finally found the issue (heating the unused second nozzle). The fault was on my side... I still have to make some more checks - i will upload it to GitHub in the next days - i will inform you. Regarding the "hard-coded" positions: I think the best way would be to make all those X/Y-coordinates (bed-levelling and heatup positions) relatively to the MIN / MAX_POS constants in "Configuration.h". This would significantly reduce the amount of needed modifications on your side, wouldn't it? And last but not least: It should definitely work with TEMP_SENSOR_2 = 0 ...except you are using HEATER_2_PIN somewhere in your code (but this is intended for a third extruder...)

1. The flickering of the led seems to be a rare issue on some models of the printer if the buildplate temperature is PID controlled - i have no clue about the reason but you can switch it back to bang-bang mode (preferences). 2. Actually it are 5mm... The reachable y range with the stock firmware is 5 - 230 - if you try to use y coordinates between 5 and zero the printhead just bumps into the front panel - i thought this is rather confusing and changed it to 0 - 225. But you're right - this breaks the compatibility with the stock firmware. I will change it back with the next release.

@ultiarjan I'm back on-line (yeehaa!) - but still a bit short on time... I tried to reproduce the heatup issue with no luck. Seems that i miss something... Could you share the gcode, perhaps this can speedup the search. I think you have my email address already? The nozzle heater starts when the buildplate temp. reached a value of 10°C below the target temp. That's intended. And only the use of UltiGCode leads to the extra heatup stage before the print starts. The conditions that are used to decide if the printing temperatures are reached are only checked inside the (boring) heatup menu - but not in any of the tune menus. That's the reason because it stucks there. It would be quite a bit of work to change this - i assume that's the main reason why nobody has done it yet...

Cura never reduces the printing speed below the "minimum speed" setting, no matter of the value for the minimum layer time. "Cool head lift" affects the surface quality too much (speaking from my own experience). Probably the best solution is - as neotko suggested - print more then one at a time and use a nozzle temperature from the lower end of the scale.

I made a short check just now. It's working like expected in the simulator (since i don't have a second extruder i cannot test it any further). Did you sliced it with Cura (UltiGcode) or something else? Using UltiGcode: the first comment lines are important. A non zero value for MATERIAL2 switches on the second nozzle. If in doubt - can you share the gcode-file (send me a PM)? But keep in mind that i'm moving to a new appartment this weekend - so probably i'm not very responsive - my online connection has to move too - let's see how that works...

I "borrowed" these lines from daids script. TEMP_SENSOR_1=20 EXTRUDERS=2 That's all.

It's called "PREVENT_DANGEROUS_EXTRUDE" (follow the link for an easy workaround)

Really...? So many boring digits... Just to be sure... You're talking about the "Heatup nozzle" and "Move material" functions? Since you love those boring numbers... - i think it would be nice to combine it a bit (either both settings on a single screen - or easy to switch without the need to leave the current menu...) What do you think?