John Lokanis
-
Posts
797 -
Joined
-
Last visited
-
Days Won
14
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by John Lokanis
-
-
Maybe next year. I am only presenting at the local users group now. But, I have some ideas for a few presentations at NI Week 2010 so we will see if any get selected.
BTW: noticed that I spelled 'radio buttons' as 'radial buttons' in the description above. I guess technically since they are circular, they are 'radial' in appearance...
-
Just a reminder that my presentation on LabVIEW web services for the Seattle LabVIEW Users Group (SLUGs) is tomorrow! I will post the slides on Wednesday. Still editing them!
-
I'm @jlokanis
-
I do something like this, but in my case I *do not* want to have the plugin share sub-vis with the main app, even if they are really the same VI. This is because I may have 'upgraded' that sub-vi after releasing the main app and broken backward compatibility. So, I use OpenG builder to build my plugin LLB and namespace all the VIs so they never share with the main app. The only exceptions to this would be functional globals that I want the main app and the plugin to share. In that case there is a tab in the OpenG builder to exclude a VI from the LLB (forcing the plugin to use the one in memory from the main app).
I find the easiest way to build something like this is to have a project with all my plugin code in it and one VI that is never run, but has all the VIs needed by the plugin on it's BD (top level VIs and any dynamic VIs). I call this the 'static links' vi. This is the only VI I include in the OpenG builder setup. By doing this, it picks up all the required VIs and puts them into the LLB.
Beware including or not including the vi.lib VIs in your LLB. If you don't then you will have to hope the main app included the ones you need. If you do, you will add to the overhead of your LLB and will need to include any external DLLs those VIs use (a good example for me was using Fieldpoint VIs in my plugins but not in my main app, leading to many un-fun build issues/bugs).
OpenG Builder is a great tool for solving your problem. I wish NI had some of this functionality natively.
-John
-
Not sure what is causing this but here are a few things to try:
1. what is in your Error case? Do you pass the queue ref through?
2. Try using a shift register for passing your ref through the loop. This is just good practice and is very important in FOR loops because if the loop does not execute and you don't use a shift register then the output tunnel will be NULL. Not sure if timed loops can also do this. Normal While loops cannot since they always execute once.
3. Are you sure you are not stepping on the queue somewhere else with a force destroy set to true?
4. Can you post more of the code for us to look at?
-
1
-
-
Polling...bummer. I really wish they would give us a mouse scroll event!
-
What event are you using to trigger this code?
-
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
-
I put in a request to up the priority of getting it fixed.
Thanks!
-
I don't quite get this. The notifier itself can carry data, so why are you passing a reference to a single-element queue?
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!
-
It's not exactly a critical issue
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:
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:
-
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
-
2
-
-
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
Modal Madness
in Development Environment (IDE)
Posted
Have you ever been editing a bunch of VIs in your project and then decided to run the main VI to see if the edits worked, but you left a modal dialog VI front panel open somewhere? The result is it becomes frontmost, but is not actually running so you are stuck because you cannot get to your main VI UI and you cannot interact with the modal VI either. I do this all the time and it just ticks me off. So, I threw together this simple VI to avoid all that. I drop it down on the block diagram of my main VI so it runs first.
If this happens to you, give this a try and let me know what your think.
-John
Stop on Modal VI Open.vi