Is anyone experienced with Newport Electronics iServer-Microserver ethernet device?

[Stephmon]

Hello,

I've been adapting a chart-recorder program written by a collegue and would like to incorporate the output from a Newport Electronics iServer Microserver ethernet temp/humidity device. I was able to locate the device using the Measurement and Automation tool, but have been unable to extract any data. Does anyone know of a plugin, or have tips for accessing the four channels of data that this device is outputting to our LAN?

Cheers,

Stephen

[Elsa Fung]

After you set up the IP of the device, you can download HTTPGET from the newport web site (http://www.newportus.com/software/iServer.htm), and use LabVIEW to run HTTPGET as a system command.  For details, checkout page 32 in the attached PDF (actual PDF's page 32, but the numbering at the footer of the page).

Hope this will help ^_^

See-Ming

[Stephmon]

Thanks for the pointer, it went a long way, once I put HTTPGET directly in the Windows folder (the website's "installer" doesn't put it there itself).

Now, I'm wondering if someone could point me to good examples of using the System Exec for this sort of thing... Ideally, I'd like the command.com window to stay out of sight (and only open once) while I query the four outputs from the device and send the four responses to four graphs. I'll keep poking at it, with the limited spare time I have, but at the moment, it is launching the command.com window repeatedly and not passing the HTTPGET and the rest of the command string. I also need to convert the output string, into a format that the graphs will accept...

Cheers,

Stephen

[Elsa Fung]

some input/output you might want to pay attention to:

(from LabVIEW help)

>> If wait until completion? is TRUE, standard input is available as input to the command and standard output and standard error are available when the command finishes running. If FALSE, the command runs in the background and its input and output are not available.

    - must be TRUE, since you're waiting for the output

>> command line indicates which command for LabVIEW to call to run your program.

Windows 9x To use a DOS command, insert command.com /c before the command, and set working directory to the location of command.com.

Windows 2000/XP To use a DOS command, insert cmd /c before the command. You do not have to set working directory. If you do specify working directory, standard output returns the same directory list.
    - depending on the version of Windows you have, add this before the HTTPGET command

>> working directory is the file system directory from which you want to execute the command.
    - I think you have to define where HTTPGET.exe is

>> If run minimized? is TRUE, the VI minimizes the run of your executable program. The default is FALSE. run minimized? is unused on Linux platforms
    - even though it just say minimize, it actually hides the window (at least it did for me)

>> standard output returns information from the program you called if wait until completion is TRUE. If wait until completion is FALSE, System Exec returns an empty string.
    - output that you want to parse into legimate readings

I have a iSeries temperature controller, and sending cmd /c httpget -r -S "*02X01\r" 172.23.1.134:2000 in the command line input will read the temperature (at address 02), but then it takes a long time and won't return the output until timeout.  This is because the httpget command continuously read the device and update the output (I think).  You might want to contact Newport (I think they're in the west coast, so make sure you're not calling too early in you're in the east coast ^_^ i kept calling when they were out to lunch, and took me a while until i could get someone to help) and ask them how to read just one time instead of continuously using httpget.

after reading it, just use the fractional string to number function to convert the reading to numbers and pass it to the graph

See-Ming

[Stephmon]

Thanks again,

I'm coming to the conclusion that HTTPGET is probably not going to be a viable solution. It is intended to change one parameter, or get one response and then be done. This makes it a poor way to querie the 4 parameters repetitively.

I see that Hyperterminal is an alternative communication method, which allows continuous communications. Is there a Labview plugin for Hyperterminal, or perhaps a terminal emulator function within Labview?

Cheers,
Stephen

[Elsa Fung]

hm... I'm not sure, didn't see anything in the manual

[Stephmon]

OK, I think I've made the big breakthrough...

Using the Instrument I/O assistant, I've managed to contact the device. Now, I can either querie the device for responses, or let it send a continuously streaming string such as...

TA77.4F
TB73.2F
HA43%
etc...

The speedbump was in the "number of ports" setting in the web based setup for the device. It only makes sense that it needs to be non-zero, but it's taken me this long to realize that it was set to zero.

Thanks for the help! If I can answer any questions about what I've done on this end, I'd be happy to...

Cheers,

Stephen

[Elsa Fung]

are you using ethernet to connect to the device with labVIEW?  how do you do that?

[Stephmon]

Yes, the device is connected to our LAN via the ethernet port and serving a webpage at the IP I selected. Then, I used the configuration section of the web-based Java controller to setup the communications (that's where I missed the fact that I had zero ports open). Using the Measurement and Automation Tool, I created the ethernet communication as an "Instrument". Now, I can place an Instrument I/O Assistant in my block diagram and wire it to my graphs.

Funny how missing one setting can cost so much time...

Cheers,
Stephen

[Elsa Fung]

i didn't know you can do that... if i knew, i would have used this instead of the Newport OPC server program to connect to my iSeries... i'm having a lot of communication problem with the OPC server program and it's starting to drive me nuts... but i can't change a lot of my application because it's been deployed already... oh well.. maybe i'll sneak in the changes next time...

Thanks!