M308 and Current Loop Temperature Sensors

AJ Quick

Testing now. Those changes work, however any sensor that comes after the first are not reading the correct information.

M308 S0: Sensor 0 (Chamber) type Current Loop using pin (spi.cs5,duex.cs5,exp.50), reading 41.7, last error: success, channel: 2, temperature range 0.0 to 100.0C.
M308 S1: Sensor 1 (Model) type Current Loop using pin (spi.cs5,duex.cs5,exp.50), reading 201.6, last error: success, channel: 0, temperature range 109.5 to 330.0C
M308 S2: Sensor 2 (Support) type Current Loop using pin (spi.cs5,duex.cs5,exp.50), reading 201.4, last error: success, channel: 1, temperature range 109.5 to 330.0C

If I disable all except the Model for example. The temperature changes to the correct reading:

M308 S1: Sensor 1 (Model) type Current Loop using pin (spi.cs5,duex.cs5,exp.50), reading 109.5, last error: success, channel: 0, temperature range 109.5 to 330.0C

Seems the first sensor defined is always reading the correct number, but the 2nd or 3rd is always reading the wrong number. I suppose the SPI isn't actually queuing reads correctly? Further testing is needed.

dc42

@AJ-Quick said in M308 and Current Loop Temperature Sensors:

I suppose the SPI isn't actually queuing reads correctly?

I can't remember how the MCP3204 works, however with many SPI devices the data you read during a transaction is from the register whose address you set in the previous transaction.

It would probably be better to have the master device read the ADC results for all channels (which can probably be done in a single transaction - check the datasheet) and store them; then each child device can ask the master for the reading from its own channel. If you want the child devices to have different ranges, then either the child device will need its own configuration parameters, or the master configuration parameters changed to allow different ones to be specified for each channel (for example, by accepting arrays for the H and L parameters).

AJ Quick

@dc42

Best I can tell, only one channel can be read at a time.

Theoretically, if you have two CurrentLoopSensors running on different chip select pins, wouldn't it schedule the SPI transactions so that they are never talking over each other?

It is odd that the first channel to be designated is always correct, the 2nd, 3rd, 4th.. etc. Are always tied to each other and produce the wrong data. Shouldn't they all be separated by the different instances of the sensor? Shouldn't the SPI transaction be treating each one as if it were it's own sensor running on SPI and keep them separated? I imagine it could be an SPI bug.

Here is what I did to test:

I changed my code to have 3 CurrentLoopSensors' each using their own chipSelect pin. I tied all 3 chip select pins together, so it doesn't really matter who is driving the signal. The same behavior exists no matter if it is using the code I just changed or the default RC8 firmware. It doesn't keep the SPI sensors separate.

EDIT: Just found what is going on:

It is only producing the ADC reading from the first defined sensor, it is just on the L/H scale that is specified.

AJ Quick

My best guess at what is happening is this:

Everything with the CurrentLoopSensor is configured properly.

-When CurrentLoopSensor issues SPI read command it is sent over the SpiTemperatureSensor.
-SpiTemperatureSensor requests a lock to use SPI with-in 10 (attempts? seconds? milliseconds?)
-If lock is successful, it sends the data out and receives the temperature data back.
-The temperature data that is sent back is always for the first defined sensor in the config, despite the data out presumably being correct.
-The data is correctly interpreted based on the Low / High settings and computed into a temperature.

Something in there is causing the SPI data to always come back as the first defined sensor. Perhaps the SPI lock isn't actually working? Are the other sensors trying to talk around the same time as the first sensor? It's reading the first sensor's data as if it were the data it had requested?

I'm assuming it will poll in order: Sensor 1 > 2 > 3, so Sensor 2 and 3 are seeing the data for Sensor 1 and assuming it is their own?

dc42

I think the problem may be the "static" keyword at line 117 of CurrentLoopTemperatureSensor.cpp. I will remove it.

PS - the latest RepRapFirmware commits depend on updates to CoreNG and FreeRTOS that I have also committed.

AJ Quick

@dc42 said in M308 and Current Loop Temperature Sensors:

I think the problem may be the "static" keyword at line 117 of CurrentLoopTemperatureSensor.cpp. I will remove it.

Bingo. That was it!

AJ Quick

My code for re-using the chip-select pin between multiple SPI sensors is now ready as well:

https://github.com/dc42/RepRapFirmware/pull/383/files

This change is simple and is forwards / backwards compatible with existing RRF3 configurations.

Also includes a bug fix for the CurrentLoopTemp sensors.

ajquick opened this pull request in dc42/RepRapFirmware

open Allow Chip-Select Pins to Be Used by More than One Sensor. #383

dc42

Thanks, but I won't be able to consider your PR until development on 3.02 has started, because 3.01 is close to final now.

ChrisP

I hadn't really followed this topic much until I got a github notification this morning, but I'm kinda hyped about this now!

One of the systems I work on has a requirement of having to read from a significant number of thermistors, and following a conversation with @T3P3Tony a while ago, he suggested using a MCP3208 (it'll actually need 2).
Anyway, I've only just realised that your current loop sensors have already done pretty much all the groundwork - thanks
I have some MCP3208 here, so I'll knock up a board today and get testing!

Ultimately, I think my application would be better as a standalone CAN expansion board in the end as each sensor is monitoring an individual heater... but that's a next step for some future time.

AJ Quick

@ChrisP said in M308 and Current Loop Temperature Sensors

Good to hear! Yep CurrentLoop Temp Sensor fully implements the code for MCP3204 and 3208.

The only thing that's a little wonky about it is in that it wants you to input the Low and High values where High is the absolute maximum reading and the Low is 20% of the range.

I've written a simple formula for it to be calculated based on the desired Minimum value:

L=0.2 H + 0.8 MinVal

For example if your range is from 50-120 degrees:

0.2 * 120 + 0.8 * 50 = L

L = 64
H = 120

You should be able to read from 16 ADC using only 5 pins.

@dc42 said in M308 and Current Loop Temperature Sensors:

Thanks, but I won't be able to consider your PR until development on 3.02 has started, because 3.01 is close to final now.

I assume you aren't implementing new features until 3.02? I was hoping this and my SX1509 expansion code were ready to go for the next full release.