Daid

Testing firmware has been updated to 3.5.0 This still isn't the final release. As we are still testing and finding a few minor things here and there. The 3.5.0 changes active leveling, it changes the measuring locations to points where we are getting better results. It also measures both nozzles 3 times. All this will still being faster then before. Some internal changes make the measurements a bit more accurate. And we added more sanity checks here. There are also some other fixes and improvements, for example, we track if the hotend was "deprimed" (no more filament inserted) and then speed up the material and hotend unload processes, as we no longer need to heatup and cooldown then.

We're still in the process of testing issue EM-1222, this will improve the measured position of the 2nd nozzle, as it will do 3 measurements instead of 1.

Yes it would. As bonus, this update supports "override" files, you can put a modified .json file in /var/lib/griffin/machines/ and it will load that instead of the one in /usr/share/griffin/machines And it won't get erased on an update. As extra bonus, you can put just your overrides in there by abusing the hardware revision. If you make a file called 9066-0.json and put the this in there, you can overrule definitions without requiring a full copy of the configuration file, just your overrides. { "inherit": "9066.json", "properties": { "leveling_paper_thickness": 0.0 } }

Part of general transparency and beta testing effort, we've yesterday pushed a new Ultimaker 3 firmware to the "Testing version" of the firmware. Note that this version isn't considered stable (else it would be on stable). And we are currently still regression testing it. There are also a known bug which is quite important to know if you want to work with the latest and possible unstable firmware: Manual bed leveling does not set the Z offset between nozzles correctly. It applies the paper thickness the wrong way around causing a 0.3mm offset. Most noticeable changes: A few workflow speed improvements. Like the ability to skip the welcome setup, and tracking if the hotend is primed with material or properly deprimed. So we do not have to heatup the hotend if you are changing material and it was already deprimed at the end of a print. You can see your hotend usage statistics in the "about this printer" menu. Removed the error on starting a machine without printcores inserted (this was left over from early development) Improved XY accuracy after active leveling, position occasionally was lost due to the XY motors being off during probing. Sped up and improved the manual leveling procedure by removing the homing of the bed in between. Improved handling of G4 and M400 so we still get temperature updates in this time. Fixed the case LED http API Fixed the temperature set API Fixed a problem where printers would very rarely completely lock up. Fixed a bug where the network interface would stop for a few seconds every minute if your WiFi hardware is broken/missing. Improved NFC tag handling, both detection of tags and the user flow has improved which should result in less problems. Note that updating to this firmware is at your own risk.

http://software.ultimaker.com/jedi/Marlin-2016.10.10.zip That's the marlin as it is in the current firmware release. I see no reason why the e step change wouldn't work properly for both feeders... The upcomming release if the firmware has a "talk to marlin" feature on the printer. We're using this during debugging as well. It's a python commandline tool that runs directly on the printer. We pushed 3.4.90 to testing yesterday, this version contains the commandline tool. You can access it by logging in as "ultimaker" on ssh in developer mode. Note that this testing version has a few known bugs, of which the most important one is that manual bed leveling does not properly set the Z offset between nozzles.

System->Maintenance->Update Firmware While hovering over that menu you get the current version at the bottom of the screen. Inside that menu you can choose between "Stable" and "Testing", each of those will show a version number as well. Note that updating to the testing version is a risk, even if it has a higher version number. As there could be bugs in there.

It is marlin based. Based of the Ultimaker 2 firmware. I haven't put the source code online yet, didn't get around to do so yet. Before the FOSS people start to scream things about pitchforks and torches, if you have an UM3 and want a copy of the Marlin source. Send me a message and I'll send you a copy. Same for the linux kernel, which isn't online yet due to the size of the repository not fitting on github. (Yes, that's enough to comply with GPL, it does not state that the source needs to be online for everyone. Just that you need to provide it to people who have your product. Not doing this to be an ass. But because it is less effort right now)

Note, that you can use M142 like it currently works is actually a bug. A future release will change it into M142 with HSV values instead of RGBW. Once that version is released I will put in the details of this change. Until then, see this as a workaround.

Yes, but you are doing something that you need to be very careful about.

My original is still going strong with it's first hotend. But I don't know how many hours it has seen. It has seen its far share of abuse :-)

