Thanks Michael,

With my current knowledge of the behavior of  the eUp I don't think this will help. Reason: When the polls are too frequent the car will never shut down. So the only possibility is to use the 12V voltage level to see if the 12V battery is charging or not.

I will go forward now and put some usable features into the source. I will go and have a VCDS session tomorrow (hopefully) to see what it is doing and to sniff the ExtendedDiagSession messages which it hopefully uses.

Soko


On 09.08.2020 13:04, Michael Balzer wrote:
UpMiiGo guys,

Am 30.07.20 um 14:43 schrieb Soko:
Can I somehow get called (in my vehicle-class) if an can-error is thrown?
Am 30.07.20 um 16:17 schrieb Michael Balzer:
CAN tx errors can be caused by other issues as well, so should generally not be interpreted that way.

According to Chris on the GE forum, you're also seeing CAN tx errors on the Komfort CAN bus, so maybe it actually makes sense for you to check for CAN errors.

There are two options:
  1. Register a TX callback for a specific TX frame
  2. Register a general TX callback

Option 1 is currently not supported by the poller framework (but could be added). For a manual frame transmission, simply set the frame callback pointer to your handler:

static void CAN_tx_callback(const CAN_frame_t* frame, bool success) {
  if (!success) {
    // tx failure
  }
}

…

  CAN_frame_t txframe;
  txframe = {};
  txframe.MsgID = 0x705;
  txframe.FIR.B.DLC = 8;
  txframe.data = { 0x…, 0x…, … };
  txfrane.callback = CAN_tx_callback;
  txframe.Write(m_can3);


Option 2 uses the same handler signature. A handlers is registered as a general callback like this, e.g. on vehicle init:

    MyCAN.RegisterCallback(TAG, CAN_tx_callback, true);

You can also register an RX callback by passing "false" or omitting the third argument. On unloading the vehicle module, simply do:

    MyCAN.DeregisterCallback(TAG);


CAN callbacks are called directly within the CAN driver context prior to all standard queues, so can be used for very fast CAN responses -- and thus need to be very fast too, to not affect CAN driver throughput. Don't do any complex processing in the handler, avoid anything that could block the task.

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