QA401 Programming Commands

It seems very easy to control the 401 with tractor but what about a list of commands like most all other lab equipment manufactures have. I’ve done lab automation for years but I do not see anything straight forward here if controlling it from your own code or creating you own driver.

Hi @ggorman, there are two interfaces for controlling the QA401:

  1. DotNet Remoting
  2. REST

The first is going away in the 2.0 release, so there’s not much point in using it now. But the basic idea with DotNet remoting is that it’s strongly typed, and as soon you load the QAAnalyzer.exe as a reference in Visual Studio, the API becomes clear via the class explorer. There’s a sample project on github (HERE) that shows how to make a range of measurements.

The second is REST. This is available today in the headless QA401H application (wiki HERE). This documentation for this API is available via the browser when you connect to the QA401H application using the URL http://localhost:9401.

And since it’s a REST API, you can connect and control from any language that can load webpages. In the link below, you can see how to use Python to acquire and measure the THD of a signal. Some of the syntax has changed since that post was written for the Audio Generator, but the changes needed to correct should be straightforward from the web server response. If you are familiar with tools such as Curl or Postman, you can test commands interactively as you gain understanding in how the REST interface works.

If you want to understand how Tractor uses REST to control the QA401, that source code is located HERE.

I looked at it but it’s very complex considering a regular instrument would have a few simple command strings to set level, freq, get dat, set attenuators I have code that does the filters, FFT and everything else. Have you all ever look to see how simple it is to talk to lab Instrments from Tektronix, Agilent, NI, etc

IPhone E-Mail from

Jerry Gorman

Hi Jerry, yes, I’ve written a lot of factory GPIB and custom test code over the decades. The approach here is different. Instead of downloading a 35GB (!) package (LabView) with loads of drivers for various instruments, or using a DLL to speak GPIB, the approach with REST leverages the enormous work that every language has put into web-based operations. Measurements become just another web-based operation. It doesn’t matter if you are adding an employee to a database or setting the maximum input level on a QA401–the technique is the same.

That means you can make the measurements without any drivers. The Python example I linked above lets you make a THD measurement with a fresh install of Python (or C#, or visual basic, or Matlab or ?) out of the box from any language that can download a webpage and do basic manipulations (JSON) on the data.

Do you really think 6 lines of new code in a fresh Python install to do the following is complicated?

  1. Set the max input on the QA401
  2. Set the generators
  3. Set the FFT size
  4. Capture the THD measurement

No drivers. No DLLs. No huge downloads. Your choice of modern languages running in the environment you prefer. And total freedom when it comes to producing an installation of your test program that runs on another machine. A machine that can theoretically be as small as a Raspi running Linux?

I do agree that if you are used to preparing strings for GPIB it’s a big shift. But I think the shift comes with a lot of rewards. And there’s no reason you can’t do both at the same time: LabView knows how to do REST–the NI forum has lots of discussions on how to do PUT/GET/POST etc.

What is your preferred language?

I have used several languages but for lab automation mostly LabVIEW. I also have the sound and vibration tool kit. I already have the software done but most sound cards are not adequate. I work at Texas Insturments so I have access to AP equipment but I just want something for home use. I guess I could use your interface but when a person likes their own code and can easily add to it going down another path seems frustrating. Even working at a company the size of TI and around a lot of software guys I’ve never heard of anyone using REST. For your target audience I guess the Tractor software that does most things out of the box is a good thing. I need to get something soon any update on the QA402 release date and do you still think it will be March?

Thanks,
Jerry G

IPhone E-Mail from

Jerry Gorman

Hi Jerry, REST is mostly a state of mind (!), but I’ll bet your SW guys are using REST principles in their daily work already.

This link is how to do an HTTP PUT from within labview:

https://zone.ni.com/reference/en-XX/help/371361R-01/lvcomm/http_client_put/

And this link shows all the different “commands” from within LabVIEW. With these primitives, you can control the QA401.

https://zone.ni.com/reference/en-XX/help/371361R-01/lvcomm/http_client/

If you do a POST to the following URL http://localhost:9401/Acquisition the QA401 will acquire a signal.

If you do a PUT to the following URL http://localhost:9401/Settings/Input/Max/6 and then PUT to http://localhost:9401/Settings/Input/Max/26 you’ll hear the relay click as you change ranges.

The strings above would be the URL input of the POST command in LabView

https://zone.ni.com/reference/en-XX/help/371361R-01/lvcomm/http_client_post/

If you don’t have a QA401 yet, then just run the QA401H application and do a GET on http://localhost:9401/Status/Version and you’ll see the version reported within labview.

Please let me know if you are able to try and I can help figure out what might be going wrong if not working. However, I’m not a labview guy so we’d need to rely on your expertise there.

Thanks I’m digging into it, your right it’s probably pretty simple and it looks like I can do it from LabVIEW. I don’t have the QA401 I’m trying to wait for the QA402.

IPhone E-Mail from

Jerry Gorman

High everybody.
Sorry for reviving this old topic, but it’s the most fitting for my issue I’m facing currently.

We had been using the QA401 with the Headless Server in a Test Fixture since 2018. Now we have to update the test sequence (from a C++ handmade to a LabView) and I’m struggeling to get the REST Interface to work.

  • QA401 works perfectly via GUI
  • QA401 works perfectly via our old C++ Executable (but cannot be used anymore, since the results are not shared properly)
  • QA401 works perfectly with the QA401W Browser App (Awesome BTW)
    With LabView I’m only getting a “Bad Request 400” when I try to use the above Functions with HTTP Put, Post, Get etc.

Am I missing a big previous step, a setting or a web service?

Any Idea?

Thanks

Hi @Gruman, do you see anything in the QA401 headless terminal when the LabView issues the request? Can the LabView app successfully do things like a simple PUT to set the atten levels? Or a GET to get the REST API? Sounds like not. But I’m curious what the terminal output shows.

Hi Matt

Thanks for your reply.
The QA401 Terminal shows nothing from LabView.
Tested Postman → Worked flawless
Tested via PowerShell (Code from Postman) → Worked flawless
Simple LabView PUT or POST: Error 400 Bad Request. Invalid Hostname

When I recreate this example. The POST is successfull. Curious why I cannot use the same on Localhost:9401.

Thanks

Hi @Gruman, there might be an issue with permissions for the Labview app. The fact that you see nothing in the terminal means it’s not getting to the QA401 app. Is it possible the Labview app defaults to HTTPS?

You can read more about folks able to use curl but not labview. I don’t know if this is your issue, but I’d investigate permissions on the Labview side. For example, can your Labview app fetch www.google.com?

Also, the “invalid hostname” suggests that Labview tried to resolve localhost but failed maybe? If you tried 127.0.0.1:9401 (instead of localhost) does it work?

Hi Matt
Google works without a problem.
I get the same when I use the 127.0.0.1:9401 instead of localhost.

I will have to revisit this topic later again. Currently we fixed up our C# solution and use this as a stopgap for the moment. Audio Analyzer working like expected :slight_smile:

Will update when I find a solution.

Thanks.