Hello, I have a couple of questions on the CAN poll TX framework. Is there a recommended method for adding a one-time CAN poll to the queue with the response to be processed by IncomingPollReply? What is the recommended method for adding or modifying obdii_polls after initialization? Thank you
Currently, Not really, however I have some stuff in the pipeline that permits exactly this kind of thing. IF you would like, I could push it up to my own branch to my github account. (I've been pushing up bits and pieces and working with the main devs on the feedback). One way you _could_ do it, I guess, is to make a copy of your poll struct, include the one-off poll you wanted, and just temporarily modify the values to a 1 (you'd want to lock the poll mutex) and change it back to 0 after receiving the result. The below example actually calls back on Incoming_Full with the full data after receiving all the frames.. but you can also make a OnceOffPoll that just allows it to go into the normal Incoming functions. This one will even retry 3 times in the case it gets a failure the first time. //.ichael ----8<------------------- example --------------------[ bool OvmsHyundaiIoniqEv::PollRequestVIN() { if (!StdMetrics.ms_v_env_awake->AsBool()) { ESP_LOGV(TAG, "PollRequestVIN: Not Awake Request not sent"); return false; } auto poll_entry = std::shared_ptr<OvmsPoller::OnceOffPoll>( new OvmsPoller::OnceOffPoll( std::bind(&OvmsHyundaiIoniqEv::Incoming_Full, this, _1, _2, _3, _4, _5), std::bind(&OvmsHyundaiIoniqEv::Incoming_Fail, this, _1, _2, _3, _4, _5), VEHICLE_OBD_BROADCAST_MODULE_TX, VEHICLE_OBD_BROADCAST_MODULE_RX, VEHICLE_POLL_TYPE_OBDIIVEHICLE, 2, ISOTP_STD, 0, 3/*retries*/ )); PollRequest(m_can1, "!xiq.vin", poll_entry); return true; } On Sat, 17 Jun 2023 at 07:37, Solterra <solterra@kezarnet.com> wrote:
Hello,
I have a couple of questions on the CAN poll TX framework.
Is there a recommended method for adding a one-time CAN poll to the queue with the response to be processed by IncomingPollReply?
What is the recommended method for adding or modifying obdii_polls after initialization?
Thank you _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Solterra, Am 17.06.23 um 01:37 schrieb Solterra:
Is there a recommended method for adding a one-time CAN poll to the queue with the response to be processed by IncomingPollReply?
For single-shot requests you can either use the synchronous `OvmsVehicle::PollSingleRequest()` method(s) or temporarily replace the PID list via `OvmsVehicle::PollSetPidList()`. For the latter, you'd reinstall your standard PID list in the incoming handler once you've received the response.
What is the recommended method for adding or modifying obdii_polls after initialization?
In most situations you only need to switch polls partially or change the poll frequency. For this, use the up to four poll state timings per list entry, and call `OvmsVehicle::PollSetState()` to switch the current state. If you need to fully replace a poll list: 1. Lock the poller mutex 2. Remove the current PID list 3. Create / modify your PID list 4. Install the new / modified PID list 5. Unlock the poller mutex For dynamically created PID lists and/or combining predefined with dynamic entries, use a C++ std::vector & std::initializer_list. For a full example of this and also an example for how to do the PID list update, see the `vehicle_vweup` OBD module: * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master... * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master... Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Thanks for the tips. For my first question, I initially copied the what the Ionic5 module did for VIN request, but it doesn't really fit with the framework of my vehicle module. I'm in the process of refactoring and figured there were other instances where I'll just want to send a one-time poll and let the framework process the response. Your response points me down the right path... For my second question, I'm considering a command where I need to enter a UDS diagnostic session and will need to add a poll to keep the ECU in that session. I don't always need the poll, but once I do I need it every 2 seconds or so. Then, at the end of the session, I'll return the polling back to the 'standard'. Things are going well with my module, by the way. I'm having trouble where the communications gateway ECU goes to sleep when the vehicle is 'off' and I dont yet know how to wake it up. This might cause some charging sessions to be missed. I haven't decided if I care yet or not, as my initial use case is most important when the vehicle is on. I'm going to do some reverse engineering of the Toyota TIS software communication today to see how they keep the communications gateway ECU awake. On 2023-06-17 03:01, Michael Balzer wrote:
Solterra,
Am 17.06.23 um 01:37 schrieb Solterra:
Is there a recommended method for adding a one-time CAN poll to the queue with the response to be processed by IncomingPollReply?
For single-shot requests you can either use the synchronous `OvmsVehicle::PollSingleRequest()` method(s) or temporarily replace the PID list via `OvmsVehicle::PollSetPidList()`.
For the latter, you'd reinstall your standard PID list in the incoming handler once you've received the response.
What is the recommended method for adding or modifying obdii_polls after initialization?
In most situations you only need to switch polls partially or change the poll frequency. For this, use the up to four poll state timings per list entry, and call `OvmsVehicle::PollSetState()` to switch the current state.
If you need to fully replace a poll list:
* Lock the poller mutex * Remove the current PID list * Create / modify your PID list * Install the new / modified PID list * Unlock the poller mutex
For dynamically created PID lists and/or combining predefined with dynamic entries, use a C++ std::vector & std::initializer_list.
For a full example of this and also an example for how to do the PID list update, see the `vehicle_vweup` OBD module:
* https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master... * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master...
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Oh, I just realised I did not clarify that the example VIN code is where I'm heading to.. Not what exists now. Presumably you looked at what I have now in the Ioniq 5 code. There are keep-alive mechanisms and examples around. Michael On Sat, 17 June 2023, 7:46 pm Solterra, <solterra@kezarnet.com> wrote:
Thanks for the tips.
For my first question, I initially copied the what the Ionic5 module did for VIN request, but it doesn't really fit with the framework of my vehicle module. I'm in the process of refactoring and figured there were other instances where I'll just want to send a one-time poll and let the framework process the response. Your response points me down the right path...
For my second question, I'm considering a command where I need to enter a UDS diagnostic session and will need to add a poll to keep the ECU in that session. I don't always need the poll, but once I do I need it every 2 seconds or so. Then, at the end of the session, I'll return the polling back to the 'standard'.
Things are going well with my module, by the way. I'm having trouble where the communications gateway ECU goes to sleep when the vehicle is 'off' and I dont yet know how to wake it up. This might cause some charging sessions to be missed. I haven't decided if I care yet or not, as my initial use case is most important when the vehicle is on.
I'm going to do some reverse engineering of the Toyota TIS software communication today to see how they keep the communications gateway ECU awake.
On 2023-06-17 03:01, Michael Balzer wrote:
Solterra,
Am 17.06.23 um 01:37 schrieb Solterra:
Is there a recommended method for adding a one-time CAN poll to the queue with the response to be processed by IncomingPollReply?
For single-shot requests you can either use the synchronous `OvmsVehicle::PollSingleRequest()` method(s) or temporarily replace the PID list via `OvmsVehicle::PollSetPidList()`.
For the latter, you'd reinstall your standard PID list in the incoming handler once you've received the response.
What is the recommended method for adding or modifying obdii_polls after initialization?
In most situations you only need to switch polls partially or change the poll frequency. For this, use the up to four poll state timings per list entry, and call `OvmsVehicle::PollSetState()` to switch the current state.
If you need to fully replace a poll list:
1. Lock the poller mutex 2. Remove the current PID list 3. Create / modify your PID list 4. Install the new / modified PID list 5. Unlock the poller mutex
For dynamically created PID lists and/or combining predefined with dynamic entries, use a C++ std::vector & std::initializer_list.
For a full example of this and also an example for how to do the PID list update, see the `vehicle_vweup` OBD module:
- https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master... - https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master...
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Thanks for the help. I ended up going with PollSingleRequest for the one-off messages (VIN request, Charge Type, and Charge Mode so far...). It seems like sometimes it inturrupts a poll Tx/Rx cycle (receives the Rx from a previous poll and fails), so I added a retry in those instances. Code snip below. I'll probably encapsulate that (poll and retry) into a function to do a one-off requests. I saw your post in March about changes to the OBD Poller (paying more attention now that I'm writing code...) Is that change still in the works? It sounds great. void OvmsVehicleToyotaETNGA::RequestChargeType() { std::string response; int chargeType; int maxRetries = 5; int retryCount = 0; int res; while (retryCount < maxRetries && res != POLLSINGLE_OK) { res = PollSingleRequest( m_can2, PLUG_IN_CONTROL_SYSTEM_TX, PLUG_IN_CONTROL_SYSTEM_RX, VEHICLE_POLL_TYPE_READDATA, PID_CHARGING_VOLTAGE_TYPE, response, 1000, ISOTP_STD ); if (res == POLLSINGLE_OK) { // Request successful chargeType = response[0] & 0xFF; SetChargeType(chargeType); break; } else { retryCount++; ESP_LOGW(TAG, "RequestChargeType: Request failed with error code %d. Retrying (%d/%d)", res, retryCount, maxRetries); } } if (res != POLLSINGLE_OK) { ESP_LOGE(TAG, "RequestChargeType: Maximum retries reached. Request failed with error code %d", res); } } On 2023-06-19 21:49, Michael Geddes wrote:
Oh, I just realised I did not clarify that the example VIN code is where I'm heading to.. Not what exists now. Presumably you looked at what I have now in the Ioniq 5 code.
There are keep-alive mechanisms and examples around.
Michael
On Sat, 17 June 2023, 7:46 pm Solterra, <solterra@kezarnet.com> wrote:
Thanks for the tips.
For my first question, I initially copied the what the Ionic5 module did for VIN request, but it doesn't really fit with the framework of my vehicle module. I'm in the process of refactoring and figured there were other instances where I'll just want to send a one-time poll and let the framework process the response. Your response points me down the right path...
For my second question, I'm considering a command where I need to enter a UDS diagnostic session and will need to add a poll to keep the ECU in that session. I don't always need the poll, but once I do I need it every 2 seconds or so. Then, at the end of the session, I'll return the polling back to the 'standard'.
Things are going well with my module, by the way. I'm having trouble where the communications gateway ECU goes to sleep when the vehicle is 'off' and I dont yet know how to wake it up. This might cause some charging sessions to be missed. I haven't decided if I care yet or not, as my initial use case is most important when the vehicle is on.
I'm going to do some reverse engineering of the Toyota TIS software communication today to see how they keep the communications gateway ECU awake.
On 2023-06-17 03:01, Michael Balzer wrote:
Solterra,
Am 17.06.23 um 01:37 schrieb Solterra: Is there a recommended method for adding a one-time CAN poll to the queue with the response to be processed by IncomingPollReply? For single-shot requests you can either use the synchronous `OvmsVehicle::PollSingleRequest()` method(s) or temporarily replace the PID list via `OvmsVehicle::PollSetPidList()`.
For the latter, you'd reinstall your standard PID list in the incoming handler once you've received the response.
What is the recommended method for adding or modifying obdii_polls after initialization? In most situations you only need to switch polls partially or change the poll frequency. For this, use the up to four poll state timings per list entry, and call `OvmsVehicle::PollSetState()` to switch the current state.
If you need to fully replace a poll list:
* Lock the poller mutex * Remove the current PID list * Create / modify your PID list * Install the new / modified PID list * Unlock the poller mutex
For dynamically created PID lists and/or combining predefined with dynamic entries, use a C++ std::vector & std::initializer_list.
For a full example of this and also an example for how to do the PID list update, see the `vehicle_vweup` OBD module:
* https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master... * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master...
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (3)
-
Michael Balzer -
Michael Geddes -
Solterra