Mike Ashe

From one point of view, this is more of a documentation issue than a bug. The justification seems to work for the entire column. If you place a delay in the loop, you can see it cycle through the various justifications and whatever is last is the one you end up with. Then again, a bug is usually defined as any undesired behavior. If it says "Row" I'd like to see it work for each Row, not just change the doc's to reflect actual behavior. The Multi Column List Box works correctly, allowing you to set justification on a per cell basis.

QUOTE(dsaunders @ Jun 11 2007, 02:06 PM) I agree, the entertainment value has been far to high, in places, to lock off the thread because it has lulled in other places.QUOTE(PaulG. @ Jun 11 2007, 11:07 AM) I'm glad you're only a LV programmer. I'm not going to filter back through all 16 pages of this thread, but ... have we ever seen any evidence of this? Really? This isn't an attack, so don't get your feathers (or scales, or whatever your evolutionary level endows you with...) up I never tune into this channel expecting news and solid reporting, no, this is "Deepak Chopra Debates All Comers Whilst Hosting Saturday Night Live"

QUOTE(Aristos Queue @ Jun 11 2007, 09:30 AM) And it is a good thing that they (we) are not.If Necessity is the Mother of Invention, then Dissatisfaction (with the status quo) is the Father QUOTE In any case, good work, gentlemen. Here, here !! :beer:

QUOTE(yen @ May 31 2007, 03:15 PM) If you search here on LAVA you will indeed find several examples. I like http://forums.lavag.org/index.php?showtopic=2453&view=findpost&p=8374' target="_blank">this one for Menus on Trees (example by Jim Kring).And I've used the technique on a recent project, so I know Jim's example scales up well, with a bit of tinkering. Cheers,

QUOTE(Irene_he @ May 31 2007, 06:25 PM) Very nice product Irene! Low price as well. I had some problems accessing the link above. What is shown in blue is not what the link actually is. It has some other stuff in front. I deleted everything before the normal hytekautomation.com stuff and it worked.

QUOTE(Tomi Maila @ May 31 2007, 02:30 PM) Still a nice tool, and for projects no less. Good work.

The OpenG index works with 2D as well, but not the Conditional (so far).

Haven't been here in a while, but it (he) hasn't changed Alfa, where ever you go, there you are ...

I'm a fan of glass surface acoustic wave (SAW) touchscreens as opposed to resistive, capacitive or infrared. They tend to last longer, are more precise. Look into ELO Touch Technologies and Guide to Choosing a Touch Technology Don't go into sticker shock: 32 Inch Intellitouch wall mount touch screen YMMV

The multi-touch will be nice when we get it in LabVIEW. I am currently experimenting with an ELO SAW touchscreen editing LabVIEW 8.2.1 and getting decent results with the right type of stylus tips. Fingers are a bit clumsy at current resolutions, a stylus tip is much more precise and therefore faster. But I can see where with multi-touch you could use one hand to do a local zoom around your node/terminal, and complete a wiring operation at the same time with the other hand, then release/snap back the zoom to normal and end up with a faster editing workflow than using a mouse. I think/compose/architect better with a pen/stylus in hand than a mouse on the screen.

QUOTE(Aristos Queue @ May 31 2007, 10:26 AM) It used to be that speed/performance was a very valid reason. You could implement the example you give above in G and in a CIN or DLL in C and the performance difference was pretty large. I know that NI has made a lot of optimizations in how LabVIEW handles arrays in recent versions. I was wondering if you have any up to date benchmarks on the relative difference between G and C"whatever the flavor of choice" array performance today?

QUOTE(crelf @ May 30 2007, 01:04 PM) Thanks Chris, maybe I'll use this and get off my butt for releasing that button library.

QUOTE(Ben @ May 31 2007, 10:06 AM) We haven't had a good conspiracy theory for a while now Hmm, at the risk of seeming greedy, I'd like to throw out a third question, or request: At NIWeek there has been the practice of "Talk with a LabVIEW Developer", where you could sign up and ask your question directly of someone on the development team. I'd like to see an "NI SkunkWorks Fair" at NIWeek. One session period where NI has tables set up and all of the LabVIEW developers are sitting there with thier favorite pet internal project that has not seen the light of day yet. We sort of get this when Jeff K. and others give us glimpses of things they are working on/toying around with for 2-3 versions down the road. But I mean all the developers, all the "black budget" projects. I was told that NI had undo internally long before it was released. Obviously there is scripting. I was told that LabVIEW for linux started out as a pet project, etc. I'm not saying it would be in NI's IP interests to have this, but I know people would be standing room only, and probably in a waiting line out the hall.

