Ok.... I have the code loaded and all the wiring hooked up. I changed the baud rate on the serial monitor so it would spit out words instead of giberish. On the monitor I am getting turbo rpm reading, I am getting changes on the serial monitor when I switch from performance cruise and brake, but I am not getting any response from the turbo. the actuator is a brand new one from cummins. I changed the line to 0x02 to calibrate the actuator and it did calibrate. That is the only response I have got though. Any thoughts?
Reverse the Can + and - from the unit to the turbo. suppose is 0x02 did something though, the can is right.
How are you powering the turbo? It will need a relay powered off the battery directly.
I have this code to just walk out the turbo slowly. to test the vane sending functions.
#include <SPI.h>
#include <can.h>
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
// Defines for setting up the CAN Bus
#define mode NORMAL // define CAN mode
#define bitrate 250 // define CAN speed (bitrate)
MCP CAN1 (10); //Create CAN Channel
//LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE); // Set the LCD I2C address
unsigned int last_vane_position = 40;
unsigned int DesiredPosition;
unsigned int vane_position;
int VanePos = 0;
void setup() {
// Initialize Serial communications with computer to use serial monitor
Serial.begin(115200);
// lcd.begin(20, 4); // initialize the lcd for 20 chars 4 lines and turn on backlight
// Set CAN mode and speed
CAN1.begin(NORMAL, bitrate);
//lcd.setCursor(0, 0);
//lcd.print("CM^2 = ");
}
void loop(){
if(DesiredPosition > 800){
DesiredPosition = 100;
}
else{ DesiredPosition += 1;}
// Set the Turbo Position
SendTurboPosition( DesiredPosition );
// Delay for Processor
delay(5);
VanePos = constrain(map(DesiredPosition,40,960,3,25), 3, 25);
//String TurboPos = String(String(VanePos, DEC) + " ");
//lcd.setCursor(6, 0);
//lcd.print(TurboPos);
}
void SendTurboPosition( int TurboPosition )
{
last_vane_position = DesiredPosition;
int FinalPosition = map( TurboPosition, 0, 1023, 960, 40 );
byte lobyte = lowByte(FinalPosition);
byte hibyte = highByte(FinalPosition);
unsigned long ID = 0x0CFFC600; // Random Extended Message ID
byte length = 8; // Data length
byte data[] = { lobyte, hibyte, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF }; // data message with an added counter
CAN1.send ( ID, extID, length, data ); // Load message and send
}
I'm not sure if you'll see a difference in position when you switch between modes, or if it's large enough to notice..
I should write a mini sketch just to test that..
Curtis knows his code better and should be able to say
The code I posted walks the vanes out slowly then jumps back to 0 position and back out. You should be able to hear the turbo pretty easily and verify if it is walking out.
I somehow missed that,.. it's exactly what I'd have done
I didnt figure it would change between the modes but the exhaust brake should have a major difference. Driving it the turbo is wide open. I have tried 3 different actuators. They all will calibrate and thats all they will do.
I ran that code. Had to remove the lcd part to make it compile since im not running a screen. No response at all.
did you zero the vanes before you put the controller on ?
after calibrating did you power cycle the turbo ?
Yes and yes. I have done it with 3 different actuators now
Try adding this code
void ReadCanMessage() {
if (CAN1.msgAvailable() == true) { // Check to see if a valid message has been received.
//This is from the MCP examples, modified to work for what I need
unsigned long ID; // assign a variable for Message ID
byte length; //assign a variable for length
byte data[8]; //assign an array for data
CAN1.read(&ID, &length, data); // read Message and assign data through reference operator &
PrintCANmessage(ID, length, data);
}
}
void PrintCANmessage(unsigned long ID, byte length, byte* data){
Serial.print("ID");
Serial.print(" | 0x");
Serial.print(ID,HEX); // Displays received ID
Serial.print(" | ");
Serial.print("Data Length DEC");
Serial.print(" | ");
Serial.print( length); // Displays message length
Serial.print(" | ");
Serial.print("Data");
for (byte i=0;i<length;i++) {
Serial.print(" | ");
if(data[i] <0x10) // If the data is less than 10 hex it will assign a zero to the front as leading zeros are ignored...
{
Serial.print("0");
}
Serial.print(data[i],HEX); // Displays message data
}
Serial.println();
}
And add this in the "void loop()"..
ReadCanMessage();
Send it to your unit, and watch the serial monitor, it should give you lines of messages with the ID and each byte of data... if it doesn't I'd have to say it's a communication problem, try reversing CanH and CanL. (Edit: maybe you already tried that, I missed it above in reply #1) and make sure you're initializing the CAN on the right Arduino pin (I think it's 10?)
I wish I had 3 actuators to test with!
Here are the message ID's I've found through trial and error
Since it calibrates, you probably have the address already set right... The VGT listens for messages sent to this address
0x0CFFC600UL
Here is what I call the Status message ID, it gives feedback on what's happening with the controller
StatusMessageID 0x18FFC502UL //this is the message id of the messages we're concerned with
Here's the Break Message ID, I think it's sent once every 5th message, perhaps for timing reasons? it can be ignored
BreakMessageID 0x18FF0A02UL
Here's what I call the Error message ID.. When I deliberately reduced the voltage, I'd start to get this message.. Haven't figured out the details of it yet.
ErrorMessageID 0x18EEFF02UL //Seems to be an error message ID when low voltage is triggered?
And here's a breakdown of each byte (or two) of the Status Message ID
These two bytes together tell you what position the VGT is *actually* at
VgtRealPosition = ((data[2] * 256) + data[1]);
This byte tells you the temperature, though I haven't figured out the scaling yet
VgtRawTemp = data[3];
These two bytes tell you what position you're commanding it to be at
VgtCommandPosition = ((data[6] * 256) + data[5]);
This byte tells you the relative motor command speed..
VgtMotorCommandSpeed = data[7] - 127;
I remoted in today, and was all over the controller.
From my extensive testing, the LBB is 100% functional. He has 3 controllers for the turbo, 2 appeared to not even send/respond to can messages. The 3rd brand new in box from Cummins, broadcasted messages, accepted calibrate. But refused to respond to anything else.
With an error of 0x11 up front, after calibrate / power cycle on 0x08 error (calibrate and reset).
The unit also did not apply torque to the motor when just powered on, freely spun by hand, so I can only assume that either this unit needs programming or is non-functional.
Wow.. that's really weird
Is there any chance they're programmed to respond to a different address?
Don't know, I can't necessarily scan for it... you know ?
Have you tried just dumping the CAN messages to serial, kinda like what I showed above? you should be able to see if some other address is broadcasting.. I figure you've tried it though.
Ya it dumps the normal addresses with that timeout info.
Like I said, it was working great, it just doesn't want to accept a commanded position.
High and low bytes in the right order?... I'm just thinking out loud why it could possibly not work.
Turns out this new actuator is for a 6.7 in a 650 ford.. not sure if it talks different than a cummins dodge one does. I also wo der if there is some programming that has to be done with cummins insight or a drb3 before it lets the thing work. I am getting a known good controller from a 08 dodge tomorrow. Hopefully it works. Big thanks to Curtis for the help on this issue..
It will probably have different command sequences and addresses than the Cummins one.. Heck, I'm kinda surprised they don't change the command and addresses on the different years for the Cummins ones just to make it impossible to get used parts.
Crossing fingers the known good controller works!
Update.. Got a known good actuator today and it works perfect. I havent bolted it on yet but it calibrates and with the truck running when i flip the brake or rev it up the position changes. My actuator move when the key is powered and the actuator cant be moved by hand when powered like my old one. Going to install it tomorrow and hopefully enjoy my truck again.
Sweet... well.. bittersweet I guess... I'm glad you have it running, sucks to have 3 useless actuators though
what if the can bus speed is different? to match ford ecu.
What turbo was on the 6.7 in the F650?
He300? He341ve? or ???
They used to run He341ve on 5.9 in the big Fords. Hard turbo to find.
Good call on the CAN bus speed... that certainly sounds like a possiblity.. Are the Ford ECU's slower too? :P
lol I'm pretty sure there the 500kbs.
read where the ford gt runs more lines of code then the boeing dreamliner.
but like over 50 years ago the car is fast but unreliable. Shelby's team had to fix the gt40.
Part of the deal to fix the gt40 back then was to stop the daytona coupe project.
I have a hard time believing that car runs more lines of code than the Boeing dreamliner.... Remember that a lot of aviation systems have triple redundancy, even written in different languages and compiled for different processor architecture.
planes use the kiss method.
uh, pretty sure planes have like 7 fall over systems for just wing control. lol
I actually make parts and tooling for military Aircraft. mostly f16 p3 ground support tools.
I do all the parts for the Firehawk fire suppression system including the snorkle hose.
most of the p3 c130 maffs system replacement parts. but there old planes
Did a quote on making harnesses for c130 color HUD. CAN BUS would have saved at least 100lb in wires.
We do make programming kit for smart bombs mostly Ethernet cables and a very expensive Ethernet($1700 if i remember correctly) switch in a weather tight box.