PEAK-System Forum

Hi,
I am seeing ever increasing timestamps even if I restart my application and reinitialize the PCANBasic API. How can I reset the internal clock in the hardware using the api?

Grüß
Pär

Hello,

the time stamp of a CAN message contains the number of microseconds since the start of Windows. So you have to restart Windows to achieve an internal clock reset .

If you want the timestamps to always start with 0 within your application then you have to use a timestamp offset and calculate yourself the time elapsed. You achieve this by substracting the first received timestamp of the last one, each time a message is received.

I am using Python on windows.
I want to calculate the time between two CAN frames on my bus. When I run this code I get following values:
18740080279
18740080537
18740080802
18740081064

If I minus any two consecutive I get around; 262L or 258L
what it means by these '262L or 258L' ?

When I read PCAN_View I get values in thousands. and difference is of 3
1,3600
1,3603

Can you please difference and explain

Hello,

hmluqman wrote:TS = readResult[2]
        TimeStamp = TS.micros+TS.millis*1000 + 0x100000000 * 1000 * TS.millis_overflow       
        print TimeStamp

You are calculating here the time stamp of the Frame as the total of microseconds since the start of Windows.

hmluqman wrote:If I minus any two consecutive I get around; 262L or 258L
what it means by these '262L or 258L' ?

When you substract one value from the other, you will get the difference in microseconds between those two CAN-frames, i.e. how much time is elapsed between the reception of both. If the times are from frames with same ID, then this is the cycle time of a CAN-Frame (what you see in the Receive pane of PCAN-View). In your example, it would means that the second CAN-frame was received "258 microseconds" after the first one.

hmluqman wrote:When I read PCAN_View I get values in thousands. and difference is of 3
1,3600
1,3603

PCAN-View shows the time, in seconds, that has elapsed since the recording was started, with a resolution of 1/10 Millisecond. In your code you have a difference of 300 microseconds. Since PCAN-View has only one place for the microsecond it may show rounded values.

Thanks a lot for your reply.

Hi,

we are working with PCAN basic on Windows and would need to translate the timestamp into an absolute datetime. We are aware that we are potentially losing some precision (the micros) but the question is what time should be used as the reference time. I know it's the last Win reboot, but in .NET we have several ways to retrieve this info. Some take into account sleep time, some do not, so with the experiments so far we got that translating timestamps may end up in a moment (slightly) in the future.

Which is your suggested way? I guess PCAN-View does a similar thing in order to show the elapsed recording time.

Thanks in advance
Adhara

Hello,

the Timestamp of CAN messages within PCAN-Basic correspond to the number of microseconds since Window's start.

You should get the absolute time to "Now", substrat the time elapsed since windows start, and add the time represented by the timestamp. That would be the absolute time of the CAN message.

PCAN-View just store the time at when the record starts (DataeTime.Now). Messages times are then relative to that.

Hello,

I have managed to obtain the timestamp for the received CAN frames, from PCANBasic. My question is how to also obtain the timestamp of the sent frames, on the PCANBasic on the read function a timestamp is passed:
so When I read on my side I can see the value but on the write function: There is no timestamp passed. What I want is to be able to log the received and sent messages in a text file with precise timestamp.
Thanks
** Edit by Admin **
Please see Forum Rules - code need to be Formated

Hello,

Timestamps are only available for received messages. If you want to get the timestamp of sent messages, then you can activate the parameter PCAN_ALLOW_ECHO_FRAMES. This causes your applicaiton to read an echo of any sent frame. This echo frame is placed in the receive queue when the message is physically sent, together with the precise sent timestamp. This echo message has to be read then in the same way you get other messages (over the CAN_Read/CAN_ReadFD function) and you recognizes it because the MSGTYPE of the message has the flag PCAN_MESSAGE_ECHO.

Thanks for the reply, does firmware version 3.2.0 support self receive frames? Im using IPEH-xxxxxx-000411 with 6 usb ports