QUOTE(Gary Rubin @ May 31 2007, 09:44 AM) I don't see how you could do that on an embedded processor. The problem isn't so much LabVIEW, as it is MATLAB. If you can get MATLAB on the target I think you could get them to communicate. Perhaps with a custom board running QNX. I believe LabVIEW will target that now, but I'm not sure about MATLAB.

QUOTE(crelf @ Apr 1 2007, 06:44 PM) Not gold, brass ...

QUOTE(TiT @ May 31 2007, 09:27 AM) A quiet and honest one, that pointed me in other truthfull directions, and effectively sidestepped my question. Sometimes you learn more about how something is answered than by the answer itself. I first asked this question at dinner one night during NIWeek 1996. The answer I got then (from Greg McKaskle) was that it is and would be impossible. I will state flatly that we could create a functional equivalent to LabVIEW 1 using LabVIEW 5 tools. I think we could create most of LabVIEW in G now, especially with NI's help. Certainly there is little or nothing about the front panel and diagram editing environments that we could not write using picture controls and spawned instances from templates now. I'm not saying it would be easy, heck, LabVIEW has several hundred person-years of development in it by now. I've re-asked the question several times over the last 10 years. Usually I get blank stares, sometimes intrigued stares, seldom a direct answer. Brian pointed me towards that fact that LabVIEW is used to make the LEGO mindstorms code. He pointed towards the LabVIEW Embedded version, that translates G into C code for the compiling tool pipeline of whatever processor you are targeting. He pointed out that more and more of the LabVIEW editing environment is written in G, such as the properties and startup pages, etc. But he didn't address rewriting the G compiler in G, the way you can write a C compiler in C, until I directly phrased it that way. He then paused, grinned a bit and allowed that he supposed it was possible, but wouldn't go further than that.

QUOTE(Gary Rubin @ May 31 2007, 09:27 AM) I didn't tie, I translated. LabVIEW Embedded did not (and does not currently as far as I know, someone correct me if I am out of date) support calling MATLAB code. We were taking algorithms in MATLAB and translating them into LabVIEW Embedded for the AD Blackfin processor. To do that I (we) made up several libraries to handle the MATLAB style matrix manipulations. But we only did it for 1,2 and 3D matrices. I think variants and XNodes could be used to generalize to N-dim.

I did a fair amount of this last year on a project using LabVIEW Embedded and Matlab. I had to do it using loops and under NDA, so I can't post that code, but what you want isn't a huge amount of work. The problem becomes that MATLAB is naturally polymorphic with array dimension size and LabVIEW is not. I think this can be generalized using variants and XNodes and/or polymorphic VIs, but to get rid of looping will require NI. I'd love to see this. The only downside is that it will probably be another $1000.00 toolkit

QUOTE(Tomi Maila @ May 30 2007, 04:19 AM) Hi Tomi, Lets both keep smiling here , but I did understand your question. Perhaps I stated my response without explaining the underlying assumptions. You assume that having other graphic languages will raise interest in general and therefore raise LabVIEW. I simply state that from my observations it seems that NI does not share that assumption. If they did they would move in their own self interest and encourage those languages. Instead, they seem to view other languages as mainly competition, and that the best way to gain more interest in LabVIEW is to make more LabVIEW, not encourage "other" graphical languages. Note that they have come up with the new LEGO Mindstorms to get the kids into graphical programming. There is the push into new hardware markets, specifically the embedded markets with the LabVIEW Embedded and FPGA tools. All of these are based on LabVIEW, not on encouraging others to come up with graphical languages and then cheering them on. Until the market forces them to do otherwise, the most effective way for most companies to increase their share of the market is to push those areas where they have an IP/competative advantage. Currently NI is the 400 kg gorilla in the graphical language department. They are on top in sales and market share. If other graphical languages were encouraged and gained popularity then it might also gain the attention of 40,000 kg gargantua like Microsoft. NI already has their niche. That all being said, I would love to see them help other graphical languages get going. Now that the basic G language patents are up, they could use that as a good PR excuse to do what you are asking. But I'm not holding my breath. Hmm, let me try to agree with you, by asking my question of NI in a rephrase of yours: 1st Question NI: now that the patents are up, are you already, or would you be willing, to work with others on a standardized version of ANSI G, like ANSI C/C++ ? Say, something with the functionality of LabVIEW 5? 2nd Question NI: When are you going to generalize LabVIEW such that you can rewrite LabVIEW, in G, and dispense with text languages altogether? (I recently asked that one of Brian Powell, NI Principal LabVIEW Architect) Cheers

