Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
CCPWriteDAQ Multibyte/Singlebyte block size
elmo
Member
12-23-2004 06:09 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
The CCPWriteDAQ.vi relies on the ECU supporting multibyte block sizes. What option is there for ECU's only supporting single byte block size.
Eg. A signal list input for CCPWriteDAQ.vi consists of a signal defined with the size 4 bytes. Previously using my own CCP functions written with Frame API's, I would have to call CCPSetDAQPtr then CCPWriteDAQ four times with block size always set to 1. Now I call them only once, where CCPWriteDAQ sets the block size to four. The CCP handler in my ECU does not support this; is there a way around this problem without modifying the CCP handler in my ECU.
I dont think it is possible to delibrately modify the signal list as this would mess up the decoding of the signal later when calling the CAN read function.
Eg. A signal list input for CCPWriteDAQ.vi consists of a signal defined with the size 4 bytes. Previously using my own CCP functions written with Frame API's, I would have to call CCPSetDAQPtr then CCPWriteDAQ four times with block size always set to 1. Now I call them only once, where CCPWriteDAQ sets the block size to four. The CCP handler in my ECU does not support this; is there a way around this problem without modifying the CCP handler in my ECU.
I dont think it is possible to delibrately modify the signal list as this would mess up the decoding of the signal later when calling the CAN read function.
biker2000
Active Participant
12-27-2004 03:15 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hi elmo,
can you fall back to the logic that you used when you used the Frame API as a workaround? Thus, you would need to split your 4-byte data into 1-byte chunks and call CCPSetDAQPtr and CCPWriteDAQ four times, once for each byte.
Do you mind, if we contact you directly? We have some questions regrading the ECU and would like to discuss that offline.
-B2k
can you fall back to the logic that you used when you used the Frame API as a workaround? Thus, you would need to split your 4-byte data into 1-byte chunks and call CCPSetDAQPtr and CCPWriteDAQ four times, once for each byte.
Do you mind, if we contact you directly? We have some questions regrading the ECU and would like to discuss that offline.
-B2k
12-28-2004 08:42 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
With the Frame API's, I do not believe I coded the application in the most efficient way, particularly when decoding the messages from the CAN frames relating to the DAQ DTO's. I had struggled using many while loops, queues and occurrences to split all the DAQ DTO's into 10 groups (since I have 10 events) and then decoding the messages in each group which are encompassed across 3 CAN frames (where a message can be spanned across 2 CAN frames, thus more efficient use of available memory), thus I have to wait for transmission of all 3 CAN frames before decoding the messages. The decoding of messages is the main issue I have really.
This gave me some problems with buffer overload, queue overload although I did look into some support papers regarding memory management and performance issues. I have not really looked into using C functions and have always coded in LabVIEW blocks, do you think this would improve performance of some of my code?
One other issue I wanted to check, I assume the CCP functions do not span messages across CAN frames as mentioned above. For example an ODT table will have 7 blocks of 1byte data and if you set the pointer to this ODT table and write data such that it then exceeds the 7bytes, I assume it will give an error.
As a comparison, we have always used Vector CANape for ECU data acquisition and calibration which we have no issues, but for my purpose now, I need to use LabVIEW to perform in almost the same way.
I dont have the CCP version which we are using at the moment.
Biker 2000, I am out of the country early next month but let me know what your email address is and I can contact you. Thanks.
This gave me some problems with buffer overload, queue overload although I did look into some support papers regarding memory management and performance issues. I have not really looked into using C functions and have always coded in LabVIEW blocks, do you think this would improve performance of some of my code?
One other issue I wanted to check, I assume the CCP functions do not span messages across CAN frames as mentioned above. For example an ODT table will have 7 blocks of 1byte data and if you set the pointer to this ODT table and write data such that it then exceeds the 7bytes, I assume it will give an error.
As a comparison, we have always used Vector CANape for ECU data acquisition and calibration which we have no issues, but for my purpose now, I need to use LabVIEW to perform in almost the same way.
I dont have the CCP version which we are using at the moment.
Biker 2000, I am out of the country early next month but let me know what your email address is and I can contact you. Thanks.
01-10-2005 05:24 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Biker 2000, I am now back in office, you can email me at kevin.fan@ricardo.com or phone me +441926 477171
