Thanks a lot to all of you!
PT100 Sensors have the problem of all of them being quite "big", but I am in contact with a manufacturer who might be able to supply a small enough Version of it.

Right now I am using the H and L parameters to finetune my thermistors, but this is a little frustrating to do as you can't just measure the temperature difference and enter it but need to work your way there. At least my thermistors all vary so I'd need to tune all of them.

If the sensor temperature is not the same as at the nozzle it does not matter as the deviation should be the same on every printer if the sensors (probably PT100) don't vary.

@dc42 said in Setting precise temperature for chocolate printer:

Yes, in RRF the G10, M104 and M109 commands accept floating point values for the temperature parameter.

You made my Day! I did not find any documentation this is possible and stupidly did not try.
But this leaves me with one Question: Is there a way to set it at steps 0f .1 of a degree? I dont want my customers to have to use the m104 command all the time.

Do you happen to know if there is a way to set them using a repetier server? (or using PanelDue)

Hey,

For printing chocolate I am trying to get temperature as precise as possible. In a perfect world the actual temperature would be within 0.2° of the temperature shown and the temperature could be set in steps of 0.1° for better control.

With some time spent on tuning and tweaking the PID values I managed to get the temperature to vary by less than 0.5°. Measuring with a calibrated thermometer I had a deviation of something like 1.5° depending on the temperature sensor I use. Is there some way to correct / offset the temperature reading to the actual value?
Also is there a way to set temperatures in steps of less than 1°?
Both things I did not find anywhere so far.

Getting back on your reply at the reprap.org forum:

Good to know extrusion is always relative. Obviously changes a few things.

Can you tel me how to set something up actually adding the E values including M the extrusion multiplier?
If this gets too complicated I guess I'll add a second switch somewhere, even if it is something I'd like to avoid.

Is there a way to send E Moves to another axis which has a actual position? (If it is actually moving or not doesn't matter I guess) Something like creating a Axis for homing and the hiding it.

Thanks!

I wish retraction could be a lot smaller, but with the syringe based system I need it, at least for now. Obviously within the extrusion I need to go as fast as possible and Extrusion amounts within the print are given.
For now everything worked just fine and should it actually result into loosing steps rarely I guess there is no alternative for now. Probably it should not matter that much anyways as it is more like a flow rate I'm working with instead of actual small extrusion amounts.

Do you see any alternative?

@dc42

Thanks a lot, great effort!
The extrusion factor is right, for sure but it's a completely different setup (printing chocolate by using a syringe like mechanism).

Also I am sure I didn't change anything but shortened the E-values.
Thinking and working outside of standard use-cases often results in quite a bit of problems. So for now I'll keep experimenting and if a problem like this comes up again will have another look. Hopefully it is so many special things coming together it will not happen again.
Worst case I'll stick to repetier but I like RRF better by now.

This it what it looks like when finished (if interested):

@Phaedrux it is a Duet 2 Wifi

config.g

@dc42 I just tried, still the same thing.

sure, here you go:

edited (working).gcode

unedited(stops with first print moves).gcode

Hey,

working on a custom slicer for my needs right now. Yesterday it output the following G-Code (the left one). Starting script went fine but, starting with the lines you see here, it stopped extruding. Even after stopping the print and starting a new and working one there were no more extruder moves. Unfortunately there was no error message like heater fault or anything alike.
To find the source of the problem I shortened the E-Values and it works just fine, even on the lines i didn't shorten.
Any ideas?

Running RRF 3 RC9 (same problem on another machine running version 2

That was a fast reply! Thanks a lot!

Stall detection worked great and also explains why trying to home against the button using G1 H1 Exxx did behave strange. (stopped right away)

Hiding the unused axis also is a good idea I did not know about.

Right now I am still running on 2.05 and did not look much into RRF 3. Is there some documentation on the new daemon.g file as I did not find much about it?