Mike Ashe

Although I was a reviewer for the LabVIEW for Everyone, 3rd Ed and there fore am obviously biased as well, I would heartily second Richards AND. You can buy both books for just under half of the NI course, and you qualify for free shipping as well. :thumbup: Don't get me wrong, I think the NI quality is great, and the course IS worth the money. But NI charges a premium price for everything, and you can get better bang for the buck with these two books. YMMV :beer:

One option is to put a node alone on a VI, save, then set to merge in the paletes. We have discussed creating an open source paletes of the scripting nodes like this several times. OpenG has a couple, but not a lot. Maybe we could start that as part of this thread.

A good book to read that gives you specific training to prepare is the third edition of "LabVIEW For Everyone" by Jeffrey Travis and Jim Kring.

Ouch Don't get me wrong, I've used directories and single VIs on my last three projects, including at my current client's, I just think think they're still useful and they're LabVIEW, so I'm partial. Plus, I admit, I really like to add and add to the tools and capabilities and seldom like to lose something if I don't have to. Thank you.<snip> Okay, I'll buy that, I just wondered if NI was tinkering with it again in a skunkworks room somewhere. A couple of people have told me that NI is working on a lot more tools to handle LabVIEW code than before. Yeah, I figured it was an extension. I was wondering if an extension to the extension would allow file operations inside the LLB, perhaps using a LabVIEW DLL made of VIs from the LabVIEW Library Manager. Hmm, maybe I'll have to experiment in my free time.

Has anyone used LabVIEW to create a script for one of these tools and then envoked the tool to automate LabVIEW functions? There are still things we can do from the LabVIEW menus and buttons that we do not have programmatic control over. I recall an issue with MAX losing ID for Firewire cameras if the system was powered down. We had to manually go into MAX and reset them. No way to do it programmatically. A workaround would have been to have LabVIEW detect the problem, then invoke a script in one of these tools to start MAX and rest the IDs. Kludgy, but it would probably work.

Hi hma, welcome to LabVIEW. Actually, yes you can have arrows on your block diagram, you just cannot anchor the ends to the comment and wire. But you can place them however you want. Just place an arrow on your front panel from the decorations pallete, then copy it from the front panel and paste into the diagram. You can then move, resize etc. This works with any of the decorations. For some reason NI has not added this directly to the palletes for the diagram, but don't let that stop you. Good luck!

I should have been more explicit, but I figured gmart would understand. I already knew about your point above, that current methods only allow single files. What I am asking is if NI is working on letting us do SCC with individual VIs inside LLB's. I see no reason why it should not be possible. Unfortunately almost all of the source code packages today assume that you are working with a text based language. I respect your opinion, and a lot of people agree with you, but, I disagree. I've been programming almost fulltime in this language for a lot of years and I think LLBs are a good thing. You commonly see well written text based code that has multiple functions in one text file. A long time ago there were a lot of problems with corruption of LLBs, it was a pain. Then people started using SCC packages with LabVIEW and everyone said to move to directories and single VIs since the SCC tools couldn't handle it any other way. To me that is a fault of SCC, not LabVIEW LLBs. Professional LabVIEW should have it's own SCC that handles LLBs. Look in the \example or \project or \vi.lib or ... (you get the idea) directories and note how much of the code that ships in LabVIEW is in LLBs. If LLBs were so bad why are they not already split out into subdirectories? LLBs are convenient, compact, and I personally cannot remember the last time I had an LLB corruption problem. Just, my opinion, YMMV PS: If Windows Explorer can be given an extension that lets it look inside LLB's why not an SCC?

Very good idea. Regarding my ConPane Constant and the graphic. Although I made it (in part) to get rid of the need for the big graphic of the panes I think you might want to leave the graphic in your examples as a teaching tool and also include another one from the forums here that also shows the pattern order of the conpane terminals. Can't seem to find it right now. Also you might want to include mballa's Picture Ring Control that also does the connector pattersn. That post is: here

We're not fanatical, we're just enthusiastic On another SCC note, gmart, can you comment on SCC with VIs inside of LLB's? Thanks.

Another good use for all this is if you have a LabVIEW application running as a Windows Service, completely invisible. Then you have another VI that starts up and minimizes itself to the System Tray and provides a monitor-interface to the LabVIEW Service Application. What is the advantage to all this you ask? Security. You can have your LabVIEW Service application run at computer startup, but setup the user login so that you have to hit Ctrl-Alt-Del to login. This lets you set up a secure LabVIEW app as a network service available just by turning the machine on, but hidden behind password security that no one has to login to before use, just flip the on switch, even remotely. :beer:

