RomRaider

Hello all!

So I finally was able to get RR logger into its mushy brain state again and down below is the system log file. This was done on the github version 425c8e0 for the second half of the RR system file, and on the official release for the first half. Reason why I'm not posting this issue on GitHub is because I'm presuming that it's going to be some user error where java doesn't like having multiple RomRaider.jar files in existence or something like that, rather than an actual coding issue.

So what causes the logger to go into this mushy state where it just shows "stopped" and nothing you do can fix it? Last night, I was able to get it to throw a null pointer exception (first half of the rr_system file). But today, it just shows "stopped" and won't throw any exceptions anymore. What's strange is that now, the official release logger works fine but the github release one doesn't. I even reinstalled the git release in the RomRaider folder to see if maybe the location was causing issues, but it didn't seem to make an impact.

So just to clarify;
Official Release = "Stopped" Null Pointer Exception thrown (Yet, it eventually fixed itself after resetting my computer.)
GitHub Build = "Stopped" no errors.

In the official version the exception is in the routine that builds the top toolbar options for the ECU / TCU and in your case the ABS checkboxes.
Most likely an error in the Logger def as this is part of the GUI build and occurs right after reading the Logger def.
Since your debug output has no line numbers, I can't isolate the error any further.

The second part of the log only shows that the query manager was started then stopped 1/2 a second later with no error.

Hmmm. Even with v370 logger def and v8.0 for RR logger, it's still showing "stopped" and "disconnected".

Although, I deleted the settings and profile backup file, ran logger, set debug mode, and selected the current logger file + protocol and it gave some potentially new exceptions. But it looks to be mainly mad about the OP2 cable not being connected, which shouldn't be an issue because in the November 2020 release, it would just constantly keep searching and attempting to connect even without an OP2 plugged in.

I updated romraider last night to the 0.8.0 and now it will not connect to ecu I believe it is not reading the tactrix cable being plugged in. It only shows stopped and disconnected on mine and will not attempt to reconnect when you click refresh. my ecu flash is still working and my logger version 0.5.9 is working on my other laptop so I was able to rule the cable being the issue.

Did you load the new Logger definition file?
viewtopic.php?f=2&t=19023
Read the notes

I attempted with my own logger def, with the 1 before the ECUID as well as the official logger def, which only would contain standardized CIDs. Both yielded the same “disconnected” results, unfortunately.

When I tried restarting the computer last night it still didn't work but when I turned on the laptop today to play with it it was attempting to connect and displayed the com port options. I guess it either took a complete power down to rest or decide to fix itself lol.

I’ve had the same experience in the past, it would just randomly start working properly after either enough restarts or enough time haha But so far, I’m three resets and multiple days in without much changing. When building the versions leading up to the official release, none of their loggers changed from “disconnected” for me either.

Does this only happen with Nissan definitions?

It wouldn’t matter, as the default protocol is SSM. So when clearing settings, I believe it defaults to having SSM set. If not, I already tried selecting other protocols and nothing caused it to change unfortunately.

Without any clean logs I can't say what the problem might be.
If you are using un-official defs, then we'll need to see those too.

Have you power cycled the J2534 cable when this happens? That would be disconnect it from the USB and the OBD-II port.

May have made some progress in regards to this. Attached are two error logs (taken from a separate instance where only one is running at a time) from attempting to run the v7.2 logger and v8.0 logger. The v7.2 logger continually attempts to connect (as shown in the screenshot), while the v8.0 logger just sits there twiddling its thumbs.

While both error logs are provided, I attached a screenshot of what each logger is attempting to do during a specific instance. The V7.2 logger is attempting to locate a J2534 cable, but failing to do so (since it's not attached). But the V8.0 logger decides it's just gonna sit there and do absolutely nothing. This is probably what's causing it to fail to do anything but show "disconnected", since it's not even looking for a J2534 cable.

Interesting. I didn't touch that part of the code when adding CAN support, but then I wasn't the only one making changes. I'll have to compare between the two to sort it out.
Thanks for the logs.

No problem! I’m hoping it’ll be a simple fix, as it’s not a universal problem for whatever reason (AFAIK?).