Getting/Setting device offsets / section control on/off delays on ISO implements

[freggala]

The task_controller_client and the seeder example both demonstrate how DDOP is built dynamically. Amongst other elements, there's a DeviceElement named "Connector" which has some DeviceProcessData objects like "Connector X":

retVal &= poolToPopulate->add_device_process_data("Connector X", static_cast<std::uint16_t>(isobus::DataDescriptionIndex::DeviceElementOffsetX), static_cast<std::uint16_t>(ImplementDDOPObjectIDs::ShortWidthPresentation), static_cast<std::uint8_t>(isobus::task_controller_object::DeviceProcessDataObject::PropertiesBit::Settable), 0, static_cast<std::uint16_t>(ImplementDDOPObjectIDs::ConnectorXOffset));

To provide a value for this DPD to the TC I added eg.

case static_cast<std::uint16_t>(isobus::DataDescriptionIndex::DeviceElementOffsetX):
{
	value =  2850;
}
break;

to the switch statement inside request_value_command_callback(...).

If, however, a user tries to change that setting through the TC's implement setup GUI, how can I make the tc client/seeder receive that event and the new value?
I would assume I have to add AvailableTriggerMethods::OnChange to the DPD creation,

retVal &= poolToPopulate->add_device_process_data("Connector X", static_cast<std::uint16_t>(isobus::DataDescriptionIndex::DeviceElementOffsetX), static_cast<std::uint16_t>(ImplementDDOPObjectIDs::ShortWidthPresentation), static_cast<std::uint8_t>(isobus::task_controller_object::DeviceProcessDataObject::PropertiesBit::Settable), static_cast<std::uint8_t>(isobus::task_controller_object::DeviceProcessDataObject::AvailableTriggerMethods::OnChange), static_cast<std::uint16_t>(ImplementDDOPObjectIDs::ConnectorXOffset));

and add another case to the switch statement inside value_command_callback(...)

case static_cast<std::uint16_t>(isobus::DataDescriptionIndex::DeviceElementOffsetX):
{
	std::cout << "set DeviceElementOffsetX to " << processVariableValue << std::endl;
}
break;

That doesn't work though (tested on a JD Gen4 4640 display), as I never get to see that message.
I'd like to use this to store offset and delay (DataDescriptionIndex::SCTurnOnTime, DataDescriptionIndex::SCTurnOffTime) settings inside the tc client.
What's my mistake?

[ad3154]

The request_value_command_callback callback is used when the TC requests a value, but the value_command_callback is used when the TC itself want to set a value. So you are right to handle it in both places if you want it to work.

If the TC isn't requesting the value, or setting the value, you could try adding it to the default set isobus::task_controller_object::DeviceProcessDataObject::PropertiesBit::MemberOfDefaultSet or maybe give it a trigger, such as the on-change trigger isobus::task_controller_object::DeviceProcessDataObject::AvailableTriggerMethods::OnChange (and make sure to update your structure label if you do change the DDOP).

Admittedly, I haven't checked the connector data on my terminal - I'll try to take a look myself.
Apologies my responses have been a little slow here as it's a holiday weekend!

[trm01]

I was able to get the TC to re-initialize the DDOP. I added the "set_state(Disconnected)" the the TC client terminate() call, but I had to ensure that I never called the update() function again, not until after calling configure() and initialize().

[GwnDaan]

Sorry for the delay! I created an issue #354 to keep track of the progress of restarting the TC client.

For your question about changing the number of sections while the TC client is running, I'm not sure. I haven't really worked much with the TC yet, but from reading the standard, I make an educated guess that one is only allowed to make "presentation" updates. So changing the number of sections is not part of that, since it add/removes objects in the DDOP and hence not allowed at runtime, I think?

Also I think there should be some way of de-activating the object pool and then re-transmitting the pool? Then a full restart isn't necessary. Maybe @ad3154 knows more?

[ad3154]

Thanks for creating that issue @GwnDaan as I do agree that that should be cleaned up.

Changing DPTs' values at runtime or adding/removing objects in the DDOP will always require completely re-uploading the DDOP, which we could and should allow I suppose, without deleting the interface. It should be fairly simple to add this functionality.

I don't think we'd want to monitor the DDOP for changes though? We'd never know when the consuming application was done changing the pool, so we could inadvertently do multiple unneeded re-uploads... It would have to be a function that the user calls very deliberately to request a re-upload to the TC. This also puts it on the consumer to handle the user experience side of this behavior, because otherwise we could break any TC task that's in progress at the time. Basically, if the user has a job/task open on their TC, and the client deletes the DDOP (using the delete message, not like, deleting the shared pointer) to upload a new one suddenly, that could cause incomplete logging to occur or the user would have to manually exit and restart their logging, for example.

So yeah, I'm thinking we should add a function that transmits the delete pool message, then does a re-upload through our state machine.

[trm01]

Yea, i don't think having monitoring the DDOP makes much sense.

Maybe "changing the section count" is a bad example. I'm fairly new to ISOBus and learning as I go, but I have been trying to make sense of the spec and how I can make it work from my application. I find myself wondering if I can change my specific settings without the need to re-upload the DDOP. For my use case I am reloading the DDOP when my number of booms and tanks changes (at runtime) and also the "Actual Cultural Practice" of those tanks may change too. Looking a bit closer at the spec, I should be able to change the "Actual Cultural Practice" from properties to "on change" process data. However, handling the varying number of booms/tanks, I'm not sure what to do yet. I'll try forcing their "Actual Work State" to disabled on a couple different consoles and see how some of the TC servers will handle it.

[ad3154]

Sounds good, feel free to review my proposed additions for reuploading the DDOP and resetting the TC connection in this PR if you like: #363