Retard with MS3

[Bernard Fife]

gurov,

Yep. But the MShift code can't write to MS3's memory at all, it can only send a CAN message. MS3 has to receive that CAN message properly, interpret it correctly as a 'write' command, then put the sent retard value in the right place, and then act on it appropriately. Because the B&G code receives the right message, we know the format and content of the message are correct. So that leaves:

- the MSG_CMD CAN message format for *any* 'write' message in the standard format is not being handled properly at MS3 (MS3 may have any number of 'non-standard' message formats that work, but that doesn't matter. What matters here is that it understands the standard format properly),
- the value isn't written to the correct place (based on either the user settings or perhaps some unintentional offset in the code), and/or
- MS3 doesn't do the right thing with the value (subtract it from the advance) even when it is in the right place.

If this was mine, I suppose I might try a bunch of different offsets (on the bench only) to see if you can affect the adjustment values at all. A better solution would be to insert a debug value in the code that changes based on what stage a MSG_CMD message to write a value to that table and offset gets to. Then you would be able to see where it is failing, and it should be easy to fix from there for any moderately skilled programmer.

Lance.

[gurov]

gurov,

Yep. But the MShift code can't write to MS3's memory at all, it can only send a CAN message. MS3 has to receive that CAN message properly, interpret it correctly as a 'write' command, then put the sent retard value in the right place, and then act on it appropriately. Because the B&G code receives the right message, we know the format and content of the message are correct. So that leaves:

- the MSG_CMD CAN message format for *any* 'write' message in the standard format is not being handled properly at MS3 (MS3 may have any number of 'non-standard' message formats that work, but that doesn't matter. What matters here is that it understands the standard format properly),
- the value isn't written to the correct place (based on either the user settings or perhaps some unintentional offset in the code), and/or
- MS3 doesn't do the right thing with the value (subtract it from the advance) even when it is in the right place.

If this was mine, I suppose I might try a bunch of different offsets (on the bench only) to see if you can affect the adjustment values at all. A better solution would be to insert a debug value in the code that changes based on what stage a MSG_CMD message to write a value to that table and offset gets to. Then you would be able to see where it is failing, and it should be easy to fix from there for any moderately skilled programmer.

Lance.

well it is handling it... and theoretically things should align, 630 - 512 = 118, which is the offset of the 8 byte block of 4 integers in datax1 when the var_offset is > 0x200

Code: Select all

       can[1].cx_destvaroff[jx] = inpram.Adj_varoffset;

we'll keep digging, i suppose... i've got an alpha16 + debug to get some of the CAN parameters into the logfile, and that's not making sense really for now.

[gurov]

The debug alpha with a counter for every can packet processed shows no packets when there should be shift retard. It increments if I enable can gear, can vss, and trans temp over can.

Can there be an indicator added for when retard should be applied in mega shift please ? I will upload my msq later today as well do it can be verified I am not screwing anything up.

[Bernard Fife]

Gurov,

That tells us that MS3 is not handling the MSG_CMD (defined equal to zero) format properly (since we know it is being sent properly because it shows up in B&G MS-II). [The 'read' messages are MSG_REQ (defined as =1) and apparently MS3 is handling these correctly.] This really is an issue for the MS3 developers. If they don't want to or aren't able to deal with it for whatever reason, I would like to help but there's nothing I can do (when something is broken, trying to fix the part that works doesn't help, you have to fix the part that doesn't!).

For the indicator, as I said above, the relevant channel is already in the code 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.

You can also make you own indicator out of it with something like:

Code: Select all

   indicator = { SPKAdj             }, "No retard", "Retard",    white, black, black, white

in the [FrontPage] section of the MShift INI.

Lance.

[gurov]

great, i will add the indicator.

ms3 is not receiving the message, we added a counter for number of messages received, and the counter is not incrementing when all other CAN stuff is inactive at the time megashift should be sending the packet.

we'll keep at it.

[gurov]

As mentioned before, please tell me how I'd setup the megashift firmware on an MS2 to test it.
If you are able to identify an older MS3 firmware where it did work, please let me know that also.

I'm sailing blind at the moment. The only changes to MS3 CAN that I'm aware of from alpha12-16 were fixing up some bugs with passthrough, but I _believe_ the bug was only impacting the case of the MS3 being connected to the computer via serial and relaying to the remote device. The reception of CAN messages was not impacted.

As noted in this topic, I AM able to send the required timing retard command using MS2/BG as the serial/CAN gateway and the MS3 responds as expected.

James

it was mentioned that 1.0.x worked with retard in this arrangement

[Bernard Fife]

gurov,

If it worked with 1.0.x, then the problem has to lie with the later MS3 code, as we suspected. The problem may be some unintended consequence of a CAN change, it could be an interrupt enable issue, or it could be a compiler bug (often these are optimization issues, I find), or something else.

I re-checked the code, and everywhere that outpc.SpkAdj is set, sendCANAdj() is called immediately afterwards to fill the CAN message buffer. (The timing retard is set on shifts, but also while running so that the 'in-gear' retard can be set/cancelled depending on the current load.) I thought of adding a 'send' counter, but that seems redundant since any change in the value of outpc.SpkAdj (in the [OutputChannels] of the ini) represents a 'send', so the counter adds no real information.

BTW, If it helps others in their testing, I have run MShift code on an MS-II on a 2.1 stim - it will work, and the tach input becomes the VSS. You might have to play with the gear lever input settings to get the controller to be in drive so you can shift through the gears using the tach input to run through the speeds (depending on the tach signal generation circuit, you might need to change the 'number of VSS teeth' setting to get a reasonable speed range).

Lance.