Serial Communications Timeout exception

[DCDowns]

I apologize for "re-posting" this question, but I realized I had commented on a closed topic and found this community to be more appropriate to the subject. That being able to capture the read buffer for a serial communication read operation with a timeout exception being thrown. Please see the referenced post. Thanks in advance.

[James_Battleaxe]

Hi,

I wanted to find out more about how you are making these calls. Without reading from the device it's hard to confirm the write commands actually went through. I'm wondering if any communication has been established with the device at all. 

Have you tried using an example to try and establish communication with your device? Does the device show up in MAX as a serial device? Does the VISA Test Panel work with that device when you send a basic command? 

[DCDowns]

Thank you for your response. To answer your first question as to how I am establishing a connection with the device. I am able to establish a session with the device reading  the interface name as a serial device using the following code:

 Try
           'Instantiate new message based VISA session
            mbSession = CType(Ivi.Visa.GlobalResourceManager.Open(strVISARsrc), _MessageBasedSession)
            lblInterfaceName.Text = mbSession.HardwareInterfaceName
        Catch ex As InvalidCastException
            MessageBox.Show("Resource selected must be a message-based session")
        Catch ex As Exception
            MessageBox.Show(ex.Message)
        End Try

The device can be written to using a string command word  variable strWrite which equals the literal "FA;". This command tells the device to respond with the device's frequency using the NI's RawIO.Write:

       Try
            mbSession.RawIO.Write(strWrite)
        Catch ex As Exception
            MessageBox.Show(ex.Message)
        End Try

The  device should then respond with a string indicating what command it is responding to and the frequency using the routine:

       Try
            strResponse = mbSession.RawIO.ReadString
            txtRead.Text = strResponse
            ' Handle Time Out Exception if type is serial
        Catch ex As Ivi.Visa.IOTimeoutException
            ' Ignore timeout exception and capture read buffer
            'viRead contains response as long as timeout >0
            ' Unable to read buffer without timeout exception being thrown
            ' Disable timeout event
            mbSession.RawIO.Read()

        Catch ex As Exception
            MessageBox.Show(ex.Message)
    End Try

The above block is where the Timeout Exception is thrown, making it impossible to capture the read buffer - even though the NI-I/O Trace utility does see it as documented on the second figure of my original post as line 137. I have attempted to disable the timeout exception utilizing the compiler option, but as the exception is thrown within the driver itself it has been ineffective.

I am able to use NI-VISA Interactive Control and get a proper command/response. When debugging my application, I am tracing the handshaking between the app I compiled , the driver and the device using NI-I/O Trace utility. NI-MAX has not been tried as I am confident that communication has been established by using the Interactive Control. This application does not utilize Lab-View which I am assuming gets to your question about the Test Panel. I am just using direct calls to the driver extensions within Visual Studio 2017..The attached video shows the communication.

[James_Battleaxe]

Hi,

It is odd that you're getting data from the read but also getting an error at the same time. I think we can first try to troubleshoot using the VISA Interactive Control like you did in the video before moving to your actual code. I think if we can eliminate the timeout error from VISA Interactive Control we can do the same when making the same call programmatically. 

I've linked an article that addresses the timeout error. There are several recommended steps to try, but one I think you can start with is increasing the timeout value. Try to see if there's a larger Timeout value you can use where this error no longer happens. 

Link: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019L3mSAE

[DCDowns]

James,

I was able to eliminate the timeout exception by adjusting the Bytes to Read within the NI-Interactive Control, Input/Output tab by the expected response length -14 bytes. Increasing the timeout did not affect the error. I was able to time the typical turnaround  time between write and read using NI-Trace. It is only 200 ms.

As the referenced article suggests. I suspect the serial parameters need to be initialized accordingly within my session. As my application is not a LabView environment, I am having difficulty determining  the appropriate calls to the attributes seen in the trace. I am unable to refer to them programmatically i.e:

viserialattributes

I think we are on the right track. Setting the number of  bytes to read after each write seems a bit cumbersome. There is a terminating character ";" for the return string, but the options in the Interactive Control were limited.

I appreciate your help.

[James_Battleaxe]

Hi,

Glad you're making progress! You should be able to just set those attributes once at the beginning. In terms of how to call those, I'd recommend looking through one of our .NET examples and model you code off of that. I've included an article showing where to find these examples. Take a look and see if they're helpful for you.

Link: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8r4SAC

[DCDowns]

Thank you for your pointing me to the examples. The example, SimpleReadWrite , emulates the Interactive Control  utility which demonstrated the timeout exception if the Bytes to Read was not set to 14. This example demonstrates the same issue, but it does not allow for setting the Bytes to Read,

Yes there is an example  that I should be able to model my code after. The RdWrtSrl example, although written in C+, it does demonstrate the initialization of the serial parameters. However, those calls are not available to me for some reason. A crucial call that is not accessible is: viSetAttribute. The references I have added to my project are shown below:

Am I missing  an extension in my project? The article made me wonder if I don't have to have a purchased driver license? I will reiterate, this is not a LavbView environment nor do I have LabView on the machine. Your guidance is greatly appreciated.

[DCDowns]

Here I thought we were making some progress, until the topic got pitched over the wall for being "the wrong programming language"  - so I ended up here without any follow-up. Has it come full circle as this started with the question of support for Visual Studio 2017? The devil is in the detail - so let's make it simple. Are the serial driver attributes referred to earlier,  exposed in the NIVISA1700Full install without any associated NI products? I am not even sure they are accessible with the Measurement Studio 2015 trial version - but I digress. A little bit of guidance would be appreciated so I can redirect my development efforts as needed. Until that basic question is answered there can be no resolution to this topic.

Thanking you in advance.

[James_Battleaxe]

Hi,

Visual Studio 2017 is not supported at this time but it should not affect what attributes show up. I found a "ReadByteArray Method" that I think should do the same thing as setting the Bytes to Read property. I've listed the documentation for it below. Are you able to see that method?

http://zone.ni.com/reference/en-XX/help/370627F-01/mstudiowebhelp/html/8fc2a640/

[DCDowns · Accepted solution]

Thank you for the reference. The attributes are accessible, but not as originally thought. They can be accessed as members of the session. The key to reading the buffer was to  eliminate the timeout exception by setting the termination character appropriately within the application. NI I/OTrace was indispensable in troubleshooting and identifying the necessary settings.