Pressure Control is not responding to Load (GPIO 4L80E)

[rxl158]

Hi, I am running Tuner Studio with version 4146 using matching .s19 and .ini.
Operating the GPIO stand-alone, gathering non-CAN load via a separate TPS sensor.
The Shift, PC Tables and Load Gage are all responding wrt VSS and TPS changes.
The problem is the Pressure Control output Only changes with VSS and is not affected by Load.
Attached is my MSQ file, can someone take a look to see if I got something goofed?
I will grab a datalog file soon when I'm able to drive the car again.

Thanks for the help and guidance

[Bernard Fife]

rxl158,

It looks to me like the load itself is the issue, as it seems stuck near -280 on my bench with your MSQ. I think there is a problem with the 4.146 non-CANbus load calculations (likely the same error as in 5.099 until very recently).

I am about to make 5.099 the release code very soon (as 5.100, it just needs a tweak to the TCC logic), so could you try that instead? Its 2-point load calculations have been verified, and so they should work for you. I will post the latest code here:

Monitor_5099w.abs.s19

(82.84 KiB) Downloaded 541 times

GPIO_MShift_5099.ini

(277.7 KiB) Downloaded 524 times

If this doesn't help, then a datalog would be enormously useful.

Lance.

[Bernard Fife]

rxl158,

Ignore my comment about the lack of response on the non-CAN load channel - I made a mistake when testing. However, if you could try 5.099x (or 5.099w below) and post a datalog, that would help me to get to the bottom of this as soon as possible.

Monitor_5099x.abs.s19

(82.91 KiB) Downloaded 544 times

GPIO_MShift_5099.ini

(277.7 KiB) Downloaded 521 times

Lance.

[rxl158]

Thanks Lance, I will try the 5.099x and it's cooresponding ini later in the day today. I attempted to download the 5.099w code today but couldn't get a connection with my newer laptop through the USB converter. I'll try my old Thinkpad that has a serial port and see what happens.
Rob

[rxl158]

CurrentTune.msq

3-15-2015

(45.55 KiB) Downloaded 752 times

Lance, it seems to work well now after a quick drive
The only immediate issue I noticed is when I selected Burn out mode under "Follow Mode Usage".
I put shifter in 3rd and it selects 3rd and will hold it, do a nice burnout, but once I put shifter in 4th and attempt to launch it never shifts out of first until I stop put it in park then back to 4th and everything shifts normally. I attached my quick throw together MSQ and datalog from the drive home. I will try to get a good datalog of the burnout mode 'hang-up' this week once I can do alot more driving. Rob

[rxl158]

Hi Lance, something weird is going on now. I tried data logging while driving and it would loose connection and lock up the MS unit. I'd have to pull over and restart, then it would seem to randomly lock up even with laptop disconnected. Any ideas what it might be? I didn't have this happen with 4.146 code, actually drove with that code for hrs except for the line pressure not adjusting. Has something changed with how the MS communicates with TS? Thanks for your help and suggestions:)
Rob

[rxl158]

Lance, I was able to get a short datalog before MS went offline (attached). It seems pretty repeatable, even though doesn't make sense to me. If I go out and start car without laptop connected, it will hang in 1st gear. I then come to a stop, shift into N or P and back into 4th (drive) and it shifts normally. If I connect the laptop it will loose connection within ~10 secs. I was thinking of going back to old (current released) code as a 'control' to weed out comm issues. Any advice of what I should try next? Thanks,
Rob

[Bernard Fife]

Rob,

Yes, lots has changed with the new code in terms of comms, as Al Grippo has added the new serial format that incorporates the CRC envelope checking function. This required moving lots of things in the interrupts around to suit the new messaging (and its new interrupt capabilities).

If it were up to me, we would have never adopted the new serial format, as there were few problems with the proven older format, and the new interrupt ability means that the comms can over-ride other more important functions in the code. But it's not up to me, and I didn't write the new comms code.

However, the new serial code is commented out of the 5.0xx code (it will be implemented in the 6.0xx code), and the old code is supposed to be used. However, the change in interrupts are still in place and these changes can cause a number of issues, and that's what you are likely seeing. These tend to be fairly straightforward to fix once properly identified, so I will have a look in the code. In the meantime, if you were willing to try 4.146 and report back here, to eliminate any possible hardware issues, that would be helpful.

Lance.

[Bernard Fife]

Rob,

I think the problem is in the 'CAN disabled' part of the code, and I will fix this and post some new code here shortly.

Thanks for your patience with this. I know it is frustrating and I can only apologize. The 'old' code literally had years of sorting to get these little bugs worked out. Having to adopt the new interrupt structure threw most of that debugging work into the trash bin, so we are having to go through it again all at once. But we will get there, and the more people find and report these issues the faster that will happen.

BTW, in your datalog, the manual shift lever is always in neutral (= 0). The pressure control doesn't respond to the table in neutral because you have set '60%' under 'General Settings -> Shift Factors -> Line Pressure in Neutral' (which is then rounded to the nearest PWM% step). If you want the PWM% step to follow the table in neutral, change this setting to 'Use 16x9 table'.

Lance.

[Bernard Fife]

Rob,

This code should work better for the PC%,, it certainly does on my bench (in both CANbus and non-CANbus modes, with or without the brakes).

Monitor_5099y.abs.s19

(82.96 KiB) Downloaded 510 times

GPIO_MShift_5099.ini

(277.7 KiB) Downloaded 525 times

Let me know if this doesn't help.

Lance.