Linear ADC Thermocouple Improvements
-
I am going through the code looking to implement a MCP3204 ADC to convert linear voltage inputs into temperature readings. It is my understanding that MCP3204 contains 4 channels (MCP3208 contains 8 channels). It would be extremely helpful to be able to using one single chip to access all 4 channels and have 4 temperature readings, but it appears to me (and I'm not super experienced with C++) that the code is hardcoded to use the first channel only.
Code starts around line 92, 'TryGetLinearAdcTemperature'.
static const uint8_t adcData[] = { 0xC0, 0x00, 0x00 };
Would it be possible to have a bit more customization to allow for you to specify the channel separately? If doing that, might as well allow to specify single ended or differential mode as well?
I realize this would probably require an additional configuration parameter. So it is a little above my head right now.
I suppose it would require also allowing reuse of the other channels too. Something like:
//Heated Bed, ADC CS0, Channel 0 M305 P1 X300 C0 Lnnn Hnnn //First Extruder ADC CS0, Channel 1 M305 P2 X300 C1 Lnnn Hnnn //Second Extruder on different ADC CS1, Channel 8 M305 P3 X301 C8 Lnnn Hnnn
etc.
-
The firmware is open source so you can change it however you like. We implemented the linear temperature sensor interface for an OEM who needed only one channel.
To read thermocouples, I strongly recommend you use the MAX31856 chip instead. It is supported directly in the firmware and it avoids most of the errors that are introduced when you use an amplifier and a separate ADC. The daughter board we supply includes LEDs to warn you of error conditions.
-
Thank you for making your work open source. I am very glad and it is one of the main reasons why I chose the Duet over any other option. I understand that the linear sensor interface was made specifically for an OEM. But what would you do if they came to you tomorrow and said they needed 2 channels? Would you hard code the second channel as well?
I would like to help improve the code by making it a bit more robust and open to differing hardware. I understand that the MAX chips are great, but unless they can read Linear voltage, I cannot use it for my application. As I mentioned in another thread, I am retrofitting OEM machines and I want to make a 100% plug and play board that interfaces between the OEM's electronics and the Duet.
If successful, I'm sure there would be many people interested in a 100% plug and play option. These OEM machines cost $15-$25k new and are locked down with proprietary software. The Duet can set them free.
If I understand the C++ code correctly. I should be able to extend how the M305 parameters are applied to the Linear sensor's code? If successful, I'd like to push the code for future use in the firmware, and it should default back to channel (0/1) so your OEM's wouldn't be negatively impacted.
I'll take a look at the code and see what I can do, but I'd appreciate your help double checking to make sure any improvements are implemented correctly.
-
Please see the code I have committed to my fork. I am not super well expirenced in C++, but I believe this should work and not cause any other OEM's configurations to break.
https://github.com/CNCxyz/RepRapFirmware/blob/dev/src/Heating/Sensors/CurrentLoopTemperatureSensor.cpp
https://github.com/CNCxyz/RepRapFirmware/blob/dev/src/Heating/Sensors/CurrentLoopTemperatureSensor.hNote: I implemented the addition of parameter "C" to be the channel on chip. So values from 0-3 for MCP3204 and 0-7 for MCP3208. Default value is 0 (CH1).
I figured in Hex that the default CH1 was 0xC0, with each additional channel being the addition of 0x08. So I did a simple equation to multiply the channel on chip number by 0x08 and add it to the default 0xC0 value. I am 99% certain that is valid C++ code, but I am not absolutely certain if mixing hex and decimal will yield a valid uint8_t value?
I did not integrate Differential signaling as I was not 100% certain what parameter to use in the G-Code. Wn? W0 for Single, W1 for Differential? Such a change could be implemented very quickly.
Let me know if this checks out and if you would be able to merge this with the code base for the next release?
-
That looks OK to me, but my current development is on the v2-dev branch. So please copy across your changes to your v2-dev branch, then send me a pull request.
-
Pull request submitted: https://github.com/dc42/RepRapFirmware/pull/213
I hope you find it agreeable!
(I also added a bit for selecting between single and differential channels)