NXT access via USB on OSX

[gloomyandy]

Hi Sven,
What did you use to generate the output you saw? If it was a program that uses LCP then that makes sense. The method that sends LCP requests (sendRequest) asks for an exact reply length based on the LCP command being used. For none LCP reads we will ask for a much bigger read (but this is cut down to be a maximum of 64 bytes in the native code)...

Andy

[skoehler]

Hi Sven,
What did you use to generate the output you saw? If it was a program that uses LCP then that makes sense. The method that sends LCP requests (sendRequest) asks for an exact reply length based on the LCP command being used. For none LCP reads we will ask for a much bigger read (but this is cut down to be a maximum of 64 bytes in the native code)...

I was using nxjbrowse: so yes, it was LCP. By accident, I used nxjbrowse with the original Lego firmware and nxjbrowse is compatible. Hence, the firmware was returned 5byte error packages, instead of the expected 32/33 byte reply.

I still have to test RAW mode though.

[tcwan]

Hi Andy,

Hi,
That is very odd as I'm pretty sure we use the same code on Windows and Mac, and issue 64 bytes reads (the max size that a single USB packet can be) all of the time. Could that be your problem? Are you asking for more than 64 bytes? If you are still having problems then perhaps the way forward is to add a header byte that gives you then length and read that first which will then tell you how many bytes to actually read...

Andy

No, I was reading the default buffer size (64 bytes), whereas the actual message was shorter (e.g., 7 bytes in the example given previously).
I wonder if in your case (LeJOS), the firmware was always creating 64-byte responses (with added padding).

I can implement the 2-stage read process at the top level as you suggested, thing is nxt-python would have to be hacked to work around this issue and issue exact length reads.

[gloomyandy]

No, the firmware is definitely sending none 64 byte length packets, and our Mac side code seems to happy reading them. Could it be anything to do with the way you are opening the device? You can see how we do it here...
http://lejos.svn.sourceforge.net/viewvc ... iew=markup

Andy

[afanofosc]

Currently I'm stumped by iNXT::read() which will throw an exception if the number of bytes to be read is greater than the number of available bytes coming from the NXT, whereas iNXT::pollAvailableLength() keeps giving me a "Command mismatch in firmware response" exception. (I'm assuming that I can use iNXT::pollAvailableLength() to check the length of the buffer return by iNXT::read())

The poll available length Fantom API function is just a wrapper around the NXT's PollCommandLen system command. It has nothing whatsoever to do with finding out how many bytes are available to read from the currently active connection (bluetooth or USB) to your NXT. You can find documentation for this API function by reading the LEGO MINDSTORMS NXT Communication protocol PDF that is part of the bluetooth developer's kit (at the link below).

http://cache.lego.com/upload/contentTem ... A8B567.zip

I would check out how leJOS or BricxCC uses the C version of the Fantom API. The C API does not throw an exception if you call read with a number of bytes to be read exceeds the number of available bytes. It just sets the status code to an error value.

John Hansen

[tcwan]

Hi John,

The poll available length Fantom API function is just a wrapper around the NXT's PollCommandLen system command. It has nothing whatsoever to do with finding out how many bytes are available to read from the currently active connection (bluetooth or USB) to your NXT. You can find documentation for this API function by reading the LEGO MINDSTORMS NXT Communication protocol PDF that is part of the bluetooth developer's kit (at the link below).

http://cache.lego.com/upload/contentTem ... A8B567.zip

I would check out how leJOS or BricxCC uses the C version of the Fantom API. The C API does not throw an exception if you call read with a number of bytes to be read exceeds the number of available bytes. It just sets the status code to an error value.

John Hansen

Thanks for the clarification re: Poll Available Length function. I came to a similar conclusion (though not its intended use) after playing around with the function.

When I say that the "read() with number of bytes exceeding the number of available bytes" throws an exception, it is due to the python wrapper behavior in response to a negative status code. I can ignore the status error though the negative status code does not seem to correspond to one of the documented error codes.

I've taken a look at http://lejos.svn.sourceforge.net/viewvc ... iew=markup and http://bricxcc.svn.sourceforge.net/view ... iew=markup, everything seems so straightforward, but the behavior seems to be different in Python.

The more critical issue seems to be that there is a timeout related to the read() trying to wait for the rest of the non-existent bytes to be read, which is several seconds long. It makes the message exchange protocol unresponsive, since it needs to wait for that timeout; and I don't see any Fantom API to control the timeout interval.

Guess I'll have to dig further.

[tcwan]

Hi,

This is to update on my investigation of the nFANTOM100_iNXT_read() behavior.

1. If there is some remaining bytes in the read buffer, then we can issue a nFANTOM100_iNXT_read() exceeding the available bytes to read (up to 64 bytes?) which
would return immediately but with status -0x4000ffc2. I'm not sure if I'm printing it correctly since it is a negative hex value (!)

2. If the read buffer is empty (i.e., zero bytes pending), the nFANTOM100_iNXT_read() will block for about 10 seconds (?) and then return status -0x4000ffc2.
The program can continue processing other inputs (write()/read()) after that.

So the conventional wisdom is correct, i.e., we can read more than what's available in the buffer. Unfortunately, there is no way to prevent case #2 unless we are sure that there is something waiting in the read buffer before we issue the read() call.

Thanks to Gloomy Andy, John Hansen and the others who helped point out where to start looking.

[afanofosc]

I did some digging and was able to determine that the Fantom drivers call viSetAttribute to set the TMO_VALUE of the current session to 10 seconds as part of the process of opening the USB connection to the NXT (in iNXTIterator_getNXT or createNXT). The subsequent call to viRead, when no data is available, will block until that timeout value expires and then return 0xBFFF0015 (VI_ERROR_TMO) - "Timeout expired before operation completed" - which in Fantom is converted to 0xBFFF003E (VI_ERROR_IO).

I'm looking into whether it is possible to call viSetAttribute after opening the connection using the Fantom drivers and set the timeout to a much lower value.

John Hansen

[lizard381]

Hi John,

Have you made any headway into the possibility of calling viSetAttribute from your c++ code? Because I've tried doing both this and calling viFlush, and I get a linker error even though I've included both the header files and the framework...

Thanks,
Kami

[tcwan]

Hi John,

Have you made any headway into the possibility of calling viSetAttribute from your c++ code? Because I've tried doing both this and calling viFlush, and I get a linker error even though I've included both the header files and the framework...

Thanks,
Kami

How did you manage to get the NI-VISA header files?
Also, what is the linker error? If it relates to not being able to find the VISA framework, then I think my other post related to setting up Bluetooth might apply (i.e., select 32-bit only, 10.5 Mac OSX SDK).