Jim Blackwood wrote:Is there such a thing as a stock xdf for the 12202088 OS?
It seems like all the ones I'm seeing are derived from Dimented24x7's xdf which I'll grant you is pretty great, but am I not right in saying that he deleted all the flags except for an even dozen?
I'd like to use the DTCs for troubleshooting but without the flags I don't see just how that would be possible. So is there a relatively simple way to put the flags back that a non-programmer like myself might be able to do?
Jim
Yep the best XDF for that OS is Dimented 24x7's. I thought it was pretty good though. Did you see its split in to a different file for each segment? There is also LRT's XDF which I can see has 12 flags only.
I'll add the copy of Dimenteds XDF here for now. I'll add it to the repo along side the other ones at some stage.
Been trying out the logging functionality and am not able to log for more than a couple seconds. Using an OBDLink SX cable, anyone have luck logging with one?
Here is the error I receive after a couple seconds of logging, any idea what is going on?
[04:05:17:243] Requesting row...
[04:05:17:243] TX: STPX H:6C10F0, R:2, D:2A01FEFD
[04:05:17:321] RX: 6C F0 10 6A FE 0B 90 03 10 20 00
[04:05:17:321] RX: 6C F0 10 6A FD 28 55 83 7E 00 92
[04:05:17:321] ReadLogData: 6C F0 10 6A FE 0B 90 03 10 20 00
[04:05:17:321] ReadLogData: 6C F0 10 6A FD 28 55 83 7E 00 92
[04:05:17:324] Requesting row...
[04:05:17:324] TX: STPX H:6C10F0, R:2, D:2A01FEFD
[04:05:17:418] RX: 6C F0 10
[04:05:17:418] ReadLogData: 6C F0 10
[04:05:17:427] System.IndexOutOfRangeException: Index was outside the bounds of the array.
at PcmHacking.Message.get_Item(Int32 index)
at PcmHacking.Vehicle.<ReadLogData>d__45.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at PcmHacking.Logger.<GetNextRow>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at PcmHacking.MainForm.<LoggingThread>d__25.MoveNext() in C:\GitHub\PcmHacks\Apps\PcmLogger\MainForm.cs:line 342
Just let me know if the full log is needed, I can edit to include. Just trying to save space...
The SX sent back only the first 3 bytes of a longer message. The app should not have crashed though, that's a bug, and I think I just fixed it. I do still need to test it, but it'll be in the next release for sure.
It's not something I ran into when testing with the AllPro or LX, so it may be that the Scantool SX isn't a good candidate for logging - or there may be two bugs going on here... We've seen a few issues lately related to how long the devices wait for incoming messages, and I think this might tie into that. The fix to that issue might be redo the way timeouts are set everywhere. I had hoped that the app could specify timeouts in a uniform way and use math to get the right timeout values for each device, but I'm starting to think that what we really need to do is specify timeouts for each device and each specific scenario (reading, writing, logging, etc).
But the next release will go out as soon as we get P59 full-flash support working reliably. The timeout change would come some time after that.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!