lavezza
-
Posts
57 -
Joined
-
Last visited
-
Days Won
9
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by lavezza
-
-
QUOTE(yen @ Jul 18 2007, 02:12 PM)
I would have to claim
as well, but I'm guessing NI will demo\announce the next version of LV at NIWeek, and I wouldn't be surprised if they will also demo this toolkit. That means you should probably have your answers in about three weeks. 
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)
No, there is no trial version of LabVIEW for Linux (or Mac OS X).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.
-
And if he breaks the functionality of the library somehow that is also his problem really.
Rolf Kalbermatter
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
-
Please correct me if I'm wrong, but I think LabVIEW can only work with 1 (one) Network Interface Card. So creating a bridge between two networks never work with LabVIEW
Ton
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
-
I do not know if you can run Windows directly on any Mac, Intel based included. I think you can only run Windows through Virtual PC or Parallels. I have heard that NI-488.2 can run though Parallels, but have not confirmed it. I do know that NI-DAQmx will not run through Virtual PC. If you can run Windows directly on a Mac, and not use OS X at all, please let me know. Maybe I have the wrong assumption.
John Ridpath
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
-
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.
-
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
-
Nice Idea, with a slight drawback: It makes your code not easier to read. Looking to this code after a few months might get quite painful, because you don't remember which controls are assigned to the property node. Having to double-click on it, check on the frontpanel which controls were selected, go back to diagram and repeat the process for the next property node seems IMHO not really helpful.
Didier
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.
-
Hey, Pat: you look very familiar (
). Have we met?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
-
Hi, I want to create a VI that performs matrix multiplication for two input matrices A and B. The matrix A is an n x m matrix and matrix B is an m x p matrix. I want to create the VI without using the AxB.vi in labview. Anyone can help please? :!:
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.
-
Dear all,I wonder If the VI can creat a new VI when it is running.Just like the form creat new form(IN Visual Basic). Though,I know that VB is OO but LV is not.
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
UML Statechart Diagrams
in Development Environment (IDE)
Posted
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:
Some of these might not be new (NI DataFinder Server Edition?), but some are leaks.