BB Logging beta update: April 14, 2008

Printable View

Show 40 post(s) from this thread on one page

April 20th, 2008
Blacky

Quote:

Originally Posted by swingtan

Lennart and lakingslayer, the "weird frames or "logs full of notes" sounds like the problem I'm having as well. I've found that repeated tries at opening the file eventually seems to get a clean read and displays "sane" data. I have no idea if the data is actually correct though.

The way the logs look when they open in "corrupted" form reminds me of the first BBL logs I tried on the E38 when the V2 would cause I/O problems between the ECM and other modules, bringing up dash alerts and dropping corrupted data into the log file. This was back around the start of this year. When opening these files in ScanTool, I'd get the same weir looking data displayed as I get now. It's almost like the BBL files don't have an <EOF> character and ScanTool ends up with random data at the end of the log.

Simon.

There appears to be a bug in the frame count value. The frame count value is written into the file as a 16 bit value ("%d") but should be written as a 32 bit value ("%ld"). That will cause problems if the log file is longer than 65535 frames. A fix is being made now.

If any of you have log files of less than 65535 frames that are showing corrupt frames, please send them to me at [email protected].

Regards
Paul
April 20th, 2008
GMPX

Quote:

Originally Posted by dc_justin

Still seeing the T42 base pressure bug. Screenshots below

Same TCM OS, just a different EFILive release I assume?
April 20th, 2008
swingtan
Quote:

Originally Posted by Blacky

There appears to be a bug in the frame count value. The frame count value is written into the file as a 16 bit value ("%d") but should be written as a 32 bit value ("%ld"). That will cause problems if the log file is longer than 65535 frames. A fix is being made now.

If any of you have log files of less than 65535 frames that are showing corrupt frames, please send them to me at [email protected].

Regards
Paul

I have a few, as I was also finding that opening old log files caused this issue. I just tried opening a log from 24/1/2008 that is 8842 frames long and the first 4 tries resulted in a corrupt display. The fifth try brought up a clean dash page. All I did was to double click the log file and allow ScanTool to open automatically.

I just noticed that data is stored in the "temporary cache" folder when the files are opened. There are 2 files for each opening of the *.efi log file..

Corrupt version:
- efi_cache.0 = 0KB in size
- efi_filter.0 = 0KB in size
OK Version:
- efi_cache.1 = 262KB in size
- efi_filter.1 = 0KB in size
The original logfile is 262KB in size......

Did you still want log examples ?

Simon
April 20th, 2008
dc_justin

Quote:

Originally Posted by GMPX

Same TCM OS, just a different EFILive release I assume?

Yep. The same file was opened in both versions of the software. In fact, every 07 T42 file I've opened has had the same problem.
April 20th, 2008
hymey

Quote:

Originally Posted by swingtan

Hi Paul,

I tried some more BBL-ing this morning and while the recording works well, I still can't read any of the DMA PID's in the log file, when loading into scan tool.

Simon

Any feedback for this blacky?
April 20th, 2008
Blacky

Quote:

Originally Posted by hymey

Any feedback for this blacky?

I'm working on it tonight... (no rest for me).
Paul
April 20th, 2008
GMPX

Quote:

Originally Posted by Lennart

DVT is pretty sweet! Turning on/off is a little weird sometimes as the setting will remain on even when shutting off the feature (e.g. idle speed)

Lennart, the DVT's should disable pretty much instantly, there is also some timers in the ECM that should shut them off if Flashscan is no longer broadcasting the override messages.
So on your idle speed control, as soon as you untick the idle speed control box the ECM should return to normal operation.
When you say the idle speed remains in DVT mode, for how long is this for?

Cheers,
Ross
April 20th, 2008
swingtan

1 Attachment(s)

I have an update for the PID's issue. I tried pass-through logging this afternoon and noticed that E38.AFRATIO_DMA was reading wrong. It was reading 0.56:1.

Here's the log file.....
April 20th, 2008
Blacky

Quote:

Originally Posted by hymey

Blacky I am having the same problem as swingtan. When logging all the pids are showing and recording. I load the logged data to my PC once the scan tool opens all the dma pids are missing from the recording. If I try and add them it wont allow it. It states that the pids can only be selected if I clear the logged data.

Other than that, all is going smooth. And it flashes very fast with the new calz files. I also noticed in the VVE that thr rpm increments increase by 200rpm all the way whereas before it would increase by 200rpm then 400 rpm further down the column.

Cheers

Joel

The problem was the E38 and E67 DMA PIDs are prefixed with E38 and E67 respectively. Black Box Logging was adding the prefix GM in the *.efi files. When the *.tun files were loaded into the scanner, it could not find (for example) the PID GM.AFRATIO_DMA because the PID is actually called E38.AFRATIO_DMA.

If you really need the data from those log files, you can edit the *.efi files using Hexedit (from www.bpsoft.com). Change the GM.xxxxxx_M PID names to E38.xxxxxx_M names. In Hexedit that will require you to insert a character after the GM. I.e change the existing "GM" prefix to "E3" and then insert an "8" to make the prefix "E38".

Regards
Paul
April 20th, 2008
Blacky

Quote:

Originally Posted by joecar

Paul,

In scantool build 48, doing Print All (button or menu) causes immediate access violation...

Print single works ok, but it's tedious to generate a report of everything by doing single reports of each tab.

Cheers
Joe

Hi Joe,

I still can't reproduce this problem here.
Can you tell me the settings you have checked in Properties->Printing?
Thanks
Paul

Show 40 post(s) from this thread on one page