Question about AUX inputs 2

[Matthieu-Poulain]

Hi guys,

As a customer has requested support for ISOBUS in our system, we are currently investigating whether we can fulfill this request. We have tested several ISOBUS features using AgIsoStack (great work, by the way, many thanks for your effort), including soft buttons and auxiliary inputs.

Everything worked fine on a neighbor's tractor, but when we tried the same test on the client's tractor, we were unable to find the Aux Functions to bind to the tractor joystick—they simply weren't displayed. Initially, we thought it was a mismatch in the Aux Function type (e.g., boolean latching, non-latching, etc.), but none of the different types worked.

The Virtual Terminals (VTs) on both of his Fendt tractors failed to work. My question is, have you ever encountered this behavior where your projects work on some VTs but not on others?

Additionally, I simply declared the Aux Functions in IsoDesigner. Do I need to work with object pointers, or are they unrelated?

Many thanks for any help you can provide!

[ad3154]

currently investigating whether we can fulfill this request

Are you using our CAN stack for this in your system? If it's not with our stack I am not sure how much help we can offer, but if it's AgIsoStack we can see what we can find out!

I am not a big expert on Aux-N to be honest, I have been relying on @GwnDaan for much of it 😅 but what would really help us to understand the issue you've been having is to share with us a CAN log showing your system connecting to the VT if possible, along with any logging output from the stack itself

[Matthieu-Poulain]

Thank you for your answer. I indeed used your stack with an esp32 to begin the project. Shame on me, i did not log the output when i was testing the system. I did try to set the output log in debug mode but it seems i couldn’t catch and kind of error between the flow of open/close session messages.

I was hoping to see first if any of you knew if the display of any Aux fonction/input was bound to the stack or if given a .iop file the VT was the only part required to parse, detect and submit it to user selection.

2nd and most recent fendt display seemed to group aux fonctions under a tab, which is not displayed in my case, so maybe i missed something here…

[Matthieu-Poulain]

Ok so after some digging in the standard, i found that the VT determines which workingsets provide auxiliary functions.
I'd be gratefuI if someone could confirm that the stack is not involved in the process of displaying those, except for the fact it tells the working set it is active.

Using IsoDesigner i also found Auxiliary Object Pointers but i'm not sure how and why they are used, the version i have of the standard ISO 11783-6:2018(F) being translated in french is a bit ambiguous...

[cerdei]

The primary terminal (VT number=1 or VT function instance=0) should check and list the AUX-N assignments, so the operator can view and edit them on this terminal only -> check VT number is 1 and no VT number conflict in case of multiple terminals.
On the other hand the ECU with the AUX function objects in its implement object pool should store these assignments in its non-volatile memory and should communicate it to the primary terminal at startup (and at some other special trigger events).
Auxiliary Object Pointers: can be used on AUX capable ECU's data masks (for input units like a joystick, or for your ECU with AUX function objects).
The primary terminal should show or list the related actual assigments (AUX function or input objects) when displaying these object pointers.

[Matthieu-Poulain]

The primary terminal (VT number=1 or VT function instance=0) should check and list the AUX-N assignments, so the operator can view and edit them on this terminal only -> check VT number is 1 and no VT number conflict in case of multiple terminals. On the other hand the ECU with the AUX function objects in its implement object pool should store these assignments in its non-volatile memory and should communicate it to the primary terminal at startup (and at some other special trigger events). Auxiliary Object Pointers: can be used on AUX capable ECU's data masks (for input units like a joystick, or for your ECU with AUX function objects). The primary terminal should show or list the related actual assigments (AUX function or input objects) when displaying these object pointers.

Hi, thank you for your clarifications. So if i understand well, the stack should report to the VT which AUX-functions are available in the .iop file, and if they are not displayed, it may be because of a faulty report?

Does anyone know where in the code these interactions are handled and where i should dig?

[cerdei]

