Hello,
I've noticed very recently that my actual cam angle is trailing the commanded angle by 5 degrees in all situations.
I pulled up some datalogs from previous runs and this has only started fairly recently. I think a recent update to FP Manager may actually be responsible, but I'm not sure which parameter threw it off and I wasn't paying close enough attention to remember what version I was running and when. The only notable parameter change I've seen from the previous version I was running was that VTC I in VTC closed loop control now set the -60 parameter to .4 instead of 0, like previous versions. However, I see the same situation in open loop as in closed, so I wouldn't think this is responsible.
I've attached 2 calibrations. My logs for New Tune 1.00 show no variance between cam and cam cmd, but in New Tune 1.02, there is now a 5 degree lag in the cam. I included datalogs from both tunes, as well.
Any help you can provide would be much appreciated!
Cam is Always 5 Degrees Behind CamCMD
-
- Posts: 34
- Joined: Wed Mar 13, 2013 3:20 pm
Cam is Always 5 Degrees Behind CamCMD
- Attachments
-
- New Tune 1.02.fpcal
- (21.24 KiB) Downloaded 170 times
-
- New Tune 1.00.fpcal
- (20.96 KiB) Downloaded 169 times
-
- datalog0000 (cam lags).fpdl
- (2.28 MiB) Downloaded 183 times
-
- datalog0000 (cam OK).fpdl
- (2.4 MiB) Downloaded 181 times
-
- Posts: 34
- Joined: Wed Mar 13, 2013 3:20 pm
Re: Cam is Always 5 Degrees Behind CamCMD
I updated to FP 2.3.7 and compared the calibrations after downloading and re-uploading. The VTC PID tables now match "New Tune 1.00". I ran a datalog and the Cam and CamCMD graphs are now essentially line-on-line again.
-
- Posts: 34
- Joined: Wed Mar 13, 2013 3:20 pm
Re: Cam is Always 5 Degrees Behind CamCMD
On closer inspection, there appears to be about +/-2 degree slow oscillations compared to datalogs I took back when I was running a FP 1.5.x back in 2013.
Did you guys change values when importing those VTC PID tables? If so, could you please post what the Honda original values are?
Also, why are these kinds of changes not included in the official changelog? Not just value changes, but even the addition of the tables.
Did you guys change values when importing those VTC PID tables? If so, could you please post what the Honda original values are?
Also, why are these kinds of changes not included in the official changelog? Not just value changes, but even the addition of the tables.
Re: Cam is Always 5 Degrees Behind CamCMD
Create a new calibration and see if the VTC PID values are the same as your calibration.
Hondata
-
- Posts: 34
- Joined: Wed Mar 13, 2013 3:20 pm
Re: Cam is Always 5 Degrees Behind CamCMD
The values don't change when making a new calibration compared to what's in mine. I tried pulling in a few of the basemaps to see if there were any different ones, but they're all the same.
Re: Cam is Always 5 Degrees Behind CamCMD
If the PID values are the same then it is not the ECU control.
Hondata
-
- Posts: 34
- Joined: Wed Mar 13, 2013 3:20 pm
Re: Cam is Always 5 Degrees Behind CamCMD
The PID values are the same if I create a new cal since those tables were added. Since those tables were not available when VTC worked correctly, it's hard to say if they're the same now.
It's definitely not a mechanical issue, because I dug out my old mechatronics textbook and spent about 2 hours idling in my driveway tuning the PID values on the live table by stepping the angle up and down and changing the PID until performance was similar to stock. It tracks pretty well now and there's no offset or saw-toothing. The response is roughly equivalent to stock (0.3 second delay on step input), but it seems like there's room to improve. I'm not a PID expert, though; just an amateur.
It's definitely not a mechanical issue, because I dug out my old mechatronics textbook and spent about 2 hours idling in my driveway tuning the PID values on the live table by stepping the angle up and down and changing the PID until performance was similar to stock. It tracks pretty well now and there's no offset or saw-toothing. The response is roughly equivalent to stock (0.3 second delay on step input), but it seems like there's room to improve. I'm not a PID expert, though; just an amateur.