address request/response 1EFI: 7DF - 7E8 use ATCRA7E8
address request/response 2EFI: 7DF - 7EA use ATCRA7EA
address request/response A/T: 7E1 - 7E9 use ATCRA7E9

take the initialization string:
ATSP6\nATSH7DF\nATCRA7E8 for 1efi
ATSP6\nATSH7DF\nATCRA7EA for 2efi
ATSP6\nATSH7E1\nATCRA7E9 for a/t

Thanks for the suggestion. I want to display and log data from both banks (both engine ECUs) at the same time - it looks like this would limit all data to just one of the ECUs. I've tried using ATCRA7Ex in the "Diagnostic start command" for custom PIDs, but it is not 100% reliable (I tried it with two different adapters).

to watch the two blocks at the same time, you need to create external PID to another block with a header of the second block 7EA

I had already tried custom PIDs with 7E0 and 7E2 as the OBD Headers, but they return "No data", same as from the commands from a telnet session. Or did you mean something different?

You take the initialization string?
ATSP6\nATSH7DF

I've already tried AT SH 7DF followed by AT SH 7E0 and a PID in a telnet session and got "No Data":

>AT SH 7DF
OK
>01 05
7E80341055F
7EA0341055F
7E90341055F
>AT SH 7E0
OK
>0105
NO DATA
>AT SH 7E1
OK
>0105
7E90341055F

I can try it in the initialization to see if that makes any difference (I'll try it this weekend - I'm out of town right now).

Hello!

Sorry I'm a bit late catching up with this thread.....

IIRC I put a bit of code in that stored the extra replies in a 'get-attable' pid in the app (though never used it so I may need to check it's still there)

You should be able to:

Start the app, view the relevant PID (that generates the multiple replies) as a normal OBD2 PID (one of the 'standard' sensors)

Torque will receive the multiple replies and /should/ store them all. It'll store the 'main/default' ECU one in the normal place but the others it should also store (and these, once populated, *may* be visible in TorqueScan in the list of pids (the scrollable list when you start the plugin))

I know I did this for pre-canbus vehicles. It may or may not be working for canbus as well (but should not be too difficult to add support if it's not)

The ECU's not responding when directly queried is a pain for when you're trying to setup a proper PID just for the one ECU. Kind of difficult to work around, though I should hopefully be able to get you running with a few minor mods if needed (or it may already just work)

Most excellent - I was hoping you had some hidden capability like this. I'll try it Saturday.

One of the options to create a file .csv with the external PIDs of the 2 blocks indicating the header and put the bird "Use alternative header OBD2"
the initialization string
ATSP6\nATSH7DF

Ian, I don't see any additional PIDs on the torque scan and I tried using "get-attable" various ways with no success. I'd appreciate if you could check if it is still in the code. If not, perhaps an implementation like this might work:
- Use the normal "OBD2 Mode and PID" (e.g. 010F) in a custom PID
- Use a special designator in the "OBD Header to use" where the desired ECU can be specified, e.g. "ECU:7E2" (or perhaps another field to specify the desired ECU, but that seems like a lot of extra work for this rare situation)
- Hopefully torque could optimize this to see it is not really a new PID, just an additional response so it does not have to make another OBD query

I was hoping the R0, R1, ... capability you added in 1.8.92 might provide access to the responses from the other ECU. I tried out past R20 and none seemed to provide the data from the other ECU. Any chance you could add the capability to (efficiently) access extra responses for any given PID in the next release?

Hi!

They're separate responses so Torque will take the first one for the equation parsing (the subsequent ones will be shelved and stored in the app which should have been visible in TorqueScan)

I'm a little busy this week to look at it (trying to get the theme updates out for all the dials), though I'll set something up to mirror your setup next week and see if I can make the app store the data elsewhere (as I can't overwrite existing PIDs). It should then be trivial to then add a custom PID for the other ECU

I never noticed the extra responses in TorqueScan, but I'll try it again tonight.

Sounds great, thanks!

Ian, I signed up for beta testing and can test whatever you can hack together for this.

Hi!

Apologies for the delay, I'm going to try to get to do this one tomorrow.

Any luck getting to this one Ian?

Are you sure these are the correct PIDs? I went through the complete database and couldn't find any of the mentioned addresses in any BMW ecu...

These are standard OBD-II PIDs ( https://en.m.wikipedia.org/wiki/OBD-II_PIDs), and I've tried others. 010F (mode 1, PID 0F) is intake air temperature and the returned data I see is as expected. This is when I use direct test commands to the 7DF broadcast address. The returned results are from two addresses, 7E0 (7E8 in the response) and 7E2 (7EA in the response). Those are presumably the two ECUs (the data looks reasonable).

Hi!

Sorry I haven't got to looking at this yet, though it is on my list of things to do (I need to look at why in some instances it's not sticking the extra data from the other ECUs in an accessible format for you) - should hopefully get to do this one in the coming week!