Hi, there is no "report" for AUX function objects, these objects are simply part of the iop, and the (primary) terminal should detect them during the iop parsing process.
So that's why you have to declare these AUX function objects in your favorite pool editor (like ISO-Designer/Maskmaker).
You can also declare the AUX object pointer (Auxiliary Control Designator Type 2 Object Pointer) objects and place them on your data mask, but this is optional and not necessary for the basic functionality.
Based on your first comment the issue may be on the (Fendt) terminal side, but it is hard to tell without a CAN log.
If you encounter any problem, saving the actual terminal product name/type (like Fendt Varioterminal 10.4" or 7") and the CAN log for further investigation is always a good practice.

[Matthieu-Poulain]

Thank you so much for these clarifications.
So the VT is indeed responsible for parsing the .iop from where it should extract the Aux functions available for affectation.
Indeed, data loggin will be on my todo list on next test session, I was lacking experience :/

I understand i dont need AUX object pointers, but in order to have the full picture in mind, would you say that once added in the data mask, they would act kind of like a button?

[cerdei]

The AUX object pointers are some kind of visual helpers for the operator on the mask of the implement (baler, sprayer, etc.) or input unit (joystick, arm controller, switch box, etc.), for example:
The operator can use the mask of the joystick and baler to check the device/machine's graphical representation with the related AUX assignments placed close to its input (joystick button) or function (open baler door, stop baler belt, etc.).

An AUX object pointer's content is displayed by the terminal based on the actual (network-wide) AUX assignments,
so the operator can easily identify which - graphically represented - AUX function or input has:

• no assignment: a terminal-specific "icon" (X or something),
• one assignment: the assigned AUX function or input object's designator,
• multiple assignments: multiple designators or
  a terminal-specific icon ("+++" or something) to show them in a "popup window" or (filtered) assignment list (by pressing/activating the icon).

In this short video you can see:

