Retard with MS3

gurov · Post by **gurov** » Sat Nov 19, 2011 2:33 pm

and also, i tried to get timing retard via can to ms3 working, and that didn't seem to work.

i set it to retard only above 20 kpa (so always, yes ?) upshift/downshift 20 degrees, and 40 degrees retard for 2nd - 5th gears. drove it around the block, to get into 3rd, but over on ms3 side timing didn't change. are there limits that something is not enforcing which ends up corrupting that variable ?

can a "shift retard" indicator be added any time this feature is active, is it only active during the shifts, if so, what setting controls the duration ?

Bernard Fife · Post by **Bernard Fife** » Sat Nov 19, 2011 2:36 pm

gurov,

It works on MS2 with the B&G code, so I would ask on the msextra forums regarding MS3. The MShift code can only send the retard to MS3, it can't make it happen, and any limits would be in the MS3 code. The developers may even have moved the relevant variables, and/or not implemented/tested them properly.

Lance.

Bernard Fife · Post by **Bernard Fife** » Sat Nov 19, 2011 3:09 pm

gurov,

The 'retard indicator' rightfully belongs in the engine code, since it can be triggered by any of the CAN devices, and is only acted on by the engine controller. However, the spark adjustment is already in the output channel as SpkAdj. It isn't in the datalog, but you could add it with a line like:
entry = SPKAdj, "SA", float, "%.1f"
in the [Datalog] section of the INI. You can also make a gauge out of it, if you like, see the [GaugeConfigurations] of the INI for examples of how to do this.

The way the trans code sends the retard is, when a shift is commanded:
- a shift flag is set (this blocks a number of actions in the normal flow of the code, and prevents shifts from 'piling up'),
- if the load is high enough, the target gear is compared to the current gear, and the appropriate upshift/downshift retard is sent via CAN,
- things like line pressure are adjusted as required, and the pressure adjustment delay is waited out,
- the clutch outputs are switched, if used,
- then the solenoids are switched,
- the clutch outputs are reset,
- the appropriate retard for the target gear is sent via CAN, depending on the current load,
- the shift buttons are reset,
- the shift flag is cleared.

So the duration of the retard is equal to the line pressure adjustment delay plus the shift completion delay, plus a millisecond or two.

4.007 will have the voltage based lever determination error, as noted above. This will get fixed and be released as 4.008 when I add the voltage based shift buttons.

Lance.

gurov · Post by **gurov** » Mon Nov 21, 2011 8:51 am

Lance wrote:gurov,

The 'retard indicator' rightfully belongs in the engine code, since it can be triggered by any of the CAN devices, and is only acted on by the engine controller. However, the spark adjustment is already in the output channel as SpkAdj. It isn't in the datalog, but you could add it with a line like:
entry = SPKAdj, "SA", float, "%.1f"
in the [Datalog] section of the INI. You can also make a gauge out of it, if you like, see the [GaugeConfigurations] of the INI for examples of how to do this.

The way the trans code sends the retard is, when a shift is commanded:
- a shift flag is set (this blocks a number of actions in the normal flow of the code, and prevents shifts from 'piling up'),
- if the load is high enough, the target gear is compared to the current gear, and the appropriate upshift/downshift retard is sent via CAN,
- things like line pressure are adjusted as required, and the pressure adjustment delay is waited out,
- the clutch outputs are switched, if used,
- then the solenoids are switched,
- the clutch outputs are reset,
- the appropriate retard for the target gear is sent via CAN, depending on the current load,
- the shift buttons are reset,
- the shift flag is cleared.

So the duration of the retard is equal to the line pressure adjustment delay plus the shift completion delay, plus a millisecond or two.

4.007 will have the voltage 0based lever determination error, as noted above. This will get fixed and be released as 4.08 when I add the voltage based shift buttons.

Lance.

jsmcortina wrote:
gurov wrote:i'm caught up to alpha15 on my bmw now. car seemed to start better. was there a change to the missing + 2x cam decoder code ?
Possibly in relation to the half/full sync indicator.
trying to get msgpio's megashift to retard timing during shifts still does not seem to be working. outpc 7 , address 630 produces no change in what timing is displayed when it should be getting retarded by the trans controller. is there a way to get that variable ( ign retard ) to see if gpio is sending anything at all ?
I've tested just now using CAN passthrough via an MS2/Extra and writing to address 0x278 (632) does indeed alter the timing.

