Measurement Studio for .NET Languages
Support for Visual Studio 2017
Solved!
Hi Peter,
My name is Collin Draughon and I am the product manager for Measurement Studio. We made a difficult decision last year to prioritize ensuring we had best-in-class .NET APIs for our hardware devices over releasing a Measurement Studio 2017 that supports Visual Studio 2017. We did this because we want to consistently promise to our customers that their experience working with our hardware in .NET is the best experience available. I want to sincerely apologize for any inconvenience we introduced with this prioritization but also want to reinforce that National Instruments is dedicated to making Measurement Studio the best Visual Studio add-on for engineers in the market and we have a long roadmap of features we want to add moving forward. We intend to support Visual Studio 2017 and 2015 in the next release of Measurement Studio which will should be available in a few months through our beta program at ni.com/beta. Feel free to email me at collin.draughon@ni.com for more details!
As for support of DAQmx in Visual Studio 2017, the readme, http://download.ni.com/support/softlib//multifunction_daq/nidaqmx/17.1.1/readme.html, signals support for .NET framework 4.5.1 which you are able to target in Visual Studio 2017: https://msdn.microsoft.com/en-us/library/bb398202.aspx. Therefore, you should be able to use it without issue.
Please let us know if you have any other questions.
Regards,
I suspect the problem I am experiencing is unrelated to the support for Visual Studio 2017, but as I am using it as my development platform and just installed the NIVISA1700 package, I thought I would throw this out here and see what type of support is forthcoming.
I have written a Windows Forms App(Net Framework) Visual Basic program using the National Instruments assembly extensions. The interface is a USB serial adapter connected to an amateur radio transceiver to manipulate the device's internal memory via RS232 serial data strings. I am able to write data to the radio, but am unable to read the data due to a timeout exception being thrown. However, the NI utility NI IO Trace used in conjunction with NI-VISA Interactive Control or my application does capture the returned string. My question is, "How do I read the Read input buffer?" I have written an exception to the exception in my code. See the screen shots below as an illustration
I can see it, but I have not figured out how to access it programmatically.
The IOTimeoutException Constructor(Int64) identified within the NI-VISA .NET Class Library Help document seems to address this as the actual data argument, but I am unable to use the 64Bit version due to warnings of instability being raised by the compiler. Is there another method available in the 32bit environment? As the application employs the MessageBasedSession type would it be suggested that I employ the DisableEvent method to ignore the timeout exception? As this may get into a discussion on how to handle exceptions, I will suggest reading the excellent article, Customizing a C Series Example Program for Wireless Data Acquisition
found in the document section of this community in which the author explains in the Programmatic Error Handling section a variety of workarounds for this particular problem ; however, the example is written for a LabView environment.
As a programmer of limited skills I wish the SerialPort1.ReadLine worked. The solution to strResponse = mbSession.RawIO.ReadString may be resolved by the same fix. Any suggestions will be appreciated - the more simple the better.
@DCDowns wrote:
I suspect the problem I am experiencing is unrelated to the support for Visual Studio 2017, but as I am using it as my development platform and just installed the NIVISA1700 package, I thought I would throw this out here and see what type of support is forthcoming.
It indeed is! Your problem is the termination character! If you had posted this as a new topic, it would have been more likely that you received a reaction before this one.
viRead terminates on 4 conditions:
- an error occurred in the underlying driver
- the configured termination character for this session was received
- the number of requested characters/bytes was received
- the configured timeout for the session has expired
So the solution is not to disable the timeout exception but to avoid it. From the two options that remain (an error is also not a desirable option nor would it help in any way as it will be simply throwing a different exception) you do not really want to change the number of requested bytes as that makes your software very depending on the actual message that device returns. Instead you want to either cause the instrument to issue the same termination character as what VISA is by default waiting for for ASRL (serial port) resources, or reconfigure the termination character for the current VISA session. It would seem that your device tries to use the termination character that you use in your command that you send, or maybe it really uses the semicolon as such. So find out what it is.
If the device is adaptable you can try to append the carriage return character \r and/or line feed \n to your command you send to the device. VISA by default should terminate reads on \r for serial port resources.
So if you can make your device to append this character to the end of the answer you should all be done.
Alternatively you can add something like this to your code before you start communicating with the device:
..... /* Initialize the timeout attribute to 10 s */ viSetAttribute(instr, VI_ATTR_TMO_VALUE, 10000); /* Set termination character to carriage return */ viSetAttribute(instr, VI_ATTR_TERMCHAR, ';'); viSetAttribute(instr, VI_ATTR_TERMCHAR_EN, VI_TRUE); /* Don't assert END on the last byte */ viSetAttribute(instr, VI_ATTR_SEND_END_EN, VI_FALSE); /* Clear the device */ viClear(instr); .....
