PCAN Basic API - Multiple interfaces - No receive events

[SomeFancyUsername]

Hi,

I use two PCAN-USB interfaces which I have configured to use the device ids 0x1 and 0x2. This setup usually works for me but I have noticed that sometimes the PCAN Basic API (C#) seems to stop receiving (at least).

This happended to me multiple times, but during development -> I have a lot of initialisations/deinitialisations or even missing deinitialisations due to killing the SW or exceptions.

Symptom is as follows:

- I have a PCAN View open in the background on interface 0x2
- The application that I am working on uses interface 0x1
- Both interfaces connected to the same bus
- I am using events for reception in my application
- Some time during development I notice after a restart of the SW that I do not receive frames anymore
- Checking on the PCAN View shows bus is bussing as expected
- Using PCAN View to open either of the interfaces works just fine
- Restarting the application will not help to receive frames with interface 0x1 again
- (!) Unplugging interface 0x2 and then restarting the SW will make it work with interface 0x1 again

I am using all recent versions of the Peak SW.
My strategy for obtaining the correct PCAN-USB handle is scanning for device ids 0x0 to 0xff using PCANBasic.LookUpChannel. The handle that is returned for 0x1 is then used for that interface.

I think its probable that missing deinitialisations might play a role here. Is there any way to hammer on the API to prevent this from happening?

Thanks and best regards
Julian

[M.Heidemann]

Hello Julian,

This might be a physical issue on the bus itself, due to the fact that disconnecting
one channel will resolve this behaviour, so to confirm this you could try the following:

- Does uninitializing and reinitializing after disconnecting channel 2 resolve the behaviour?
- If yes, when channel 2 is connected, are you able to trace error frames via PCAN-View? (Check in the Tracer options to enable error, event and status frames)
- In your PCANBasic-Application, what does your Reads return, once you enabled PCAN_ALLOW_ STATUS_FRAMES and PCAN_ALLOW_ ERROR_FRAMES (Via"SetValue")

Please report back to us regarding this.

Best Regards

Marvin

[SomeFancyUsername]

Sorry, just to clarify my previous statement regarding disconnecting interface 0x2: With disconnecting I meant unplugging the USB of that interface.

[M.Heidemann]

Hello,

This was clear to me.

Both questions not directly refering to channel 2 are refering to the remaining channel 1.
Maybe i was a tad vague about this.

A phyiscal issue would explain why it would be resolved, once channel 2 seizes operation
and does not actively participate on the bus anymore.

Best Regards

Marvin

[SomeFancyUsername]

Intermediate report: Was just trying to reproduce and then this happened the first time:

Starting PCAN View, both interfaces show. 0x1 is opened by my application and happily receiving. I selected the 0x2 interface to open with PCAN View and I get ILLNET 1800h. Never saw that before.

Update: This behavior was reproducible until I exited my application that uses 0x1. Now I can open 0x2 again...

Update: Now I have started my application again. No reception. Tracing everything with the 0x2 interface using PCAN View shows normal behavior and no error frames whatsoever.I can even connect to the already open 0x1 interface and it behaves the same as the 0x2 one in PCAN View (except for the warning that is in use already). Ending PCAN View does not help receiving again. Restarting my application does not either. Unplugging USB of 0x2 while the application is running does not either. But reinitialising after unplugging (without restarting the application) does make it receive again.

Update: PCAN View ILLNET 1800h is reproducible: I have replugged 0x2 and try to open it in PCAN View: Same behavior as described before.

[SomeFancyUsername]

Closing in. I can eleminate PCAN View for now. Following symptom:

Plugging in 0x1 device first -> Reception is OK, handle returned by the query for the device number 0x1 was 0x51 (expected)
Plugging in 0x2 device first -> Reception is NOK, handle returned by the query for the device number 0x1 was 0x52 (expected)

That is a problem because even if I would open the wrong interface -> they are both connected to the same bus and it should just work. But that does not even seem to be the issue here.

[M.Heidemann]

Hello,

We excluded physical issues, as far as i am concerned (wrong bitrate, termination, etc)
as there are no error-frames when tracing on the bus.

This suggests this is software related.

Can you provide us with your code so we have an idea of
what exactly is going on once your application runs?

Please check, if this is reproducable in the PCANBasic-Example application:

Hook up both the Example-APP and PCAN-View to the same channel, disconnect and reconnect
via the Example application. Is the behavior described reproducable? Will read seize to register events
in this scenario as well?

Can you elaborate on which hardware is used here for the two channels?

You also should check the transceiver on both channels for good measure, please see this guide:

viewtopic.php?f=120&t=52

Please report back to us regarding this.

Best Regards

Marvin

[SomeFancyUsername]

I will try to make a minimal sample.

Devices are one 002021 and one 002022.

The link to the guide seems broken.

[M.Heidemann]

Hello,

A small sample would indeed help us to
reproduce this here and assess the cause.

Please let us know once you have an example avaialble.

Also, check the link again, it was fixed.

Best Regards

Marvin

[SomeFancyUsername]

Whoops. I think I just found it. After I was not able to reproduce this symptom with the PCAN Basic Sample application I looked through my application considering doing a minimal sample...

I stumbled over my read call: Instead of calling it with the handle that I used to initialize, there was a hardcoded PCANBasic.PCAN_USBBUS1 in there that was a remainder from initial development. That naturally explains why Read did not deliver: Initializing one and reading from the other is probably a bad idea .

I am sorry for wasting time, should have reviewed that upfront. But I have found a bug in multi device handling before (PassThru back then) and felt reminded of that.

Thank you for your prompt support.
Best regards
Julian