John Lokanis

Thanks! Unfortunately I already found a bug! But the fix was easy. On failed pings the options .net ref was null. I was trying to close this ref in all cases. Should have read that MSDN a little closer...

Here is the new version.

-John

Click here to download this file

Name: Ping dotNET

Submitter: John Lokanis

Submitted: 07 Jul 2009

File Updated: 03 Jan 2011

Category: Remote Control, Monitoring and the Internet

LabVIEW Version: 8.6

License Type: Creative Commons Attribution 3.0

Ping dotNET v1.0.1

Copyright © 2009, John Lokanis

All rights reserved.

Author: John Lokanis

LAVA Name: jlokanis

Contact Info: Contact via PM on www.lavag.org

LabVIEW Versions:

Created and tested with LabVIEW 8.6.1

Dependencies:

Requires .net 2.0 or higher

Description:

This VI performs a ping operation on the requested IP address or host name (requires DNS)

the timeout for each ping as well as the delay between pings can be specified.

The results are provided as arrays of each output type and in a text format designed to

mimic the command line ping output.

Instructions:

Enter a valid IP address or host name and execute the VI.

Known Issues:

None.

Acknowledgements:

MSDN

Change Log:

v1.0.0: Initial release of the code.

v1.0.1: Updates to the readme file and arrangement of the folder structure. (Mark Balla)

License:

