GS4 Task Controller not consistently establishing a session

[trm01]

Hi,

I recently started looking around for a ISOBus TC client stack to integrate in my app and I came across this project and really like what I see (thanks!). I started kicking the tires on the stack with a Deere GS 4600 by running both the "task_controller_client" and the "seeder_example" from the advanced-example branch.

The seeder_example is enlightening. The issue I am encountering is that more often then not, the TC doesn't link up with the GS4. I see comparable behavior for both aforementioned TC client examples.

It is worth noting that the VT still works fine in the seeder example (it will alarm me that the TC isn't connected).

Does anyone have any idea what could cause this?

I've attached a candump of it not working in case that is relevant.

Below is the log output when it doesn't connect.

[Debug][NM]: A control function claimed address 240 on channel 0
Loaded object pool from BasePool.iop
[Debug][NM]: A control function claimed address 129 on channel 0
[Info][NM]: Partnered control function with name b0008200042ec3db has claimed address 251 on channel 0.
[Debug][NM]: A control function claimed address 237 on channel 0
[Info][NM]: Partnered control function with name a0001d00042d289d has claimed address 38 on channel 0.
[Debug][NM]: A control function claimed address 247 on channel 0
[Debug][NM]: A control function claimed address 210 on channel 0
[Debug][NM]: A control function claimed address 42 on channel 0
[Debug][NM]: A control function claimed address 238 on channel 0
[Debug][NM]: A control function claimed address 248 on channel 0
[Info][AUX-N]: New auxiliary input device with name: 11529362380695949046 and model identification code: 289
[Debug][AC]: Internal control function a008800008000002 could not use the preferred address, but has claimed address 128 on channel 0
[Warn][PR]: NACK-ing PGN request for PGN 65395 because no callback could handle it.
[Debug][VT/TC]: Language and unit data received from control function 38 language is: en
[Info][VT]: VT Server has a matching label for 1ecd97c. It will be loaded and upload will be skipped.
[Debug][TP]: Session Closed
[Info][VT]: Loaded object pool version from VT non-volatile memory with no errors.
[Debug][TC]: Startup delay complete, waiting for TC server status message.
[Debug][TP]: New Rx BAM Session. Source: 251
[Debug][TP]: Session Closed

Versus when it does link up:

[Debug][NM]: A control function claimed address 240 on channel 0
[Debug][NM]: A control function claimed address 129 on channel 0
[Info][NM]: Partnered control function with name a0001d00042d289d has claimed address 38 on channel 0.
[Info][NM]: Partnered control function with name a0008200042d289d has claimed address 247 on channel 0.
[Debug][NM]: A control function claimed address 210 on channel 0
[Debug][NM]: A control function claimed address 42 on channel 0
[Debug][NM]: A control function claimed address 238 on channel 0
[Debug][NM]: A control function claimed address 248 on channel 0
[Debug][NM]: A control function claimed address 251 on channel 0
[Debug][NM]: A control function claimed address 237 on channel 0
[Info][AUX-N]: New auxiliary input device with name: 11529362380695949046 and model identification code: 289
[Debug][AC]: Internal control function a008800008000002 could not use the preferred address, but has claimed address 128 on channel 0
[Warn][PR]: NACK-ing PGN request for PGN 65395 because no callback could handle it.
[Info][VT]: VT Server has a matching label for 1ecd97c. It will be loaded and upload will be skipped.
[Debug][TP]: Session Closed
[Info][VT]: Loaded object pool version from VT non-volatile memory with no errors.
[Debug][VT/TC]: Language and unit data received from control function 38 language is: en
[Debug][TC]: Startup delay complete, waiting for TC server status message.
[Debug][TC]: TC Server supports version 3 with 5 booms, 255 sections, and 5 position based control channels.
[Debug][TP]: New Rx BAM Session. Source: 251
[Debug][TP]: Session Closed
[Warn][TC]: Timeout waiting for version request from TC. This is not required, so proceeding anways.
[Warn][TC]: The TC is < version 4 but no VT was provided. Language data will be requested globally, which might not be ideal.
[Debug][VT/TC]: Language and unit data received from control function 240 language is: en
[Debug][VT/TC]: Language and unit data received from control function 38 language is: en
[Debug][VT/TC]: Language and unit data received from control function 38 language is: en
[Debug][TC]: DDOP Generated, size: 1421
[Debug][TC]: Server indicates there may be enough memory available.
[Debug][TP]: Session Closed
[Debug][TC]: DDOP upload completed with no errors.
[Info][TC]: DDOP Activated without error.
[Debug][TC]: TC Requests element 2 DDI: 160 on change by at least: 1
[Debug][TC]: TC Requests element 3 DDI: 158 on change by at least: 1
[Debug][TC]: TC Requests element 0 DDI: 141 on change by at least: 1
[Debug][TC]: TC Requests element 2 DDI: 161 on change by at least: 1
[Debug][TC]: TC Requests element 2 DDI: 290 on change by at least: 1
[Debug][TC]: TC Requests element 3 DDI: 11 on change by at least: 1
[Debug][TC]: TC Requests element 3 DDI: 12 on change by at least: 1
[Debug][TC]: TC Requests element: 3 DDI: 12 every: 1000 milliseconds.
[Debug][TP]: New Rx BAM Session. Source: 251
[Debug][TP]: Session Closed
^C[Debug][VT]: Requested object pool deletion from volatile VT memory.
[Info][VT]: VT Client connection has been terminated.

Thanks,
Tim

candump-2023-11-15_054601-tcbroken.log

[ad3154]

I think I know what the issue is - the NAME filter for the TC isn't specific enough for your use case.

In most of our examples we filter what qualifies as a TC (or a VT) by function code.
However, this isn't working for you because I can see you have another device on your bus with function code 130, but with industry group 3 (whereas a TC would be industry group 2). This device is identified as a "John Deere Land Leveling System Operator Interface".

So, basically what I assume is happening is we're matching whichever function 130 device address claims first 😅

Easy fix though I think - you just need to add an additional filter for industry group 2 in seeder.cpp.

Change these lines:

const isobus::NAMEFilter filterTaskController(isobus::NAME::NAMEParameters::FunctionCode, static_cast<std::uint8_t>(isobus::NAME::Function::TaskController));
const std::vector<isobus::NAMEFilter> tcNameFilters = { filterTaskController };

To:

const isobus::NAMEFilter filterTaskControllerFC(isobus::NAME::NAMEParameters::FunctionCode, static_cast<std::uint8_t>(isobus::NAME::Function::TaskController));
const isobus::NAMEFilter filterTaskControllerIG(isobus::NAME::NAMEParameters::IndustryGroup, 2);
const std::vector<isobus::NAMEFilter> tcNameFilters = { filterTaskControllerFC, filterTaskControllerIG };

Let me know if this clears up the issue for you!

If it does, we should probably update our examples across the board to be more choosey about their partners.

-Adrian

[trm01]

That did it! Both examples now come up consistently.

Thanks for the quick response.