best way to do temperature pid with linuxcnc

sleepybishop wrote:

does it look reasonable?
github.com/sleepybishop/linuxcnc-mirror/...s/max31855_bspi.comp

I don't think you need any correction curves, that chip ought to output the actual temperature, it does the cold-junction compensation internally.


ive compiled and installed it, i tested hardcoding the 32 bit value from the sensor to a known 32 bit value and the expected temperature shows up on the new pin.

however i cant get it to work with actual sensor data, its always 0, even with the thermocouple disconnected which should trigger a fault and NAN as the pin value, which leads me to believe theres something really wrong somewhere.

If the pin updates then that would seen to indicate that the function is being called, but it appears that the bspi values are not being read by the hm2_bspi code.
I think the only way to debug this would be to add debug pins / prints to the bspi.c code to watch what is happening.

sleepybishop wrote:

wrt to correction curves, the datasheet for the max31855 says
"Because all thermocouples exhibit some level of nonlinearity, apply appropriate correction to the device’s output data."

So it does.
docs-europe.electrocomponents.com/webdoc...0900766b813d54ca.pdf
I had missed that.

The question then becomes "how much is the error, and do I care?". For a filament extruder or similar you probably don't care about the _absolute_ temperature, and can optimise your machine around a slightly different temperature scale.

this graph shows the error in the output of the 31855 output against temperature.



I think this is a case where I would accept the error for my own use, but feel obliged to correct it in something I was planning to release to the wider world.

Would you be interested in submitting the component to LinuxCNC?

One odd thing is that there are a number of output pins called things like "temp_celsius.#.in". The "in" seems superfluous, a more normal name would probably be just "temp-celcius". I guess that adding temp-fahrenheit and temp-kelvin might be worthwhile too, it's hardly any computational burden.

I think it looks OK, though the PR might generate more suggestions.

Maybe the docs section should point out that "personality" is the number of channels on that specific instance of the component?

Have you tested with more than one instance of more than one channel each?

I can see arguments either way. The CS and data clocking has to do all devices serially. If you had hundreds of them you might want to run several instances of several channels simultaneously to get the data at the required rate at the expense of more IO lines in total.

I can't see any compelling reason for option singleton = yes; That is for _obligate_ singletons where multiple instances would break things.