• 0:22: arm controller mask - "no assignment" X icon inside all AUX object pointers
• 0:35: terminal's (built-in) AUX assignment editor - adding an assignment to the arm controller
• 1:16: arm controller mask again - the assigned AUX function (designator) is displayed in the related AUX object pointer (which is referencing the arm controller's specific input object)

Extra info: some terminals can be set up for AUX-O or AUX-N functionality,
please check it on the problematic terminal, like this (Fendt).

[Matthieu-Poulain]

Nice I understand it now. Thank you very much for your help!

[Matthieu-Poulain]

Hi guys,

I found the issue with the fendt terminal.
While implementing something to store the preferred assignments in my esp32, i removed lines that i had no idea would impact the displayed available Aux functions... What i can't explain is that this did work on the first Deere tractor i used to test.

(Note that the send_auxiliary_functions_preferred_assignment() was sent just ahead of this block, in the load_preferred_assignment_from_NVS function...

CANStackLogger::CAN_stack_log(CANStackLogger::LoggingLevel::Info, "[HQ_DBG]: LOADING PREF ASSIGNMENTS (Step 0).");									
parentVT->load_preferred_assignment_from_NVS(parentVT); // Does the parentVT->send_auxiliary_functions_preferred_assignment() inside
									
									
// if (parentVT->auxiliaryFunctionEventDispatcher.get_listener_count() > 0)
//{
//	if (parentVT->send_auxiliary_functions_preferred_assignment())
//	{
//		CANStackLogger::CAN_stack_log(CANStackLogger::LoggingLevel::Debug, "[AUX-N]: Sent preferred assignments after LoadVersionCommand.");
//	}
//	else
//	{
//		CANStackLogger::CAN_stack_log(CANStackLogger::LoggingLevel::Warning, "[AUX-N]: Failed to send preferred assignments after LoadVersionCommand.");
//	}
//}

Now i still have an issue to load those prefered AUX-N after a reboot.
It works fine when i reboot the esp32 and not the VT. However if i start both VT and ESP32 at the same time and VT is not up when esp32 stack is, then i loose my assignments. Has someone tried to implement AUX-N loading?

I tried to set this up from this commit here made by @GwnDaan : 0f845b2

On another note, i found this line to be maybe incorrect:

case static_cast<std::uint8_t>(Function::AuxiliaryAssignmentTypeTwoCommand):
{
	if (14 == message.get_data_length())
	{
		std::uint64_t isoName = message.get_uint64_at(1);
		//OLD VALUE:  bool storeAsPreferred = message.get_bool_at(9, 7);
		bool storeAsPreferred = !message.get_bool_at(9, 7);

As i found that the value to store as prefered is 0 in the ISO documents:

Lorsque l’opérateur a décidé d’attribuer un objet Entrée auxiliaire de type 2 à un objet Fonction
auxiliaire de type 2, le stockage comme bit d’attribution privilégiée doit être réglé sur 0. Maintenant,
cette attribution doit être stockée comme attribution privilégiée. Dans toutes les autres situations, elle
doit être réglée à 1

When the operator has decided to assign an Auxiliary Input type 2 object to an Auxiliary Function type 2 object, storage as the privileged assignment bit must be set to 0. Now, this assignment must be stored as a privileged assignment. In all other situations, it must be set to 1

As a result, if we use storeAsPreferred , we must invert the value of the bit...
Hope this can be of help.

[GwnDaan]

As a result, if we use storeAsPreferred , we must invert the value of the bit...

Hi @Matthieu-Poulain, you are absolutely right. That needs to be fixed.

The commit you linked has not been tested, it was just a simple draft. Hopefully you will manage to get it working! Without the full code I'm afraid we can't help you much .

It would be greatly appreciated if you could submit a PR with the necessary changes once the auxiliary assignments are fully functional. That would be really great

[Matthieu-Poulain]

Hi @GwnDaan,

Sure thing, I'll share with you what i find, however i did not go through the save engine you created, as i had to get it to work fast, i changed a bit the way it worked specifically for my ESP32, but maybe that could be usefull.

Would you happen to have an idea as to where should I place the functions that load the assignments in order to ensure this is done after the complete boot of the VT?
I found 3 places in the persistent-aux-n branch, but i'm yet to have this to work. Maybe it's related to the missing part of code of my previous message.

[GwnDaan]

I looked into this a bit more and found the following:

Would you happen to have an idea as to where should I place the functions that load the assignments in order to ensure this is done after the complete boot of the VT?

The function is already called in two places in the VT client:

1. After the LoadVersionCommand is received

   AgIsoStack-plus-plus/isobus/src/isobus_virtual_terminal_client.cpp

   Lines 2947 to 2958 in 80e95fe

   	//! @todo maybe a better way available than relying on aux function callbacks registered?
   	if (parentVT->auxiliaryFunctionEventDispatcher.get_listener_count() > 0)
   	{
   	if (parentVT->send_auxiliary_functions_preferred_assignment())
   	{
   	LOG_DEBUG("[AUX-N]: Sent preferred assignments after LoadVersionCommand.");
   	}
   	else
   	{
   	LOG_WARNING("[AUX-N]: Failed to send preferred assignments after LoadVersionCommand.");
   	}
   	}

2. After the EndOfObjectPoolMessage is received
   

   AgIsoStack-plus-plus/isobus/src/isobus_virtual_terminal_client.cpp

   Lines 3071 to 3082 in 80e95fe

   	//! @todo maybe a better way available than relying on aux function callbacks registered?
   	if (parentVT->auxiliaryFunctionEventDispatcher.get_listener_count() > 0)
   	{
   	if (parentVT->send_auxiliary_functions_preferred_assignment())
   	{
   	LOG_DEBUG("[AUX-N]: Sent preferred assignments after EndOfObjectPoolMessage.");
   	}
   	else
   	{
   	LOG_WARNING("[AUX-N]: Failed to send preferred assignments after EndOfObjectPoolMessage.");
   	}
   	}

These are the right places for the cases when no preference allocation is available, or when all preference units for auxiliary input(s) are ready.

But we need to resend the preference assignment if

• a preferred input unit is ready (and was previously not detected or not ready)
• an auxiliary input unit with active assignments has gone offline and/or reconfiguration with alternate auxiliary input units is desired.

I hope this helps in debugging the issue. (For more detailed info see chapter J.7.7 of part 6 of the standard, and also J.5 to understand the behavior of the VT)