timotub

You might also check if the axis pulleys are loose. If so, you can fix this by tightening the pulleys' screws.

Have you checked the g-code for this object? - Maybe the error has already been introduced by the slicer? I have also observed peculiarities related to the start and stop seam of each layer after printing the object. For the example below I had expected that the seam would be at the same xy-position, but it wasn't. Here we can see that the seam has been set to a slightly different location by the slicer:

Ich habe Erfahrung mit einem 3D-Scanner, der ebenso wie dein Vorschlag ein Streifenlichtprojektionsverfahren zur Erfassung nutzt. Der Scanner, den ich nutze, produziert die besten Ergebnisse bei hellen Objektfarben, vorzugsweise Weiß. Dunkle Farben sind eher schwierig zu erfassen, bspw. konnte ein schwarzes Objekt gar nicht gescannt werden..

Here is a poll on problems faced during 3D-printing

Thank you guys, I can confirm that @geert_2's part above also warps with PLA. I think there is potential to minimize this example even further, I will try one fourth of @geert_2's test part. Another kind of feature that are often affected are holes (as I've read), do you know about other feature-specific occurrences of warping?

Here is a publication that disconfirms your theory, saying that low layer thickness leads to high dimensional accuracy: Dey, Arup, and Nita Yodo. "A systematic survey of FDM process parameter optimization and their influence on part characteristics." Journal of Manufacturing and Materials Processing 3, no. 3 (2019): 64. Does anybody have a minimal CAD-model + slicing parameters (or G-Code) that reproducibly exhibits warping on an ultimaker?

I'm sorry, my fault, it works, I just looked at the wrong value..

Dear Ultimakers, I wanted to check how accurate and correct the capacitive sensor measures the distance of the print head to the bed. So I logged in via ssh and executed gcodes using the sendgcode utility. I positioned the head above the printbed using G0 X50 Y50 Z50, then executed M310 S20 and was surprised how precisely this sensor can measure the distance to the bed. But then I powered off the motors (M81), moved the print bed manually downwards and turned the power on again (M80). As I had changed the Z-position of the bed, I expected that the capacitive sensor measurement would now return the manually changed position. But actually it returned the previous value that the sensor had measured before the power turn-off. Do you have a hint how I can get reliable measurements using this capacitive sensor? How does this sensor work?

Meanwhile, the search feature has been implemented, as I see. But most often I get an error like this: I agree that a search would be really helpful.

Thank you for your reply and sorry that this may sound strange. There are additional sensors mounted to the printer, whose data is already streamed to Kafka by separate hardware. I want to stream the G-Code instructions as well, to gather all the live data in one place and to analyze it to enable a better control of the printing process. Why I want to process the data on a separate machine? - Because I think that the embedded UM3-system should not get more compute load to work on.

Is there a possibility to stream the currently executed G-Codes somewhere? - Maybe this could be integrated into the REST API? I guess I have to implement this feature myself, for that I have the following questions 1. Is it possible to upgrade python to a later version without danger of destroying something? - On my printer there is an installation of python 3.4. 2. Could I add pykafka to the existing python installation without dangers? 3. Where in the architecture would you sugguest me to plug in this feature? - I have figured out that the actual transmission of G-Codes to the Ultiboard is done in physicalLayer.py, using a SerialDumpFormatter. I would then modify the SerialDumpFormatter to only include the plaintext of transmitted code and stream it out either using pykafka or integrate it to Flask. What are your thoughts?

I think (as far as I understand) by ssh-ing on the UM3 it is possible to disable the cleanup requirement in the configuration (/usr/share/griffin/griffin/machines/um3.json). Maybe it would be similar for the UM5? By doing this the cleanup step will be skipped after each print, so be careful..

Maybe the printer could analyze the camera images to automatically detect if the printed object is still on the build plate or not? - And then free the user from pressing the button..

The switch is not broken, it seems to be old and often-used. I guess the force required to switch has increased. I also observe that one axis misaligns during the switching calibration. This misalignment is then healed when the print head moves to the home position again.

Thank you for the answers! I have suggested this feature, because actually the lift switch of the printer that I'm using is not working properly. The printer cannot switch nozzles, so the active leveling fails. Recalibration of the lift switch positioning didn't help either. Workaround was to set automatic leveling frequency to 'never' and do a manual leveling. Nevertheless, I would suggest to implement one of the following solutions 1. remove the second extruder and circumvent the switching issue in this way or 2. manually act on the lift switch to set the active extruder before printing and let the printer know that it should not use both extruders during automatic leveling and printing Another idea was that the printer could make use of the camera to detect if the lift switch works properly during automatic leveling and inform the user about this, giving instructions to make printing possible even though the problem persists.