.NET and DLL callbacks
-
Hi, I have a problem. On our computer (Celeron 566 MHz, 128MByte, W2000, .NET1.1) we use a CAN bus for getting measurement data from a client. For the CAN bus there is a DLL for NT/2000. Everytime if data comes in, the DLL calls a callback routine in my C# program. Data will come all 50 ms at the moment. This is working so far but if the data comes in, the CPU usage goes up to 100%, even if the callback routine in my C# program is doing nothing. That means only for calling the callback routine every 50 ms is killing the system. Is it possible that I'm doing something wrong? Before we have written this software in Delphi and at that time the program needs only around 2%-5% CPU usage with 50 ms and around 10% with 1 ms data interval. Regards Michael
-
Hi, I have a problem. On our computer (Celeron 566 MHz, 128MByte, W2000, .NET1.1) we use a CAN bus for getting measurement data from a client. For the CAN bus there is a DLL for NT/2000. Everytime if data comes in, the DLL calls a callback routine in my C# program. Data will come all 50 ms at the moment. This is working so far but if the data comes in, the CPU usage goes up to 100%, even if the callback routine in my C# program is doing nothing. That means only for calling the callback routine every 50 ms is killing the system. Is it possible that I'm doing something wrong? Before we have written this software in Delphi and at that time the program needs only around 2%-5% CPU usage with 50 ms and around 10% with 1 ms data interval. Regards Michael
I think you'll need to post a little more information to get much help. That's a pretty difficult question to answer without code. Still, when you say CAN, are you referring to the bus protocol often used in automobiles, trucks, and various equipment? If so, who wrote your communications DLL? If it's what I'm thinking, you need to take a look at setting filters to limit the amount of incomming data. CAN data running at full speed (about 1 meg I think) is quite a bit of callbacks. If filtering isn't an option in the supplied DLL, you could write your own in ATL COM. This should be much faster and then you could post up only the messages you really need to your application. If we're on the same page, you may want to consider another provider for your communications DLL like possibly Noregon Systems out of Winston Salem, NC.
-
I think you'll need to post a little more information to get much help. That's a pretty difficult question to answer without code. Still, when you say CAN, are you referring to the bus protocol often used in automobiles, trucks, and various equipment? If so, who wrote your communications DLL? If it's what I'm thinking, you need to take a look at setting filters to limit the amount of incomming data. CAN data running at full speed (about 1 meg I think) is quite a bit of callbacks. If filtering isn't an option in the supplied DLL, you could write your own in ATL COM. This should be much faster and then you could post up only the messages you really need to your application. If we're on the same page, you may want to consider another provider for your communications DLL like possibly Noregon Systems out of Winston Salem, NC.
Ok, I will give some more info. CAN means the busprotocol which is used in automotiv industries. The DLL is written by the manufacturer of the industrial computer (using the Win DDK), where the CAN chip is build in.Of cause this is not only the DLL but also a system driver for this hardware. The DLL is only the interface. We used the CANbus with 250 kBaud which enables us to read the incomming Data with 1 ms resolution and we need all the data because we have to control a very dynamical process. Next I will give some code how I have impleneted this: using System; using System.Runtime.InteropServices; using System.Windows.Forms; using System.Threading; using System.Security; namespace CanOpen { // First of all I define the data structure for the callback function // Before this was public byte oldData[] and public byte newData[] // But the structure of the Callback function works with byte oldData[8] and // byte newData[8] and I didn't know how to realize this in C# public struct NewDataType { public int node; public byte oldData1, oldData2, oldData3, oldData4, oldData5, oldData6, oldData7, oldData8; // public byte newData1, newData2, newData3, newData4, newData5, newData6, newData7, newData8; //; public int dataLen; //max. 8 bytes (= max. PDO data length) public PDOChannelType PDOChannel; } ..... // Next I define the delegate for the Calback function delegate void DelegateUserCANNewInputData( ref NewDataType pNewData); ..... // This is the function, which registers the callback function, // I tried with and without SuppressUnmanagedCodeSecurity but it has no influence [DllImport("canopen.dll"),SuppressUnmanagedCodeSecurity] static extern int CANopenNewInputDataRegister(DelegateUserCANNewInputData UserCANNewInputData); ..... private void RegisterCallBackFunctions() { int RetCode; DelegateUserCANNewInputData FptrUserCANNewInputData = new DelegateUserCANNewInputData (UserCANNewInputData); RetCode = CANopenNewInputDataRegister(FptrUserCANNewInputData); }
-
I think you'll need to post a little more information to get much help. That's a pretty difficult question to answer without code. Still, when you say CAN, are you referring to the bus protocol often used in automobiles, trucks, and various equipment? If so, who wrote your communications DLL? If it's what I'm thinking, you need to take a look at setting filters to limit the amount of incomming data. CAN data running at full speed (about 1 meg I think) is quite a bit of callbacks. If filtering isn't an option in the supplied DLL, you could write your own in ATL COM. This should be much faster and then you could post up only the messages you really need to your application. If we're on the same page, you may want to consider another provider for your communications DLL like possibly Noregon Systems out of Winston Salem, NC.
Ok, I will give some more info. CAN means the busprotocol which is used in automotiv industries. The DLL is written by the manufacturer of the industrial computer (using the Win DDK), where the CAN chip is build in.Of cause this is not only the DLL but also a system driver for this hardware. The DLL is only the interface. We used the CANbus with 250 kBaud which enables us to read the incomming Data (PDOs) with 1 ms resolution and we need all the data because we have to control a very dynamical process. Next I will give some code how I have impleneted this: using System; using System.Runtime.InteropServices; using System.Windows.Forms; using System.Threading; using System.Security; namespace CanOpen { // First of all I define the data structur for the callback function // Before this was public byte oldData[] and public byte newData[] // But the structure of the Callback function works with byte oldData[8] and // byte newData[8] and I didn't know how to realize this in C# public struct NewDataType { public int node; public byte oldData1, oldData2, oldData3, oldData4, oldData5, oldData6, oldData7, oldData8; // public byte newData1, newData2, newData3, newData4, newData5, newData6, newData7, newData8; //; public int dataLen; //max. 8 bytes (= max. PDO data length) public PDOChannelType PDOChannel; } public class VCanOpen { ..... // Next I define the delegate for the Callback function delegate void DelegateUserCANNewInputData( ref NewDataType pNewData); ..... // This is the function, which registers the callback function, // I tried with and without SuppressUnmanagedCodeSecurity but it has no influence [DllImport("canopen.dll"),SuppressUnmanagedCodeSecurity] static extern int CANopenNewInputDataRegister(DelegateUserCANNewInputData UserCANNewInputData); ..... // During the initialization of the CANOpen class private void RegisterCallBackFunctions() { int RetCode; DelegateUserCANNewInputData FptrUserCANNewInputData = new DelegateUserCANNewInputData (User
-
I think you'll need to post a little more information to get much help. That's a pretty difficult question to answer without code. Still, when you say CAN, are you referring to the bus protocol often used in automobiles, trucks, and various equipment? If so, who wrote your communications DLL? If it's what I'm thinking, you need to take a look at setting filters to limit the amount of incomming data. CAN data running at full speed (about 1 meg I think) is quite a bit of callbacks. If filtering isn't an option in the supplied DLL, you could write your own in ATL COM. This should be much faster and then you could post up only the messages you really need to your application. If we're on the same page, you may want to consider another provider for your communications DLL like possibly Noregon Systems out of Winston Salem, NC.
Matt is right, do you really need all of that data? Are you using RP1210A? If so, filter out what you don't need at the driver/dll layer and don't allow all of the data to come up. CAN is a very fast protocol and on a loaded bus can bring almost any computer to its knees if it tries to process every message. david
-
Matt is right, do you really need all of that data? Are you using RP1210A? If so, filter out what you don't need at the driver/dll layer and don't allow all of the data to come up. CAN is a very fast protocol and on a loaded bus can bring almost any computer to its knees if it tries to process every message. david
I really need all this data. I need all the PDOs coming in for this measurement data. The data is already filtered in the system driver. And there is only one other node which sends data. At the end I need to record the data with a frequncy of 1 kHz. But even with 50 ms the system is not more usable. Again, before we use Delphi and it works very well. Only 5 % of CPU is used with Delphi. Another question? If it is so, as you described, maybe .NET is not the future solution for applications which must handle a big amount of data in short time. regards, Michael
-
I really need all this data. I need all the PDOs coming in for this measurement data. The data is already filtered in the system driver. And there is only one other node which sends data. At the end I need to record the data with a frequncy of 1 kHz. But even with 50 ms the system is not more usable. Again, before we use Delphi and it works very well. Only 5 % of CPU is used with Delphi. Another question? If it is so, as you described, maybe .NET is not the future solution for applications which must handle a big amount of data in short time. regards, Michael
Couple of thoughts: 1) Try using windows messaging instead of callbacks. Windows messaging is much more efficient and optimized by the OS. 2) Try offloading the callback to another thread. As for Delphi, I've never used it. What is your busload on the CAN network you're trying to read everything from and what speed are you running (250, 500, 1M, etc)? I can tell you that nearing 70-100% busload on a 250k CAN network will make a boat anchor out of my PC, if it tries to process all the data. Not to mention you are trying to record it... which requires flushing to a file every now and then. David