Get position at Master Brick with bricklet connected to an Isolator bricklet

[cl-]

Hi everyone,

I'm struggling or maybe my brain isn't as fresh anymore as I think it is.

I have an IndustrialDualAnalogInV2Bricklet (IDAI) connected to an Isolator Bricklet, which in turn is connected to the Master Brick.

How do I get the position at the Master Brick (a, b, c, d) to which the Isolator Bricklet is connected, by processing the enumerate response from the IDAI. When you process an enumerate response of the bricklet which is connected to the Isolator, it doesn't know about the "connected_uid" of the Isolator bricklet (as both, Isolator and IDAI won't show up in the same enumerate callback function, obviously). I can't ask the IDAI, because its position is always z, as it's behind an Isolator. I like to know the position of the Isolator bricklet at the Master Brick inside the enumerate callback of another bricklet (which is connected to the Isolator) There might be a complex way to get around this problem, but is there an easy way, which I just can't see at the moment?

What's the right way of doing this? I need to know the position of the Isolator Bricklet at the Master Brick, because I have multiple IDAI connected and the local channels of the IDAI (0, 1) have global channels in my setup. Think of having two IDAIs (going through Isolator bricklets) connected to the Master Brick (positions A and B), therefore you'll end up having four global voltage channels, that is IDAI A with channels 0 and 1 (connected to Brick at position A through Isolator A) and IDAI B with channels 0 and 1 (connected to Brick at position B through Isolator B). On the broader scale, I need to know which of the local IDAI channels maps to which global channel, in order to save the measured values in the IDAI callback receiver loop to the right locations in my data structure.

 

Cheers, Claudio

 

[photron]

This is not possible from a single enumerate callback, as you already figured out. Possible solutions:

a) In the Isolator enumerate callback you remember its UID and port. In the IDAI enumerate callback you compare the connected UID (this is the UID of the Isolator) to the Isolator UID/Port pairs you have remembered.

b) In the IDAI enumerate callback you use the connected UID (this is the UID of the Isolator) to call the get-identity function of the Isolator to get its port.

[cl-]

Ok. I guessed it wouldn't be possible right away. I know I could save the uids and ports of the other bricklets to get what I wanted.

Possibility a) only works (and that's why I was looking for another approach), in case the enumeration of the Isolator bricklet comes first in the sequence, that is after the IDAI enumerates. Is there a constant order in the enumeration process? Does it go from inside (bottom Master Brick at position 0) to outside the network topology?

Possibility b) doesn't work, at least from what your documentation says. Your comments in the source code say "For a Bricklet this ... [connected_uid] ... will be a UID of the Brick where it is connected to." Frankly, I started that way using the connected_uid of the EnumerateResponse object (Rust API), but when I found out, that I get the UID of the Master Brick instead of the Isolator, I gave up on this. If the documentation is misleading (or I just misunderstood, which is more likely) and I can use possibility b), that would be the approach I'd follow.

[cl-]

Possibility b) works. Great, thanks a lot for clarifying!

So maybe you could add one more sentence into the documentation that the connected_uid - in case a bricklet is connected to an Isolator - is indeed the Isolator and not, as the documentation states, the Brick it is connected to.

Again, thanks

[rtrbt]

Hi,

I agree, the documentation is a bit confusing there. I've changed this to

For a Bricklet this is the UID of the Brick or Bricklet it is connected to.
For a Brick it is the UID of the bottommost Brick in the stack.
For the bottommost Brick in a stack it is "0".

The change will soon be in the online documentation. The Rust (and Go) documentation in the code and on docs.rs will be updated with the next bindings release.

[cl-]

Thanks a lot. That will make it easier to understand.