Running Multiple Monitor Threads for Reading Probes

[TerryJC]

Something that came to mind last night, which also needs to be considered, is identifying the measurements from each individual A/D Converter. At present the function get_compensated_probe_voltages() returns the voltage from each column in the probe, so as well as identifying the I2C address of the required converter we also need to identify the source of each set of measurements. Since Plan A was to have three instantiations of the ManageHallEffectProbe() Class, there needs to be a way to tag each set of values with the ID of the converter.

The more I look at this, the more I get confused, I'm afraid.

I'll be going back to focusing on hardware construction today, I think

[hamishmb]

Naming convention for Stage Pi (a))

G123 makes sense, but I think there may be assumptions in the code that limit us to Gx:Py format - I think having more than 1 digit for the site might make it choke. By all means try it. We can of course fix this if desired.

Overall approach (b))

This seems like a good idea, certainly better than hard-coding the address like we have been. Maybe this should be a list. and be specified for all the pis, so the code can set up as needed the same way for each pi that uses an ADS? Some other changes will be needed to accommodate this, but it's probably a good way to go I think. A list makes it more interoperable with different numbers of ADS units, but a dictionary might be better, as Patrick suggested.

Whatever it is, I think it should go in config.py. I think a conditional check for 1 or 3 ADS units would work. but would need changing again later if

I'm not sure I understand the last question in your initial post Terry.

ADS objects being made outside of HallEffectProbe

There was definitely a reason, but I can't currently remember. I'll have a look. I think they might be used in multiple places, and I don't know if two separate ADS objects can be made for the same device. I imagine that it's not thread-safe to do that.

Hopefully this was a helpful post. I'm happy to chip in and help/do this bit if needed later anyway

[PatrickW]

With hindsight I think I have probably been more of a hindrance than a help here, but I definitely learnt a lot about the software framework in the process!

[TerryJC]

Well learning is a big part of the job and for me is part of the reason I do this stuff. I just wish my (almost) 70 year-old brain could think the way it did in my twenties

[PatrickW]

A list makes it more interoperable with different numbers of ADS units, but a dictionary might be better, as Patrick suggested.

Whatever it is, I think it should go in config.py.

One or both of us has definitely misunderstood the other! I would have thought we would just want a config in config.py, and make the objects elsewhere, but if you're following my suggestion AND putting it in config.py then you're instantiating the ADS objects directly in config.py?

Learning is definitely a big part of the job.

[TerryJC]

Naming convention for Stage Pi (a))

G123 makes sense, but I think there may be assumptions in the code that limit us to Gx:Py format - I think having more than 1 digit for the site might make it choke. By all means try it. We can of course fix this if desired.

I'm happy to stick with G3, as it is in the version of config.py I have here ATM. I was simply pointing out the anomoly and asking if anyone had a problem with it. Obviously, the comments / documentaion will highlight this.

Overall approach (b))

This seems like a good idea, certainly better than hard-coding the address like we have been. Maybe this should be a list. and be specified for all the pis, so the code can set up as needed the same way for each pi that uses an ADS? Some other changes will be needed to accommodate this, but it's probably a good way to go I think. A list makes it more interoperable with different numbers of ADS units, but a dictionary might be better, as Patrick suggested.

Whatever it is, I think it should go in config.py. I think a conditional check for 1 or 3 ADS units would work. but would need changing again later if

I too aren't sure what you mean here. In my current version of config.py, each A/D address is stored with the data for that probe. Presumably we would have to change that arrangement if we were going to add a List to the config. Personally, I like the approach that I've taken, ie, keeping the current format, so what I would like to see if we need this stuff in a List, is that this is done in coretools or devicemanagement.

I'm not sure I understand the last question in your initial post Terry.

I'm not sure I know which question you mean. I ended up saying "Any thoughts on all of this?"

Hopefully this was a helpful post. I'm happy to chip in and help/do this bit if needed later anyway

I'm definitely some way forward, but feel that I will need a bit of hand-holding to get this to work.

[hamishmb]