Printer stats will be added in the API on a firmware update. We are already collecting things, but they are not yet exposed. Currently the motor current is hard-coded in griffin/printer/controller.py

PHA might not stick to PVA? ABS has a bit of the same problem, it doesn't stick very well to PVA. It's a chemical problem, they don't form bonds. Which is why we think CPE and PVA is a much stronger combo. Our PLA, CPE and Nylon don't have this problem. (Naturally, we haven't tested every filament out there. So we can only talk for our own materials)

Having some personal experience with the "multiple tubes into a single nozzle" way of doing things that Prusa is now selling. I wouldn't recommend it. I had a hard time getting to work it somewhat reliable on a single machine with just PLA. Example of people reporting same issues: And that's besides the whole "mixing of different materials could be problematic" issue. XY offset calibration takes 17 minutes if you take instant action when required (oddly specific? we measured), in which it does a print. So that includes heating up the bed and active-leveling. The AA-BB combination comes factory calibrated right now. The AA-AA not. You really only need to do this once. One of the major things in the development of the printhead was making sure the PrintCores end up at exactly the same point in the head every single insertion. Not having the XY offset calibrated does not prevent you from printing, however, you will get bad results. So you will get a warning of you try to do this. You can enter the XY offset values directly in the menu as well, so if you want to use/develop an alternative method, that is possible.

There will be more info later on, these posts took me more time then I planned. Maybe doing one once a week would be a better phasing. And yes, resting on day 7 was a bit symbolic :-)

The motor might reverse if you put in negative E steps. But that could also break things, didn't try that. Planning to make it easier to have a custom json file. This also helps us internally on various experimental machines. I took a quick look at doing this today, but the code was a bit more complex then a quick patch.

Integrated solution. I'm not sure how much I'm allowed to share.

That's only half of the story, the sensor board is really just a pcb with copper on it. The new head PCB has the driver chip.

The core problem was mechanical. And there was no easy fix we concluded after a lot of research. So releasing that has no real use other then wasting time. Electrically it was based on the AS5048B chip. So if you get out your soldering iron, you could still build this. Cables are still in place.

Yes. In the future, M142 will change to M142 H[hue] S[saturation] V[value] I've submitted that patch for review yesterday. Will be most likely in the December firmware update. As right now, the M142 bypasses the whole system and directly sets the leds. Which means the "led subsystem" as no idea that you did that. And the API values also do not update. We are using HSV instead of RGB because that is a more natural way to work with colors. And you can dim the lights without changing the color way more easily.

Nope, no sensor to check the material movement. It is one of the features that didn't make it. (it's "feature X") We had prototypes, you can encounter remains of it in the code. But we had reliability issues with the design. And we did not want to release something that wasn't reliable. The sensor was added because it is almost free. And in the future we can use it for better temperature control as well as potential warnings when you want to print with PVA and your room temperature is too hot.

Oh, but that chip is what we are using, I forgot to mention that. Still, there are quite some differences in readings from chip to chip and day to day.

Files can be up to 600-700MB, compressed size. The file is stream-decompressed, which means it does not need to uncompress the whole file, only "line" that it is reading. So this does not add the need to uncompress the whole file on the printer. Keeping memory requirements fine even for extremely long prints. Currently there is no size check in place yet. I think Cura 2 still has some issues with files over a certain size.

The file is stored in memory of the printer, printing won't start before the whole file is there. There is no option for remote file management, as we are not storing files on the printer.

Note, the MACH3 flavor did/does exactly this.

Just made a small fix to the example script, authentication would not be saved if you needed new authenication because for example, you started to talk to a different Ultimaker3.