robinmdh

if you mean the connector going to the feeder that's not connected, then yes. Inside the spool holder is a small PCB and it only works if it is in between the 2 spools (approximately), does that help? you know most NFC is only e few centimeters of detection. Extending the cable might not be the greatest idea, while it may work there was an issue about noise on that line if I recall correctly.

good Idea

did you try to unbrick the printer with the guide @gr5 posted? you can just grab the latest version of the recovery image that way you're up to date as well.

you realize anyone could be watching? those streams take bandwidth about 1-2 Mbit/s which is quite a bit, so if you have that stream open multiple times locally and add in some external viewers I can imagine some wifi problems just because of network load. here's a random UM3

ehh, since I fixed it you should know the following: There can still be another print in the queue and yes the queue uses the clean command to know when it can send the next job. you can use the webUI to disable the printer (stop sending jobs to this printer) before confirming the buildplate is clean when it is not. A successful print will not be reprinted if power was lost after it was finished printing but before it was confirmed that the buildplate was clean, this previously resulted in a reprint which was obviously wrong! A failed print (printing during the power fail) is still kept and will be re-started... so same behavior in this case. You can just manually push the bed down before confirming the print is cleaned, to do so automatically is also problematic as the bed <-> print <-> printhead adhesion may be stronger then the Z motor... The print may be stuck to the nozzle which is what keep it there, nothing else. So this is certainly is something the user will have to take care off and can't really be helped by SW.

We almost had this in the print queue (aka Cura connect) but since we have no flow sensor in the UM3 the tracking of filament position is not as exact as we'd like. For instance your printer starts grinding during a 3 day print over the weekend, after the print has failed and you come back: your roll of filament could be more than 75% full in reality but we'd be able to read close to 0% left. conversely we've had reports of the printer being empty when you have a good 1.5 meters of material left. Should we then display a warning before you send the next print? The danger is that it becomes more annoying then useful. The idea is to add it as an experimental feature. but fair warning there are about 40ish issues ahead of that one. The UM3 was always meant to have a flow sensor to augment this but due to technical difficulties it was left out :( which is why accuracy is not as great as we'd want.

would it be possible to just stick some tape to the sensor? I've used a mouse before for only the scroll-wheel and buttons and that is so ridiculously simple that it makes the software option a bit useless?

Yes Cura can use the G280 S1 as @daid said. EM-1161 was rejected when we implemented that command and created an issue to be solved by cura/curaEnigne (@bagelorb (aka Tim) was once upon a time working on this). Which then didn't happen. after they introduced the option to turn it off. P.S: super late reply because I couldn't find my password when the site changed and my browser didn't remember it for me anymore

Indeed, also I don’t think that UM has much spirit towards letting people change what they define (and of that I’m sure) Ouch, why do you think that? Change whatever you want, that why the SSH option is there we also do intend to open source a whole bunch of it so that people can change it more easily. The advantage of SSH is that there is a little bit of access implies a certain level of know how and If you know how you can probably also unbrick your printer if something goes wrong, without too much trouble. But perhaps a web UI to change machine settings, or maybe just a web based file editor with some pre-set files, so that all of the python code is accessible? This could be of use to our own experiments as well, Having spend the 5-10 minutes to set up persistent (after updates) changes to the machine json for someone else (discovering there is a annoying bug in the file parsing) recently I Feel some of what you say. Then again there is only so much time in our day. And if someone wants to build something like that before we manage to get to it I'll gladly help them. BTW: This specific movement behavior is not something you can influence that easily and the prime locations can be changed in Cura, not everything is in the machine json.

Oh, right and I forgot there is a bug that when you don't clear the "print finished, clean buildplate" message before a reboot it will come back as a "print FAILED, clean buildplate" message and after clicking OK on that, the print will indeed be reprinted. :(

@cjs, A minute or 2 should suffice. There currently is turn off menu option and with the current hardware it is dubious. (yes, the software can turn off, but then everything is still powered on, the user must then still use the switch at the back; why would you want to do both?) can you confirm then that this happens after clearing a buildplate clean message, followed by a power cycle (turning something on and off, not related to bicycles of any kind:P) We were thinking about a status indicator, telling you not to switch the machine off, but preliminary work seems to indicate this will not work with our file system.

can you maybe provide some logs? You can get those via the dump logs to USB option in the maintenance menu. Did you turn off the printer shortly after confirming the buildplate was cleared? If you do/did that, it can explain the behavior you're seeing. There will always be a chance of unintended consequences when you turn a computer of just after doing something that should be saved, this is no different. And in our case unfortunately off is just that, imediate, like pulling a plug.

Agreed, or just print via network, you can use the wired network if you don't have WiFi. Combined with Cura connect network(WiFi or Ethernet) printing is a lot more attractive, IMHO.

How annoying :( Was it a power-loss during the install? Otherwise can you tell me when you started to update, and from what version? In the mean time, have a look here. If you have a microSD card ready it should be pretty easy but you do have to remove some of the plastic covers, etc. Let us know if you run into any problems. If you can't recover the printer on your own you can always get in touch with your reseller they should be able to help you as well.

like @mastory said it's compiled into a .hex file, and it's not possible to edit those values if you only have the .hex file, you'll need to compile it yourself. Assuming you have a UM2 it is here: https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/Configuration.h Download marlin from github (then edit the confguration.h to fit) and use the arduino IDE to compile on windows (or just type make if you're on Linux) then use cura to upload your custom firmware. or have a look here: https://ultimaker.com/en/community/38154-how-to-build-marlin-the-way-tinkerghome-and-ultimaker-do-it-if-you-have-windows

