Section Control On Esp32

[SpiceFormDune]

Hello, I’m trying to implement the SC features on my generic ESP32 board. The VT and TC connect to the server (on my tractor) correctly. SC even starts working because I can see that my tractor sends PGN messages through the UART debug, and I can observe the setpoint value when I enter a zone where the sections should be off.

However, I don’t receive any messages when the sections should be on. I even performed a CAN trace, identified the ID that sends the DDI commands, and verified the correct message when the sections should be off. But when the sections should be on, it’s not working.

What could be the issue? Could it be something related to the DDOP settings during the TC setup?

I used the Seeder And TC client example from stack just a little changes for ESP32

[ad3154]

Can you please include a CAN trace? We'll need to see the DDOP upload and the subsequent commands to get a full picture of what's happening.

It's probably something simple, like the section control or prescription control state being 0....

[SpiceFormDune]

First of all, thank you so much for taking the time to respond, especially during the New Year. You've done an excellent job with this stack—it’s truly impressive!

I included the file containing the CAN trace and checked the ID where the DDIs appear, which is 0x0CCB80F7. After starting the trace, I initiate the task and enter and exit the area where the sections are supposed to run twice.

When checking the Setpoint DDI ID, I noticed that the Setpoint DDI only comes when exiting the area, but no value is observed upon entering. I debugged this using a printf statement I added to the value callback, and the value output in the terminal is -65536. This indicates that the desired value for 8 sections (the target count) has its bits zeroed out when converted to binary. As I mentioned, I only get this value when the sections are supposed to be off.

case static_cast<std::uint16_t>(isobus::DataDescriptionIndex::SetpointCondensedWorkState241_256):
{
   std::uint16_t sectionIndexOffset = NUMBER_SECTIONS_PER_CONDENSED_MESSAGE * (DDI - static_cast<std::uint16_t>(isobus::DataDescriptionIndex::SetpointCondensedWorkState1_16));
   printf("PROCESS VAL : %ld\n", processVariableValue);
   for (std::uint_fast8_t i = 0; i < NUMBER_SECTIONS_PER_CONDENSED_MESSAGE; i++)
   {
       sim->set_section_state(sectionIndexOffset + i, (0x01 == (processVariableValue >> (2 * i) & 0x03)));
   }
}

---

Additionally, I also checked the SectionControl DDI, and its value is as expected: 1.

The issue I suspect, though I’m not completely sure, is that the TC server might always consider the unit states to be on, and it only sends the command when they go off. However, I can’t get any request commands to report this to TC. It might be something missing during the initialization of DDOP or TC. I used the example code provided with the stack, but could this be related to the ESP32?

I also tried another Seeder example and faced issues with std::vector<> variables returning incorrect sizes. For instance, no matter which unit count I set, it always returned 16. I'm not entirely sure if this is related to the issue.
canout.txt

[SpiceFormDune]

I am still having the same problem. Has anyone successfully gotten the section control feature to work in the field?

[GwnDaan]

Hi there, I have been able to successfully use section control with the stack last summer in the field.

But I think your suspicion is correct. I also see your TC only sending the SetpointCondensedWorkState1_16 with 8 sections to off. I'm wondering whether #486 fixes your issue. Note that there is still one comment open.

Are you able to provide more information about your setup? I.e. which tractor are you using and which version TC does it have? Also exact codebase you're running on the ESP32 would be useful to have. And lastly the logs that the canstack outputs to CANStackLogger tells a lot

[SpiceFormDune]

Hi,

My tractor is NH T7.300, and it can use both TC versions. I tested the SC feature on both versions and I have been using SC machines from other manufacturers without error , but now with ESP32 the issue remains the same.

Additionally, I followed your recommendation and switched to the specified branch using PlatformIO:

lib_deps = https://github.com/Open-Agriculture/AgIsoStack-plus-plus.git#adrian/tc-default-process-data

However, the problem still persists.

This is how I initialize the TC. The create_ddop function here is identical to the one in the stack example:

