Jump to content
Ultimaker Community of 3D Printing Experts

picaschaf

Dormant
  • Content Count

    30
  • Joined

  • Last visited

Community Reputation

3 Neutral

Personal Information

  • Country
    DE
  1. Today I've found an interesting issue (possibly) with auto leveling. After some time I enabled it again because of wobble issues, but now it seems as the Auto Leveling at the begin of a print overrides my manual settings of the print bed. The back part of the bed was a little bit too high, so after Auto Leveling, during the print of the brim I adjusted the back bed screw so the layer was fine again. But the next time I started a print, after Auto Leveling the brim looked the same way it did before. After 100 prints the back screw is possibly falling off the bed Why does the auto leveling co
  2. Hi, Today I was setting up our new office printer (that classic 2D one ) and when I was in the setup dialog I found our Ultimaker 3 Extended offering itself as PostScript printer via Bonjour (ZeroConf). As there is currently a long running print I was too afraid to just add and test it. Does anyone know something about this? Is it a feature, and what does it do? Best regards, Alexander
  3. A hot-workaround would be either setting the system's language to english before starting S3D, or to open the gcode file in an Text editor, remove the non-ASCII characters and convert the file (or, use iconv for example with the -c option which discards invalid characters).
  4. I’ve a little update on this issue. When I tried to run the gcode file to an UTF-8 to ASCII converter it stopped because of a unconvertable character (‚ä‘ as in März, March in german) in the file. It looks like S3D is using a system function to get a localized Date in short RFC format and if this contains a non ASCII character, it will automatically use UTF-8 for the export.
  5. The exported gcode file is encoded in UTF-8. I've sent you a PM on how to upload you an example file.
  6. Hi, I have a different kind of a problem. Could it be, that the new firmware silently changed the parsing of the G-Code file from UTF-8 to ASCII? When I try to print a S3D sliced model (exported G-Code is UTF-8) it immediately stops with an error in line 1 and the log says: Mar 29 15:17:22 ultimakersystem-ccbdd3000c63 python3.4[443]: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 418: ordinal not in range(128)Mar 29 15:17:22 ultimakersystem-ccbdd3000c63 python3.4[443]: 2017-03-29 15:17:22,877 INFO faultHandler warning(, Error while reading file 'Spray_Can_Rac
  7. No, the nozzle didn't let scratchmarks on the glass, but it touched it so heavily that it made bad noises when the print head moved
  8. Thank you for sharing your experiences! Maybe I'll try this as well. But how thick is your glas? My original glas is already exactly 4mm thick. At the moment I'm in heavy contact with Tom. It's crazy how seriously the guys @ Ultimaker take this issue. At the moment we are discussing different possible causes. The print problem itself with my original glas disappeared after moving the printer back in room where it was before and after a series of auto and manual calibrations. It seems that the firmware is capable of working around small warps (like my original glas has) but not big warps >
  9. Yeah, I'm in contact with the UM support and my seller. But I would like to see a definite solution, not sending 10 plates around the continent and luckily maybe there is one that is ok. Like I said, at least the one seller I had in my driving range yesterday, had his store full of warped glasses.
  10. @neotko I had a quick look on your posting and I've already found it when searching here for warped glass. But I discarded it as my solution as on the UM3 there is no screw between the glass and the bed anymore. You can see the new construction in the 2nd of 3 pictures in my last posting with the ruler picture first. Also the glass is much more bent than the one in your posting inside the printer as well outside the printer. Also it should not be able to bend borosilicate glass
  11. Yeah your problem might not be that. On my beta um3 I fixed the deformation points by pressing the points on the metal that where curved and now my first layers are perfect. Ofc that isn't a method I would suggest to a new buyer. But I did that also long ago on one of my umo+ https://ultimaker.com/en/community/10335-glass-plate-not-flat#reply-115893 Ofc the problem to do it correctly on um3 is that you don't have easy access to the gcode to see where the nozzle goes up/down on a banana bed. I did it using the command_util.py that's on the linux of the um3. To access it you would need to ssh
  12. I have the most current one the UM3 offers me to update to. But the only change I saw is that now the active leveling also does 3 points for the second print core. But as my glass is warped this is not enough for an accurate calibration. After manual leveliing the nozzle at least doesn't scratch on the glass, but the prints are useless. As already seen with a different part (the pink one above) this part shows the same behavior. In the front right (where the glass is flat) everything is fine. In the back left the nozzle is too far away and in the middle it nearly scratches the glass agai
  13. I don't think that the little aluminium sheet is capable of bending the glass back in shape Also my printing results show that this is not happening.
  14. I went out to buy a new original Ultimaker glass and I am shocked. All four glasses at the seller are warped O_O And, not a little bit. 2 of them are actually far more warped (>2 mm) than my current one. Now I've bought the one that has the least warp but this is still causing issues. Today I also updated to the current firmware with the new calibration mechanism but this changed nothing. The machine still assumes a flat bed. Is there any unwarped/unwarpable alternative to the glass for the UM3?
  15. I've used Cura as well and I see the dead zone there. Most of the time I use Simplify3D and yes, I could specify a dead zone in the software. But in my opinion from a software developer view this should not be a software issue, but a firmware issue. Firmware should always prevent hardware damages caused by external interfaces (in this case the gcode) which should be always treated untrustworthy - even for the own tools.
×
×
  • Create New...