brent99

Definitely a couple cool things in here. No doubt in my mind - that cleanup diagram is the runaway winner! I wish it would condense the wasted space in case statements though, and a "fix all vis" function would be fine for me (although I suspect someone will dummy up a tool to do that soon enough). I also had one of my large VIs choke on it, for no apparent reason. This particular VI needed nearly 4GB of memory to clean up. Oddly, other VIs of comparable size and complexity cleaned up in a matter of seconds. Go figure??? Gotta love that "wire through" feature too, easily one of the worst things in labview in my mind. Having to wire every freakin local variable through a case structure was the worst. The "cool but not necessarily something I'll ever use" awards go to the html feature that allows non-labview clientside interaction and possibly that wireless feature. Anyway, seems like everything upgraded ok and I cleaned up most of my legacy diagrams. Enough to make me want to renew my SSP.

QUOTE(PJM_labview @ Feb 25 2008, 06:42 PM) Or put in the context of my issue.... This would solve the "problem" if you could create an installer that installs via the web if the RT X.X runtime engine has not yet been installed!!!! Great idea.

QUOTE(REM1 @ Feb 25 2008, 11:47 AM) There are other languages besides english?? <sik> Well, there you go, 30MB for language support is a pretty big deal. And I think the browser plugin is somewhat unnecessary, based on my own personal experience having just installed that yesterday. The POINT is that you can't make "hello world" and distribute it to Joe Public (who doesn't have labview 99% of the time) under 10GB anymore, which is not good. And I use 10GB because MOST public email systems will not handle mail files larger than 10GB. In fact, most barely handle ones near 10GB if you are lucky enough to get an attachment to upload properly (works in hotmail, not much else). Looking at Labview as a great way to write simple programs, this is a problem. If you are looking at it for a full heavy weight corporate application, I don't think its such a problem but not everyone looks at labview that way (ducks).

QUOTE(Chris Davis @ Jan 21 2008, 01:37 PM) I saw that, and just assumed that Labview IS written in QT (at least as of v6.0 or so). No?

Yes, the "dead horse" posts are useful because its not just me, which was my question. The point isn't that there is an RTE, but that the RTE grew so dramatically from 7.0 to 8.0 with the main feature being a project manager. WTF? (Ok you could blame the new OO support, but then give us the ability to opt-out since its not a heavily used feature, I imagine) Although, speaking of large RTE, uhmm, isn't Labview compiled to machine language? Its NOT Java running byte code. Is it?

I apologize if I'm beating a dead horse here -- I'm not sure if and how often this has been brought up in the past -- but I'm kind of annoyed at how large the distribution file has become since Labview 7 because of the massive Labview 8 RTE. I used to be able to distribute a complex program at about 8MB or so. Now, even a simple program is taking like 50MB. Am I alone in this or do other people see this problem? You can email an 8MB program, but you have to serve up a 50MB program. It really limits distribution of a simple program to people who don't normally use Labview.

QUOTE(Aristos Queue @ Aug 7 2007, 11:14 AM) Instead of using a while loop that breaks out when the count > x or test=true, you use a for loop of x that can break out early if test = true. Slightly easier on the brain and apparently makes the vi code smaller.

I have a non-graphical COM object I'm trying to use. The object shows up as "creatable" when I try to select it but it only allows me to select one of two Interface files. I can't select the main object itself. When I select an interface file and put it to automation open, I get the "Can not create error 3004". Without creating, its a null reference. Is this a problem in supporting multiple interfaces with a COM object? I'm using 8.0.1. A working VB example refers to MYDevice, but Labview can only select IMYDevice.

I cheated -- used Vmware.

I have a fairly large project and building an exe can take a good 5 minutes or so. I'd be interested in reducing that time if possible. I tried putting a large section of my project into a library using the new project tree, but that did nothing in terms of compile times. I'm not really sure in what way that was useful at all, really. Not so long ago, I recall saving all my vis into an LLB and I believe I could pull from that without recompiling all of the VIs, leading to faster builds (although not sure about that). But these days, the "save all with options" stuff seems to be removed and the current LLB builder seems handicapped. Am I missing a good option here to place 98% of my VIs into a pre-built library, so I can link in 1 rebuilt vi and have the compiler be done quickly? Or is this just the state of LV right now that I got to watch my VIs get rebuilt over and over and over again?

Ha, you suckers that upgraded to 8.20, now what will you do while your coffee is brewing in the morning?

