RP1210 Tx/Rx Messages not processed by RP1210_Test.exe and PCAN-View as anticipated

[CANChallenge]

The problem described below occurs with software I have written.
However, the issue is detailed using RP1210_Test.exe to remove any concerns as to the code base, so as to assist with root cause investigation.

Description:
Issue: Messages not received or transmitted between RP1210_Test.exe and PCAN-View as anticipated.
Limited message exchange can be initiated by starting a second instance of RP1210_Test.exe. An external CAN device will enable all message behaviours as anticipated.

System Configuration:
CAN: J1939 CAN 2.0B 250 kbits/s
O.S. Windows: 11 64 bit
Product: PCAN-USB firmware 5.1.1 Driver version 4.4.0
Software: PCAN-View version 5.1.0.887 (x64)
RP1210: PCAN-RP1210 C (ReadMe.txt 26/05/2023)
Application: RP1210_Test.exe

Steps to reproduce behaviour:
1) Start PCAN-View
2) Connect to PCAN-USB: Device Id 0h Settings default 250 kbit/s Extended
3) Configure an Extended address 8 byte message frame transmitted at 10 ms intervals - any content
4) Start RP1210_Test.exe
5) Select PEAKRP32
6) Select SAE J1939 Protocol
7) Select (1) PEAK-System CAN Adaptor
8) Select Baud rate (Auto)
9) Channel remains as 1
10) Press OK
11) Connect
12) Set Message Option to 'Include' and 'Accept All messages (open) and Apply

Note that no messages are received.

13) Open a second copy of RP1210_Test.exe using the same SAE J1939 protocol (it does not matter if the filter is set.
14) Press the connect button
15) Press the disconnect button

Note that messages are now received.

Additional information:
If a single powered CAN J1939 device which defaults to transmitting messages is connected to the PCAN-USB. The application RP1210_Test.exe receives both the device broadcasts and the messages from PCAN-View. i.e. it is not necessary to start a second copy of RP1210_Test.exe to enable communication. If the device is powered off the application RP1210_Test.exe stops receiving messages from any source.

The following error message is received if a single transmitted message attempt is before unblocking via a second RP1210_Test.exe instance.
Code 159
Returned if blocking is used and the message was not sent.

The following error message is received if a single transmitted message attempt is made following unblocking via a second RP1210_Test.exe instance.
Code 137
'API DLL’s transmit message queue is full.'
The single message is in fact transmitted to PCAN-View

Desired behaviour:
It is preferable that it is not necessary to start a second copy of RP1210_Test.exe to enable communication with PCAN-View. That the application receives messages without a powered external CAN device. That the application continues to receive messages from PCAN-View if the external CAN device(s) are disconnected. That the application sends messages to PCAN-View without need for a powered CAN device attached.

Question:
1) Should the first RP1210_Test.exe session send and receive messages from PCAN-View without any other actions?
2) Should the operation follow the desired behaviour described?

The same process allows my code to function, though only via using the application RP1210_Test.exe to enable the communication. Not by any code method I have been able to implement. External hardware allows communication as anticiapted. (Point the debug RP1210_ClientConnect(0,1,'J1939:Channel=1',0,0,0): 1 message 'J1939:Channel=1' does not connect in my code. My code uses the 32 bit PEAKRP32 dll version).

[PEAK-Support]

We will try to reproduce it in our office - but one short question up in front. You always use a valid CAN network ? (minimum 2 active CAN nodes connected)
The RP12010 us the self-receive - that means you will not read the message if it was not ACK well on the CAN Network.
An this is only possible if you have 2 active CAN nodes on the network! If you run with one only - you will not get the CAN Frame back by Self receive ! (because it was not send !)

[CANChallenge]

Hi,
thanks for the reply.

I assesed the ACK to be contribtuory, following connection of the external CAN hardware.
Hence question 1.

The confounding point was use of a second instance of RP1210_Test.exe which at least permitted exchange from PCAN-View.

