Topics created by benecito

@benecito Pleaes create a feature request as a 'New Issue' on Github, here: https://github.com/Duet3D/RepRapFirmware/issues

The 'Firmware wishlist' category on the forum is more for discussion of firmware changes, as you have already done in your other thread, before a feature request is made. Creating the request on Github allows it to be tracked, rather than lost in the noise of the forum!

Ian

@benecito said in Expected negative temperature rise:

From my understanding this would mean a heater that might be at full power with no temperature rise will not trigger a heater fault?

That's correct, if all the following are true:

you set a temperature that is too high for the heater to reach (which may depend on the print cooling fan speed) that temperature is lower than the temperature limit set by M143 (or the default if you didn't use M143 to set a temperature limit) you have run tuning on that heater, so RRF knows that it shouldn't expect a temperature rise at that temperature in heating up to that point, the measured temperature behaved in accordance with the model.

@dc42 I was hoping there would already be a way to do so. But thanks! I will create one.

@benecito we recently found a bug in the handling of large amounts of USB input. This affects all Duets except the Mini5+. This may account for the issue you are seeing on your Duet 2. We've fixed it in release 3.5.0-rc.2 which we hope to publish today. So please try that release.

@benecito Thanks, that confirms my assumption:

State: 0, disconnects: 1, timeouts: 1 total, 1 by SBC, IAP RAM available 0x0dadc

RRF lost connection to the Duet because the SBC didn't respond in time, which can happen when the SBC is temporarily overloaded. Consider exchanging the microSD card with an A1- or A2-rated card if you haven't done this already.

@benecito ok. My offer of a preview build of the Duet 3 Mini firmware still stands. The current firmware supports up to 7 CAN-connected drivers but the assumption we made was that they would be across up to 4 CAN-connected boards. I have now increased the limit to 8 CAN-connected drivers across 8 expansion boards.

@dc42 my apologies

@dc42 thats a bit unfortunate but we'll try to make something work for now.
Will feed hold work with external (USB) printing?

@jay_s_uk fair enough and thanks - please also make sure it does not only work on USB as we are using the DSF socket in SBC mode for communication.

@dc42 I think we briefly talked about this at last years Formnext and is has definitely worked previously 😉 Makes sense for me and that's not the problem - we can use another trigger number in case.
Rather trying to figure out the fan behavior and so on...

@chrishamm Thanks! I know it's not the first option to chose, but at least it works for now. We'll still try to make an actual SBC setup work, but that's something for another day.

@phaedrux just sent it. Any news if the replacement from the US will work?

@benecito said in Improve / optimize PT100 temperatures:

Sorry if I have to ask again, but wouldn't it be much easier vor everyone to be able to tune the temperatures by applying an actual offset instead of fiddling with ADC offsets or resistor values?

If there is an error in the reading, then the best way to correct it depends on the nature of the error. If the reference resistor isn't quite the right value, or the PT100 element isn't quite the right value, then adjusting the R parameter is the correct solution; because adding an offset would lead to reading errors at higher temperatures.

@jay_s_uk thanks - I'll give it a try and get back to you if needed!

@dc42
Thanks I‘ll try as soon as I find time and get back to you if needed.

@benecito Put your code setting the globals in a macro and call it from config.g. Then you can edit the file using GCode without messing with config.g itself. In config.g:

M98 P"/macros/setglobals"

Then, to change the globals, you'd have to rewrite the entire setglobals file, unless you had it, in turn, do calls to other files:

M28 "/macros/setglobals"
global var1=1
global var2=2
...
M29

@benecito I had the same problem for a syringe extruder. After having followed the recommendations of the forum, I changed the trigger M581 for the filament sensor M591, in addition to increasing the segmentation of the print buffer.

M669 K0 S100 ;increase fragmentation to 100 segments for second. M591 D1 P1 C"21.io0.in" S1 ;Trigger pause when "filament" is empty.

With this setting I have been able to make printing pause when the syringe runs out. In a file "filament-error.g" that is executed upon reaching pause, I execute the functions that I need at the time of trigger that endstop.

@jay_s_uk I will try on the next printer! Not exactly what I had in mind but I guess it will do the job 😉

@benecito I used a 0.01uf ceramic cap between gnd and signal and a 4.7k resistor between signal and 3.3v. Watch your cap size though, too big and it will damage the switch over time and also delay the triggering which could be a problem for Z. Ive followed @dc42 's advice to wire all my triggers to N/C, but like you, I have one trigger that is just too much of a pain to replace the switch to gain a N/C contact. So I wired it like this (sorry for the finger painting):
IMG_6789.jpg
You can crip the resistor right at the Duet board connector like so and slide shrink tube over the wire and resistor:
dont follow the pinout, this is an old photo with the cap.
IMG_6790.jpg