Ah: school on 1200 pounds a year. Nice if you can get it, I suppose. I think my books cost more than that. I think largely the point of NI training is corporate -- it is best for those who have software engineering experience but need to get up to speed in Labview as quickly as humanly possible because their feet are being held to the fire on a new Labview job. Most people with programming experience should be able to get up to speed on Labview with books and online resources that are readily available. I actually skipped the basics and went straight to the Intermediate classes when I was first dunked into Labview. And most of the intermediate stuff, if I recall correctly, is on an Application Builder level that would be outside the financial resources of most students anyway. Don't get me wrong -- your point on mass-propogation through inexpensive training is well-taken. Really, that's up to the NI marketing gurus on where they wish to focus their expansion efforts, and I'd bet that changes radically every year. Microsoft has always given their stuff away (well, practically) to academics in order to get young ones comfortable with the MS tools so they demand them in real jobs when they grow up. I don't know to what degree NI has looked into that strategy.

The doc says that they view the purpose of GOOP as encapuslation and inheritance, but much of the purpose of encapsulation is BECAUSE of pass-by-reference issues. I also found their argument for pass-by-value in standard G interesting, as they argue its to enforce the notion of parallalism which could have two independent processes referencing a variable in a non-standard order. Although, in practice, the problem I find more often is that I'll have globals in my code and have one part of the code update a state boolean global and another part of the code will come AFTER the update, read it, and Labview still hasn't been updated the global yet so it gets the wrong value anyway. This, I find, to be more insidious because I expect the update has occured already even when it hasn't. So these days, when I want to be sure an update has happened, I end up writing to it AND polling it to make sure the readback = the write. Dulp! Perhaps Labview is biting off a bit more than it should chew in GOOP. Incidentally, now that I'm writing about it, I really think this is something that should be fixed...I'm sure someone will say something about semaphores next. <g>

I think you've hit the nail on the head. I think the "pass by reference" issue really is one that should have received attention in the last couple years, because you get some real performance problems when you pass a large data structure between stages of a VI just to get it from VI #1 to VI #7. The workaround is probably to dump it in a global, but now you are really enforcing bad coding style. So hence, my reaction last week about NI managing to implement GOOP before "pass by reference" is a landmark in language devolution. Still, I think we can all see the continued march of G as a very serious development language and platform, rather than a simple prototyping tool.

Probably worth pointing out they added DYNAMIC calling of DLLs too. This is pretty huge, actually. DLLs currently lock up the front panel when you are in the DLL code, so a long DLL or a DLL that waits for another process needs to return control back to the VI or you end up with a frozen screen. Dynamic calling w/ callback should solve this far more efficiently.

I think Labview is now the first language in history to implement object-oriented inheritence before the implementation of "pass by reference" variables. So trying to weed through the extensive "blah blah blah" to get to the meet of the 8.20 improvements. I see: 1. Ability to define and use object-oriented classes (whaaaaa???) 2. Import feature for DLLs and implementation of user-defined callbacks 3. Looks like some sort of improvement to multi-user internet access has evolved, although it seems like I need to watch a 45 minutes presentation on the history of remote access to have a chance to figure out just what they added. Hmmm, some pretty meaty stuff.

I have a follow up to post. After extensive work trying to get this technology working, I still had a few problems. 1. MAC support lacking, which MAC users didn't seem to appreciate 2. While I was able to get multi-user switching to occur and be largely stable, some users still reported that they were getting kicked off 3. The labview server, running on a 486, was pretty sluggish to respond at times 4. Users didn't like downloading and installing the plugin, and the "right-clicking" was awkward 5. Large graphics in the VIs were causing clients to boot I actually found a workable solution to ALL of this. Its pretty "out there" but it works great. What I did was connect to my Windows Labview program using a linux browser. So the Labview program sees 1 connection. Then, I serve up the linux browser (disabled in a "bank client" mode) via VNC. The result? Works on basically all computers No right click switching of users Fast Web Server response Large Graphics "ok" Totally stable Works via internet browser without any special plugin (uses Java wrapper to launch VNC) No licensing limit on the # of users connected (default of 1 for developers now ok) Environment can be contained so that the server is "safe" from the users Anyway, I'm pretty impressed with how this crazy idea worked out, so I thought I'd at least attempt to share it, even though its not the simplest blueprint in the world to follow.

I never claimed it was a GREAT idea, just an idea...

According to the documentation, it transmits the private protocol over port 3015. I'm not sure about duping it out. I think its a serious limitation when dealing with more than one client using this technology, but since NI doesn't seem to have many people appying this technology with multiple clients, it isn't a high priority for them. Its fine for 1 client because you can auto-connect easily. My thought on duping it out is that if you could get the html to continually try and auto-connect every 10 seconds or so, then the server could choose a client by disconnecting clients until the desired client grabs the connection. I'm running my game on a slow server and I noticed last night I have a slow memory leak that tanks the program once it runs out of physical memory. I'm pretty sure the leak is caused by an unclosed reference in a loop that polls for initial connections and can be resolved easily, but that's probably another thing to keep an eye out for.