void init_tc_client(std::shared_ptr<isobus::InternalControlFunction> InternalECU, std::shared_ptr<isobus::PartneredControlFunction> PartnerVT){

		const isobus::NAMEFilter filterTaskController(isobus::NAME::NAMEParameters::FunctionCode, static_cast<std::uint8_t>(isobus::NAME::Function::TaskController));
		const isobus::NAMEFilter filterTaskControllerInstance(isobus::NAME::NAMEParameters::FunctionInstance, 0);
		const isobus::NAMEFilter filterTaskControllerIndustryGroup(isobus::NAME::NAMEParameters::IndustryGroup, static_cast<std::uint8_t>(isobus::NAME::IndustryGroup::AgriculturalAndForestryEquipment));
		const isobus::NAMEFilter filterTaskControllerDeviceClass(isobus::NAME::NAMEParameters::DeviceClass, static_cast<std::uint8_t>(isobus::NAME::DeviceClass::NonSpecific));
		const std::vector<isobus::NAMEFilter> tcNameFilters = { filterTaskController,
													  filterTaskControllerInstance,
													  filterTaskControllerIndustryGroup,
													  filterTaskControllerDeviceClass };

		auto PartnerTC = isobus::CANNetworkManager::CANNetwork.create_partnered_control_function(0, tcNameFilters);

		TCClientInterface = std::make_shared<isobus::TaskControllerClient>(PartnerTC, InternalECU, PartnerVT);
		
		ddop = std::make_shared<isobus::DeviceDescriptorObjectPool>(3);

		mySC = std::make_shared<SectionControl>();

		uint8_t sectionCount = 8;

		mySC->set_number_of_sections(sectionCount);

		tractorSpeedMessages = std::make_shared<SpeedMessagesInterface>(InternalECU, false, false, false, false);

		tractorSpeedMessages->initialize();
		tractorSpeedMessages->get_machine_selected_speed_data_event_publisher().add_listener(handle_machine_selected_speed);
		tractorSpeedMessages->get_ground_based_machine_speed_data_event_publisher().add_listener(handle_ground_selected_speed);
		tractorSpeedMessages->get_wheel_based_machine_speed_data_event_publisher().add_listener(handle_wheel_selected_speed);

		if (mySC->create_ddop(ddop, TCClientInterface->get_internal_control_function()->get_NAME()))
		{
				TCClientInterface->configure(ddop, 1, sectionCount, 1, true, false, true, false, true);
				TCClientInterface->add_request_value_callback(SectionControl::request_value_command_callback, &mySC);
				TCClientInterface->add_default_process_data_requested_callback(SectionControl::default_process_data_request_callback, &mySC);
				TCClientInterface->add_value_command_callback(SectionControl::value_command_callback, &mySC);
				TCClientInterface->initialize(true);
		}
		else
		{
				printf("Failed generating DDOP. TC functionality will not work until the DDOP structure is fixed.\n");
		}
}

I also tried both DDOP functions from the seeder and TC client examples, but the issue persists.

Here are the logs:

W (353181) AgIsoStack: [Warn][PR]: NACK-ing PGN request for PGN 64834 because no callback could handle it.
I (353261) AgIsoStack: [Info][NM]: Control function with address 240 and NAME a000860078a0007b is now offline on channel 0.
I (353621) AgIsoStack: [Info][NM]: External CF 'a000860078a0007b' is evicted from address '254' on channel '0', as their address is probably stolen.
I (353991) AgIsoStack: [Info][NM]: External control function with name a000860078a0007b has claimed address 240 on channel 0.
I (354081) AgIsoStack: [Info][VT]: VT Server has a matching label for dks2   . It will be loaded and upload will be skipped.
I (354121) AgIsoStack: [Info][VT]: Loaded object pool version from VT non-volatile memory with no errors.
I (359871) AgIsoStack: [Info][TC]: Task controller structure labels do not match. DDOP will be deleted and reuploaded.
I (360311) AgIsoStack: [Info][TC]: DDOP Activated without error.
W (364731) AgIsoStack: [Warn][TC]: TC sent us a PDNACK
P VAL = -65536

The P VAL is just my printf debug to see changes on point state but its still giving me only off signals
I hope these helps!