John Lokanis

Here is another good discussion of that article:

http://blog.objectmentor.com/articles/2009/09/24/the-duct-tape-programmer

My favorite comment about Joel was: "never take software advice from a bug tracking system salesman".

I used to respect Joel, but if there was a way to comment on that article, I would simply tell him:

'you are an idiot'.

The line that really got me was: "If there’s no unit test the customer isn’t going to complain about that.”".

Sure, that is what Microsoft has been thinking and doing all along. The world is their beta (and often alpha) tester! Who cares if it is good, as long as it ships.

Well, I have spend MANY hours of mine and my employer's time dealing with the bugs that these 'duct tape' programmers leave in the code because they are too lazy or stupid to come up with a decent set of requirements, design and test plan and then take the time to actually implement it!

Wiz-bang features for the sake of elegance may be a waste of time, but careful planning, execution and testing of ANY code is CRITICAL. I don't care if it is going in a 747, a desktop OS or an mp3 player. Just because it ships doesn't mean it is good.

/rant

-John

yes. take a look at this:

NI Web Service Server

John Lokanis, which is your idea? Can you provide us with a direct link?

Look for all ideas by 'jlokanis'. I have posted several.

I liked your .NET idea! Kudos!

Cool. How did you do that?

I like it but would suggest you have the pallets 'snap' to a grid of some sort so we don't have to nudge then around. Or, let us lay them out and then choose a menu item to 'snap and align' them.

Where can I get a job playing around with LabVIEW GUI stuff all day and still get paid?

Closing the parent node invalidates all the children nodes. But, it should error, not crash.

I have not been impressed with the quality of Dell laptop components. I would look at the Thinkpad or better yet, get a MacBook Pro and use bootcamp.

Thanks for the detailed reply! Sorry for not responding sooner but I was on vacation.

The DLL in question will be performing some math on DBL arrays of data. It will not be a 'LabVIEW only' DLL. I think there is enough info here to answer all my questions. Still surprised I could not find this info on NI.com somewhere...

thanks again,

-John

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

Why? You just use the SEQ directly to store the data itself. DVRs don't offer anything you couldn't do with a SEQ. They do offer better guarantee of inplaceness and less chances of causing deadlocks, but the functionality is the same as you would get with a SEQ (except you can obtain a SEQ by name and preview its data, which you can't with a DVR).

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.

As for your other question, DVRs are also typed, just like queues and notifiers.

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

But if I'm going to put the DVR in the SEQ, then I will just bypass the DVR and just use the SEQ

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 agree. I use Darren's "Abort" quite often. It sits on my desktop.

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

Why not post an idea to the idea exchange yourself?

Done! Go vote for it if you like the idea!

am i missing something??

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

To avoid this problem I never set my VIs modal in the VI properties, VIs to appear modal set themselves "modal" when they are called and set themselves back to "normal" after execution.

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