I used the Viewpoint 6K VIs on the controls for the mirror coating chamber at the Gemini telescope in Chile. They worked fine. For that app, the control was serial. Never really had any problems to speak of. I would second the opinion of Viewpoint. They are a good group, write good code. If you are going to use the 6k hardware, stop wasting time on this decision and just buy the toolkit from Viewpoint. You'll spend more time and your company's budget on the "make or bake" than the toolkit costs. I mean really, an engineer's time doing LabVIEW development bills at $100.00+ (and thats low at many companies). You can't possibly write in 10 hours anywhere near what you'll get in the kit. And Viewpoint had decent docs. Of course, that's all a moot point if you go with a different controller. The concern is valid. If the project has to be supported for many years out, you'd be wise to look at a newer option. Personally I've started to become a fan of the various brands of "smartmotors" like you can get from http://animatics.com/

QUOTE(Guillaume Lessard @ May 29 2007, 03:31 PM) Actually, no. I am not an NI employee, but I have asked Tomi's question several times, of NI employees, at several different levels in the corporate food chain. You get a lot of different answers depending on whom you ask and who is listening, but I have never had the slightest indication of paranoia or meanness (which is what "because we could" implies). Profit is a lot of the reason. NI is a for profit company and makes no apologies, nor should they. Most programming languages were invented either by a tax funded lab or in an academic environment. In research, people in universites, etc, share, which is great. But that is not how LabVIEW was born. NI invented and patented the original technology and a lot of graphical languages have been close enough to NI's patents to convince a court that they had infringed, or convince the other company that they could not win a suit, or stay afloat financially while fighting it out in court. Note that NI has gone after a bunch of different people, but to the best of my knowledge (I could easily be out of date on this) they have also been for profit companies. Lots of big corporations (and small ones!) aggressively protect their patents and profits, not just NI. Besides, the basic patents on the G language ran out back in February of this year if I recall right. If you or others are that annoyed, you are probably free to invest the time and effort to come up with your own graphical language now, and by all means, give it away for free as a public service. There's probably lots of people who would be happy to beta test it for you right here on LAVA ... I'm breathing normally :laugh:

QUOTE(crelf @ May 21 2007, 09:52 AM) I like the whack, as applied to HH's, and the chug as applied to any grouping of two or more LAVAs :beer:

Since most of it is static, and the rest is repetitive small motions I don't think this would be too hard to code up in the picture control. I think it would take more time to draw the background image than to populate the motion items. Way cool images from the top icon. The last rainbow starburst is now my desktop wallpaper (dual 20 inch monitor and 65 icons on the far left, tiled background) which I had not changed in a while. Don't know how long this will last before it gives me eyestrain ... http://forums.lavag.org/index.php?act=attach&type=post&id=5853

QUOTE(bjarket @ May 12 2007, 03:05 PM) Not easy as in a "canned" toolkit solution, but don't get discouraged. Making an icon based drag-n-drop system dependent on the picture control is also not that hard, especially if you've done it before. I assume that your system has a bunch of valves that control the interconnections between the pumps and the tanks, yes? And that the physical system, once built, does not change very often, if at all; rather you only change the position of sets of valves and turn motors/pumps off and on, same for maybe heaters or other piping system type components, yes?

QUOTE(bjarket @ May 11 2007, 08:45 AM) In a past project I worked on an antenna <-> radio equipment switching system that did what you describe, only with radio equipment instead of pumps and valves. The display and connection screens are based on the picture control and a database of allowable connections. The system components are drawn on the picture control and then the current connections are drawn as wires per the database. The user can click on the picture control and bring up a routing matrix dialog and change the routing. Sometimes this is explicit, other times the system selects the best route using an autorouter routine very much like a schematic capture/board layout autorouter using color mapping topology algorithms. So you can do this with LabVIEW and a simple database (or even totally in LabVIEW, the database just makes it easier). Good luck.