Mindboards

Hi tcwan,

first of all, here is what I got to look up VISA error types, don't know anymore where that came from:
http://www.mindstorms.rwth-aachen.de/tr ... orString.m
I also found this header-file, don't know if that is what you were talking about:
http://www.mindstorms.rwth-aachen.de/tr ... visatype.h


I do remember that nasty 10-second-timeout, even though I never used Fantom to talk to the NXT via Bluetooth. In my experience, this timeout was the default setting for the serial port. Maybe you can somehow extract a sort of "device handle" from the Fantom datatypes, or get the actual underlying serial port, and change the timeout yourself? We use this MATLAB-command to manually open a COM port: Timeout is the timeout in seconds. We use 2 as default. Much lower values can give you unrecoverable packet loss that occure more frequently, higher values give you longer timeouts which are annoying, as you noticed yourself...

tcwan wrote: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).

I'm not using XCode, I'm using Eclipse, so that didn't really apply, but it doesn't matter. It seems that while fantom needs you to link to the VISA framework as a dylib, if you want to use the VISA header files you need to link to it as a framework (i.e. -framework VISA in your Makefile).

The NI-VISA header files are there if you've downloaded NI-VISA, which I assume you have if fantom is working. On a Mac they're located in the Frameworks directory.

Kami

lizard381 wrote:

tcwan wrote: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).

I'm not using XCode, I'm using Eclipse, so that didn't really apply, but it doesn't matter. It seems that while fantom needs you to link to the VISA framework as a dylib, if you want to use the VISA header files you need to link to it as a framework (i.e. -framework VISA in your Makefile).

The NI-VISA header files are there if you've downloaded NI-VISA, which I assume you have if fantom is working. On a Mac they're located in the Frameworks directory.

Kami

Hmm. So if you specify both the Fantom and VISA frameworks as frameworks, does it allow you to access both?

Ah yes, I've forgotten to check in the Frameworks directory for the header files. Thanks for the tip.
Too much coding lately :0)

linusa wrote:Hi tcwan,

first of all, here is what I got to look up VISA error types, don't know anymore where that came from:
http://www.mindstorms.rwth-aachen.de/tr ... orString.m
I also found this header-file, don't know if that is what you were talking about:
http://www.mindstorms.rwth-aachen.de/tr ... visatype.h


I do remember that nasty 10-second-timeout, even though I never used Fantom to talk to the NXT via Bluetooth. In my experience, this timeout was the default setting for the serial port. Maybe you can somehow extract a sort of "device handle" from the Fantom datatypes, or get the actual underlying serial port, and change the timeout yourself? We use this MATLAB-command to manually open a COM port:

Code: Select all

handle = serial(ComPort,'BaudRate', BaudRate, 'DataBits', DataBits, 'Timeout', Timeout);

Timeout is the timeout in seconds. We use 2 as default. Much lower values can give you unrecoverable packet loss that occure more frequently, higher values give you longer timeouts which are annoying, as you noticed yourself...

Hi linusa,

Thanks for sharing your experience.

The visatypes.h just gives the status/error codes. It does not provide the headers for VISA functions. Kami (lizard381) gave the correct location in another post.
So far, what I've found is as long as there's some bytes in the receive buffer, the timeout is not triggered. Fortunately the GDB message exchange protocol can meet that requirement.

By the way, I have not managed to get raw message exchange working over Bluetooth yet. I can send direct commands which do not require any response (eg. play tone) just fine, but those which require a reply does not work if sent as raw messages using write() and read(). Sending the command using the sendDirectCommand() function works though. I'm assuming that the message format remains the same for USB vs. Bluetooth, since there is no way to indicate which type of connection is to be used when calling send() or receive(). The Bluetooth protocol reference document does mention differences in the packet encoding over the air where 2 extra bytes are added as prefix, but if I tried to include those 2 bytes, the command (e.g., play tone) fails when sent using write().

