lavezza

Actually, I just looked around the NIWeek website and I noticed they list the Alliance Day sessions. I don't remember them doing that in years past. Maybe I'm wrong. Anyway, there are some tidbits in there that someone probably wasn't supposed to post yet. Since it's out there for anyone to see, here are some highlights: "Test-drive the new features in the upcoming release of LabVIEW" "new features in the Digital Waveform Editor " "Learn how to architect a LabVIEW application with the shared variable, and find out how new features in the next edition of LabVIEW introduce new reliability" "Examine the technology behind NI DataFinder Server Edition" "The day has finally come - LabVIEW Real-Time now supports multicore PXI and PC targets. We will also review new features including the new LabVIEW Real-Time Execution Trace Toolkit, improved file system, and faster shared variables." [new LV Real-Time usually means new LV] "Learn about the newly released CompactRIO systems that feature an integrated RT controller and FPGA chassis along with a lower cost for high-volume applications." "NI is now selling motors! Learn how you and your customers can select the right NI stepper motor and drive using a free interactive software utility" "Simplify complex applications with the new LabVIEW Statechart Module, a new development tool that provides a high level of abstraction for designing applications using states, transitions, and events. Deploy applications built using the module to all LabVIEW targets." Some of these might not be new (NI DataFinder Server Edition?), but some are leaks.

QUOTE(yen @ Jul 18 2007, 02:12 PM) There is a Technical Session at NIWeek (TS1686) on Tuesday at 3:30. Title: "State-Based Programming from Desktop to FPGA with LabVIEW" Abstract: "State-based programming is popular in the manufacturing, energy, automotive, and aerospace industries. Explore statechart topics such as hierarchy, concurrency, events, and the UML statechart specification. Also discuss the use of LabVIEW and statecharts for various applications and hardware – from desktop user interfaces to FPGA control logic." Of course, this doesn't come out and say there is a new toolkit being released. But if you think there is a beta for such a toolkit...

Some coworkers and I went to the Developer Education Day here in Phoenix. I didn't stay for the "Performance Optimization for Embedded LabVIEW Applications" discussion, but they did say that required inputs can reduce memory allocations. There isn't much info in the slides, but you can see them here: ftp://ftp.ni.com/pub/events/labview_dev_e...ced_labview.pdf I get the impression that this applies to all versions of LabVIEW, not just embedded. See slide #30. I think what they were saying (based on a email from a coworker that did see the presentation) is that LabVIEW needs to set aside memory for the default values of recommended/optional inputs. It might not need to do this for required inputs if the "inplaceness" algorithm determines that a copy doesn't need to be made. If so, the subVI can use the same memory that was allocated in the calling VI. I'm thinking Jeff's results could be one of three things: 1) The "inplaceness" algorithm determined that his subVI needed a copy, in which case memory has to be set aside regardless of required/recommended/optional settings. 2) When building an executable, LabVIEW does additional optimization and gets rid of any memory allocations for default values of inputs that are wired. 3) The slides above only apply to embedded. Of course, it could be that the slides are wrong. Or maybe they apply to versions of LV that aren't released and the presenter didn't realize that. Wouldn't be the first time that a NI employee said something only to come back and say something like, "Sorry, I'm using an alpha copy of LV9. What I said doesn't apply right now." Pat

QUOTE(Jim Kring @ May 16 2007, 11:50 AM) I'm assuming this is because the Linux and Mac OS X versions of LabVIEW don't use the licensing mechanism that was introduced with LabVIEW 8 for Windows. Since LV8, the fuctionality of LV on Windows is tied to the license that is installed. No license = trial version. Without the licensing mechanism, NI would have to create special versions of LV for Linux and Mac that were time/feature limited. So, does anyone know if the licensing stuff is coming to Linux and Mac? You know, I think it's been a while since we've had a good licensing brouhaha. Multiple machine debugging, VISA serial distribution, forced toolkit upgrades, "Authorized Applications"! Who's with me?

