jsmcortina wrote:Phil,
I know I mentioned the blocking factor earlier, but as this is CAN passthrough, shouldn't that actually be irrelevant? So long as the blocking factor used in TunerSutdio matches the CAN "master", there are only 8 bytes sent over CAN at a time anyway?
James
Prior to TS 3.0, TS didn't use the readChunk command, it always read the full page. As you know if you open a dialog, TS refreshes the data from the controller to make sure you are always looking at what is actually on the controller. So prior to TS 3.0, this meant TS would look at all the settings in a the opening dialog and issue reads on any pages contained in that dialog.
With MS2 Extra or MS3, generally this was still very fast as they all support the crc 'k' command, so it will pass the CRC for the page and skip the full read, worse case it was a 1024 byte read and still didn't take a great deal of time. Thus there was little motivation to implement readChunk and read subsets of the page.
However, there have been some firmwares that do not use the k (crc) command such as MShift and others with much larger pages. in a case where TS has to read a large page, this interfered with runtime data while it was retrieving the page refresh.
Thus the implementation of the readChunk command. In TS 3.0+, TS follows similar logic where it refreshes the data from the controller, but now only the ranges of the page that are included on dialog.
Now to finally answer your question.....
When using the readChunk command to read a block larger than the blockingFactor, starting at an offset > 0 , on a firmware not supporting the k command, TS was mis-aligning up the indexing of the data read. The data was shifted.
In my own car I regularly use a project with an MS3-Pro as the primary controller and your Trans code as a CAN controller. Never had an issue, but I see that is because your Trans code supports the k (crc) command, so it would skip the chunk read as it should always pass the crc when opening a dialog.