I'm happy to stick with G3, as it is in the version of config.py I have here ATM. I was simply pointing out the anomoly and asking if anyone had a problem with it. Obviously, the comments / documentaion will highlight this.

It's certainly the easier option and meaning should be clear.

I too aren't sure what you mean here. In my current version of config.py, each A/D address is stored with the data for that probe. Presumably we would have to change that arrangement if we were going to add a List to the config. Personally, I like the approach that I've taken, ie, keeping the current format, so what I would like to see if we need this stuff in a List, is that this is done in coretools or devicemanagement.

I think I forgot how the configuration worked. As long as there's a way of specifying which ADS to use for which hall effect probe, we should be fine

I'm a bit confused by this bit:

My thinking is that I need to modify this Class to accept the ADCAddress definition from config.py and then pass it to the ads object so that the correct A/D is read. My problem is that I'm a bit uncertain how to do that.

One or both of us has definitely misunderstood the other! I would have thought we would just want a config in config.py, and make the objects elsewhere, but if you're following my suggestion AND putting it in config.py then you're instantiating the ADS objects directly in config.py?

I misunderstood you, I think. I thought your suggestions were pretty good I was just thinking of having all the ADS information needed to set the ADS objects up in config.py. Instantiating the objects where needed (what we currently do) is the way to go I think. At the moment, this seems to be done in devicemanagement.py:

Code: Select all

#Setup for ADS1115 (A2D converter).
import board
import busio

import adafruit_ads1x15.ads1115 as ADS
from adafruit_ads1x15.analog_in import AnalogIn

# Create the I2C bus
i2c = busio.I2C(board.SCL, board.SDA)

# Create the ADC object using the I2C bus
ads = ADS.ADS1115(i2c)

I'm not sure how the address is being selected here to be honest. Perhaps this is what you were talking about earlier, Terry?

[TerryJC]

Code: Select all

#Setup for ADS1115 (A2D converter).
import board
import busio

import adafruit_ads1x15.ads1115 as ADS
from adafruit_ads1x15.analog_in import AnalogIn

# Create the I2C bus
i2c = busio.I2C(board.SCL, board.SDA)

# Create the ADC object using the I2C bus
ads = ADS.ADS1115(i2c)

I'm not sure how the address is being selected here to be honest. Perhaps this is what you were talking about earlier, Terry?

It isn't being selected in that code because when we originally wrote it we didn't know that we would have to read data back from multiple A/D Converter boards.

My reason for including it originally was so that I could explain my dilemma; how do I get the address to the Adafruit ADS1115 Class? Concatenating all of the points made above, I'd like to see something that allows me to pass the content of ADCAddress in config.py when I instantiate the ManageHallEffectProbe() Class and then use that address to ensure that the right board is read:

Code: Select all

ads1 = ADS1x15(address=ADCAddress) * Where 0x48 is content of ADCAddress
ads2 = ADS1x15(address=ADCAddress) * Where 0x49 is content of ADCAddress
ads3 = ADS1x15(address=ADCAddress) * Where 0x4B is content of ADCAddress ]

(Which isn't quite the same as the example code on the Adafruit website where the original came from.)

Leaving the exact syntax aside for the moment, address assigment doesn't have to happen when the i2c bus is created because the API for the Adafruit ADS1115 Class makes provision for the IC2 address. However, in our code, this is done outside of the ManageHallEffectProbe() Class, so I'm uncertain if I have to create three ads objects, (as above) and then pass these into the ManageHallEffectProbe() Class when I instantiate it or if I can pass the address into the ManageHallEffectProbe() Class when I instantiate each thread.

Then there is the problem of getting the measurements back into the right set of results of course.

[hamishmb]

Ah I see.

It might be better to have the ManageHallEffectProbe class instantiate them, as long as nothing else in devicemanagement.py needs them - I don't think we want to end up creating multiple ADS objects for the same physical device if we can help it.

If configured right, the ManageHallEffectProbe class will handle getting the measurements back right by itself

[TerryJC]

Ok I'll look into that.

I'm assuming that I would need to pass the device ID to the class, so that the decision can be made to create one or three ads objects.