Distributed under the Creative Commons Attribution 3.0 (http://creativecommo.../about/licenses)

See link for a full description of the license.

Support:

If you have any problems with this code or want to suggest features:

please go to www.lavag.org and Navigate to

LAVA > Resources > Code Repository (Certified) and

search for the "[CR]Ping dotNET" support page.

Distribution:

This code was downloaded from the LAVA Code Repository found at www.lavag.org

Click here to download this file

Yes, that was a problem at first because the DLL was in the 'data' support folder of the EXE. Once I moved it into the same folder as the LLB, the error 1003 went away.

So, now I have bundled all the vi.lib VIs into my LLB, got the DLL in the right place, made an iak file of all the cFP units in the whole factory and tweaked the:

C:\Program Files\National Instruments\Shared\FieldPoint\LabVIEW\fpconfig.ini

file so it has an alias that points to my iak file, I can finally run code that uses the IO Point input to the FP VIs using a string derrived from a script file! I have achieved data driven cFP nirvana! WooHoo! Now I can deploy and only need to update the iak if the IPs change or we add new hardware! And it is 10x faster than the old method (using LOGOS calls via DataSocket).

I must say, however, what a PITA this was. And completely undocumented by NI.

I use the 1804 FP unit that does not have a controller. So, the RTE I am referring to is the one for a Windows machine.

Yes. That does solve the issue, but it adds 600k to the size of my library...

I have run across a strange issue. I have some code that calls FP driver VIs (from vi.lib). These VIs are loaded dynamically by an EXE (plug-in architecture). I build the library of these VIs for distribution using OpenG (target: llb). I also exclude the vi.lib VIs since these should be included in the RTE. This has worked fine for all my code up until I starting using the FP VIs. (FP Open.vi, FP Read.vi, FP Write.vi, FP Close.vi).

It seems like these VIs are missing from the RTE vi.lib. Very weird.

Does anyone know how to have the OpenG builder include just some of the VIs from vi.lib that a particular VI has dependencies on? I don't want to include everything from vi.lib in my LLB distribution or it will be huge.

thanks for any ideas.

-John

QUOTE (jdunham @ Jun 4 2009, 12:36 PM)

I can't seem to find the VI Server property to dig this information out at runtime.

I think your first problem is the statement above. In the RTE, there is no concept of a 'project' that a namespace is running in. That is strictly for the IDE. Once you build an EXE, the only unique namespace is the name of the application, which is easy to get from a VI Server property.

I find that if I want to have multiple instances running at the same time and communicating vi VI Server under the RTE, I need to set up each one with it's own unique port number. And, 'localhost' does not always work either when trying to get a referecne to an app instance from another app. You need to use the actual IP of the machine for this to work reliably.

Yes, it is all very confusing. Espcially when you start using Web Services that run in yet another special app instance, separate from your EXE.

Good Luck!

One option is to write a web service interface for your application. This can allow any language that can make http requests to script the functionality of your program. It is not quite like the traditional GUI test harnesses used by commercial software test systems but it might solve your need to allow other tools to control your LabVIEW app. If you just want to control the VI through the standard windows hooks into GUI elements, I am not sure if that will work with LabVEW EXEs. But, I have used a tool to do the opposite (control the GUI of a standard windows app from LabVIEW) that might offer some insight. The tool is called AutoIt.

http://www.autoitscript.com/autoit3/index.shtml

hope that helps.

-John

QUOTE (vugie @ Jun 2 2009, 01:28 AM)

(scrolling is so slooow when wiring)

Slightly off topic, but why would you ever make a VI where you needed to scroll to wire? If the VI is so big that two connected nodes cannot fit on your screen, then it is time to re-factor!

Back on topic, I think the whole concept is like trying to compare apples to oranges. There is simply no way to accurately compare a graphical language to a text based one. It's like comparing radio to television, IMHO...

I reported this to NI but am posting here so everyone is aware of this and can avoid losing work.

If you have a linked tunnel in your code and try to make a copy by ctrl drag, it will crash LabVIEW.

I was setting up a state machine and made a shift register that connected through a case statement with a linked tunnel. I then wanted to make several copies of this setup for passing data around my code. When I selected the shift register, wires and the linked tunnel, then held down ctrl and dragged down to copy, the system crashed.

If the tunnel is not linked, then the copy operation works fine.

see attached example.

Download File:post-2411-1242859218.vi

-John

QUOTE (minzuk @ May 19 2009, 01:37 AM)

great!!! fantastic!!! thank you!!!!

You are welcome!

Yet another update. Fixed two bugs:

1. The wscleanup.bat file had an error. Debugging code was accidentally left in so it was not doing anything. This new version should fix that.

2. The screenshot function no longer worked now that I changed the server to be run as a windows service. This is because it was not associated with any user who has a screen to render. So, this new version has the web service VI call out to any EXE that the user is running and runs the screen grab code in that user's app instance. The caveat is the user EXE must have the 'get local screenshot.vi' embedded and in memory so it can be used by the web service. I am open to better solutions to this if you have any.

Download File:post-2411-1241054615.zip

-John

QUOTE (Mariano Gauderio @ Apr 27 2009, 09:12 AM)

I thought I couldn´t "reach" the name of the VI If I built an EXE file, am I wrong?

I build a simple EXE file (test.exe) and the name of the vi is test.vi.

Anyway I tryied and i couldn´t see the panel of the VI this way (http://localhost/screenshot/get_panel/png/test.vi) even (http://.../test.exe).

You do not need to enter the name of the EXE. The exe name is meaningless to the web service. You do need to enter the name of the VI, like you did above:

http://localhost/screenshot/get_panel/png/test.vi

What error are you getting when you do this?

Have you enabled the VI server in the INI file for your EXE? What port did you set it to?

Try adding the port number to the end of the call. For example, if your EXE is on port 3363, then call it like this:

http://localhost/screenshot/get_panel/png/test.vi/3363

Also, try specifying the actual IP address of the machine instead of using localhost. I have seen some bugs with trying to get the proper application instance reference when only using localhost for the specifier.

-John

QUOTE (Mariano Gauderio @ Apr 23 2009, 04:38 AM)

I would like to remember it will work just in Windows in English language because of the path in BAT, INI and TXT files.

I believe it should be usefull to put an explanation file teaching the code in files we need to change if you use another windows language, like me (portuguese), the path must be changed in some files.

I´ve already change the paths and the my webserver Is already online.

I´m still trying to use It correctly, but I still couldn´t. I appreciate If you could help me somehow.

I have already put the webserver up, the "echo" works well, but I still couldn´t have the print screen and front panel in my browser.

I have doubts about how to use it.

I have some exe files, and i would like to see remotly. So, what do I need to do with this EXE file?

Where should I need to reference it?

Do I need to put it in an especific Path?

Am I need to do a LVWS to put in any directory?

These are my doubts.

My e-mail address is mariano@grameyer.com.br, I appreciate very much if somebody could help me to put all working.

As for language issues, I don't know anything about customizing software for non-English versions of windows, so you are on your own.

Since you say the echo test is working, that means that the web server is running AND the web service has successfully been deployed. So, that is good.

In order for your LabVIEW built EXE to be viewable by the web service, the EXE must have VI server enabled. Also, you need to know what port VI Server is set to. The default it 3363. If you use a different port, then you must specify it in the web service call. Do not use 3364 since that is what the web server is using.

Here is an example of the things that must be in your EXE's INI file for the VI server interface to work:

server.tcp.enabled=True

server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000"

server.tcp.access="+127.0.0.1"

server.tcp.port=3363

You do not need to specify a path to your VI that you want to get the image of since it is already in memory. You do need to enter it's name correctly, however.

Another thing you can try is the screenshot web service call. If that works, you can at least prove you can stream MIME types from you machine to your client. If that is not working, then you have IT issues (firewalls, etc). I can't help much with that either.

There is no need to build an LVWS file to use the services I have already created. The project already does that for you. If you want to make more web services for other uses, then you would create your own LVWS and place it in the install directory.

Hope this helps. Good luck!

-John

New version with minor tweaks. You no longer need to stop and start the service when updating. Also, the wscleanup batch file now does this for you when installing your own LVWS files.

And I updated the PDF. If I have to type 'web service server service' one more time, I might go insane...

-John

http://lavag.org/old_files/post-2411-1240533082.zip'>Download File:post-2411-1240533082.zip

One note of caution, I have discovered that if you place a new LVWS in the install folder while the web server is running that it will get deployed BUT it will not run until you stop the web server and then restart it. This is counter to what NI told me. So, use the 'Stop NI Web Service Server' before installing new LVWS files into the install folder and then use the 'Start Web Service Server' to restart the service afterwards. Also be sure to cleanup the old deployments while the server is stopped.

-John

Major upgrade!

I have changed the project so that it creates a windows service. I have also renamed it to:

NI Web Service Server

This is more of an 'engine' that keeps the web server running all the time. So, now your other projects do not need to install/run the web server. Instead, all they need to do is place their web service LVWS file into the 'install' directory and the web server will deploy them automatically.

I am still including the web service that allows you to take screen shots of your target machines as well as retrieving images from VI panels or your EXEs. This now works with multiple EXEs by allowing you to specify the VI Server port that the EXE is listening on.

And I added a new web service that can get the version number of your EXEs.

We use these web services on all our deployed machines to be able to do remote support and to query the installations for maintenance tracking.

I hope you find this useful. There is a lot of power in the new web services once you sort out the gory details. I hope this example helps show the way.

-John

Download File:post-2411-1240260082.zip

QUOTE (ned @ Apr 18 2009, 01:27 PM)

You should be able to wire the string "localhost" or the IP address 127.0.0.1 to get a connection to the local machine, rather than going through String to IP and back.

I will give that a try, but I doubt the 'localhost' string will work since that is the default value if left unwired and when I did that it definitely did not work.

I have spent some time trying to figure this out and here is what I can tell you that might be helpful.

1. Web Service VIs run in a separate application instance from the LV EXE that starts the web server.

2. Web Service VIs 'think' they are the application that started the web server. (have your web service VI return the App.Name property and you will see what I mean).

3. If you want to talk to your EXE (or any EXE) form the web service VI, you must open an app reference to that EXE. If you try to just use the Default App Instance, you will get a reference to the app instance of the EXE that started the web server. If you have multiple EXEs, this can be a problem. If you have one EXE that acts as windows service to keep the web server running, then this fact will prevent you from calling into other EXEs.

4. If you use the Open Application Reference function and leave the machine name input blank (because your web service and your EXE are on the same local machine) then the app reference you will get will be for the app instance that your web service is running in, NOT your EXE, even if you supply a different VI Server port number that is unique to your EXE. It just will never work. I think this is a bug, IMHO.

5. In order to connect to your EXE, you must provide both the actual IP address of your machine and the VI Server port of you EXE. An easy way to get the IP is to wire the output of the 'String to IP' function into the input of the 'IP to String' function, set the use dot notation input to TRUE and do not wire anything into the 'String to IP' function. Wire the output of 'IP to String' into the machine name input on your Open Application Reference function.

I hope this saves someone some time. I wasted a day on this. Too bad NI chose not to document any of this...

Good sessions. Thanks for taking the time to come visit us up here and share your wisdom. I am already bugging my boss about putting more time into software quality efforts. Wish he could have attended the session.

-John

ps. I still want my mouse wheel to work in the string control!

QUOTE (Darren @ Apr 14 2009, 03:32 PM)

Definitely a bug, I was able to reproduce in 8.6. I couldn't find a workaround, but I filed CAR# 160408 on the issue.

-D

Thanks for the quick follow up. I guess I'll file that in the 'just don't do that' bin for now...

Here is the setup:

You have a VI with at least one horizontal splitter. In each pane you have an object set to fit to pane (scale object with pane). (for example, a multi-column listbox).

The user maximizes the screen. They then move the splitter bar that separates the upper and lower panes below the previous (un-maximized) bottom of the window. Finally, they return the window to its previous size (by pressing the un-maximize, or restore button). The result is a totally messed up window.

Is there any way to avoid this? See attached VI.

Download File:post-2411-1239747456.vi

Before:

After:

QUOTE (gmart @ Mar 26 2009, 03:20 PM)

App.kind returns what type of application is running the VI. So in the development environment, the property will return "Dev system" (or whatever it is). If a VI is loaded via the run-time engine, the property should return "Run Time System".

Yes, but as it turns out this is not working correctly for web services. Here is the response I got from NI:

"I just tested this, and the App.Kind property currently reports as being in the Development Environment. I don't believe this is proper behavior, so I reported it to R&D under Corrective Action Request (CAR#) 157042 so they might change it in a future version."

QUOTE (gmart @ Mar 26 2009, 01:46 PM)

You could try using the App.Kind VI server property.

Yes, but what 'App.Kind' is a web service?

QUOTE (NathanK @ Oct 17 2008, 09:00 AM)

My main application happened to be in a project and I knew that project was the only project open. Alternatively you could use the property to get the main application instance (the property I don't have wired). Or if you didn't know what application instance your VI was in you could append them all to one array and search through them.

I have a question about this. What if you want to write some code that will work in both the case of running under the dev env where you ahve a project open AND running as a compiled EXE, were the main exe is in the main app (default) instance. Can you test for DEV vs RTE in the web service? Does it even run as if it were in the DEV env? Is there a better was to detect this?

thanks,

-John