PEAK-System Forum

(I'm considering purchase of this development package, but would like some information regarding transmit behavior and completion status to help in making the determination.)

I understand that it is not possible with PCAN-Basic to obtain a timestamp for a transmitted frame. Is this possible when using PCAN-Developer 4?

I read the product description, and so understand that a second client (on a 'net') can be used to see the messages that a first client sends, but there is no indication as to whether the second client sees this only after the message is actually sent on the bus (and acknowledge bit received). Such an approach might still require comparing outstanding transmit requests against received messages to recover the status of a particular transmit request (but hopefully the API provides a strict association between request and status). There is also the question of whether and how transmit failures / timeouts are indicated.

A related concern is whether outstanding transmit requests can be reordered in the transmit queue based on priority (or arbitration ID), and if so, whether this is a controllable feature.

Hello,

BStout wrote:I understand that it is not possible with PCAN-Basic to obtain a timestamp for a transmitted frame.

Correct. PCAN-Basic doesn't offer a way to obtain the time at which a message was transmitted. Thought, you can get an estimated time by using the Windows API function QueryPerformanceTime, since this is internally used for timing calculation.

BStout wrote:Is this possible when using PCAN-Developer 4?

Yes, with PCAN-API (PCAN-Developer 4 API), you can set a parameter called SELF_RECEIVE. You will then receive your own sent messages. They will have a reception timestamp of the time when they were placed into the transmit queue. If you want to have the time when they were physically sent instead, then you can set an additional parameter called DELAYED_MESSAGE_DISTRIBUTION.

BStout wrote:I read the product description, and so understand that a second client (on a 'net') can be used to see the messages that a first client sends, but there is no indication as to whether the second client sees this only after the message is actually sent on the bus (and acknowledge bit received).

PCAN-API allows you to set a parameters called DELAYED_MESSAGE_DISTRIBUTION. If it is set, all clients connected to the same net will receive the messages at the same time they are written to the bus and acknowledged. If it is not set, the messages are received at the moment they are included in the send-queue of the driver. In both cases you get a reception timestamp.

BStout wrote:There is also the question of whether and how transmit failures / timeouts are indicated.

This is handled by CAN, also, you receive error frames and error warning messages when problems are detected (see for example the message types PCAN_MESSAGE_ERRFRAME and PCAN_MESSAGE_STATUS within the PCAN-Basic help).

BStout wrote:A related concern is whether outstanding transmit requests can be reordered in the transmit queue based on priority (or arbitration ID), and if so, whether this is a controllable feature.

No, messages placed in the queue can only be removed when the queue is clear. Deleting single messages, or reordering the queue is not supported.