Posts made by krzaku

Using a new SD card seems to have fixed it, I'm not 100% sure though because of the semi-random nature of this problem. Let's say it's resolved for now, if I encounter it again with the new card I'll report it. Thanks for the help in debugging this.

Common ground for 24v and 12v is fine.

I've been away from 3d printing for a while, I've just come back and I tried reproducing this bug again, and it's still there. Although I can't see any additional debug info you're talking about in the M122 output: https://pastebin.com/9GYuUWFF

Phpbb is old and mostly obsolete, use a modern forum engine. My vote is for Discourse.

I have no experience with migrating forums but I have some database experience. If you really want it, it is not impossible to migrate any forum system to any other one, people just don't want to put in the effort to do so or don't have the expertise required.

Shows a 404 error for me.

I think there's something wrong with the link you posted.

Can the 3-piezo under-heatbed setup be directly attached to the silicone heater? And wont the heat damage the piezo speakers? The temperature is quite high, up to 140 degrees.

@Mike:

My PT100 temp sensor is malfunctioning in this beta (1.20b6) - heater fault at 2000 degrees.
It's defined by:
M305 P1 T100000 B4138 C0 R4700 X200

On a side note, has anyone been able to trigger Stallguard yet?

T, B and C parameters have no effect on PT100 sensors, and in the new beta the R parameter configures the reference resistor. If you have the original PT100 daughterboard you should remove the R parameter (and the other parameters I mentioned in case they are used in the future).

It's literally the first result when searching for "duet mounting" on google…

Thanks, will try it and report back.

No, I never used the USB port.

You don't actually have to set the P parameter, it defaults to "eventlog.txt".

Maybe the g-code generated by your slicer repeats the wrong temperature.

David, are there any news on this?

That's kind of missing the point, isn't? Buying an expensive temperature sensor just to lower the accuracy with a wrong resistor?

I'm trying to rewrite the MAX38165 module in the firmware based on the example I linked above, but to be perfectly honest I have no idea what I'm doing. My C++ knowledge ends on simple console games and I have zero experience coding for ARM. What I'm having trouble with is getting the ohm reading. In the GetTemperature method you have an adcVal variable. How do I convert this value to ohms? What I tried is mostly copy-pasting from the example like so:

[[c++]]
uint32_t dummy;
uint16_t adcVal = (rawVal >> 1) & 0x7FFF;

dummy = (uint32_t)(adcVal << 1) * 100 * (uint32_t)430; // 430 is the Rref value, hardcoded for now
dummy >>= 16;
uint16_t ohmx100 = (uint16_t)(dummy & 0xFFFF);

But I must be doing something wrong because I'm getting no reading (2000 celsius). I also don't know how to debug stuff so I'm going through this blindfolded, not knowing what values those variables have.

That's the exact formula from the linked wiki page: revs_per_second = (2 * supply_voltage)/(steps_per_rev * pi * inductance * current). It's the max revolutions per second of the motor itself, why would a target belt speed be in there?

How accurate/up-to-date is this wiki page: https://duet3d.com/wiki/Choosing_stepper_motors ?

This question is mainly directed at @dc42 because as I understand it, he tested the values there. What I found out from the formulas there, is that the formula for back EMF inductance doesn't make any sense. The values @dc42 got are wrong due to rounding (I guess? What else could it be). What I got was completely different, and basically after applying this formula I got the supply voltage back. Always. Changing inductance, current etc. had no effect on this, meaning you could never have a high enough supply voltage. I've prepared an example spreadsheet with the values from that wiki page: https://docs.google.com/spreadsheets/d/1OVMbsiDDr5Fs4YFG2YvgqywIt_NdG0XkNiIsKGuiXL8/edit?usp=sharing

It has to be a virtual heater for it to show without a defined tool in the WebGUI. If you're only using the thermistor input of the 3rd heater then use the X parameter of the M305 code. It let's you override the thermistor channel without changing the heater parameter. As in: M305 P103 X3 S"whatever" […].

Sorry, I meant a temperature sensor with a virtual heater as P parameter. That is the M305 g-code. You can name it using the S parameter.

If you define a NAMED virtual heater, it is shown in the web interface in the "Extra" tab, not much else you can do. I modified the WebGUI to make it always show the extra tab under the tools and heaters.