Mike Ashe

QUOTE(yen @ Mar 10 2007, 02:53 PM)

Also, can't you backsave the Picture to Pixmap VI from LV 7.0? It's password protected, which I assume means that its diagram is still there. Or does LV consider that a system VI and does not allow backsaving it?

I tried backsaving before I posted the VIs above, but LabVIEW told me it could not do the save for me.

I have a lot of stuff open in 8.2 right now, so I don't really want to fire up 6.1 to check the get image method. I am not sure, but I think I recall that the VIs I posted were from a version before we had the Get Image Method available.

Funny, all the hacks we've done over the years to work around something, that later we get to replace later with some of the goodies we've gotten from the Elves.

QUOTE(Jeff Plotzke @ Mar 6 2007, 10:27 AM)

Other than that, I've also seen huge speed improvements from the 7.1 internet toolkit to the 8.20 version. I'm doing a project now that I'm transfering hundreds of MBs of data from a RT system to a Windows Host, and I'm getting great speeds using 8.20.

How has this affected determinancy for you on RT?

Have you been able to do this transfer while running DAQmx IO at the same time on the PXI chassis?

If you are running time-critical loops, do you stop them to do the data transfers or do you stream at the same time?

I'm in a current project where this matters, so thanks in advance!

Looks like what I need for my evening brandy sniffer

QUOTE(LV Punk @ Mar 9 2007, 12:58 PM)

The only thing better than beta is alfa, I mean alpha,

The corollary is that the only thing more dangerous than beta is alpha

(the fact that alfa is more dangerous than alpha goes without saying...)

Several nice goodies here, especially and ,

and I really can't wait to test

:beer:

QUOTE(jbrohan @ Mar 8 2007, 02:28 PM)

Hi

I'm taking a program back to 6.1 for a simpler install. There seems to be an issue with writing Jpeg's. The step between a picture and the input required by the write Jpeg is missing anyone remember?

Gee, you know how to make the older neurons creak and pop, don't you?

To convert between picture and flattened image data:

http://forums.lavag.org/index.php?act=attach&type=post&id=5164

This includes a test VI demonstrating what you ask for.

To get a little fancier, with more options on writing to files,

and goodies with the pixmap manipulations:

http://forums.lavag.org/index.php?act=attach&type=post&id=5163

The old technique is shown here, using pixmap arrays & subVIs with refs back to picture data.

Now my head hurts

Open the Find Examples dialog and search for Polar Plot Demo.vi

You'll have to do a little work to modify it and make a customized version of the Polar VI inside, but it has the basics of drawing the polar grid. You can then use the polar <-> rectangular VIs for coordinate conversion and draw a line from the center to the perimeter of the graph, sweep that around. If you wanted to get a little fancier and simulate actual data you'd put down an array of color points/pixels along the current trace line. Just before you write that line you take the current Picture and "fade" it very incrementally by lightening (or darkening more likely) the whole picture in the direction of your background color. Remember to refresh from the basic polar grid/background, otherwise, if you simply keep adding to the Picture control it gets bloated data wise.

QUOTE(dthomson @ Mar 9 2007, 12:02 PM)

For anyone who is interested in the plight of the Ethiopian coffee farmers (and of those in many other coffee-producing regions), you can look for Fair Trade beans that make an attempt to address this situation.

PBS is showing the movie Black Gold

on April 10th, 2007

Thanks for the note on Fair Trade, Dave. I just looked up my area and found a couple places nearby to get my beans.

Didier ,

Best wishes to you and your family in the new management job. Glad to hear that you don't have to wear a tie all the time. Remember to read Dilbert regularly as a self check. If the humor stops making sense to you, then it's time to think about going back to your old job

Seriously, I've greatly enjoyed reading your posts. You've been a been a great contributor here and we'll all appreciate it if you stop back from time to time. In time you'll probably really miss it here. After all, it's not all strictly LabVIEW, that we're here for, I mean, how can you seriously contemplate going for too long without threads like The 5th Dimension "In the beginning was the Alfa, and his prose was without form, and his logic void, and ..."

Welcome to LAVA Sherif.

Could you tell us a little bit about what type of project you are using LabVIEW for now?

QUOTE(yen @ Mar 8 2007, 02:32 PM)

Search for some LabVIEW tutorials and for "PID".

Ditto, while you're at it maybe you could look in your .\LabVIEW\Examples folder for PID examples, or even go to your Help menu in LabVIEW and "Find Examples" and search for temperature control or PID, just don't turn in the unmodified example VIs as your homework ... any teacher worth their salt will be checking for and rightly fail you for that.

Forgive us all for labeling you an H², but it seems doubtful that if you had been using LabVIEW for a while, that you would not already know that LabVIEW already has more example code, for free, that what you need to do what you ask.

Do yourself a further favor, and after you look up temperatures & PIDs, etc, that you spend some time and get familiar with most of the examples that come with LabVIEW.

QUOTE(REM1 @ Mar 8 2007, 04:39 PM)

True, your participation must be authorized by NI. When I say public beta I mean one where you can request admittance by going to ni.com/beta as opposed to a private beta where you must get an invitation email from me the beta coordinator just to get to the signup page.

It seems to help if you have beta tested before (some of us are well into the double digits on betas now), but they are always interested in new beta testers, as they look at things with a fresh eye, as contrasted with us older seasoned battle-hardened persons-of-prior-testing who sometimes tend to look at things the same way.

To quote from RAH again:

"To stay young requires unceasing cultivation of the ability to unlearn old falsehoods"

QUOTE(tcplomp @ Mar 9 2007, 01:31 AM)

Our machine was broken this morning, sorry for the rants... Ton

QUOTE(crelf @ Mar 9 2007, 07:55 AM)

Ton, as soon as I read your apology I had to try to look up where your rant was, since reading a good rant with it's resultant ROTFLOL is almost as cathartic as writing the rant in the first place. So I heartily agree with Chris, never apologize for a good rant, unless the real intent of your apology is stealth advertising to draw more attention to the rant ...

Oh yes, 2nd cup is in hand as I type, so:

Coffee, the Elixir of Life. Googling on "history of coffee" (in quotes) brings up over 115,000 entries, which is appropriate since we have coffee to thank for the prominence of the most prestigious modern insurance and banking companies and is the second largest international export after oil.

The invention of the expresso machine ranks up there with the greatest inventions of all time. During one of my former lives, on a nuclear submarine (no it wasn't yellow), we came up with a more fitting acronym:

M.A.G.N.I.F.I.C.A.D.

Manually

Actuated

Gastronomic

Nirvana

Inducing

Fluid

Infusive

Coffee

Aquafication

Device

One of my lifetime goals is to make a pilgrimmage to the place of the world's first coffee shop, Kiva Han in Constantinople. I grew up in Washington State and have already been to the original Starbuck's in Seattle's Pike Street marketplace. I could go on and on about coffee, but my third cup is waiting, LabVIEW work is calling and we must now return to our regularly scheduled channel of waiting for our next installment of "The Chronicles of Alfa".

P.S. In an expression of social responsibility, uncharacteristic for an otherwise conservative capitalist such as myself, I'd like to make a shameless plug for an upcoming documentary on the plight of Ethiopian coffee farmers contrasted with the bega-bucks* of Starbucks and others.

http://forums.lavag.org/index.php?act=attach&type=post&id=5158Black Gold: The Movie

*Bega for billions, not the usual millions

QUOTE(didierj @ Mar 8 2007, 05:00 AM)

"Tea" :question: , I thought you were THE "coffee"-man?

No, that would be me.

When We've had Our second cup tomorrow morning,

We shall elucidate further on the illustrious history,

of coffee, http://uploads//post-932-1159825841.gif' target="_blank">The Elixir of Life and the device that enables

the world to function,

The M.A.G.N.I.F.I.C.A.D.

QUOTE(crelf @ Feb 27 2007, 01:43 PM)

No, you must be under 4" to work at VI Engineering - that's how we keep our overheads down...

You realise you just typed "under 4 inches", is this a Freudian slip ...

QUOTE(yen @ Feb 20 2007, 12:59 PM)

You should be careful when you say that to a woman (which you were). In some states, you could probably get sued.

Isn't Heinlein great? :laugh:

Yes, I know who Crystal is, we've met, and she has a good sense of humor (also a job situation that I'd kill for oops, guess the NI R&D job is in the past) and that's why I said the tongue-in-cheek. Also, when I spoke earlier about writing up another InYourDreams christmas list she was going to be one of the NI Elves I was am was going to send it to.

Yep, R.A.H. is cool. We don't see eye to eye on everything, but we do on enough that I've been a fan since I was 12. Nice thing with his works is that you can be a fan from 12 to 40-something and beyond. The Notebooks of LL are gems.

QUOTE(robijn @ Feb 19 2007, 04:08 AM)

...If it's just restoring a front panel it's a piece of cake. But I'm afraid you also want to be able to build loops, conditions etc... What are OSTE's full requirements ?

MIKE: Yep, we have loops, simple branches, inputs from operators, database queries, and a bunch of other step types. OSTE's design also separates between the data acquisition and the later analysis/evaluation of the data. Sure you can still write a complete test in a single VI, but the design encourages separation of those two. Why? to allow modularization of acquisition and analysis into reusable (and resellable) components. More on all the requirements will come on first beta, but it's not ready yet.

In Europe software patents cannot be filed nor defended (officially, that is) so this is no problem for me to participate. I am strongly against software patents as they hinder innovation (and me) and are not needed at all (copyrights...).

MIKE: I would tend to agree, sometimes... I don't want to say more. Softwre patents can actually be a good thing if they are for truly original, innovative techniques, but lets face it, most are not. Some patents are granted for things that are so obvious as to make you want to scream. If you think it's bad in software patents, bio-technology is now worse. Look down at your hand, about 20% of the DNA you "see" is patented.

Sorry for getting on a non-LabVIEW rant there

QUOTE(xtaldaz @ Feb 19 2007, 01:18 PM)

I guess I should have had a qualifier ... that LabVIEW code written by people who aren't educated in LV development, don't understand software engineering principles, and only write ad-hoc programs doesn't scale well. Nor is it easy to start using those principles on LV code written that way once you've seen the error or your ways or once you start thinking more abstractly. No, it's not the environment's fault

Okay, we're getting closer to agreement. But you can substitute any language for LabVIEW in your quote and it would be as true. Especially, I think, about the part of trying to start doing things right on a really large project (code base) that is already screwed up. It is often much easier to "scrape the directory clean" and code up again from scratch, but that usually doesn't fly with budgets or management.

QUOTE

Normally, I'd really have to disagree with that last statement, but anyone in a LabVIEW forum with an avatar like yours ...

QUOTE

I don't think we said it would, at least not directly. But indirectly it would benefit everyone if scripting were (more) out in the open. Some of us would have an easier time making tools, those tools would benefit all. By the way, I'd like to make the points that: 1) a lot of us are making tools anyway, even though the cookie jar is on a higher shelf and the shelf has rusty nails. 2) my complaints and requests should not be taken as sour grapes. I'm very grateful that we have the scripting we do now. Or at least had. I really wish that at least NI would put us back into the state we were in for 7.1, :headbang: that if you could get to it it would work. Sigh... maybe during the next version

QUOTE

Hey, it just reminded me of the good ole days when both LabVIEW and Windows were in version 3.1. Wireworkers were still Real Men in those days, and wore out and replaced the Ctrl and S keys every other week or so. Come on now admit it, haven't you been missing your daily hourly dose of BSOD in the last few years?

No? Okay, well I don't think it would make most people, including me "a better software engineer", I just think it would make it easier for me to write some of those software engineering tools Jim & I are talking about.

To quote another favorite author:

"Progress doesn't come from early risers - progress is made by lazy men looking for easier ways to do things." - R.A.H.

QUOTE(Jim Kring @ Feb 18 2007, 05:11 PM)

-- that the state of software engineering tools for LabVIEW is pretty meager. ...The solution, in my opinion, is an open, machine-readable/writable source code format (I vote for XML). I good first start would be to open up http://forums.lavag.org/LabVIEW-VI-Scripting-f29.html' target="_blank">scripting.

I'd love to see both, although opening scripting is tops on my list. Yeah, lots of us are scripting away right now, but it feels like alchemy when it could be chemical engineering. I must slightly disagree with my friend in that having these two items he asks for, while really nice, won't solve the discipline problem directly, but would facilitate our (the community & NI together) making more tools to help automate and check the Design/Development Patterns in a LabVIEW Project.

Here's a semi-trivial example: A few years ago I was working on a project and had refactored a lot of the client's initial code to use error clusters and checking. I supplied several libraries of VIs and examples. Later there was a lot of support calls/emails about problems "with Mike's code", etc. I was at a loss to explain the problems until I arrived on site and started looking at how they were using my libraries. You guessed it, some error terminals were not wired up. Randomly it seemed. There was a lot of code. It took a while to track it all down and get it wired right.

During this I emailed one of the Elves at NI (Aristos, was that you?) who sent me a (diagram hidden) VI that I could use to scan through a bunch of VIs and check if my subVIs had the output error terminals wired on the calling diagrams. It was a wonderful little VI ... hidden. My real desire here, was to be able to inforce discipline in the development process, remotely, as there were thousands of miles between me and the client most of the time. Thanks again to the Unknown Elf (sorry, my memory is glitching) who helped.

Since then, I've learned how to do the same thing (and a lot more) myself using scripting. We need a large suite of Tools and Utilities that can scan a hierarchy, project, VI, etc for Design and Coding Standards. I really appreciate the effort NI is expending on the LV Project, etc, but the community could do a lot more. Opening up scripting would make it a lot easier.

Recently I was asked by several NI reps what NI could do to make enthusiasm go up and to help people adopt new features faster, the way us "guru oldtimers" did 10 years ago. It was pointed out to me that we were rabidly enthusiastic about LabVIEW then (and now, just with a little more elderly restraint ) and I was told that NI isn't seeing the same response. My answer is going to get truncated (because my son just said dinner is ready), but it seems to me that proportionately more effort has gone into making more and more items for the LabVIEW beginners, to get people to adopt LabVIEW. Well, I can't blame NI for wanting to make new sales, so do I. Nor am I denigrating some of the nifty features that do benefit more CS/Engineering and guru programmers. But I really would like to see a major version of LabVIEW come out where almost all of the efforts went into the types of things Jim was talking about above and other hard CS and CASE Tool type items like we've touched on in this thread.

It's been a couple of years since the "InYourDreams" thread on Info-LabVIEW, so I suppose it's past time for me to write up a new list to Santa's Elves.

The really nice thing is that this time I expect to get all of these things within a couple more years after asking. "InYourDreams" was semi-joking, but we now have almost everything on that list, except the single file executables again, and I can live without that.

Oops, second call for dinner, I'm in trouble...

Ditto on the Thanks Jeff, this will come in handy in the next two weeks as the current project shifts from bench to lab to production testing. :thumbup:

QUOTE(Jeff Plotzke @ Feb 16 2007, 09:09 AM)

...I'd find some sort of "status" command to send to the remote device (some command that didn't do anything other than return data) and send that every second or two. If I didn't hear back a response after a few tries, I considered the device disconnected.

I do this on TCP Servers, typically calling the command a "heartbeat" if there is no relevant data returned and a "Status_Query" if I expect data from the connection. Standard practice these days seems to be to make a TCP Listener that will spawn off a new instance of a TCP Handler VI for each client that connects in. Each handler sends and receives the TCP messages, usually communicating with other local code via LabVIEW Queues.

In my typical implementation I have a flag that can be set, to en/disable the heartbeat functionality, such that the each handler will wait for outgoing messages on the outgoing Queue with a timeout of period=heartbeat. If nothing is available from the Queue, then I send the Heartbeat msg, which expects some trivial reply, "Yep, I'm still here".

QUOTE(dannyt @ Feb 15 2007, 04:32 AM)

The one area I find Labview to be really really poor, is the scaling up to large projects being worked on my multiple programmers, where software auditing \ tractability and reuse are key and I believe this is due to the history of Labview being a "non-programmers" programming language.

