PCANBasic.dll performance

[DF1AS]

Hi,
I used PCAN_USB.dll and PCAN_2USB.dll (both 2.0.4.0, 81 kB) to drive a PCAN-USB Pro interface adapter without any problems. One send call takes about 200 µs, which leads to a net data rate of > 300 kbps in 1-M mode.
Now I switched to the actual PCANBasic.dll (4.3.4.246, 338 kB). All runs fine - however, the data rate dropped drastically. One call to send 8 bytes now takes 3 to 15 ms, data rate drops accordingly to 10 kpbs!
What is wrong? I did not change any programming except for adaptation to different function parameters.
Can PCANBasic.dll not be used as a replacement for PCAN_[2]USB.dll? Should I stay with the old software or is there any other free DLL that reaches the old performance?

[M.Heidemann]

Hello,

We haven't heard of perfomace-issues like yours regarding PCANBasic.

Could you send us your code so we can figure out, what causes this behaviour?

PCANBasic is a completely different API and is not meant to be a newer version of PCAN-Light but it's own API.

Did you use the the PCAN-Light API with the PCANBasic.dll?

Both DLL's are supposed to be used with their respective API.


Best Regards

Marvin

[DF1AS]

Hi Marvin,
I included in a C++ project and built with latest VS
- PCANBasic.h, signed "Last change: 13.11.2017 Wagner" (30,095 bytes)
- PCANBasic.lib, obviously 4.3.4.246 as from same folder as the DLL below (4,262 bytes)
On runtime
- PCANBasic.dll, 4.3.4.246 (346,560 bytes)
Just three functions are used
- CAN_Initialize()
- CAN_Write()
- CAN_Read()
Hardware is a PCAN-USB Pro FD. From the device manager
- Driver version 4.1.4.16279 (2018-04-27)
Mention that all is working properly except for data throughput.
Kay

[M.Heidemann]

Hello Kay,

Thank you for providing such detailed information.

Would you be willing to share your code with us?

I would like to take a look at it, determine if there is something that may cause this beheaviour because, like i said before, we never heard of something like this regarding PCANBasic.

If you are not comfortable with sharing it here, you can also send us an email to support[at]peak-system.com.


Best Regards

Marvin

[DF1AS]

Hi Marvin,
the source code that has changed is a just a 5-liner, an additional DLL wrapper that connects our application with the PCAN DLL. Both DLLs reside in the folder of the application. When we switch to the new version we have to exchange both DLLs - that's all. I attach the file for completeness. It has to be noted that both old and new software run in x86 mode on a 64-bit W10 system. However, the performance of the old PCAN interface is top notch on either 64- or 32-bit systems. I did not check the new compilation on 32 bits. The slow-down may have to do with translation (JIT?), debugging or logging features etc. of the new PCAN Lib/DLL.
BR
Kay

[M.Heidemann]

Hello Kay,

i conducted a test myself to see, if calls actually were that slow.

The way i tested this:

I modified the button-event in our examples supplied with the download of PCANBasic.

Code: Select all

        private void btnWrite_Click(object sender, EventArgs e)
        {
            TPCANStatus stsResult;
            TPCANStatus Result;

            // Send the message
            // 
            for (int i = 0; i < 40000; i++) {
                stsResult = m_IsFD ? WriteFrameFD() : WriteFrame();
            }
            // The message was successfully sent
            //
       
        }

I connected two PCAN-USB FD to run my test, one is used by the modified sample-application, the other is used by PCAN-View.

If the calls actually take several ms, i should be able to determine this by looking at the cycle times of those messages.

See the attachment for the results i got.

This indicates that the calls could have not taken several ms, this would bottleneck every call, hence cycle-times below 1 ms would be impossible.

Cycle time of modified example to determine call times

CallTimeTest.PNG (11.22 KiB) Viewed 1796 times

To investigate this further i would like to answer me two questions:


Are you able to reproduce the test i did?

How did you determine the call-times?


Our development-team is looking into your issue as well.


Best Regards

Marvin

[DF1AS]

