Jump to content

robinmdh

Team UltiMaker
  • Posts

    326
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by robinmdh

  1. nice write up, added a comment there as well that you can skip the footprint probing problem b adding: To the header. This was done so no footprint probing was attempted when there are multiple layer 1's as with print "one at a time" print-sequence option in Cura. We could do a updated header documentation and other new things, as a lot has changed since the UM3. We have a few more API's on the printer, as well as the cloud API. for starters. Also thanks for the bug report! I added a small fix, don't expect it on a printer anytime soon though.
  2. Indeed ultimaker charges a premium for it's products with the intend that they work seamlessly together. The printer detects the filament and the print-core and know if they are compatible and will stop you from breaking your machine, etc. All the while we do have an open filament system, no encryption on any of our nfc tags or on our print-core eeproms, you can root the machine and change things if you want to. (there were even third party print-cores out there, though they did make them by buying ours first, but that just shows the cost was still less then making their own) I do see some contrast to how some other companies work, but of-course I work for ultimaker so I'm definitely biased. I don't think there is a push for the cloud for the reasons you are thinking off, there is just the desire to not have to maintain too many systems that do basically the same thing. Because maintaining those takes time away from making new features. Meanwhile I'm also happy to have the duplicate printjobs functionality back, thanks to all of you commenting!
  3. if this is about Cura maybe it should be moved to the Cura forum?
  4. you, you can add mirror finishes with sprays, shows this process, but I'd add a resin clear-coat to protect it from scratches and fingerprints like @fieldOfView said, it's a fragile and tiny mirror layer. There are tools used to chrome automotive plastic parts as well that work similarly but may be cheaper. you can also do a slightly worse mirror like finish with graphite powder on a glossy paint base.
  5. I would not use concrete the weight and heat during curing will break your PLA mold/outer shell. Small layers (if you only pour small layers at a time the temperature of the exothermic reaction will not rise very high) of polyurethane foam seem like a better plan. Maybe instead of PLA use PETG or ASA since the higher temperature resistance is worth a bit even if it only has to stand in the sun for a short bit. I'd try and print most of the outer shell, with the FDM techniques with some sanding, filling etc you will be faster and cheaper/faster then covering everything with resin prints, keep the resin prints for details where precision matters, like the face and other small details.
  6. I think feature X was the planned but not implemented filament flow sensor, and you should be good in connecting to that line. M260 is not implemented in our version of marlin, which can be found here , you'd have to add your own version of that. Best quick check to see if your i2c connection is live is the M12100 which scans the i2c bus. Some gcodes like G28 are caught in the python code side when coming from a gcode file and won't be executed because it would loose us bed probe data, etc. The "linux" olimex board also has an i2c bus and you could hook it up there, which would allow you to use command-line tools like i2cdetect, i2cget and i2cget. this would require a lot less modification, you'd have to change the WAIT_FOR_CLEANUP steps to not happen and trigger your robot arm instead. The python code I'm referring to can be found on your printer in /usr/share/griffin/griffin/printer/ good luck!!!
  7. the only error I see is the printcore takes too long to heat up, this can be caused by: The heater of sensor being disconnected from the printcore. a weird situation where a high temperature is requested and then a only slightly higher or lower, this can take long because the heating response will be slower as it's already almost at that temperature. E.G: have the initial temperature in the gcode header file be 300 degC and then having an M109 S305 in the gcode, this can cause the watchdog for that temperature change to time out. but this is after 10 minutes of waiting. you can fix that with Cura settings. a bug where a communication error happens right as the temperature is set, this can caused by be environment. The 1-2 does mean it's waiting for both hotends, so i could also be that the one hotend is working fine but the other one is not?
  8. we mostly have @CarloK to thank for this, he made this fix before he left😞 ultimaker !!!!!
  9. @leonhart88 I think you'll have to write some code to do this, the xy calibration in the ultimaker is set as for the combination of serial numbers, making this a bit more complex, the calibration is only applied when a print starts and removed after, there is also a large offset that Cura knows about, which differs per printer model a bit. this is set as the hotend_offset_1_x(18mm for the UM3) and hotend_offset_1_y (0 AFAIK) properties. The offset is set in steps of ~ 0.07 mm since a research paper suggested that as a the smallest difference the average human can see with the naked eye.
  10. AFAIK the speed of travel to the switch is set by cura, the switching speed itself and the short distance move into the bay are set in the /user/share/griffin/griffin/machines/um3.json file as hotend_switching_speed and default_travel_speed respectively. Feel free to try some different values, but be aware that faster operation may cause more errors (which can be seen as leveling errors, or just mess up a print) and possibly damages things, especially if not calibrated perfectly.
  11. I guess you can't rule things out but with the UM3 we didn't have that much variation in hardware suppliers as we've had with the S5, S3 etc (mostly due to Chipageddon). Most bugs we find also don't have that as a cause, and often differences between machines can be cause by settings, a factory reset or (better) doing a clean install from an microSD card can help. But certain things like bed leveling sensor have certainly had a lot of different printhead PCB's in the attempt to make the leveling process better and less vulnerable to ESD. That should move between printers with a swap of the printhead though. Cura is not that likely to remove the option to generate UM3 compatible files, I wouldn't worry about that. As far as I can remember an UM3 can also print plain gcode files as sliced for an UM2 or a UMO+ while some features like proper estimates of print times will fail, the print should be fine.
  12. This is difficult to troubleshoot with no clear error, but one error I can imagine is that you need to have both printcores in the printhead, if the printer doesn't detect both printcores it stops you in most cases because with a print-core missing the the cooling won't work and the manual leveling also detects the difference between the printcores. So even if your printcore is broken the printer must see it be present for the printer to work. You must also have ran a manual level or an automatic one before you set the active leveling to never AFAIK. I'm on UM3 version 5.3.0 though
  13. developer mode is still there on all of our printers UM3, S3, S5 etc... for the firmware 6.1.0 R1 and R2 and I'm only linking to restore images because downgrading that far back just doesn't work, you need to reinstall via micro sd card. I still don't really recommend it. --- why don't they just have a dedicated place that is easily accessible for all firmware's I agree, and have argued for this; But support doesn't want this for some reason.
  14. The camera stream hasn't changed at all recently, did you try turning the printer off and on again? which printer type and firmware version are you using now?
  15. sorry, but nope. I did make a installer/patch that added the layer number to the existing progress screen. The resistance against this is gone though, so maybe we can add a stats for nerds type page to the print progress SwipeView in 8.1.x maybe. 8.0.x is closed for new features.
  16. Yes, we saw this as well and have already fixed it, so it will definitely be fixed in a future software release. Since it doesn't actuality block use (it just super inconvenient) we decided it wasn't critical, so it did not block the 7.1.3 release at the time. It will definitely be fixed by version 8.0.0 which is pretty much done, but I don't exactly know when that version will be released. Thanks for the bug report @Link !
  17. the location hasn't changed, the only think I see is that the axes (E X Y, z etc) was changed to lowercase! (e, x, y, z) and I do note that the manual has it in upper case. though I would recommend making a file in /var/lib/griffin/machines as this is kept between updates to firmware. you can put a um3.json file in there that inherits from /usr/share/griffin/griffin/machines/um3.json so that it changes only those properties (or use the specific filename for your printer model as I've done in the attached file). so you should be able to copy the attached file to /var/lib/griffin/machines (after you run mkdir /var/lib/griffin/machines) good luck either way! 9066.zip
  18. Thanks for sharing!, good to hear it resolved itself. For anyone else with problems like this after half an hour since the first blank/logo screen, any update should definitely have installed, so rebooting it then should be safe. Hopefully we can fix these issues in a future release.
  19. in the UM3 it should indeed be possible to never use active leveling, so indeed set it to Never AND also run the manual leveling procedure once after doing so. It might also be better to do a factory reset/reset all settings before you do any of this so that old data can't block this from working.
  20. the command does not process a U parameter I think you FilamentChange plugin and firmware might have a version/implementation mismatch but it should certainly do the first unloading moves even then, does it not retract filament? that said the display of the UM2 is very different from the default marlin you'll need to change quite a bit more code to get the screen button interaction. have a look at the M601 right below which has this wait until a bit is set in a global variable to wait for the user. and is running lcd_update() in that loop amongst other things... https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJar/Marlin/Marlin_main.cpp#L2175
  21. that is a super usefull bit of info, thanks @lawrie @mmsg The data is shared with ultimaker directly via a developer tool called sentry (https://sentry.io) but ONLY IF you have allowed sharing of data with ultimaker (on the printer, Cura and the digital factory have saperte data sharing block options)
  22. I can't say I was ever a fan of this "feature" (it's supposed to stop you from damaging the print prematurely and yes people have also complained about us allowing you to remove the print too early) but despite my arguments very similar to yours it got in ages ago, it's a bit more visible now but it's been there for quite a while. We have a new UX person since then though so it's at least up for discussion, I'll point him to this discussion.
  23. @CarloK ahh, yeah that is just an approximate guess.
  24. @jsw as far as I know the long wait at the end of the print was fixed in 7.0.0. Though we're also waiting for the buildplate to cool down and if you use a material station for the material to deprime and park above the printhead.
  25. I think I agree with @Torgeir but far be it from me to deny you the freedom to choose which firmware version to run. https://software.ultimaker.com/releases/firmware/9066/stable/5.2.8.20190320/um-update-5.2.8.20190320.swu https://software.ultimaker.com/releases/firmware/9066/stable/5.2.11.20190503/um-update-5.2.11.20190503.swu https://software.ultimaker.com/releases/firmware/9066/stable/5.2.16.20200331/um-update-5.2.16.20200331.swu https://software.ultimaker.com/releases/firmware/9066/stable/5.2.17.20210723/um-update-5.2.17.20210723.swu https://software.ultimaker.com/releases/firmware/9066/stable/5.2.18.20210820/um-update-5.2.18.20210820.swu 5.1.x firmware is tricky since that used a different update mechanism so you can't downgrade the normal way to those versions, you'll need to install the firmware using a microsd card as if you are unbricking your printer, there is a nice guide on how to do that by @gr5 https://software.ultimaker.com/releases/firmware/stable/5.1.8.20181207/recovery-5.1.8.20181207.img https://software.ultimaker.com/jedi/releases/UM3_recovery-4.3.3.20180529.img Let us know what it was if you find out what the problem was?
×
×
  • Create New...