your problem is different, just remove the circular paper/carboard that has the NFC tag and place that on the spool holder as proxy....

I fully agree. But @shassel asked kindly (and it doesn't hurt to rule this out). So do I, there has (for a long while) been firmware of past versions available at https://software.ultimaker.com/jedi/releases You need to download two files; both the file ending at *.tar.xz and *.tar.xz.sig Put those files on a usb stick and choose the firmware update function from the printer menu. More info on the procedure: https://ultimaker.com/...29-updating-firmware but note that this path is not tested by us! In the mean time @shassel the gcode header requirements have changed a little bit but I'm sure that @tinkegnome was also using Simplify3D in the beta of this software so I'm quite supprised... but you might need to add the the line ";EXTRUDER_TRAIN.0.NOZZLE.NAME:AA 0.4" to the gcode header... I'm also missing the header in your start gcode example, shouldn't that be there? sample valid header: ;START_OF_HEADER ;HEADER_VERSION:0.1 ;FLAVOR:Griffin ;GENERATOR.NAME:Cura_SteamEngine ;GENERATOR.VERSION:3.0.3 ;GENERATOR.BUILD_DATE:2017-10-17 ;TARGET_MACHINE.NAME:Ultimaker 3 ;EXTRUDER_TRAIN.0.INITIAL_TEMPERATURE:210 ;EXTRUDER_TRAIN.0.MATERIAL.VOLUME_USED:3629 ;EXTRUDER_TRAIN.0.MATERIAL.GUID:506c9f0d-e3aa-4bd4-b2d2-23e2425b1aa9 ;EXTRUDER_TRAIN.0.NOZZLE.DIAMETER:0.4 ;EXTRUDER_TRAIN.0.NOZZLE.NAME:AA 0.4 ;BUILD_PLATE.INITIAL_TEMPERATURE:60 ;PRINT.TIME:1626 ;PRINT.SIZE.MIN.X:9 ;PRINT.SIZE.MIN.Y:6 ;PRINT.SIZE.MIN.Z:0.27 ;PRINT.SIZE.MAX.X:129.27 ;PRINT.SIZE.MAX.Y:118.474 ;PRINT.SIZE.MAX.Z:33.87 ;END_OF_HEADER

@geert_2 as the priming can be completely controlled by cura, yes this could be done. "G280 S1" will forward the material (of the active hotend) to the point it should be just at the nozzle tip without extruding (intentionally, it might ooze, the printer tracks retracted length, which can vary) then Cura can add whatever gcode to prime in the air if needed, re-enabling the paper-clip method In the UM2 priming is done completely by firmware so there is NO way for Cura to change it, so it's not so much a setting in that case as a do nothing...

you can also switch to relative coordinates but I don't recommend using that in production gcode on the UM3 ... // G90 - Use Absolute Coordinates // G91 - Use Relative Coordinates so G91 and then a G1 Y10 would just move the Y axis back 10 mm and -10 would go forward(towards front of machine)

The Cura front end fixes the headers for normal prints (not the engine), so this might be a situation of the command line never being used so that part might be broken without anybody noticing...

you can, if you deselect everything using CTRL + up/down.

short answer: It works and nobody has asked for it to be different, so why change it? long answer: "Then the bed rises and the head moves to a point half way back on the right hand side" is one of the probe locations. And this is left over from when setting the bed level (after measuring or when starting a print using measured data or user calibrated data) could not be done at any height/location so it had to set the height that has been measured at one of the probe locations. We've changed some things in how we store/calculate the hotend height so now I/we can change it fairly easily but it hasn't been an issue as far as I know for anyone, you unique butterfly, you ^ ^ But it was one of the things I still had on my not important should still do it sometime list in the back of my head... I'm working on Cura connect in the mean time and there are bigger things missing there So please let us know how big of an issue it is?

This is an issue of some debate, the short answer is don't, just change the profile of an existing material and hope this will get fixed in the future. Previously Cura sent all the material profiles to your printer This was disabled by firmware because this could break firmware by setting the printing temperature to something unmanageable, after which people could no longer do an XY calibration print since that uses those temperatures, which by default works fine. Anyway your new material now has a unique ID (UUID aka GUID) that the printer does not know. If you set your printer to developer mode you could create a file for your material in /usr/share/fdm_materials/ (or possibly /var/lib/griffin/fdm_materials/ this is where the cura data previously ended up and would then not be erased by a firmware update, while the other location is removed on a firmware update) but note that only "generic" materials can be selected in the menu.... Have a look at the generic_pla.xml.fdm_material file as an example, find and put your GUID in there and change the name/type to match, rename the file and put it in one of those directories and let us know what works. Having given 2 ways to work around this I hope the problem is not as extreme anymore.

Yes this is a bit awkward, we realize. The short answer is there is no workaround, except for going to the printer :( From a technical standpoint the USB job does not exist inside Connect (this is because connect is a add on to the original firmware, etc) and you are aborting a job object not a printer, so it is not the printer that has an abort/pause. This seems like a mistake in hindsight, we will have to either make sure all jobs are always in Connect or allow a pause/abort on the printer level iso the job, so that the buttons always work. I'll check if this is on our list of things to fix, if not I'll add it because this behavior does indeed suck.

Only saw this topic now :( for future reference I think your printer had a power-outage that may have broken some files (delayed write on the filesystem) and this could have been fixed by following this procedure. Though that does require a micro sd card and unscrewing 1 of the plastic covers on the bottom of the printer.