robinmdh

Sorry but that does not seem very well though out: 49% so far... (from those that have chosen to share statistics) (you can't see future statistics anyway so that's like saying we should never have gone to the moon because we wouldn't be back for decades afterwards anyway, how did you know? besides it's still very early for this feature) Being able to click print anytime and have my printer remember/continue the queue is a huge benefit not counting how many printers you have. What on-line environment? This is all running on the printer, the printer does not require an Internet connection. The maintenance logging is not the main feature here, or is it? Though to be honest, do you think everyone is aware of how often you should do which things? I get that currently Connect is missing some features (though I don't think this is the worst, by a long shot) but come on and stop bashing it because you miss one tiny feature and don't have a use for one other tiny feature... Bringing the pre-heat back at least for one printer setups seems very feasible though, I'll add it to the list.

Well here is the windows 3.0.3 Let us know what happens and if no Cura dev comments I'll pass it along!

You can remote control the printer by using the API but I've noticed X and Y control are specifically broken ATM, probably since nobody is using it (Z works fine). I'll was thinking about adding a web-page with a jog wheel to play around with sending motions since it's still requested occasionally, but that would still require authentication atm. But Octo-print for a UM3 would be a step down IMHO, no queue, no high speed serial link, no certainty of transmission of gcode, etc. And the serial output to marlin should only be touched by one program at a time... Currently the easiest way to move the X and Y around manually is: Set your machine to be in developer mode in system -> maintenance -> diagnostics -> developer mode (this also opens large holes in whatever security measures the machine has) use putty or ssh to log in to the machine with the usename/password both as ultimaker in the (cmd) prompt, type sendgcode to make the printer move if you send the Gcode: G28, followed by G1 X100 you move the head to the ~middle of the X axis.

you're a bit(years) late, though you can grab the 15.04 version of Cura :)which is the latest and last version of this particular flavor of Cura. We've moved on to something a little different in the meantime though, try Cura 3.0 ? If I were a moderator I might complain about necroing threads but I just think it's funny.

Hey Flyntm, Actually Cura connect is a huge time saver/convenience when you only have one printer IMHO. But even then most of your temperatures are still reported within Cura, Just Click on the printer in the monitor tab.

The only times I've used that was during development to test something, or to visualize gcode and when I strapped a USB microscope to my UMO So I'm just curious, what do you use it for?

I hope you'll take another look at Cura connect, the having of a print-queue makes even one printer a lot more productive IMHO. and I think you'll agree if given the chance because it fits a lot better with your time problem https://ultimaker.com/en/community/51699-what-time-is-my-print-finished You can send your print when you have finished slicing, not when your printer has also finished, then you can already slice something else, etc... P.S: You can also downgrade the firmware on the printer, then the new Cura keeps talking to the old printer in the old way.

So far 94% percent of people using Cura connect (and sharing anonymous data) only have on printer in their cluster, so that might be the way to go indeed. Then again the installed base on the printer is not really big enough to know that for sure.

Uhm... that could mean it would heat for hours being idle? What about energy efficiency? TL, DR: No, I disagree, this is largely dependent on the implementation. If a user presses a button it does not mean no energy is ever wasted. But then that's why we're still discussing it.... and not have already done it. And of course there will be some for who this is completely undesirable and would want an off switch. So there would certainly be an opt out. Pre-heat can timeout in a set time in seconds. and Cura connect can report it's slicing every x seconds. So please ask yourself this, are you tweaking your print in Cura for hours? or are you designing, slicing finding something wrong and then spending another 10+ minutes designing, then tweaking your print a bit more in cura at the end? If we are only heating up while slicing and tweaking the slice there would not be so much time waste depending on how long/frequently Cura(connect reports) to the printer that you are (still) slicing. So that would heat it for seconds to minutes incorrectly, definitely not hours, at least for the use that I've observed. On the other-hand if we make a button, and then a (matching or random) printer gets pre-heated, after-witch you change your print properties which causes it to be printed on a different printer is not a loss of energy/efficiency? But perhaps before arguing points and use cases we should see if we can answer this question by looking at the usage statistics of Cura, I'll ask @nallath if we can see the required information. In conclusion: It's not that simple, since you can have N printers now you have to do something to decide which printer to pre heat anyway, this can be wrong depending on when that is sent. AFAIK the pre-heat is also not used much so it makes sense to automate it so everyone gets that efficiency increase except only those that know to press a button at the exact right time with the right set of materials selected, etc.

it does indeed look like a CAD issue, use a boolean operation to merge all objects into one... Cura sees the walls of your 2 objects separately and since they then intersect weird stuff happens in determining what is inside the print and what is outside. Interesting to see that it's a mixing nozzle, what are you mixing? we have someone here that prints those as well.

Perhaps have a look at the new Cura connect feature! you probably already have it on your printer... (you also asked about the pre-heat, I think this means you have firmware version 4.0.1 or up) Because it tells you this with at-least some amount of accuracy on the webUI running on the printer and on the monitor tab in Cura.

Well we have the Cura Connect now and it becomes far more complex once you can have N amount of printers you might pre-heat, and not just one. So it was lost due to our product owner finding features like "move job to top" more important. We do plan to reintroduce it but make it automatic, or at least we are discussing it. (while you are slicing and adjusting settings your intent would be to print, so we could then already heat up the printer closest to matching your configuration)

There is not an easy way to do this, the workaround requires enabling the developer mode (this makes the printer very insecure). And then using the Linux command line, here is some guide for using connman to do this: https://communities.intel.com/thread/60242 There are some more people struggling with this though: https://ultimaker.com/en/community/50136-configuring-static-ip-address-for-wifi-connection or https://ultimaker.com/en/community/27035-how-to-set-ip-address-without-wifi-or-dhcp So please consider if configuring a static DHCP lease is an option instead.

Authorization is give on the remote printer's screen. the request for authorization receives an ID and KEY this is stored on both printers and when you click OK on the remote machine this is saved as an authorized user (see /var/lib/griffin/http_api_users.json) When you only have one printer it should already automatically be added to cura connect though, since the software controlling the printer is then running on the same machine as cura connect no authorization is required.

I think there were a few pins missing on the original board, It was a while back that we looked at that option so I'm not sure, but if there is no way to get the uart set to a different pin that is exposed, that would be a huge blocker for instance. Also my fan takes 30 mins to stop making a racket by now so maybe this is just a good excuse

I don't think you can, you can instead disable the prime blob and write your own prime gcode. go to the manage printers screen and click machine settings then set your gcode as the start gcode and you can apply your own version of priming for every print.

@daid has managed it as a one off test, but we'd need to put in quite a bit of work, it would require some serious messing with the electronics (so definitely have a high DIY level) and it would not be that cheap either. It would also break the SD card reader, would probably have either Ethernet or WIFI, not likely to have both, have the Ethernet cable plug in via the bottom, not on the back and maybe some more caveats. And then we'd still need to add the UM2(+) as separate machines in Cura connect, though that is the easier bit. I'd want it on my UMO (an ancient one, definitely not +) and that would be even worse and require all new electronics, replacing temperature sensors, the printhead, etc.

The combination active leveling and @rebekah_harper's suggestion does not seem compatible, manually level the buildplate first. If after following @rebekah_harper's suggestion this is still affecting your print quality, call your reseller for support, they can help you determine if your bed is outside of specs, etc. Current active leveling measures 3 points and uses that to define the plane to print on, it assumes the bed is otherwise flat.... Instead the bed can indeed be as unflat as 0.5-6 mm, but that was a bad batch of glass plates indeed.

T1 and T0 are the gcode command to select the left and right hotend respectively. These commands are intercepted in the python code on the UM3 and then a more complex sequence of actions is triggered and sent to marlin. You could easily intercept a M to trigger a bit of python code and create a snapshot and place that snapshot in a folder of the webroot, add to that a api that keeps a new timestamp every time that image is updated and you can monitor that timestamp and get the image every time it's updated, or just keep getting the image every few minutes/seconds and compare images. you then still need to insert that M code into the gcode file (for instance at every ";LAYER:" line) though.

If you can write some python script you could make a snapshot when the change active hotend code is running (findable on the printer at /usr/share/griffin/griffin/printer/procedures/print/switchActiveHotendStep.py, this requires developer mode and ssh). You could use how the T0/T1 is intercepted by the switch active hotend to introduce your own gcode to make a snapshot. You can write code that connects to that step/procedure running via dbus, also on the printer You could monitor the API, but you'd ahve to monitor position z height or head position near the switching bay and that is not exact. I hope that helps! maybe in the future we can make a snapshotting feature or even a timelapse feature with the cura connect software launching the 7th of November, but that would be a relatively low priority thing, so don't expect it anytime soon. In the mean time if you want this you'd have to get your hands dirty with some code.

@gr5 is very right here, and we don't have a good high humidity climate test chamber, we do try though. I guess consider getting/making a drybox for the PVA in that high humidity. And keep an eye on the stuff in the bowden tube, if it is no longer stiff, trow it away or you are just cleaning cores repeatedly.

several vague questions here, I'm not sure what you are trying/want to do, perhaps you could try and explain that a bit better? you ca send print jobs from Cura. you can control the printer, printhead position, print jobs, case lighting, more etc. from the REST web API the documentation for that is available on the printer by browsing to: /docs/api/ you can also enter developer mode(makes your printer extremely insecure, hidden in the diagnostics menu) and talk to the services directly via dbus once you log in via SSH. you can give some of that a try by logging in as the ultimaker user, in that command shell you can at least send gcode to the motion controller directly. I hope that helps, otherwise please try to be a bit more specific...

currently the stream is served by mjpg-streamer so you should be able to use a variation on this guide: https://learn.adafruit.com/wireless-security-camera-arduino-yun/stream-video-to-youtube You will need to create a port forward if you are behind a firewall or NAT, just google NAPT (network address port translation) and know that you need to direct that to your printer's ip on port 8080 Also note that mjpeg-streamer is quite possibly insecure so expose it to the internet at your risk!

Just as an aside the BB printcore is more suitable for difficult materials in terms of experimentation then the AA core. Though the BB core will have more of an oozing issue. PLA is not recommend with the BB core but it is allowed, while PVA is blocked from being used in the AA core as it will destroy the print-core. so I would experiment with the BB core. The difference is small though (in implementation, not result in that there is a wold of difference) And remember you can always break a printcore if you experiment with it.

On top of the clip might work, but we'd need to check the stickiness (both ability to remove and initial sticking force of our 9 main material types on the metal of that clip... This gives the added annoyance of you having to tell your printer you have the clip on trashbin, though maybe with a big QR code it could be recognized by the camera? Even then Cura determines the prime position, so it's in the gcode not completely controlled by the printer. We changed that early on as you might not want to prime both nozzles at the start of a print...