The addresses are:
0x276 (630) FuelAdj
0x278 (632) SpkAdj
0x27a (634) IdleAdj
0x27c (636) SprAdj

James

it works in MS3.

i'm just trying to get my setup working. indicator should be on both sides in order to figure out what's not working right.

i have it set up as instructed by MS3 devs, block 7, address 630. with 40 degrees timing retard in all gears the timing/engine tone was never changed, so it's clearly not working somewhere.

Bernard Fife · Post by **Bernard Fife** » Mon Nov 21, 2011 10:52 am

gurov,

I just re-tried this on MS-II with B&G 2.905 code and a GPIO with MShift 2.111 and it works fine. I have the shift delays both set to 504 milliseconds, and the retard set to 25 degrees, and the MS-II Ignition Advance gauge in TunerStudioMS shows the appropriate retard from its steady state value for the duration of the shift (~1 second). I also checked the 'in-gear' retards for 2nd, 3rd, and 4th, and these act exactly as I would expect on the advance gauge. This is with TS attached to MS-II, with the MShift data coming through the CAN pass-through.

So there's not much else I can do. I suppose I can check with the B&G 3.770 code, as there were a few small changes to the CAN comms for that, and I will try that later (but that still won't tell us anything about why the MS3 isn't working as it should).

Lance.

gurov · Post by **gurov** » Mon Nov 21, 2011 3:28 pm

any way you could try ms2extra code ? implementation there is identical to ms3.

Bernard Fife · Post by **Bernard Fife** » Mon Nov 21, 2011 4:02 pm

gurov,

The CAN implementation in the MShift 2.XXX code (and the protocol used to exchange data with other controllers) is exactly the same as in B&G 2.9xx code, and I wouldn't want to change it in any way (it is known to work, as I said above, and it forms the basis of CAN comms on a few B&G code threads).

Your MS3 doesn't need to know what code is in the MShift controller, it only needs to follow the same CAN protocol as laid out by B&G in the source code that the extra guys based their code on (and you have to enter the right settings for the table and offset, of course). Since this works perfectly on B&G code, it is up to the msextra developers to sort out the problems their code has. I can only assume they have tinkered with the standard CAN implementation, and haven't got it right. I have no interest in digging through extra source code (if it is even available, I don't know) to see what might be messed up.

Lance.

gurov · Post by **gurov** » Mon Nov 21, 2011 5:07 pm

Lance wrote:gurov,

The CAN implementation in the MShift 2.XXX code is exactly the same as in B&G 2.9xx code, and I wouldn't want to change it in any way (it is known to work, as I said above, and it forms the basis of CAN comms on a few B&G code threads).

Since this works perfectly on B&G code, it is up to the msextra developers to sort out the problems their code has. I can only assume they have tinkered with the standard CAN implementation, and haven't got it right. I have no interest in digging through extra source code (if it is even available, I don't know) to see what might be messed up.

Lance.

i'm not asking you to dig thruogh extra code. just install latest ms2extra on whatever setup you have, and run a quick test on the bench you have set up.

if it doesn't work, then it will be up to the extra devs to figure out where this is broken.

Bernard Fife · Post by **Bernard Fife** » Mon Nov 21, 2011 5:52 pm

if it doesn't work, then it will be up to the extra devs to figure out where this is broken.

gurov,

You have already shown that it doesn't work (on your MS3), so it's up to the extra developers to figure out where they have broken their code. Me trying it won't add anything at all. If I try it and it doesn't work, all we know is that there is a problem with the msextra CAN code. If I try it and it works, then all we know is that there is a problem with the MS3 code. Both of these are issues for the extra developers to sort out, I can't do anything about them.

Lance.

gurov · Post by **gurov** » Mon Nov 21, 2011 6:54 pm

Lance wrote:
if it doesn't work, then it will be up to the extra devs to figure out where this is broken.
gurov,

You have already shown that it doesn't work (on your MS3), so it's up to the extra developers to figure out where they have broken their code. Me trying it won't add anything at all. If I try it and it doesn't work, all we know is that there is a problem with the msextra CAN code. If I try it and it works, then all we know is that there is a problem with the MS3 code. Both of these are issues for the extra developers to sort out, I can't do anything about them.

Lance.

is the current 2.111 code tree published somewhere ? james is willing to take a look