Hi Marvin,
What is WriteFrame() with no parameters doing? I use the following function:
TPCANStatus __stdcall CAN_Write(TPCANHandle Channel, TPCANMsg* MessageBuffer);
I checked the following setups:
1. PCANBasic.dll 4.3.4.246, 32 bit, 338 KB
2. PCANBasic.dll 4.3.4.246, 64 bit, 393 KB
3. PCAN_USB.dll 2.0.4.0, 81 KB (PCAN-Light for Windows 2000/XP/Vista/W7)
100,000 x calling CAN_Write() with 8 bytes payload data takes:
1. 730 s
2. 490 s
3. 30 s
The PCAN-Light version is fast enough to overflow the adapter's input buffer. So, the 30 s are still more than needed for the pure calls (there's a 1-ms sleep inserted every 16th call).
Another question might be if the CAN_Write() of the PCANBasic version is blocking or not.
BR
Kay

[M.Heidemann]

Hello Kay,

In the example WriteFrame() will create a TPCANMsg object and will determine its properties based on the state of the GUI. It will use the current handle and the created TPCANMsg as parameters on calling PCANBasic.Write():

Code: Select all

private TPCANStatus WriteFrame()
        {  
            TPCANMsg CANMsg;
            TextBox txtbCurrentTextBox;

            // We create a TPCANMsg message structure 
            //
            CANMsg = new TPCANMsg();
            CANMsg.DATA = new byte[8];

            // We configurate the Message.  The ID,
            // Length of the Data, Message Type
            // and the data
            //
            CANMsg.ID = Convert.ToUInt32(txtID.Text, 16);
            CANMsg.LEN = Convert.ToByte(nudLength.Value);
            CANMsg.MSGTYPE = (chbExtended.Checked) ? TPCANMessageType.PCAN_MESSAGE_EXTENDED : TPCANMessageType.PCAN_MESSAGE_STANDARD;
            // If a remote frame will be sent, the data bytes are not important.
            //
            if (chbRemote.Checked)
                CANMsg.MSGTYPE |= TPCANMessageType.PCAN_MESSAGE_RTR;
            else
            {
                // We get so much data as the Len of the message
                //
                for (int i = 0; i < GetLengthFromDLC(CANMsg.LEN, true); i++)
                {
                    txtbCurrentTextBox = (TextBox)this.Controls.Find("txtData" + i.ToString(), true)[0];
                    CANMsg.DATA[i] = Convert.ToByte(txtbCurrentTextBox.Text, 16);
                }
            }

            // The message is sent to the configured hardware
            //
            return PCANBasic.Write(m_PcanHandle, ref CANMsg);
        }

I was explicity refering to our example-application that is supplied with PCANBasic.

To determine what's going on i would need to know if the difference in perfomance is this drastic when the same exact code (or closest approximation of it) is used.

Logs of whats going on in your code could also give us a better understanding of the situation.

Remember: We don't know your application, we only can assume what your code does.

Please use the PCANBasic-example for testing so we can further assess the problem.


Best Regards

Marvin

[DF1AS]

Hi Marvin,
well, I played a bit with the sample code. Doesn't matter if in x64 or in Win32 mode, and doesn't matter if loading the DLL once and just calling the stored references or calling the "classic" functions and linking the appropriate lib (either x64 or x86). For all permutations it takes roughly 100 ms for 10,000 calls.
I made another test.
I removed the PCANBasic.dll from our executable folder, thus speed increased remarkably!
Time for uploading the 800 KB now was 180 s. (See above for comparing times.)
Not yet the PCAN light speed, but it seems to unveil the secret - DLL loading. My feeling is that for every call the function gets newly loaded because it is not cached. Do you have any idea how to avoid functions get unloaded? Is it a size problem? The light version is significantly smaller.
BR
Kay
PS: The application is GSEOS. It's a test system mainly used for space instrumentation testing. You can get some infos from http://www.gseos.de. It's not possible to modify the native code, but there's a built-in compiler where you can configure your data structures and test programs. Usually hardware drivers can be integrated to access special interfaces, but as a back-door you can also access DLLs. Because you cannot use pointers, one has to interface them by another DLL.

[DF1AS]

Hi.
I found the sore spot - multi-threading.
During transmission another thread is constantly reading data using CAN_read(), another one ditto for the 2nd channel.
If I pause reading, transmission runs at full speed. Even if there is no data to receive at all transmission somehow gets slowed down just by asking for rx data from within another thread.
However, the PCAN-light doesn't seem to have this restriction.
BR
Kay