John Lokanis

Name: Find Text Submitter: John Lokanis Submitted: 17 Jul 2009 Category: User Interface LabVIEW Version: 8.6 Version: 1.0.0 License Type: Creative Commons Attribution 3.0 Make this available on the VI Package Network?: Yes Find Text v1.0.0 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: None. Description: This project contains the Find Text.vi and supporting subvis. The Find Text.vi displays a dialog allowing the user to search a text display for a specified string. A reference to the string control must be passed in. When the string is found, the calling VI will become front-most so the string can be highlighted. If the string is not found, an error message is displayed. Searching starts from the cursor location in the text control. You can change the search direction using the radial buttons. The VI will remember previous search strings inside the combo box where you enter the text to find. If you pass in a caller reference, this will be used to center the dialog. Otherwise, the VI will attempt to find it's caller in the call chain and center on that. If you call this VI dynamically, it will center itself on the primary monitor if the caller reference is not passed in. Instructions: Open the 'Example - Find Text.vi' and run it. Select the Find menu function or press Crtl-F to open the Find Text dialog. Known Issues: None Acknowledgements: None Change Log: v1.0.0: Initial release of the code. License: Distributed under the Creative Commons Attribution 3.0 (http://creativecommons.org/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]NI Web Service Server" support page. Distribution: This code was downloaded from the LAVA Code Repository found at www.lavag.org Click here to download this file

Thanks!

Thats what I get for not reviewing the code before I post. It has been awhile since I built this. Here is what I am actually doing: In the receiver VI, I wait on a master queue. When I get 1 or more elements, I flush the queue. I then filer the elements for duplicates. Each element has an enum (command) and a variant (data). If the command is something like 'quit' then I process it immediatly (and stop the receiver loop). If the command is a new message, then the variant is a notifier refnum unique to the sender. I get the data from the notifier and display the message. I do this for each unique queue element. I then sleep one second and go back to waiting on the queue. This way, each sender can fill the queue with as many updates as it wants and I only process one of them each second. Since the element contains the ref to the notifier, each queue element from the same sender will be the same and the filter will toss all but one. Then when I process it, the notifier ref resolves to the most recent message only and I get my data. I suppose now that we have lossy queues I could replace the notifier with a single element lossy queue and get the same effect. In another part of the code, I use the wait on multiple notifiers to monitor several independent threads. There is one notifier that I use to tell this consumer loop to add a new notifier to the array to wait on. I think of this as a channel. Then that unique notifier channel is given to a thread when it spawns. The thread posts it's messages on that notifier channel and when the thread exits, its last message says to delete the notifier from the array, closing the channel. This is also a lossy scheme so the the threads can post their status as much as they want and the consumer only updates the GUI once a second with the most recent info. In the consumer I get all the updates from all the notifiers in the previous 1 second at once and then do a single update to the GUI (with defer updates on) to keep CPU overhead to a minimum. I hope that makes sense. I'm sure there are other ways to code this but this is working well for me right now. -John

Looks like it is up: https://secure.niweek.com/2009/scheduler/home.jsp And since it puts you on a wait list if the session is full, I do think registration is required and is on a first come first served basis. So, don't wait too long to build your schedule!

Unless you need it to work! In my case I use this with a web service to get remote images of running VIs. If the user minimizes the app, my image is messed up! Guess I will just have to wait... Thanks for filing the CAR...

I do something similar to this. I have multiple senders posting messages to a receiver. In my case, I wanted the system to be lossy since I only care about the most recent message from any one sender. I have each sender use a notifier to send it's message. I then wait on multiple notifiers and then process all the notifications at a maximum rate of 1 second. The notifications contain a queue ref from the sender. I filter the array of notification data to throw away dups (the lossy part) and then process each unique queue to get the data it contains (these are single element queues). I find a mix of queues (used as dynamic memory elements) and notifiers (for signaling) works quite well.

Guess I better submit this to NI as a bug then.

Anyone know why this happens? If you use the FP.Get Image method on a VI that is in the normal window state and then in the minimized state, you get a different (shifted) image from the minimized one. Here is an example: get vi image minimized.vi minimize me.vi Bug or expected behavior? Any workarounds?

I had to register last year. They had this crazy 'wingate' system that you would use to sign up and you had to rank your preferences for sessions that were overlapping.

Attendance is limited. Maybe since you are/were a presenter, you get special privileges...

Here is the link: http://www.ni.com/pdf/niweek/us/2009/prelim.pdf

Anyone know when the registration system will be online? I have already picked out the sessions I want to attend from the preliminary program and am ready to build my schedule. Last year some of the sessions filled up fast so I don't want to miss out!

How about using .NET controls in your VIs (and some of the pitfalls to avoid, like placing the control into a .NET Panel form to avoid certain crashes). Also, how to find things in MSDN to help you use the .NET features. This is always a pain for me. Maybe an overview of how the .NET assemblies are organized so we can better locate things we need or want. I will try to think of some more.

I will post the power point slides when they are ready. I don't think we have any equipment to record the presentation. If all goes well, maybe I can present it again at NI Week 2010.

I will be giving a presentation on web services in LabVIEW, including a discussion of this project at the next Seattle LabVIEW User Group (SLUGs) meeting this month. If you are interested in attending, contact our local NI rep (jared.mcinelly@ni.com) and request to be added to the attendee list. The meeting is on 7/28/09 at 7pm in Redmond, WA. Pizza and drinks will be served! Thanks! -John

Name: NI Web Service Server Submitter: John Lokanis Submitted: 08 Jul 2009 File Updated: 03 Jan 2011 Category: Remote Control, Monitoring and the Internet LabVIEW Version: 2009 License Type: Creative Commons Attribution 3.0 NI Web Service Server v2.0.0 Copyright © 2010, 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 2009 Dependencies: Requires .net 2.0 or higher, LabVIEW 2009 or higher. Description: This Project contains a set of VIs and support files designed to build an installer that will place the 'NI Web Service Server' on a target machine. The NI Web Service Server is a small LabVIEW EXE that runs as a Windows service in the background, keeping all LabVIEW web services running regardless of what other applications are running on the machine. Also included are a few web services that support the following: Getting screenshots of the target machine on demand. Getting VI Front Panel images from any running LabVIEW EXE on the target machine. Getting EXE version information from any running LabVIEW EXE on the target machine. Testing the web service with a simple 'echo' command. Please refer to the included 'NI Web Service Server.pdf' file for a more detailed explaination. Instructions: Build the various components and desired installer, then install to target machine. Use any standard web browser to access the web services. Known Issues: None Acknowledgements: NI Knowledgebase, MSDN Change Log: v1.0.0: Initial release of the code. v2.0.0: Ported to LabVIEW 2009. 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]NI Web Service Server" support page. Distribution: This code was downloaded from the LAVA Code Repository found at www.lavag.org Click here to download this file

Added better error handling and cleaned up some of the BDs. I think this is read to be submitted to the CR. Can someone let me know what next steps to take or what might needed to get this code into the CR? thanks, -John Click here to download this file

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...