QUOTE(Val Brown @ Apr 12 2007, 08:19 PM) First, you only need to run simulation.msi if you installed 8.2.1 over 8.2. If you uninstalled 8.2 first (or never had it installed), you won't need to run simulation.msi. Second, not running simulation.msi won't stop 8.2.1 from running. Only certain functions are affected. See http://digital.ni.com/public.nsf/allkb/C4B6EF55C6948A27862572B30068BF91' target="_blank">Installing LabVIEW 8.2.1 On Top of LabVIEW 8.2 Causes Broken VIs and Libraries I ran simulation.msi from "C:\National Instruments Downloads\LabVIEW\8.2.1\Products\LabVIEW_Simulation_Core_Shared\simulation.msi" which is the directory that gets created when you run LabVIEW_821.exe.

My group switched divisions in our company on January 1st. It looks like one of the things that got screwed up during the transfer was our SSP. It has lapsed. Well, there are bug fixes in 8.2.1 that we really need so I downloaded the installer and installed it. Remember, there is no difference between the evaluation installer and the regular installer now, features activate based on the license. Basically, as far as NI License Manager is concerned 8.2.1 = 8.2. Which is what we are used to with NI bug fixes. The install went fine (make sure to do the simulation.msi fix if installing over 8.2). It sounds like your rep is just as confused as the rest of us. You'll need an SSP if you want NI to ship you a CD. But if you have a valid 8.2 license, with or without a valid SSP, you can still get the 8.2.1 bug fixes by running the installer. Now, 8.5 will be another story. ftp://ftp.ni.com/evaluation/labview/pc/labview_821.exe

I'm not so sure. Our software is sold with support. We make sure we have restrictions as to what we will and won't support. So, if a user decides to upgrade from XP to Vista and stuff stops working, that's his problem. If we use LGPL code, we have to give the user the right to modify the LGPL part, correct? I'm not so sure we could use LGPL code and then add wording to our license that basically says "but you can't REALLY change the code". OK, legally maybe you might be able to do that, but it really defeats the purpose of the LGPL. The idea that we have to support a project that the end user has a right to change doesn't sit well with us. Even if our concerns are misplaced, the very fact that we have these concerns stops us from using LGPL code. The BSD license, on the other hand, is simple enough for even me to understand. Add a few sentences to our license and about box and we are good to go. Pat

Ok, I had a long reply but I lost it when I closed this window by accident. :headbang: Short comment: I use LabVIEW 7.1.1 on a machine with two network cards to connect a test LAN with a corporate LAN, just like jlokanis. We aren't using VI server, just raw strings over TCP. Maybe the problem is with VI server specifically. Now, our two cards have IP addresses that don't "overlap". In other words, one is a 10.x.x.x number and the other is a 192.168.x.x number. So if I try to connect to 192.168.1.44, there is only one card this will work on. I'm not sure what happens if you are trying to use an address that is valid for both cards. So, I don't pick which card to send stuff on and I'm not sure how LabVIEW decides (or maybe the decision is passed down to Windows?), but it works for us. Pat

You can run Windows on Intel Macs using Apple's Bootcamp program. Basically, it gives you Windows XP drivers for Apple hardware, partitions your hard drive (so you have somewhere to put Windows) and gives you a boot menu to select whether to launch MacOS X or Windows XP. Bootcamp is beta software until Leopard (next version of MacOS) is released in Spring 2007, but many people are using it. So yes, you can buy a Mac and use it exclusively as a Windows machine.

In 'Convert Unicode to ASCII.vi', I don't think the increment should be there. Feeding the results of 'Convert ASCII to Unicode.vi' into 'Convert Unicode to ASCII.vi' should give back the original string. Pat Lavezza

Here's my solution. Using a state machine give you that ability to add additional states fairly easily (like the Update Status state I added after I was finished) or redo a state (maybe you want to ask the user what to do if the Delete Files state fails) Pat Download File:post-192-1153361997.zip

OK, this is off-topic from the original post but it has to do with right-click options for primitives. There is one that has been in there for a while that just recently bit one of our new programmers. He was using the Array-to-Cluster primitive. By coincidence it was an array with 9 values and everything worked fine. When he needed to expand it to 10 values he couldn't figure out what was wrong. The array had 10 values and the cluster was expanded to have 10 values but there were broken wires. Of course, you need to set the cluster size by right-clicking on the Array-to-Cluster primitive. There are others as well. I've seen new programmers that need to compare arrays not realize that you can set the comparison mode to "Compare Aggregates". Maybe some of these primitives could get visual indicators (small ones!) that indicate their state. Pat

I don't know how to fix the horz. scroll you want, but here is a tip for those who don't know. You can turn the auto-tool on by pressing Shift-Tab. It will go to the grabby hand. You can Shift-Tab back out of auto-tool when done. Pat

