Repository navigation
|
Is it possible from application side to force a new address claim sequence to start? |
Replies: 4 comments 15 replies
|
It depends on what you want to achieve here. Do you:
Or
Both of these would be a bit unusual, though. |
|
Thanks for the answer. |
|
Any update on this question, i.e. how do I force a address claim? |
|
There has historically not been a way to do it, so I have added one in this PR: #553 as I can see it being valuable. |
|
This is now merged into |
|
That sounds very good. Thanks for the work! |
|
@ad3154 I tested your change and it almost worked. I can see the the request messages goes out and that the participants on the network starts sending their addresses. All except the internal control function that asked for the request, it seems that this control function is not getting the request, is there a "filter" that the issuer is not getting the message that was sent out? |
|
Makes sense that the internal control function never "receives" it... I will see what I can do about that as well. |
|
Can you try commit 3bb8672 on branch |
|
I have tested your change and it seems to work now. Thanks! |
|
@ad3154 Do you think that your patch can be merged to main in the near future? |
|
Yeah, shouldn't be long, just waiting on a code review from one of the other contributors. |
|
@ad3154 I ran into a problem with our TaskController. The active / primary / working TC should be on address 247. As you can see from these logs we instantly claim a new address. I think we should try to claim the original 247 address. If our NAME / priority is higher (lets say 1st vs 3rd) then we should have address 247 and the previous ECU should pic itself address 130. (According to the standard we should wait for some seconds after the address claim for all the ECU-s to settle on a new address.) But instead of that we instantly grab 130 because 247 is taken. [17:37:06.243] [Init] Creating Task Controller control function... |
|
@ad3154 pretty much all the TC-s behave weird when we can't evict them... |
The TCs? Or the clients? What do they do? |
|
The clients expect Task controllers at 247 and I'd have to evict the Task Controllers from there so mine can take that address. |
|
This is squarely a misbehavior of the client then, and should be fixed in the client... relying on the preferred address is not in the sprit of the standard IMO. But, I get it, reality is that manufacturers just do whatever they want for some reason, so we should make some attempt to interoperate. So, with that in mind, maybe there is a compromise to be made - maybe for addresses outside of an internal control function's industry group arbitrable address range (like F7 for TC), maybe we should do the eviction, but if the user passes no preferred address (the null address) or something within that range, then maybe as long as they allow arbitration in their NAME, then we continue being friendly and going to an unused address.... I can probably take a look later today |
It depends on what you want to achieve here.
Do you:
Or
Both of these would be a bit unusual, though.