[S5 "Difference between detected height of both PrintCores exceeds realistic values”]

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

[Strange anomaly when printing a cylinder]

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:

[Beratung 3D-Scanner]

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..

[Problems faced during 3D-printing]

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

[Theory on Warping]

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?

[Theory on 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?

[Capacitive sensor seems not really to measure]

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

[Capacitive sensor seems not really to measure]

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?

[Search topics]

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.

[Livestream of current G-Code execution]

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.

[Livestream of current G-Code execution]

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?

[Remotely confirm 3D print removal]

On 8/19/2021 at 1:44 PM, Smithy said:

Basically you are right, it is just implemented in the current firmware that when the print job has finished the printer is waiting that you confirm the removal of the object with a press on a button on the display. The state is stored internally, so just rebooting the printer don't solve it. And currently there is no API function to do it remotely.

 

But when you put the printer in developer mode, you can ssh into the printer and if you find the place where the state is stored or how to call the "I have confirmed and pressed the button" function, it should be possible. But someone has to analyze the code and dive deeper into the system. It is possible, because it is Python so you can read the code.

 

Tinkergnome worked on the amazing Tinkergnome FW for the UM2 printers, but they are completely different from the UM3 and S-line printers, so that will not help and work here.

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..

[Remotely confirm 3D print removal]

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..

[Feature request: Enable printing with only one extruder plugged in (on UM3)]

7 minutes ago, nallath said:

Is the entire switch broken? The switching itself is pretty reliable in my experience.

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.

[Feature request: Enable printing with only one extruder plugged in (on UM3)]

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.

[Feature request: Enable printing with only one extruder plugged in (on UM3)]

As the title says, can you ultimaker developers make this possible?

What time would you require until this feature is available?

And when do you plan to release it?

 

This feature would be very helpful for people who have lost a print core or who cannot use the second extruder for various reasons!

[Filament stuck in printhead]

Could this possibly be detected in a future release of the ultimaker firmware, maybe during nivelling? - I have faced this issue today as well..