CAN_Read not reading the expected messages

[U202457]

Hello ,

I am trying to read messages using CAN_Read in pcanbasic.

Setup:
PEAK usb is connected to Controller and controller continuously sending messages to a linux application.
the linux application is using CAN_Read function with 2000 Micro second interval to read those message coming from Controller.

As continuously messages are coming from controller, I am looking for some specific messages to be read by CAN_Read.

How I can ensure those message should be read by CAN_Read function?

Thankyou in Advance

[M.Heidemann]

Hello,

Have a look at the read-examples provided with the PCAN-Linux driver package
in the folder:

Code: Select all

peak-linux-driver-8.12.0\libpcanbasic\examples

Furthermore also read the documentation provided for PCANbasic.

You'll need to read until the Reception queue is empty, for this purpose you can use the return
value "PCAN_ERROR_QRCVEMPTY".

This way no message should go unread.

Best Regards

Marvin

[U202457]

CAN RED use case

CAN_READ.png (54.1 KiB) Viewed 6474 times

Thankyou for quick reply,

As per your comment I did the changes, please find the attachment.
I am having one doubt in it.

as per the code I have written all the message which have frame->id == 0x18D8DA32, will be read from the receive queue?
FYI "can_rx" function is being called periodically in every 2 ms.

[M.Heidemann]

Hello,

This will not read all messages with ID= 0x18D8DA32 because you'll break
the while loop once one message with ID=0x18D8DA32 has been read:

Loop break.png (49.03 KiB) Viewed 6470 times

Remove the break and it should print all instances of 0x18D8DA32.

You'll also have to read every message in the queue, there is no way around that.
You can process certain messages using an if condition, like you have done here, but then you cannot break the loop there if you intent to read all instances.


Best Regards

Marvin

[U202457]

Thankyou for reply!!

As per your previous comment I removed the "Break" and now I think my expectation will be fulfill to read all the message from queue with message ID-0x18D8DA32.
but I am facing one weird behavior:
I am able to read the message 0x18D8DA32 from the queue which is not captured in pcanview.

Screenshot from 2021-09-21 19-13-40.png (5.24 KiB) Viewed 6468 times

and at the same time I am not able to read the message 0x18D8DA32 which is captured in pcanview.

canread test.png (71.3 KiB) Viewed 6468 times

how to resolve this issue?

Thankyou in Advance!

[M.Maidhof]

Hi,

already described that behavior of the chardev driver in an other thread to you, do you remember? So why asking the same question again?

viewtopic.php?f=59&p=16239#p16209

regards

Michael

[U202457]

Hi
This is not the same question I asked before.

In this question I am looking for message coming from controller only.

So the question is like:
In pcanview I am able to see message with message ID-0x18D8DA32 and Data 00 1B 00 00 00 00 FF FF but this message is not received in Linux application.
but I am received a message with message ID-0x18D8DA32 and Data 0 11 FF FF FF FF FF FF in linux application with this message is not captured in pcanview.

Please let me know if question is still not clear.

Thankyou in advance !!

[M.Maidhof]

Hi,

looks like you mix up decimal with hex. While pcanview shows hex values, your application prints %u which is unsigned integer (decimal). Simply print as %x to see that it is the same message in hex format.

416864818 = 0x18D8DA32

regards

Michael

[U202457]

Hi
Thankyou for reply!!
what you have mentioned is correct but still my question will be same.
the message id I am getting is -0x18D8DA32 only but the data is different as per pcanview reference?

Screenshot from 2021-09-21 20-07-09.png (13.46 KiB) Viewed 6443 times

In the attachment if you see the in hex format the it will be -0 11 FF FF FF FF FF FF .
but in PCANVIEW the data is --> 00 1B 00 00 00 00 FF FF
Thankyou

[M.Maidhof]

Hi,

do you have your pcanbasic application and pcanview connected at the same time on the same device, or do you test separately?

regards

Michael