Thanks for confirming that! Makes sense. Probably something got mucked up when they changed the name between the versions. I imagine it'd be easy to fix it that's the case. Still, without the ability to assign a particular client to the server, it has limited utility to knock somebody off with the lock control. I was originally interested in this control because running the code in debug version, the clients don't always gain control on the first request click. This seems to work fine from an executable, though.

Exactly, and as I noted earlier -- on 8.0 -- I don't see the lock/unlock property controls working at all, so I can't even force a client to release, let alone dole out to a specific client. The controls to request connection referred to in a previous mention would require a seperate client-only program, which is somewhat self-defeating. There are better ways to implement multi-network apps in labview if you are going to have client-only programs. What I liked about this technology is that you can alter the server code and not have the clients download anything new. Some of the keys to remember: 1. Enable the webserver in your ini file (I include it in the project so I don't have to keep updating that line) 2. ALL properties that you call need to be set after a new client connects. Otherwise, you get the DEFAULT property showing in the client. I'm not sure if this includes value and whether the value property node differs from local variable "value". I think value properties are retained but there seem to be some exceptions to that. 3. If the server is too busy, it'll respond poorly to connections. Keep your interval loops short or your intervals long. I implemented a multi-player game that showcases this technology working as well as I can get it to work. All in all, I think it works really great. But it was an uphill battle getting it the clients to have front panels in synch, use pop-out launches, stop dropping clients, have the server be responsive, and rarely blow up browsers (seems to blow up browsers on re-entry without broser restarts), and deal with licensing issues, but I seem to have got these details worked out. Its an adult-targeted college drinking game inspired by Yahtzee: http://www.geocities.com/fsmithgoldberg and you are not allowed to view the game if you think you might have any desire to complain about its existance. While I sometimes wonder conceptually about G and all the little quirks you have with Labview, I can't imagine having implemented such a complicated program in anything else so quickly. Also, I've been told the MAC version works but is unusably slow. Because I make heavy use of pop-ups and I've read they used to not be supported, I'm partially surprised it works at all.

As far as I can tell, this doesn't seem to work programmatically. I have no idea if this is a new problem or not.

I've been working over the web server with remote front panel feature quite a bit this week and have experienced some interesting issues. I'm using 8.0.1 for the record. I have licensing issues but since I'm actively working with NI on resolving these, I'll refrain from commenting. Rest assured, if I did comment, the &%^&*%& keys on my keyboard would be getting quite a workout. The biggest problem I've experienced (aside from the one I'm not commenting on) is that Remote Panel:Lock Control/Unlock Control property of the VI doesn't seem to work at all programmatically. I've tried to exercise this proprety a 1000 ways and it seems to do absolutely nothing. I'm wondering if this could be an 8.0 bug given that they renamed this property recently, but don't have the desire to explore this theory with version 7. The other two properties Client Connections and Close Client Connection seem to work fine. I don't see a way to dictate which client has control when dealing with multiple clients. This is unfortunate because it would be a nice feature. I suppose if you were to edit the html a little to get client VIs to always request connections repeatedly and then have the server unlock connections with the Unlock property (assuming it worked) until the "right" client connected, that would accomplish that task but its a little bit roundabout. There's a "Client has control" message that appears and gets a bit annoying. I'd rather prefer there was just something in the bottom left corner signifying control. (Well, actually there is...haha) I notice when you deploy a web server application, there doesn't seem to be a way to get the ini file to generate with the "WebServer.Enabled=True" property set and i end up manually editting that ini file a lot. I'm sure there is someway to get it to stick but haven't achieved that yet. It wouldn't surprise me if a lot of people had trouble getting this feature to work for this very reason. I have found it possible to "launch" your VI out of the web browser container. For a large VI that takes up most of the screen, this may be desirable. A benefit I see of this approach vs. other remote deployment is that the code is still "server centric", meaning that you can update your code on the server to be accessed through the browser without having to update the clients individually. In fact, that's probably the best argument I see for remote front panels vs. other internet data sharing communication methods that are available through Labview. Anyway, pretty cool feature overall. Doesn't seem like many people have used it too extensively but, although not without its limitations and certainly a pretty bandwidth heavy distributed approach, its certainly a fun and powerful feature of labview. And once you get past the licensing issues and get the general idea of it, its a pretty easy feature to leverage from existing applications. Java eat your heart out? Hmmm....

But it looks like the marketing push for Labwindows in France is really taking off... http://www.google.com/trends?q=labwindows&...eo=all&date=all

I just want to opinion that I disagree a bit about the "overpriced" rant. I've paid for toolkits with 1% of the fraction of Labview that cost over $1,000. The less expensive non-pro version provides a great deal (if not all) of the functionality required for most independent developers. If you want to talk expensive, look at Micro$$$. With their monopoly, you'd think they wouldn't bludgeon you for compiler IDEs that should be free with the OS anyway.