Jump to content

gandy

Dormant
  • Posts

    15
  • Joined

  • Last visited

Personal Information

  • 3D printer
    Ultimaker S5 Pro Bundle
  • Industry
    Other

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

gandy's Achievements

10

Reputation

  1. @Bunnyman21 cool to see what you made of it. Do you host this on an open source site like GitHub? I'd love to give it a try. I see the potential of this being a Cura plugin, possibly with access to Cura's material database, but a standalone GUI is already a big plus over the CLI tool I wrote.
  2. I'd be surprised if the NFC reader is actually exposed by any of the high level APIs or even the machine's dbus. My recommendation is to get one of those 20€ USB NFC readers and go with Python or whatever language you're comfortable with as long as it works with the reader. I'd be happy to stand corrected, though, so if you find a way with the native NFC hardware, please share.
  3. @gmeardi good luck with that. I guess you don't really need to be an expert, I certainly am not. A little python knowledge can surely help and you definitely need some nfc reader/writer hardware. I'm using a ACR122U-A9 with a raspberry pi for that purpose. Got it working out of the box with pscd: sudo apt-get install pcscd pcsc-tools echo 'SUBSYSTEM=="usb", ACTION=="add", ATTRS{idVendor}=="072f", ATTRS{idProduct}=="2200", GROUP="plugdev"' | sudo tee -a /etc/udev/rules.d/nfcdev.rules idVendor and idProduct may be different and both udev and pcscd may have to be restarted before it works. For actually writing the data to the tag, I'm using something along the lines of this short script: https://gist.github.com/gandy92/1f9df107b049e12173657e28e20dc56e I'll be happy to learn how this turned out for you.
  4. @gmeardi If you can love the solution depends on how much you are willing to stretch 'easy', so here we go. Before working with the Ultimaker S5, I've never really put my mind to NFC technology, so there are very probably some gaps in my understanding. Most of what I've learned, I've deduced from comparing the data from different spools and with different amounts of remaining material. The rest I could fill in reading the relevant python code of the firmware after ssh-ing into the printer. As @Daid pointed out earlier, Ultimaker tried to implement NDEF records. According to the NFCForum-TS-Type-2-Tag standard, NDEF records need to be embedded in a NDEF Message TLV, which is missing on the Ultimaker NFC tags. That's why NFC apps report there are no NDEF records on the tags. Other than that though, the data adheres to the NDEF standard, so I was able to use the python package ndeflib to add custom record types to decode and encode the tag data. The code on https://gist.github.com/gandy92/a7eef12009045f7b3fc01d778c3b79a7 demonstrates just that. Based on this code, you can decode the data from your spools to check how much material is left (usually given in mg) or plug in the UUID from your custom material profile and the amount of material on the spool and create the data to write to your NFC tag. I will not elaborate on how to actually write the data. This depends heavily on your tag writer and OS and would by far exceed the scope of this comment. For our spools, we carefully extract the NFC tags from empty spool and transfer them to the third-party spools. Make sure to always write complete blocks to the tag: There are two stat-records on the tag, apparently with usage data at different times. My first guess was this is used for redundancy in case a stat-record gets corrupted, e.g. by the printer loosing power during a write operation. In my first writing attempts however, I failed to write the last block, rendering the whole tag unreadable for the UM-S5. I'm not sure if this is due to design or simply a bug in the firmware, but if any of the two stat-records show the wrong checksum, the whole spool is simply ignored by the printer. In Cura, I've learned it is important to actually have two filament profiles: {brand}_{material}.xml.fdm_material, where brand and color are set to "Generic" (in the profile, not in the filename) {brand}_{material}_{color}.xml.fdm_material fills in the actual values and additionally provides the amount of material Say you have material M of brand B in color C, you want two files, B_M.xml.material and B_M_C.xml.material. For a new brand and material combination, I suggest to select an existing material in Cura as template: When creating a new custom profile, Cura will pick a new UUID for it. Then add one profile for each color, each with a different UUID. Use these UUIDs for the tags. You will need to use a text editor to adjust the profiles. Later, Cura will sync the profiles with the printer, so there is no need to upload them yourself. Just make sure to increase the profile version number and never again change the UUID. There's one caveat however, when using the material station: The profile tells the printer how to load/unload the filament, but so far I couldn't find documentation on the parameters, so maybe using the profile of a material with similar properties would be a good idea. Being extra careful and standing by the printer is another good idea. For perfect integration in Cura, it would be great having intent profiles for the material, which we are still struggling to figure out how to create. If anyone managed, I'll be happy for tips or suggestions.
  5. @Carla_Birch We have the same problem with PVA on the S5, here. Both with and without the material station, PVA appears to be so brittle, it breaks very often during transport to the printcore. Once, it even shattered to small pieces inside the extruder enclosure so we had to dismantle it to get everything out. Adjusting the feeder tension is something we had thought about just recently, but is there a suggested procedure of doing that? I assume the tension has to be smaller, but how can I see when it is too small or even has the right tension? Any help or pointing in the right direction is highly appreciated. Thanks, Andy.
  6. Even though the tags are not marked to contain NDEF records, the data stored in the NFC memory adhere to the standard. There are four records one of which contains the material UUID and two others storing the amount of material on the spool. The tasks of understanding the individual data structures and how to fill them in gets much easier consulting the relevant python code on the printer. This way I managed to successfully write the UUID of a 3rd-party material to the tag of an empty spool and transfer the tag to a fresh spool of said material. I also managed to create a cura plugin for this material with both the generic and the vendor specific definitions, together with a set of profiles (which now need to be refined to meet their intent). This way, Cura uploaded the fdm_material file to the printer which now fully recognizes the material. We can even use it with the material station without any obvious restrictions. However, I am still a bit uncertain as to how to tune in the material station related parameters. For starters, I used a fdm_material file of a material with similar properties, but I'd feel much more at ease if I knew the relevance of each parameter and which material properties I need to take into account. Is there any sort of documentation on this? Another question is where we could source a small number of these circular tags, right now we don't have enough empty spools to live off recycled tags.
  7. @robinmdh, thank you for the detailed information on the probing data. Actually, yesterday after ssh-ing into the machine and just before leaving work, I found the column description in the comments of the relevant python code. I'll probably extract one or two measurement curves out of curiosity, but my original question is answered. To summarize: There currently is no parameter to correct for the observed error in first layer height on the machine level. Due to some DM exchange with @nallath the issue is known and possibly being resolved in the future. Obviously, this may take some while. Currently, there is an existing workaround in form of the z-offset-plugin for Cura. Thanks again to all participants for the discussion, Cheers, Andy.
  8. @ahoeben, I guess I have understood the motivation behind the plugin and the benefit as a workaround in the case of the S5 perfectly the first time, thank you. Regarding the issue at hand, of course you can choose to not follow my line of argument, but as you say: Each its own.
  9. @robinmdh, thank you for the two links, I wished I had known about those a week ago 😀. It's good to see how much information you share on your products, nowadays this is not typical for most businesses. The first article actually confirms my assumptions on how the probing scheme works. I'll check out developer mode and the measurement data later, but do they really contain all measurements while the bed is approaching the bed up until the probing ends (like the curve of the sensor signal vs. z-position shown in the first article) or is it just the raw z-position of the trigger points for each probed x-y-position on the bed, i.e. some sort of topography map? And yes, build plate adhesion is an important issue, but that's not my point. My point is that the first layer height is wrong and the apparently broad user base of the z-offset plugin that served as a workaround shows that there is a systematic issue that users have the need to compensate for. My argument is, that this compensation at user level would not be necessary, if the compensation would already happen at the machine level. I've just learned that this is something being worked on, so for now I'm accepting the use-as-is and looking forward to a future firmware possibly taking care of a perfect initial layer height 😉
  10. @nallath, thank you for getting in touch and confirming my theory. @ahoeben, I am sure the z-offset plugin does a wonderful job and if the printer does not allow to adjust for the error in initial layer height it is indeed the only way to keep dimensional accuracy. I will definitely give it a try, thank you for your work! @tinkergnome, you're right, squeezing in the first layer is an important factor to improve bed adhesion. That's why most cura profiles default to 120% initial layer line width. Active leveling on the other hand allows the printer to correct for a non-planar printing bed surface, making certain that the distance of the nozzle to the bed surface is the same for all positions of the bed, which is necessary for homogeneous material deposition. The intended result of any kind of bed leveling, be it manual or automated, should not be a false distance, as this really messes up dimensional accuracy.
  11. @ahoeben, thank you for the suggestion. I somehow hoped for an actual settings parameter in the printer. I do not really know how active leveling is implemented in the UM S5. Surely, the capacitive sensor in the printhead is used to determine the distance of the printhead from the bed. During each probe, the nozzle not only touches the bed, but the bed is raised a little further still, so much it tilts ever so slightly, barely noticable. I've seen a few videos of other S5s and also UM3s doing the same, so I assume it's part of the probing scheme. That may imply that the firmware checks for which z-height the capacity sensor's signal starts to flatten out. That would be the position where the nozzle makes contact with the bed surface. It would be quite independent from the bed material, too (metal under glass or bare aluminium), as long as there is something the sensor can react to. But it could still leave a certain offset that needs to be corrected. Maybe someone from ultimaker could bring a little light into this, the fact that someone went to the troubles of writing a z offset plugin in the first place indicates that I'm not the only one struggling with the initial layer height. And honestly, I believe this needs to be corrected at the printer level, not the slicer.
  12. Hi @SandervG, I just sent you a DM with the logs, hoping this helps. Cheers, Andy.
  13. Our new UM S5 arrived a week ago and from day one we've got an inconsistency in the height of the initial layer. We've tried printing Strong PLA, Nylon and TPU (all from Ultimaker) and on all materials, the first layer was of a consistent 0.16 mm height instead of the 0.2 mm specified in Cura. Same happens with PVA on the second printcore. Consequently, we need to reduce the matierial flow of the first layer to 80% to not get a totally overextruded first layer. We ran the manual bed leveling several times, even with different spacers (the thickest being a PCB with riduculous 1.6 mm), all yielding the same results. Active bed leveling was activated for each print, which may explain that the manual leveling was effectively without effect. But if this is the case, there surely must be a way of calibrating the z-offset for the active bed leveling, right? Several online searches did not turn up any results, but maybe someone here in the forum can help? Any hint in the right direction is highly appreciated. Thanks, Andy. Edit: Tested and verified for the second printcore with PVA loaded.
  14. Hi @SandervG, thank you for your welcoming words. I assume the log needs to be saved before the next reboot? I just learned my colleague rebooted the printer this morning after the camera feed got lost again over the weekend. Consequently, the dmesg file only shows messages from after the reboot. Do you need all the files stored on the USB stick or only a subset? Can I attach a ZIP archive to a DM or do you have better suited ways of uploading this kind of data? Not sure if they belong in the public area. Thanks, Andy.
  15. @SandervG we installed the latest Release on our brand new S5. Alas, this version appears to be less stable than the previous one that was pre-installed on the printer. Here's what we've encountered sofar: The camera feed, both viewed through cura and the webinterface, shows occasional dropouts of part of the image, i.e. the lower quarter or half of the image flickers briefly. After several hours of operation, the camera feed stops working On some of our computers in the local network, the printer disappears from cura and can not be discovered again though "Refresh", but works fine on other computers at the same time Just now, when trying to swap out filaments (different colors of Ultimaker Tough PLA), the new filament was not recongnized, a few seconds after that, the printer threw a ER998 at me, asking for a reboot. Filament detection worked flawlessly afterwards. None of these things occured during days of operation before installing the new firmware. The material station and air manager are on backorder, anyways, so meanwhile, we may want to go back to the previous firmware. Where can we download the image? Finally: I'm new to the Ultimaker ecosystem, is this the right channel to report this? Thanks, Andy.
×
×
  • Create New...