The machine I'm on only has 7.1 so I'll convert to 7.0 and 8.x later and substitute & add. Fine by me if you want to combine, but might I suggest that we consider moving/copying all this into the code repository later. One last note, your tutorial is great, but lets all keep the real goal in mind, which many of us have stated over and over: we want to end up with something that can eventually convert a VI to text and then recreate it from that text. Then again, I'm not sure how much work we want to put into this, I'd be pretty surprised if NI doesn't already have this in-house. Be a bummer to put in all the work and then have NI release it. Then again, NI might not release ... What do the rest of you think?

Hmmm, I can see maybe using the original express version at the start of the thread as a temporary way to make a wire label. Change the VI icon to be a short black wire with "label" instead of "same" and then use the caption as the wire label. Unfortunately we wtill have the problem that if we move the wire the VI stays in the same place until manually moved. Sigh, when are we getting real wire labels. Oopps .. almost forgot, Great Job ! to both Aitor and nrao !

Howdy taurus, welcome aboard. Wish I could have been there this year to meet, but I missed it again. Maybe next year. How long have you been using LabVIEW and what do you use it for? Cheers

:worship: Hey Chris, great examples! I heartily agree with the kudos others have been giving as well as the ideas for more. As a small incremental addition I came up with two small items to make the connector pane selection a little more intuitive and get rid of the need for the big graphic of the connector panes. This is a Connector Pane constant. The VI is below. If you add it into your paletes with the VI set with the merge option you will get the constant on your diagram. Click on the constant and you'll get the pattern menu as shown: (LV 7.1) Unfortunately the constant only goes from 0-35, so we need to add 4800 to the number as shown, so I made another simple VI to do that. Both VIs are in LabVIEW 7.1 Download File:post-45-1161803666.vi Download File:post-45-1161803706.vi Cheers

Not a common bug, but I was glad to notice and read your post JP. I've done a fair amount of this kind of closed dynamic VI programming and have never run into this error, but I'm sure I'll remember this if I do see it in the future. Your post may have saved a PC

If I had to pick one or the other, I'd take the poster, but I'd really like both. I'll give you some more detailed feedback on the pocket-&-poster details after I ponder it a bit. As for the consultant, I would also think you should have "Alliance Member" as a choice, as there are a few of us around ...

This is what scripting is really for. This is not only a challenge, it's important. The text-to-labview function is the important part. It needs to be written from an intermediate P language, so that various types of text can be converted to the P language and thence to LabVIEW. Now THAT would be useful.

If you are going to use VSS, especially if you do it over the net, I would recommend Source OffSite by SourceGear It protects the VSS database from corruption by the client, is MUCH faster than VSS's own net ttool(s) and IMHO has a better user interface. I'd rather see you try to use SVN and TortoiseSVN. Much cheaper, :thumbup: free online doc's book , several of the better LV programmers in the country are using it.

These are all nice. Since there are still a lot of people and projects using LabVIEW 7.1, it might be nice to repost in 7.x.

Not directly, that I am aware of. It might be possible to do this indirectly. Read out the case strings, use that to create yet another, new CASE, and then substitute for the old CASE.

No, but there are several reasons for wanting to have this ability. A current one that I am running into is declassification and reuse of LabVIEW code that was developed on a DoD classified computer system. Now for text based languages you can print out the code or look at it with a text editor and verify that there are no classified numbers or information, but currently with LabVIEW this is impossible. There are a few software tools that exist that can automate this process for text based code, but non (that I am aware of) that can do this for LabVIEW. If we could convert VIs to XML, we could run the XML through one of these tools and then convert back to LabVIEw, or at least allow the code to be released.

Yep, plays great now. This is a scream. Although I'm not sure which I like best, this one or theCarlton: "It's Really Big" commercial from Down Under. Anyone remember where that one was? Just found it, or at least one place where it is. A classic.

Thanks for the quick reply post. I'm low on my coffee quotient and wired the n through the True case instead of hardcoding the 1 constant. I also forgot the reentrant setting. Works like a champ now. I'm going to take it and play with a few other examples, like getting the tree of a directory path with subdirectories. I'm also thnking of trying it for some XML parsing, etc. Good Job Adam! This should be cross referenced with some of the other topics on recursion. I had posted one using VI server some while back. Your XNode does this much better. Hmmm, we need to combine this with GOOP somehow, I can see some interesting possibilities. :beer: :beer: :beer:

Nice idea. I think your example of factorial might take a second look. Maybe I did something simply wrong, but I built your example, exactly as shown and it returns an answer of 0. Makes sense, you keep subtracting one each time, til you get to zero, then pass out the eventual zero result and multiply. What am I missing here?

Hmmm, maybe it is just my computer, but the embedded player above would not play, but the link below to Google Video worked fine. Funny vid.