Shift to 5th from Park

[Bernard Fife]

gurov,

If you could, try the latest 4.003 code. There was a problem in recent code versions (since 2.00F - so your post was a huge help in finding this issue).

The issue was that in changing the error state when not finding a gear (it used to be outpc.manual_gear == 99, but was changed to a separate flag - gear_error == 99), I failed to reinitialize it properly each time through the gear lever checking loop. So the error checking was essentially disabled. With no error checking, it's not surprising that you were getting errors!

The 4.003 code ( http://www.msgpio.com/manuals/mshift/V4code.html ) corrects this and should help your Park to 5th issue.

Lance.

[gurov]

no go. exact same problem, tried 500 debounce, 2000, 3000, 4000, 5000, 6000.

i'm uploading video of this failing to work (very very slowly)

back to 200Fx_test for me. (video of this working will also be presented)

[Bernard Fife]

gurov,

A datalog (and the exact MSQ used to generate it) is much more useful than a video.

Lance.

[gurov]

first video:

http://www.youtube.com/watch?v=bfzoxzjH7CM

right column is digital switch states, left column are the voltages.

the switch states are not getting updated when the voltage flips, it CAN be made to update, but it stops working once it's shifted into drive.

the inputs are as follows:

Code: Select all

P = 1 0 0 1
N = 0 1 0 1
R = 1 1 0 0
1 = 0 1 1 1
2 = 0 0 1 1
3 = 1 0 1 0
4 = 1 1 1 1
5 = 0 1 1 0

seems that burning when the state is stuck (setting debounce to 600, then back to a higher number) cause it to unstick the states.

this still doesn't help me, as the indicators show that both up/down shift are pressed (which they should be), but it's in MANUAL MODE still (even with auto_mode != 0), and when i go to press the upshift/downshift lever, the indicators do not change like they would with 200Fx

i want to make this work, shifts into 3rd are VERY harsh due to the code not waiting for pressure to drop/adjust and just instashifting solenoids into 3rd state.

[Bernard Fife]

gurov,

I can't tell much from the video - it's hard to see what is going on because I can't read the TS labels.
Which switch states are getting 'stuck" - all of them? Or just one?

Can you post your 4.003 MSQ for me to try (or 2.103 if that's what your are using - if you haven't, you might try it, it is quite different to 4.003 and would eliminate a lot of possibilities). And ideally post a datalog.

Lance.

[Bernard Fife]

gurov,

I have tried your input patterns on my bench (w/ 4.003) and it seems to work as expected with 2.904 code.

Do you have other CAN devices on the network? It isn't impossible that they might be interfering with the messages to/from the GPIO. If you could disconnect the two CAN wires and try with the lever shifting (don't start the engine) that might shed some light on it.

Lance.

[Bernard Fife]

Gurov,

Here is some test code:

Monitor_4004.abs.s19

GPIO_MShift_4004.ini

It has a few changes that might help, but more importantly, it replaces the VSS error with a value for the shift states, but only if no valid gear is found:

- The first binary bit (0x01) is the sate of switchA (0=off, 1 = on),
- The second binary bit (0x02) is the sate of switchB (0=off, 1 = on),
- The third binary bit (0x04) is the sate of switchC (0=off, 1 = on),
- The fourth binary bit (0X08) is the sate of switchD (0=off, 1 = on).

It will show a value on the VSS error gauge and in the datalog. For eaxmple, a value of 11 = 1011 in binary (or 8 + 2 + 1), which means switches D, B, and A are on, C is off. This might shed some light on what you are seeing because we can compared them to the independent switch states.

Lance.

[Bernard Fife]

gurov,

Here is another test code version (same INI). It does something different with the VSS error, so let me know what you see with this code (or make a datalog).

Monitor_4004b.abs.s19

By the way, one thing that will definitely screw up the lever shift function is a loose/bad solder joint connection. These act just like you say - things freeze, it won't shift, etc. I *have* seen that on my bench before, so it might be worth checking. The problem can be external (in the switch or wiring, or in the input circuits on the board - most easily found with a trans stim, but you can ground the pins, etc. manually). This wouldn't explain why older code works, though.

Lance.

[gurov]

gurov,

I can't tell much from the video - it's hard to see what is going on because I can't read the TS labels.
Which switch states are getting 'stuck" - all of them? Or just one?

Can you post your 4.003 MSQ for me to try (or 2.103 if that's what your are using - if you haven't, you might try it, it is quite different to 4.003 and would eliminate a lot of possibilities). And ideally post a datalog.

Lance.

all of them are getting stuck. when there's a 4.2-ish value on the left column, that's the voltage received by the switch inputs swADC - swCDC (no DDC). 1 or 0 on the right is the state of the swA - swD variables,

what i do is load the 200Fx_test over the 4.003 or whatever newest version is out there.

http://gurov.us/2011-04-09_15-40-19.msq is the latest version i have that works on 200FX.

i will grab a datalog next time i try the newest beta/alpha.

there is no other CAN device except MS3 now, i fried my iox and haven't replaced it yet.

engine was not running in the video, whenever temp goes to -40 with yellow background, that's ignition being switched off entirely.

[Bernard Fife]

gurov,

What I need is the MSQ you are using for the code that doesn't work.

Are you connecting the serial cable to the GPIO board? If not, that's the best way to get a clean datalog file.

If this was mine, I think I would try temporarily disconnecting the MS3 box from the GPIO, on the chance that the MS3 is screwing up the CAN comms (since that seems to be the biggest difference between my set-up and yours). You won't get a load, etc., so don't run it this way, but just check the shifting.

Lance.