My suggestion is to really think about how you want the code orgainized before the project gets too big to change it. I think this is one area where programmers don't spend enough time coming up with a good solution. Our program isn't organized very well and it is a real pain. We basically have a common app framework with specific code developed for each project. Until recently, project code and common code were mixed together. It was a real nightmare to split them apart. We now have a common hierarchy of 356 nested folders containing 6913 files (VI's and perl scripts). The project I'm working on has a project hierarchy of 198 nested folders with 2063 files. As you can imagine, this would be hard to digest even if the orgainization was perfect. So, as your project gets bigger, if you realize your file structure isn't scaling well, fix it right away. Pat

Joe, I was being sloppy. It was working on my PC, so I didn't bother cleaning it up. Basically, we're telling the DLL the we are passing in a pointer to a string that is a certain length. Problem is, I wasn't actually passing in a string. I thought LabVIEW was taking care of it for me, but I guess I was just getting lucky. Here is a new version that should work. Download File:post-192-1141769510.vi

Here is another KERNEL32.dll call that Rolf Kalbermatter pointed out. Download File:post-192-1141750763.vi Pat

Here are some other ways. First, the system-wide environment variables are stored in the registry, so you can use the registry VIs that come with LabVIEW to get and set them. Here is a simple example to get all the environment variables. Download File:post-192-1141691097.vi When an application is running, it can also set environment variables, but the changes are only for that instance of that application. You can get and set these application specific variables using these two VIs (which make calls to Kernel32.dll). Why would this be useful? Imagine you have a LabVIEW program that relies on Perl. Instead of calling "c:\Perl\bin\perl.exe script.pl", you'd rather just use "perl script.pl". This will work if "c:\Perl\bin" is part of the PATH environment variable. If you don't (or can't) change the registry settings (user doesn't have permission, security mandate, etc), then you can change the application environment variable each time you start the application up. Download File:post-192-1141691193.viDownload File:post-192-1141691210.vi Pat

If this is a problem you face often, you might be able to write your own Mass Compile GUI. I would: 1) rename the top-level directory (Project -> #Project#) 2) create a new Project folder 3) Recursively move folders and files from #Project# to Project, but leave out the .svn folders 4) Do a mass compile with an Application Invoke node pointing to Project 5) ?? Move the .svn folders to Project (will SVN rebuid those folders? I don't know. I used SVN at my old job, but haven't played with it in over a year) 6) Delete #Project# I think this would work. SVN would see all your VIs as being changed, but that happens no matter what. Pat

How about something like this: Select a bunch of controls/indicators and select Create Shared Property Node. The node can grow down to add more properties or grow up to add more controls (which would need to be selected using the Link To context menu). In fact, a Shared Property Node with only one control is just a regular property node so maybe this is just made the default.

I see you've noticed my limited edition Jeff Kodosky halloween mask. I will occasionally put it on and walk around the Mopac buildings shouting things like: "Why the HELL is scripting taking longer to ship than undo!?!" "Urs interupted my dinner again last night, would someone please work on the Mac version!" "LabWindows! I wasn't serious, it was just a joke and James ran with it." "Don't you ever mention Mathworks to me again!" "Let's re-write it all in Lisp" and, my favorite "Greg McKaskle, put your damn pants back on!" Pat

What I have done in the past is put a free label where I want a comment, but only put in a number (1, 2, etc.). Below all my code I have a very large free label with a numbered list of comments. This allows the code to be fairly compact but still fully commented. It might not work for everyone, but it works for me. Pat

Be advised that you will need either: 1) LabVIEW Professional or 2) LabVIEW Base/Full with the Application Builder add-on LabVIEW Base or Full by themselves can not build .exe or .dll Pat

I'm not sure I understand the problem. These VI's seem to work just as I would expect them to. I'm not having any problems. Which version on LabVIEW are you using? I noticed it isn't 7.1.1. Maybe that is the problem. Pat

Is there something wrong with A x B.vi? LabVIEW 8 has a built in matrix type. I don't know if that will clear up any issues you have with the current vis.

William, You can also use LabVIEW Templates. Basically, they are just LabVIEW VI's with a *.vit extension instead of *.vi. LabVIEW can use this template to make multiple copies of a VI at runtime. Pat