Bricx won't find my NXT

[ggrinton]

Bricx Command Centre can no longer find my NXT over bluetooth.
When I start it, the Tools->Find Brick Port option displays only Automatic/Search/usb
- Automatic fails to find anything.
- Search fails to connect, but after I do that, I see that the port list includes two new entries - one with just the device name (BTH::G-NXT), and one with the name followed by the USB address(BTH::G-NXT::00:16:53:). Attempting to connect to either still fails.
The Lego Mindstorms program is able to connect and performs normally.
I can't see any other options, but is there some way of helping Bricx start talking again please?

Thanks.
Geoffrey

[HaWe]

did you read and try this...?
http://sourceforge.net/apps/phpbb/mindb ... f=3&t=1624

[afanofosc]

Check your nxt.dat file which is in your %appdata%\Roaming\JoCar Consulting\BricxCC\3.3 folder. The BTH::G-NXT entry is an alias for the longer entry that you see in the list. Please verify that the full brick resource string in the nxt.dat file is correct for your brick. the address is actually the bluetooth MAC address of your NXT. It shows up on the NXT Versions screen as the ID of your NXT. You should see an entry like this:

BTH::BNXT=BTH::BNXT::00:16:53:0A:75:7B::1

The portion before the equal sign is the alias. The bit after the equal sign is the full brick resource string. BricxCC adds every entry from this file into the list of ports with both the short alias and the full string (iirc). You can type in a full brick resource string also just to test to see what works, if anything. If the brick resource string is not correct then it won't work when you try to connect using it. This file can also have USB brick resource strings which look like this:

alias=USB0::0X0694::0X0002::001653FF0156::RAW

The Bluetooth brick resource string ends with the virtual serial port number that your OS creates for a paired bluetooth device which supports the SPP (serial port profile). You may need to correct this virtual serial port number in the nxt.dat file if BricxCC put the wrong value there. You can try out various values by just typing them into the ports field. But you can see what ports your OS has defined for the NXT via the OS-provided Bluetooth driver software. There should be 2 serial ports. One is incoming and the other is outgoing. If you don't see both of these then that might explain why you can't connect.

Another thing I would try is making sure you have the very latest Fantom drivers. You can get these from various sources, including from a link on the RobotC website. The NXT 2.0 software download from the LEGO website includes a very recent version as well.

Also, I would be sure that you have the latest BricxCC test release. If I recall correctly there was a version a while back that had its Bluetooth communication layer broken but that has since been fixed.

John Hansen

[ggrinton]

Thanks John. It is good to have your explanation, although I had deduced some of it already.
I found the nxt.dat file - zero bytes in length.
Thinking to force a clean start, I downloaded the latest test release (3.3.8.10) and installed that. Maybe I was being too smart for myself, as I deleted the whole ...\JoCar Consulting\BricxCC\3.3 folder, assuming that as part of a clean start, it would get recreated properly. Now, when BRICX runs, it searches for, and now successfully finds the NXT. If I then close communications and do a 'Find Brick', it again, lists the BTH entries as per my earlier posting.
However, the \JoCar Consulting\BricxCC\3.3 folder is not recreated, and I search high and low for a nxt.dat file. Consistent with that, a restart of BRICX results in a new search, as before.
But at least it now will dfind and talk to the NXT

[afanofosc]

I don't know why this folder would not be recreated any time you search. Very odd. The nxt.dat file can be manually edited with Notepad and the folder can be created manually as well. It should be under %appdata% which if you type it into Explorer will automatically expand to the right location. That should be (on Windows 7)

C:\Users\<username>\AppData\Roaming\

You can manually create the JoCar Consulting\BricxCC\3.3 folders below that and use notepad to create an nxt.dat file.

Something you may need to check is whether the Bricxcc executable is "blocked" since you downloaded it from the web. Right click on the exe and choose Properties. It may have the option at the bottom of the Properties dialog to "unblock" the executable. The same will need to be done to the compiled help files (*.chm) in the Help folder - and the rest of the executable files as well.

John Hansen

[ggrinton]

Thanks again, John.
I was able to find an old NXT.DAT on a backup and restored that, and now most of the time BRICX starts quickly and finds the NXT. Every now and then it sits doing a search for a while and fails, and I need to select the NXT from the pull-down list and connect manually. So things seem generally OK now.

Maybe a different thread is needed here, but I am now finding that when I open a file, or create a new one, I get
"Access violation at address 007CE715 in module BricxCC.exe. Read of address 00000000."
Howeever, it does seem to load the old (or new) file correctly once I click OK.

Geoffrey

[mspall]

I have seen that error, "Access violation at address 007CE715 in module BricxCC.exe. Read of address 00000000.", on opening files with the test_release20120912.zip on the Vista side of a dual boot machine. I didn't see it in a fresh Vista install inside a VMware Player on Linux. Because of that and no one else reporting it, I assumed it was beacuse of Windows cruft. I don't see the problem with earlier releases. I have not tested the latest test_release20121011.zip. I will try and test that soon.

[afanofosc]

Are you guys running in MDI mode or in tabbed window mode? I rarely try MDI mode anymore since tabbed window mode is so much better (in my opinion).

I have been trying to track down the root cause of these access violations without great success over the past year or two. It has something to do with creating/deleting nodes in the Code Explorer tree view. This happens any time you open a file or create a new file. I'll keep trying to figure out the cause and fix it.

John Hansen

[mspall]

I am running in tabbed window mode. I will test whether switiching makes a difference.

I wondered if it could be a deprecated editor setting since you first install the latest full build and then copy files over it from the latest test_release. In the set-up that doesn't have the issue I have done fewer changes from the default config.

[ggrinton]

After your helpful hint I found the cause of the Access Violation - or at least, I found what I suspect is the cause, and it is now gone

As part of my testing for the earlier issue I had installed to a new path, and as a consequence the "User Data Path" in the Editor/Paths panel of the Preferences was pointing to a non-existent directory. As soon as I pointed that back to somewhere that exists, that problem disappeared.

Now, I am not sure what the User Data Path is for, and it certainly was not pointing to either the directory with my programs or the directory containing the NXT.DAT file, but once I changed the User Data Path, the Find Brick command stopped working again. I resolved that by copying my NXT.DAT file to the directory I had specified for User Data Path.

I hope that is adequate information for you to track down the issues you mentioned you have been seeing as well, and to implement some error trapping or workarounds. Let me know if there is anything elsse I need to add to the above information.

(For the record, I was using the MDI mode, but I frankly doubt that was relevant.)