ILiveForBoost
Probationary Member
- 24
- 6
- Mar 6, 2005
-
Bismarck,
North_Dakota
Here is the basic info needed to control the HE351ve actuator. I will edit this post later to add more detailed and organized information.
The CAN protocol used is j1939 at 250kbps. 29bit extended IDs are used.
The messages used to control the vanes are Proprietary B PGNs so documentation is not available. All that I know was determined by reviewing CAN traffic and experimenting with sending messages.
There is only one PGN required to control the actuator, PGN 0xFFC6. The actuator expects to see this from an address of 0 so the complete 29 bit CAN ID is 0x18FFC600. With the ID formed, you can ignore every other part of the J1939 protocol and work with pure CAN.
Only the first three data bytes are required but I have been sending full 8 byte messages with the remaining bytes padded with 0xFF.
Data Byte 0: Vane position low order bits
Data Byte 1: Vane position high order bits
Data Byte 2: Mode
Data Byte 3: 0xFF
Data Byte 4: 0xFF
Data Byte 5: 0xFF
Data Byte 6: 0xFF
Data Byte 7: 0xFF
Sudo code:
static void sendVaneCmd(uint16_t pos)
{
static can_frame_t frame;
frame.id = 0x18FFC600;
frame.extID = true;
frame.dlc = 8;
frame.data[0] = (uint8_t)pos;
frame.data[1] = (uint8_t)(pos >> 8);
frame.data[2] = 1;
frame.data[3] = 0xFF;
frame.data[4] = 0xFF;
frame.data[5] = 0xFF;
frame.data[6] = 0xFF;
frame.data[7] = 0xFF;
can_txFrame(&frame);
}
Mode:
This tells the actuator what to do. A value of '1' tells the actuator to move the vanes to the commanded position.
Position:
Vane position ranging from 0 to 1000, 0 being vanes fully open and 1000 being vanes fully closed. Values over 1000 seem to be ignored.
The message must be sent out frequently or the vanes return to a default position. I am sending command messages at a rate of 1 every 10ms.
The CAN protocol used is j1939 at 250kbps. 29bit extended IDs are used.
The messages used to control the vanes are Proprietary B PGNs so documentation is not available. All that I know was determined by reviewing CAN traffic and experimenting with sending messages.
There is only one PGN required to control the actuator, PGN 0xFFC6. The actuator expects to see this from an address of 0 so the complete 29 bit CAN ID is 0x18FFC600. With the ID formed, you can ignore every other part of the J1939 protocol and work with pure CAN.
Only the first three data bytes are required but I have been sending full 8 byte messages with the remaining bytes padded with 0xFF.
Data Byte 0: Vane position low order bits
Data Byte 1: Vane position high order bits
Data Byte 2: Mode
Data Byte 3: 0xFF
Data Byte 4: 0xFF
Data Byte 5: 0xFF
Data Byte 6: 0xFF
Data Byte 7: 0xFF
Sudo code:
static void sendVaneCmd(uint16_t pos)
{
static can_frame_t frame;
frame.id = 0x18FFC600;
frame.extID = true;
frame.dlc = 8;
frame.data[0] = (uint8_t)pos;
frame.data[1] = (uint8_t)(pos >> 8);
frame.data[2] = 1;
frame.data[3] = 0xFF;
frame.data[4] = 0xFF;
frame.data[5] = 0xFF;
frame.data[6] = 0xFF;
frame.data[7] = 0xFF;
can_txFrame(&frame);
}
Mode:
This tells the actuator what to do. A value of '1' tells the actuator to move the vanes to the commanded position.
Position:
Vane position ranging from 0 to 1000, 0 being vanes fully open and 1000 being vanes fully closed. Values over 1000 seem to be ignored.
The message must be sent out frequently or the vanes return to a default position. I am sending command messages at a rate of 1 every 10ms.
Last edited: