JasonKing

QUOTE(xtaldaz @ May 24 2007, 03:13 PM) Why am I facing your wrath? One second you're telling me it's not okay to bring boxers that can't stay above my ankles, and the next you're threatening to send me down the river in nothing but a life preserver? I'm so confused! Anyway, on-topic, my vote is still for Salt Lick. There's something to be said for being able to roll in your own cooler full of adult beverages. J

QUOTE(xtaldaz @ May 23 2007, 02:12 PM) Swimming in a T-shirt is a lot better than swimming in boxer shorts! While many things in Texas may be big, my ###### isn't. I can't wear my LAVA boxers in public without getting arrested for indecent exposure. I want to be a lot of things in life, but a sex offender isn't one of them. However, my girlfriend loves it when I wear them around the house :laugh: J QUOTE(JasonKing @ May 23 2007, 03:13 PM) While many things in Texas may be big, my ###### isn't. Apparently we're kid-friendly in here and I can't say "arse". D'oh. J

QUOTE(crelf @ May 17 2007, 10:27 AM) We'll see. I won't be working with LabVIEW, so I fear I won't have much to contribute. Mayhaps I'll try to convince them to use LabVIEW for their hardware testing, but I don't know enough about their process at the moment to make a pitch. The work I'll likely be doing will be for the UI on touch screens or a desktop configuration application. LabVIEW probably isn't the tool for either of those. I suppose I can just come here and commiserate with the other ex-NI employees who frequent this joint (Crystal, where you at?) :laugh: Thanks for the good wishes. J

I know I haven't been very active here on LAVA as of late, but I've certainly met some of you either at NI Week or at one of the remote Developer Days. Just wanted to give a heads-up that I am leaving NI at the end of next week and moving to a small startup that makes IP-based distributed audio and video systems. So, if you have any beefs with graphs (esp. the Mixed-Signal graph), charts, events, the code disable node, or the LEGO MINDSTORMS NXT software, please direct them elsewhere For those of you coming to Austin for NI Week, I hope to drop in on the LAVA bbq if it's happening, and the 2nd annual unofficial NI-Week bar crawl, assuming I can find someone to take over the organization of this fine, long-standing tradition. J

QUOTE(Omar Mussa @ May 4 2007, 08:21 PM) However, I do think it's techhnically possible to add this feature (a lot has changed since I was actively involved in development of the graph, so it's possible I'm wrong), so I'd suggest submitting a feature request and detailing how you would use the feature/what problem you're trying to solve. It always helps to have concrete use cases to support the desire for a feature, and helps us make sure we get it right. J

QUOTE(TiT @ Mar 8 2007, 06:58 AM) Sometimes looks can be deceiving. I feel sorry for the ferarri driver who pulls up beside this New Beetle at a stoplight: http://hpamotorsports.com/projects_finished_cannonbeetle.htm http://www.motortrend.com/features/perform...kswagen_beetle/ J

Hi, Omar. Thank you for sharing your thoughts. I can certainly see why those bugs were frustrating to you, and certainly I don't expect you to have to (or even be able to) work around them. It does sound like some of your frustrations are due to not being able to find an (easy) way to get the graph to do what you wanted it to, which is partially a function of wanting to do things with it that we don't intend to be possible. That doesn't mean they aren't valid suggestions of features to add, but I don't necessarily see it as a failing of the control itself (of course I expect you to disagree with this QUOTE(Omar Mussa @ Mar 12 2007, 11:25 AM) I think you make a valid point. I am certainly familiar with the need to customize the look and layout of controls in LV front panels. However, I do think it's unrealistic to expect us at NI to forsee all the customization options that you feel are necessary. Remember that our requirements and intended use cases may not include what you would like to use it for. That may be partially due to an oversight on our part, but it might also be by design due to a compromise of function over ease of use or even implementation. Regardless, this gap between the product we deliver and the product you would like can be closed with some simple feedback. We obviously have some feedback now (though not a list of specific properties and methods you'd like to allow the customization you would like - can you provide one?), and can try to incorporate that into the feature in future releases of LabVIEW. An alternative is to get involved in the beta process and have a chance to get the feedback to us sooner (in this case we could have gotten the feedback during the 8.0 beta and hopefully added the properties and methods for that release). QUOTE(Omar Mussa @ Mar 12 2007, 11:25 AM) The MSG is an example of a graph whose best features have no API or at best an obscure one that is not well conveyed - so most users will go to great lengths to integrate a different graph (like the XY graph) with a richer API so that they can get the desired user experience. Again, any specifics you can provide will be greatly appreciated. I assure you we do what we can to take all of our users into consideration when designing new features and choosing what properties and methods to expose to allow users to get the most possible out of their use. As one who "owned" the code behind the graphs for many years, I'm very aware that we have users that rely on the ability to customize the look and layout programmatically, as well as demand high performance at the same time. It is frustrating to hear feedback that the "1.0" version of this control was not sufficient to meet your needs, but I do hope that some users are able to get some benefit out of it, and hope that we can address your needs in the future. J EDIT: Omar, I re-read your initial post and see that you filed a few CARs and some product suggestions as well. Thank you for doing that. If you don't mind duplicating your time, listing the desired features (props & methods, primarily) plus use cases, that'd be helpful. Thanks.

Hi, Ton. I can't say I fully understand your complaints. What makes it feel like an "express picture control"? What do you mean by "I need the properties and methods alike the developer experiences the control"? I'm not challenging those statements, I just don't understand them so I'm not sure how to respond, or how we can make the documentation better to address these issues. In short, the mixed-signal graph is intended to allow you to put both digital and analog data on the same graph, sharing an X-scale. I've seen many VIs where users have two separate graphs and have to write a bunch of diagram code to keep the X scales in sync because the data shares the same time axis. This graph should be make life easier for this type of user. Additionally, it does function a bit like an "express" graph because it accepts XY, Waveform, or digital data. This wasn't really the intention when we started out, but it was a nice result of all the other work that had to be done. It's not really meant to be an improved waveform or XY graph, other than it allows one to overlay other types of data with it, and you can use one cursor (a multi-plot cursor) to track values across multiple plots. Anyway, I'm sure you can see what the graph is *meant* to do, but perhaps it fails in that regard. I'd certainly like to understand how it fails, and what we can do to fix that. If it's as simple as beefing up the documentation, that's good news Thanks. J

Hi, Omar. I'm the developer responsible for most of the MSG code. I apologize for the problems you've run into, but they don't sound *that* bad to me. That's not to say they're not a nuisance - certainly they are. But without knowing what you're trying to do with the graph, it doesn't sound like it's unusable. I'd be very curious to see/hear what you are using it for. I've often wondered why I didn't hear much about people using the MSG. Is it too buggy? Do people just not know about it? Etc. Unfortunately I am no longer working on it (and thus don't get the bug reports), but I'd certainly love to hear any feedback and will do what I can to steer things into a more useable direction, as I put a lot of effort into that beast. Regarding adding and removing plot areas via VI Server. For technical reasons, we can't do that while the VI is running, but as a "Scripting" feature such a thing would be possible. Going forward, hopefully those technical reasons can be removed. J

Yes, you are correct. Overall, likely less work is done to draw the transparent graph on top of a picture control rather than the graph+picture control if you are regularly updating the data in the graph (and not the picture control). If both are being updated, then approximately the same amount of work is being done. No, what I'm saying has nothing to do with control vs indicator. Given a control or indicator that has another object on top of it, whenever that control/indicator gets a new value there is a penalty to being redrawn, as we must not only redraw the control/indicator with the updated value, but the object on top of it as well. If instead the control/indicator is on top of another object, when the control/indicator gets an updated value we must only re-draw it, as re-drawing it does not affect the object below it. Transparency really isn't a factor in this issue. J

Your memory serves you correctly regarding which implementation is which (I've attached a screenshot of the diagram to this post). As far as your conclusion...I suppose it depends on what you mean by "efficient". I would summarize it this way: using the transparent graph on top of a picture control does not require a redraw of the picture control every time the graph is updated. However, when using the bgimage of the graph, every time the graph gets redrawn (with new data, etc), the picture must be re-rendered from the picture string (we don't even cache the picture image like we do in a picture control - I'm not sure why we chose to implement it this way as it's inefficient). There's still some quirkiness in the timings I can't figure out if synchronous display is not turned on for the graphs, but it shouldn't invalidate the statement above. The main benefit to the built-in picture properties of the graph really shouldn't be looked at from a performance perspective, but rather that it makes it easier for one to align the picture with the actual data points of the graph. Does that all make sense? J And another note, regarding overlaying controls. It's one thing if the graph is transparent and placed over a control. It's a whole different issue if a control is placed on top of the graph. Any object that has another object on top of it is forced to redraw inefficiently, as we must ensure that we draw back to front. J

It turns out I was wrong in a couple of my assertions above. To clarify: 1) In any timings, the cost to draw the picture control in the first implementation will not be timed. Because the picture control is overlapped by the graph, we will not draw immediately and instead will invalidate our bounds to make sure we re-draw with the new value in the correct z-plane order. 2) Writing any of the plotimages properties of the graph will not cause an immediate draw of the picture data/graph (instead we just invalidate and come back and redraw later). As such, the cost of this call is simply the VI Server overhead and the time to copy over the new picture string. Thus, in neither implementation is the cost of drawing the picture taken into account, except as described in #3. 3) When we draw the graph in the second implementation, we are also forced to re-draw the picture data as well. Thus, the time to update the data of the picture control will include both drawing the plots as well as the picture data. This explains why implementation #1 appears faster than implementation #2. The drawing of the picture data is not measured in #1 (there really is no way other than to pull the graph off of the picture control to ensure we draw immediately). This explains why #1 appears to be faster than #2. J

Gary: Your timings aren't really making a fair comparison. There are a few things to note. 1) The time to write a value to a terminal does not include the time to actually draw the updated value, unless you have Synchronous Display turned on. Try your timings with sync display on and off for the graphs, and see how the timings change. 2) Writing a value to a control's terminal is considerably different from writing the value property. Not only is there the overhead of the VI server call (which in most cases requires a switch to the UI thread), but the call does not return until the control/indicator draws with the new value. Thus, the two calls are not equivilent if you are trying to time them and compare the efficiency. Therefore, in the first case you are not including the time to actually draw the picture control, while in the second you are. 3) In both of your loops, there is a race condition between when the picture gets updated and when the data does. While in the first case, the graph will get invalidated every time the picture gets a new value, in the second case, the graph almost certainly redraws itself every time the background image gets updated. This means that, in both cases, we may draw the data twice for a given iteration if the value is written and then the picture gets updated. I believe over the course of many iterations this should average out, this is another inconsistency that can remove a bit of confidence in comparison of the timings. In summary, I don't think your timings are accurate. Now, it may still be the case that the first implementation is faster, but I highly doubt it's by the factor that you see. Okay, I got over my laziness. If you turn on synchronous display for both the graphs and the picture control, you'll see that #1 is about twice as fast as #2. I don't think this should be the case - chances are we're just being stupid somewhere in the drawing code - but it's certainly a more fair comparison than what you initially discussed. If you change the first implemtation to use a property node for value rather than the terminal (to remove the discrepancy in VI server overhead), you'll see that it takes about 1/3 as long. I cannot explain why this speeds things up, but it's still not as bad as the original numbers you quote. It does look like the picture control is a bit smaller than the graph, so you're drawing a little bit less, but I can't see that explaining the difference. Again, I'm not sure why the built-in option is slower, but at least it's not as bad as you thought J

Do you not think the conditional compile (ifdef) node does? Being able to inline your debugging or profiling code and not having to worry about it getting compiled in a release build, and not having to modify any source code to turn it off or on? I don't know if you were at NI Week and saw any of the sessions on the LEGO Mindstorms software, but for that product we created a native HTML control using the Mozilla gecko rendering engine. It's not in LabVIEW proper yet (still has quite a bit of work to get there), but my hope is that we can not only render remote and local HTML pages, but also use the engine for rich formatting of text using HTML tags. We're continually working to improve LabVIEW for many different types of users - enhancing performance of existing features, making things easier to use for new users, as well as adding features for the advanced users like many of you here. I think to say that the new features in 8.0+ are not useful is a bit harsh, however I can totally understand feeling that they are not useful to you. You've had this ability for a while. Custom probes allow you to create custom behavior like this quite easily. J

Nope, there's not. I agree it would be nice if you could do something like use an unbundler, but the event registration refnum represents something fundamentally different from the user-defined events. J

Thanks, Jim. I'll have to check it out when our copy comes in from Amazon. It's good to know someone has looked at it. I was really just being sarcastic with my comments above. I hope the feature is useful to some people, but if not, eh, no biggie J

I think you left out another 8.0 feature no one talks about: The Mixed-Signal graph. Does anyone use this thing? Sigh. My work is so un-appreciated :headbang: J

No, I did not work on the toolkit. That was/is being done by an intern named Chris Koci and Brady Duggan who was instrumental in the development of the Mindstorms NXT software as well. I personally worked on the editing environment/desktop software application that ships with the Mindstorms NXT kit. I wasn't actively involved in the development of the firmware, VM, or any of that mechanism, so I really can't speak much about it. I doubt that much of the work we did is generalized enough for a generic module for that specific processor. It certainly showed that we can build a VM to run on such a chip and compile to an intermediate language that it can interpret. The implications of this as far as NI's product lineup, I really can't say. I'm not involved in that aspect of things. J

I'm glad to see there's a sub-forum for the Mindstorms product. It'd be great to hear comments from the LabVIEW community regarding the programming environment/language that ships with the Mindstorms NXT kit. The folks who post here don't seem to hold any punches, so I'm sure they'll pop up and I look forward to reading them (so long as they're positive . J

You are correct. Property nodes require a switch to the UI thread. Local variables do not. As a result, locals should be faster. I just skimmed the liniked article, but this fact didn't appear to be mentioned in there. J

Nope, I mean Apple. Apple usually has space on the exposition floor, and my understanding is that they will be selling Mindstorms kits down there. J

The only place in Austin that seems to have them right now is Target and Fry's. However, Apple should be selling them at NI Week on the exposition floor. J

Guillaume, how is it you see that LabVIEW has(or had) the potential to change the world in a way that JAVA doesn't? I think this is a core element of your position that I do not understand. J

I do agree that "graphical programming" is a general paradigm, just as text-based programming is one. However, what is meant by a high-performance language? What would you consider a high-performance textual language? Does it depend on the power of the exposed APIs? On speed? Memory usage? Efficiency of the compiler and the optimizations it makes? I think we're still talking in unqualified generalizations here. I certainly agree that many programmers are not aware of graphical programming, and many who are quickly write it off as not being "powerful" enough. Very few can articulate what they think is missing, though. While I agree that LabVIEW is targeted for measurement/automation/data-acquisition, I would argue that it is a very good tool outside of this realm. The language itself isn't necessarily geared towards these applications, but certainly the libraries of functions that ship with LabVIEW target these kinds of applications (analagous to a string-parsing library or the STL libraries that ship with most C++ compilers). This discussion has also been had several times, but I would also argue that LabVIEW/G serves quite well as a general-purpose graphical programming language. Sure, it doesn't currently allow for recursion, but I don't think that undermines my assertion. Some may point out the lack of Objects ala C++ and Java, but C doesn't have such things yet it's considered a general-purpose programming language. An important fact to note is that not only is LabVIEW/G graphical, but it's also data-flow based. I don't know that this is a necessary characteristic of graphical programming languages. This may be a factor influencing the general adoption of LabVIEW/G. The software environment shipping with LEGO Mindstorms NXT was written in G. Is that a "must-have" app? If you go to "the Good, Bad, and Ugly" presentation given by Greg McKaskle and Christina Rogers at NI Week this year you'll even be able to see the source code. I have no basis to make or dispute claims about the profitability of the compiler business now or back in the 80s and 90s. I think you raise an important point, though - for NI, the margins and profitability were there for what they were selling. This is pure speculation, but I doubt it made business sense to them to break the language apart from the application - the editing environment, compiler, and all the libraries geared towards test & measurement. If NI had invested the energy and money into that, perhaps LabVIEW wouldn't be the tool that it is today, and wouldn't be as compelling a software tool. Of course we can speculate to no end on this topic. While I am not a professional LabVIEW user, I personally don't think the value of LabVIEW/G really lies in its graphical nature. I think it is a combination of the built-in libraries, the real-time syntax checking, the performance afforded due to data-flow programming, and the fact that its users can focus on the functionality they are trying to accomplish rather than get bogged down in syntax details. Most of these are not related to the graphical nature of LabVIEW, aside from the benefits gleaned from it being a data-flow language (I haven't thought about it long, but I doubt such a paradigm is possible in a textual language). Another reason users are successful with LabVIEW is the built-in/automatic multithreading. Data-flow makes it relatively easy to detect data dependencies and thus schedule parallel execution in multiple threads, but this would also be possible in a textual programming environment. It just so happens that the LabVIEW compiler does this. It wouldn't naturally be part of any standard specification of a graphical language. At a very basic level, what is it you all see that makes graphical programming superior to a textual language? Jason

I am not attempting to step in and represent NI here, as this topic comes up regularly and I'm not qualified to speak for NI anyhow, but how exactly would 'G' be generating revenue on it's own? As far as I understand, compiler makers don't buy a license for C or C++. Nor to the makers of text editors. So who would be paying the money to NI and why? NI makes its money by selling software and hardware. I don't see how having 'G' be independent from LabVIEW or NI would enable greater sales of either of these things. Am I misunderstanding your comments? Do a google search for "graphical programming language -LabVIEW" and you'll see that there are plenty of graphical programming languages out there. LabVIEW/G just happens to be one the most popular. I think that one would have a hard time coming up with a "standard" graphical programming language, just as one would with a standard text-based language. There is a reason so many languages exist - they excel in different situations. A programming language is just a tool and no one tool can be the perfect one for every situation (though the "spork" comes pretty close as far as food consumption is concerned). That's why people use scripting languages for text/file parsing and manipulation but not for large application development. I think it is unrealistic to think any kind of standard could be established. J