Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SC: Pre On Off Time #446

Open
Eric-Bwr opened this issue Mar 8, 2024 · 2 comments
Open

SC: Pre On Off Time #446

Eric-Bwr opened this issue Mar 8, 2024 · 2 comments
Labels
enhancement New feature or request iso: task controller Related to the ISO-11783:10 standard question Further information is requested

Comments

@Eric-Bwr
Copy link

Eric-Bwr commented Mar 8, 2024

Hello,

is there any possibility to change the section control pre on off time?
for the tc client and/or server?

Maybe I missed it :)

@Eric-Bwr Eric-Bwr added the enhancement New feature or request label Mar 8, 2024
@ad3154
Copy link
Member

ad3154 commented Mar 9, 2024

This one is kind of a tricky one that I think has multiple approaches.

A few options come to mind for how one could do to do this "right".

  1. Read (or send) the DDIs for Physical Setpoint/Actual Time Latency (DDIs 142 and 143)
Quoting isobus.net:
The Setpoint Value Latency Time is the time lapse between the moment of receival of a setpoint value command by the working set and the moment this setpoint value is physically applied on the device. That means if the setpoint value is communicated on the network (CAN bus) but the system needs 2 seconds to adjust the value physically on the desired unit (device element) then the Setpoint Latency Time is 2 seconds. 
  1. Implement a proprietary DDI for this on both sides, which specifies the look-ahead time for section control
  2. Add an application specific way to set the look-ahead time for section control, in which case you'd just delay when you send the commanded setpoint work state for a given section.

The way that our TC server and client are written it kind of leaves this sort of functionality up to the application to interpret based on the vehicle speed and what you send or receive in the DDOP...

I am not really sure where to go with it architecturally in our stack, as those are all kind of application specific things. Do you have any thoughts about what it could look like @Eric-Bwr ?

@ad3154 ad3154 added question Further information is requested iso: task controller Related to the ISO-11783:10 standard labels Mar 9, 2024
@Eric-Bwr
Copy link
Author

Eric-Bwr commented Apr 2, 2024

Sorry for the late reply, yeah this one is hard...

I would go with option 1, but there still needs to be an algorithm that can actually predict when the implement reaches a certain point in time, and that is the hard part lol.
I hoped you guys had sorted that already but its a big undertaking.
For a start one could just delay the work state messages, that is doable.
Since I will be away from my computer in my spare time for a few weeks I would have to discuss it with my mates how far we want to go with this.
But this Feature is not too important, just nice to have. You only really need to adjust these if you goofed up on your implement geometry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request iso: task controller Related to the ISO-11783:10 standard question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants