Mike Ashe

QUOTE(yen @ Mar 10 2007, 02:53 PM) 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) 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) 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) 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) 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 H2, 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) 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) QUOTE(crelf @ Mar 9 2007, 07:55 AM) Don't apologize Ton - this is the place to rant! 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) 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) You realise you just typed "under 4 inches", is this a Freudian slip ...

QUOTE(yen @ Feb 20 2007, 12:59 PM) 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)

QUOTE(xtaldaz @ Feb 19 2007, 01:18 PM) 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 and I would argue that I love LabVIEW as much as both Mike and Jim. Normally, I'd really have to disagree with that last statement, but anyone in a LabVIEW forum with an avatar like yours ... QUOTE And seriously, Jim and Mike, how can you say that scripting released as it is could really benefit all these people? 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 I had full access to scripting for many years and (it) certainly didn't make me a better software engineer nor did it really help me understand LV any better, it just made it easier to crash in unexpected ways or otherwise get my LV into a very bad state. 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) 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 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) QUOTE(xtaldaz @ Feb 15 2007, 02:13 PM) I agree completely with DannyT that LV doesn't scale well when you start adding developers and complexity to a project. 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 My current workplace started out as one guy building the SW and HW. He chose LV and was very successful. Then he retired and was replaced with a couple of new people. They didn't get formal training on LV and when they modified the code or wrote their own, things got out of control. .... The existing LV code is similar to the 9-screen program that Stephen describes - and add thousands of locals, globals, and ...now in LV 8.x, shared variables. The LV code isn't modular, isn't able to be easily modified by groups of people, and as a result, the entire group has decided to get rid of LV as a development environment and move everyone to C#. 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) ...Ad hoc software (development) works. ... (but) generally when the software reaches a particular size and/or needs to be handed off to a new programmer or becomes a team project -- where ad hoc (development) just isn't enough (anymore). ... Software engineering is very much in its infancy. 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 tendency to avoid problems and the emotional suffering inherent in them is the primary basis of all human mental illness. ... Since most of us have this tendency to a greater or lesser degree, most of us are mentally ill to a greater or lesser degree, lacking complete mental health. Some of us will go to quite extraordinary lengths to avoid our problems and the suffering they cause, proceeding far afield from all that is clearly good and sensible in order to try to find an easy way out, building the most elaborate fantasies in which to live, sometimes to the toal exclusion of reality. In the succinctly elegant words of Carl Jung, "Neurosis is always a substitute for legitimate suffering." But the substitute itself ultimately becomes more painful than the legitimate suffering it was designed to avoid. The neurosis itself becomes the biggest problem. 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 What are these tools, these techniques of suffering, these means of experiencing the pain of problems constructively that I call discipline? There are four: delaying of gratification, acceptance of responsibility, dedication to truth, and balancing... The problem lies not in the complexity of the tools, but in the will to use them... " I think the mapping from psychology to software here is pretty obvious. QUOTE(xtaldaz @ Feb 15 2007, 02:13 PM) I'd love to refactor all the existing LV code and show everyone that LV can be used as a proper SW Engineering tool. ... 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) 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?

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"

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?