As I said, I don't have experience using Fantom for Bluetooth. But I remember a discussion with John Hansen about the lack of a "sendSystemCommand" function. I looked around the header files, and I found the read and write functions you refer to. John then implemented the missing function in Pascal, the sourcecode is here: http://bricxcc.svn.sourceforge.net/view ... iew=markup , line 311. As far as I know, it works. Unfortunately, the NXTasy thread is gone. But you could see if maybe this code does something different things than you do?

I personally didn't like the Fantom "use and feel" and the documentation, but sorry, I know this doesn't help.

lizard381 wrote: I'm not using XCode, I'm using Eclipse, so that didn't really apply, but it doesn't matter. It seems that while fantom needs you to link to the VISA framework as a dylib, if you want to use the VISA header files you need to link to it as a framework (i.e. -framework VISA in your Makefile).

The NI-VISA header files are there if you've downloaded NI-VISA, which I assume you have if fantom is working. On a Mac they're located in the Frameworks directory.

Kami,

Can you tell me what you are passing into the viSetAttribute? I was stumped by the value that I saw in NISpy which seemed to be a session address or reference or something like that. Is it a brick resource string? If it requires a session address I am not sure how to get one from what I have via calls to the Fantom API functions. I haven't had a chance to dig any further into this, sadly.

John Hansen

linusa wrote:As I said, I don't have experience using Fantom for Bluetooth. But I remember a discussion with John Hansen about the lack of a "sendSystemCommand" function. I looked around the header files, and I found the read and write functions you refer to. John then implemented the missing function in Pascal, the sourcecode is here: http://bricxcc.svn.sourceforge.net/view ... iew=markup , line 311. As far as I know, it works. Unfortunately, the NXTasy thread is gone. But you could see if maybe this code does something different things than you do?

I personally didn't like the Fantom "use and feel" and the documentation, but sorry, I know this doesn't help.

The code you referred to just prepends the System Command Byte (0x01) to the command string and sends it using the write() function.
It then waits for the reply using read() and mangles the message to return to the user what was expected.

I don't believe that I'm doing it differently, oh well.

I just double checked and my send system command routine definitely works correctly over both USB and Bluetooth. The code is pretty straight-forward. Something must be different between your code and mine.

John Hansen

By the way, I have not managed to get raw message exchange working over Bluetooth yet. I can send direct commands which do not require any response (eg. play tone) just fine, but those which require a reply does not work if sent as raw messages using write() and read(). Sending the command using the sendDirectCommand() function works though. I'm assuming that the message format remains the same for USB vs. Bluetooth, since there is no way to indicate which type of connection is to be used when calling send() or receive(). The Bluetooth protocol reference document does mention differences in the packet encoding over the air where 2 extra bytes are added as prefix, but if I tried to include those 2 bytes, the command (e.g., play tone) fails when sent using write().

tcwan, I'm having the same problem using write() and read() over bluetooth. I've also tried adding the extra bytes, but to no avail, I'm not sure what else to try.

afanofosc_99 wrote:Kami,

Can you tell me what you are passing into the viSetAttribute? I was stumped by the value that I saw in NISpy which seemed to be a session address or reference or something like that. Is it a brick resource string? If it requires a session address I am not sure how to get one from what I have via calls to the Fantom API functions. I haven't had a chance to dig any further into this, sadly.

John Hansen

John, I actually called viFlush instead of viSetAttribute, I couldn't quite figure out what to pass in as inputs for viSetAttribute and viFlush seemed to be what I was looking for. For viFlush, I cast the pointer to the nxt as a ViSession object, and that seemed to work. It has not, however, solved my problem of not being able to repeatedly poll a sensor during a single session, but that might be a topic for another thread, I'm not sure.

When I look at it, all the problems I have seem to be when I call read() and write(). I wonder if there are any alternatives to this, since sendDirectCommand() doesn't work when I need a response.

Kami

lizard381 wrote: since sendDirectCommand() doesn't work when I need a response.

Quick reply: That definitely should work. I think we use that. Check for return buffers or other output parameters...