Where an applicaiton uses PCAN-Basic for example and PCAN-View with PCAN-USB. The combination permits message exhange without need for extrernal CAN hardware. This is extremely usefull for verifcation processes. This is the process I would like to be able to replicate using RP1210.
i.e. An RP1210 application communicating with PCAN-View and PCAN-USB with no external CAN hardware.

Apart from annoying 159 error, following the process outlined it would 'seemingly' work.

Following resolution of the points, how to create the equivalent functionality is the goal.

[PEAK-Support]

You need a working CAN Network for testing RP1210 Applications. The self receive is a protocol specific hardware function.

[CANChallenge]

Hi,
in following the regimen outlined, both using the Peak-System demonstration application and now my own code. A 'Self Receive' is operational with the configuration detailed.

So it seems it is not required to have external hardware.


The question therefore remains:
1) Why does opening and closing one session inside another session permit it to function?


Is something persistent, e.g. is there some accidental mode being achieved?

The reason for persisting with the question is that considerable effort will be expended to use this (in my case desirable) feature. I want to be sure the functionality is intended, as opposed to accidental (or is it a bug? (if its a bug, may I have a Bug Bounty ) ).

Please can you confirm the functionality detailed is intentional? i.e. Am I able to rely on the software to continue to operate as it does now?

Many thanks.

[CANChallenge]

Hi,
I hope the attached image helps explain the intention?

RP1210 Message Flow IMage

CANmsg.jpg (51.32 KiB) Viewed 5569 times

P.S. If this must have PCAN-USB hardware to operate that is not an issue from my perspective

[PEAK-Support]

Sending a CAN Frame to a CAN Interface where no other node is connected will end up stressing this interface.It will send in loop the first frame you send - infinity !
Also PCAN-View and the CAN API will go into a Error Mode. (independent from the RP10211 DLL / API)
Here a short information how the Driver work internal:
We have a CAN Driver that have implemented a lot of features.
We create for every "client" , in you case the RP1210 and the PCAN-View, a incoming and also a outgoing Message queue.
We also create in the driver a queue for the in and outgoing CAN Frames from the real HW.
Inter-Process communication between PCAN-View and your RP1210 will work, but the queue for the hardware will flow over,
and the Status of the CAN Hardware will go into Busheavy and all API Calls will return with Hardware Errors.

Solution(s)

• connect a 2nd CAN Node to the PCAN-USB that ACK the send CAN Frames (same Bitrate, Terminated cable)
  It must NOT be a RP12010 Hardware which answer to High Layer Functions, only receiving to be sure that the connected CAN-USB do not go into any Error State.

• Use a Virtual driver (which do not need any Hardware) But this is is only available when you us the PCAN-Developer Tools / Drivers. In your case - overdone

[CANChallenge]

Hi,
many thanks for the clarifications and comment re-first frame. These certainly help me better understand the system implications from the CAN hardware perspective. Hardware errors, e.g. BUSHEAVY, in my case can be managed. They have not to date interfered with the desired inter-process communications.

As you state inter-process communication works. BUSHEAVY remains asserted, additionally I do indeed see the QXmtFull incrementing in PCAN-View, where no external CAN connection is present to generate an ACK. With inpter-process communications tested beyond 'OFLOW' assertion in PCAN-View.

In terms of the inter-process communication, the PEAKRP32.dll would seem to happily receive messages when the QXmtFull counter is incrementing in PCAN-View and BUSHEAVY asserted. I have not verified every message, It's not critical for my use case at this point. As might be anticipated, It appears from initial testing messages arrive in a responsive fashion on the proviso, once the RP1210 buffer is cleared messages are read at a some rate either higher than the received rate or presumably before buffer wrap around.


The only point I feel I need to better understand, remains the seeming requirement for secondary RP1210 connection / disconnect to initiate inter-process communication. i.e. RP1210 connect and disconnect 'within / simultaneous to' an existing RP1210 session (as described in the thread). For the inter-process communication between PCAN-View and the 'outer' RP1210 client session to commence.
Please accept my sincere apologies if this has been explained and I have missed this item.

Please note: Only Peak-System hardware and software products are considered in scope for this use case.

Many thanks