John Lokanis

I am looking for a whitepaper or other document that spells out (to a C programmer in their own terms) how to write a DLL that can be easily called by LabVIEW. I have searched NI for this but have not found quite what I was looking for. Can someone point me in the right direction? thanks, -John

If you want to do this programmaticly, then take a look at the NI Web Service Server in the code repository. There is a VI in there that uses .NET calls to do this for you. Feel free to use that in your project. Only works with Windows, however...

SSL was added with LV2009. I have yet to upgrade to the new version. Once I do, I will investigate how SSL integrates into this tool and post a new version. Hopefully, I will get to this in the next few weeks...

Cool. I wrote a VI years ago that does that same basic operation and I use it everywhere. I wonder how many other wheels we all have reinvented...

What I meant is if you wish to 'hide' the SEQ implementation in a generic set of VIs that can be reused and simulate dynamic memory access, then you must use a variant as the queue data type. This is because you do not know the data type of the element you wish to store until you use these VIs in a program. And you cannot make this polymorphic because you will likely want to use a complex typedef'ed data type. Therefore you must cast the data you get from the SEQ to the specific datatype for you implementation. If this is true, then yes, DVR offer no advantage since their reference carries the specific datatype of the data stored within the DVR reference wire. This is too bad because it means they really are not pointers. A pointer does not (and should not) know what it points to! At least they are a bit cleaner than SEQs but I guess they offer no new functionality after all. Bummer.

How about we simplify it and call it G++ ?? Personally, I like calling it Lab-voop, as in: "I am learning to write Lab-voop code in LabVIEW."

Yes, you could certainly do this, but then you must store the queue data in a variant and cast it back to it's native type after accessing it. (assuming you want to build a set of generic helper VIs to do this and want to be able to pass 'any' datatype using these functions.) I don't have LV2009 installed yet, but my understanding is the DVR reference is a single static datatype but it knows what it is storing. So, you would be replacing the variant in the queue with the DVR datatype and then when you need to access the data, you would use the inplace structure that could decode the data in the DVR into its native type without having to do a cast. It's a minor savings but let's you skip the typedef for the data you are passing as well as leading to cleaner diagrams. Of course I could be wrong... Anyone want to test this? Does the DVR carry it's datatype on the wire or is it stored in the memory where it points to? -John ps. sorry about your lack of TIVOness. Honestly don't think I could live without a DVR anymore (the original kind, not the LV data type).

If you really want named DVRs, just store your DVR in a single element queue and then use preview queue to retrieve it. You could put together a very simple set of VIs to implement this. I used to do something similar with single element queues and variants. Be sure not to destroy your DVR without freeing the queue or you might end up with Totally Invalid Value Objects, or TIVOs.

Yes. Not ready for prime time. When it is delivered, it will hopefully have enough functionality to be useful...

Too bad you cannot select multiple probes in the watch window and view them in the Probe Display frame simutaneously (with enough screen real estate). Perhaps this is a good suggestion for the Idea Exchange!

Be careful or this might happen to you:

Many of the presenters at NI Week promoted the LabVIEW Idea Exchange here. I have been reading, voting and posting to the idea exchange for awhile and just posted several new ideas/complaints that I thought of while attending NI Week. I challenge all LAVA members to visit the exchange and vote for the ideas you agree with (especially mine ). And if you don't agree, post a comment and tell me why! Then post your own ideas so we can all vote of them too. The more feedback we give, the better LabVIEW will be in the future. -John

I didn't know about that one. I like it. I just threw mine together in a few minutes after this screwed me up one time too many. I should have searched for an existing solution. Oh well, there is always more than one way to skin a VI, I guess... Done! Go vote for it if you like the idea!

Well, yes. What you describe is not the point of web services in LabVIEW. If you want to understand the basics, NI has several help articles on their site to get you started. What I am trying to do with this project is help an advanced developer take their web services and deploy them to a run time target. This was a bit of an after thought on NI's part and is therefore not straight forward. Since I suffered through the issues, I am trying to share that knowledge here to help others avoid the same pitfalls. In addition, I am providing some interesting uses of web services that are non-traditional but make them valuable to LabVIEW developers. -John

Good thing I looked at this. I didn't realize the BBQ was at a different place than last year!

As promised, here are the slides from the presentation. I think the topic was a bit advanced for some attendees, however. I got a lot of glazed looks when I tried to explain how important it was to understand application instances when using web services. Maybe I will get to present this or an updated version at NI Week 2010. Unfortunately, the slides don't have a lot of details and are more of an outline of my presentation, but maybe you can get something useful from them anyways. -John Web Services in LabVIEW.pdf

I never thought of that! Good idea. I will try that in the future.

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

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?

Polling...bummer. I really wish they would give us a mouse scroll event!

What event are you using to trigger this code?