QUOTE(xtaldaz @ Feb 15 2007, 02:13 PM)

With respect to your opinion, I have to disagree, or at least redirect the focus. LabVIEW actually scales pretty well, even with several programmers, separated by wide physical distance.

Cause & Effect. I agree with you on the observance of the Effect, but you have identified the wrong thing as the Cause, it is not LabVIEW. Lets look at an example of the pattern...

QUOTE

I love the fact that we now have Templates and Design Patterns. When you start a project you can now start a Project and pick Patterns for both the Project and each VI. Yes, I know you know this. You last quote above makes me think that we should have menu pick "Development Patterns", under two main categories: "Ad Hoc" and "Software Engineered". (with subtypes under each)

I cannot count the times that I have seen the "Ad Hoc:Creeping Feature" sub pattern for development (and yes I freely admit I've been quilty of it myself, lots of times). In fact, it happens so often that I'd say it is the norm, with LabVIEW project life-cycles, not that it should be. That is not the fault of LabVIEW.

QUOTE(Aristos Queue @ Feb 15 2007, 02:18 AM)

I agree with the "infancy" we don't remind ourselves of this often enough. To borrow from M. Scott Peck and para-rephrase (modular reuse and inheritance from an even older Zen teaching...?), "Software Development is difficult. Once we truly accept and understand this then Software Development is no longer difficult..." because we no longer expect and demand that it be easy.

Let me quote and paraphrase from Peck once more:

QUOTE

This sounds so much like continuing to use Ad Hoc software development methods when they are no longer appropriate, to avoid the pain, boredom, tediousness, etc of the discipline of engineering the software and the software development process/pattern correctly for larger projects. It takes a lot of effort up front to develop a large project properly.

Now, although I said LabVIEW was not at fault, never the less it does contribute to holding onto Ad Hoc way to long. It is so easy to Ad Hoc small to medium size projects in LabVIEW that we tend to resent giving up the easy path when the time comes to shift into real SW engineering. With LabVIEW we get results almost instantly, immediate gratification. Thats great, in it's place. Just a little more from Peck

QUOTE

I think the mapping from psychology to software here is pretty obvious.

QUOTE(xtaldaz @ Feb 15 2007, 02:13 PM)

I have to express some grattitude here, because the project I am currently on is one where I am not only allowed to refactor some of their current software for reuse, but also the client's development process, while implementing a completely new "modular from the ground up" architecture for the new test system. They currently have a couple of dozen systems of the "9 panel, 3x3 or 9x1 diagram" variety of LabVIEW RealTime test stands, and they see the need and are willing to commit the resources to change their code and process. I haven't had a lot of clients over the years as willing and able. If only they could all be like this.

QUOTE(Ale914 @ Feb 16 2007, 03:03 PM)

I agree, a Teststand Lite is a great idea and OSTE was a good candidate to became a smart test manager, any possibilities to restar the work on OSTE?

I could put all my experience on LUA to build up OSTE.

Ciao

OSTE isn't dead, but it has been delayed numerous times, as you and others have noted. One of the reasons it was put off a while back was due to some of the "Authorized Application" licensing and non compete issues in the LV 7.x license. Since these have been resolved in 8.2 I'll have to see what I can do to get what I have ready for further development and finally let others in on development.

There were also some patent issues, but those have also recently been resolved.

OSTE's basic premise has always been to capture the front panel of a VI and then play that back, essentially sequencing VIs. Give me a private message if you want to be in the development.

If snowballs grew on popcorn trees ...

And you Grandmother was STILL your Grandmother after a cold winter's night...

And the price of tea in China was 10 yen per pound ...

How far would a brick have to fall to break a shingle?

Event structures are better than polling loops.

It sounds a little more in the western tradition than the eastern, but ...

"To poll is human, to event is divine"

or

"To error is human, to exception handle is divine"

Ahh for the days of LV 4! Executables with the runtime built into the exe...

If my faulty memory serves this morning (only the first cup of coffee), this worked up through 5.0.1. It was the 5.1 version that did away with single file executables. I wonder what the minimum file size would be for 8.2 to do the same thing with all the new goodies we have?