Barrie

A track I never thought got the recognition it deserved was "Skateaway" from Making Movies. Awesome!

This is terribly unscientific but I have found that a VI that doesn't draw right, doesn't run right. I have abandoned approaches just because it doesn't look right and its rarely failed me. Its an aesthetic or gestalt thing. A very simple example is that my VIs run best when the dataflow is left to right, top to bottom, like a well drawn schematic.

Call it, if you will, another example of "Thinking In G"

So, I guess the question is; can aesthetics be quantified? VI Analyzer is a good start, but perhaps what you are asking is verging on AI.

Please don't take this as discouragement, just a discussion point.

Cheers,

Barrie

Brain dead? Yes. Unusual? No so much.

This site is good for a few chuckles or at least vicarious comiseration.

B.

I don't know if this should be in the Rube Goldberg section but it is implemented with NXT.

It gives Fieldpoint a run for its money.

Enjoy.

B.

<snip>

I'm probably not explaining this clearly - check out the attached VI. Delete the first unbundle and wire the second one directly to the control - it will always revert to "Sub 1.Num 1", not "Sub 2.Num 1".

Jaegen

Ok, now I'm really torqued.

I tried exactly that about a week ago and I am 99% sure it did not revert.

I just tried it again, and it did revert. :headbang: As you pointed out, if the 2nd level unbundle names are unique, it does not revert. That said, if I go back to the original scripting test VI and make the element names unique, it still doesn't work.

Any suggestions for tracking down this elusive secret?

Incense, chants, incantations or aligning the cpu with magnetic north will all be considered.

B.

It would be really interesting to know, how to programm in 5 dimensions

Perhaps, but I would be happy if I could just control the polarity and magnitude of the fourth dimension, it would give me more time to study, well..... and of course other important things, like :beer: .

The "case structure" must have good wires in all of its frames. The "diagram disable" structure may have missing subVIs, broken wires, unwired required terminals and other broken bits in the disabled frames. The "code disable" structure is for multi-platform loading. "I want this to be enabled on Platform XYZ, and that to be enabled on Platform PDQ". This handles cases where you used to have a constant wired to the case structure for "Mac" that, when you loaded on a PC, you had to remember to go find all the instances of that constant and change them to "PC". It's also able to handle other configuration changes using the keywords that you define as part of the project environment. ("I'd like to build a debug version of my VIs, which has all this slow sanity checking code, and now, with just a change to the project, I'd like a release version which leaves out all the double-checking.")

Thanks Aristos and others:

This "leg-up" prompted me to dig deeper into these structures and I must confess that my original question was an RTFM. The differences are not as subtle or obscure as I first thought. Call it laziness or fear of the unknown.

I am using various versions of GPS receivers that are wildly different in their protocol (and data content :headbang: ) so selectively including drivers programatically will reduce the code size by quite a bit, but would lock me into a device-specific build.

One thing that is not explicitly stated (or I couldn't find); I am assuming that any code that is logically eliminated from executing is eliminated from a build, based on the target system and user defined symbols but this will only occur when the diagram is removed. I am futher assuming that this feature would not be appropriate for selecting features or functions at run-time in an .exe.

Is this correct?

In other words, are these features best used to control code size, execution speed or both? Any insight into the internal mechanics would be welcomed.

In the bigger picture, I don't think the full capabilities of the Project are appreciated without a lot of digging, but perhaps I am just futher exposing my laziness . Does one maintain one project and then manage the symbols and build specifications for platform or device specifics, or does one create a different project for each build? It seems to me that this question starts to merge into SCC issues and is perhaps outside the scope of a LV discussion.

Further (at the risk of rambling) how many of you out there are full adopters of the project paradigm?

- Do you always create a project, even when you are just trying out new ideas?

- Are you converting older projects to .lvproj?

- Does anyone use SCC in a single user environment for automatic archiving?

I am always trying to improve my software skills so all opinions and philosophies are welcome.

Cheers,

B.

I've been using LV for more than a week or two but I must confess I am having some diffculty getting my head around some new features.

The behaviour of the standard case structure has been compiler optimized to discard any code eliminated by a constant. Cool.

So now we also have conditional disable and diagram disable. With the changes in the case structure behaviour the differences are, to me. subtle.

Apart from the search function which allows me to find unique structures (and presumably delete them prior to a build), I don't have a solid understanding of where, when, or why I would use the two new features.

Anyone care to enlighten me? What am I missing?

Cheers,

Barrie

Are you guys sure that you actually had this working? The end result is very dependent on which values are in the unbundle before you run, and which values you're asking for. Another annoying thing is that it doesn't return an error if you ask for something that doesn't exist.

Should I file a bug report for this??? (Or is scripting in its entirety a "bug" in NI's world ).

Jaegen

This is really bugging me. :headbang: The timing is such that I was just about to start on a sub VI that needs to do exactly this.

I'm not sure if I ever got the sample VI to work, so, not calling anyone a liar, can someone confirm that it did work consistently, at least for a while? if so, I can start working backwards to try to figure out what's going wrong. any other clues would be greatly appreciated. (Fresh copy of LabVIEW, window minimized, first run only etc.) It appears a reference is getting trashed, or some data is non-persistent, but that should create an error.

The only way I have been able to do this reliably, is really clunky. I create a tree of unbundles to get the item I want and then I wire the final unbundle to the original cluster and delete the intermediate unbundles. Not for the faint of heart.

I agree, no feedback (error) for non-existent items is a real pain. As for a bug report, I remember Jeff K. saying something about "It's ok to use scripting, just don't expect us to support it", so that's a non starter.

Scripting: The final Frontier.

Me too - one of the guys at work took a bunch of us to a jazz club downtown called Bert's Marketplace last week (one of the many benefits of living near Detroit) - it was open mic night and it was phenomenal!

Reminds me of an old bumper sticker that was near and dear to my heart:

"Support your local musicians, blow up a disco."

B.

Its in a very "obvious" place.. Programming>>Dialog & User Interface--4th row

:ninja:

Don't you just love the new re-arranged pallets?

Neville.

Thanks for asking, and NO I don't.

Particularly when I have 7.1.1 and 8.20 open at the same time.

B.

Hi bigl00z3,

the problem you have is quite frequently... but the solution you have implemented can not solve it...

LabVIEW is a dataflow language. Any function or loop (like for or while) will execute only when all his input will be avaiable!

So, the second while loop will execute only when the first will stop and the data contained in the outgoing array will flow to the input tunnel of the second while loop!

There are many solution to solve the problem you have... The more efficient, IMHO, is to use the producer/consumer design pattern... You can use the LabView Template "Consumer/producer design pattern (Data)" that appear in the "From Template" folder when you select "new..." from the File men

I though it was part of the LabVIEW DSC package, but I may be wrong.

PJM

Can't confirm for sure but you're probably right. I have the DSC package and symfac is installed.

B.

Barrie,

nice tool, but since you saved in a library you might want to save with options and include the specific OGTK VIs in the library. Some companies won't let us use the whole toolkit, but individual VIs are okay.

Gee, I thought everyone had the OGTK ! Good point actually. :thumbup:

Here is the full .llb (with some diagram clean-up)

Cheers,

Barrie

Download File:post-658-1162506452.llb

Hello All:

Rather than use trial and error to find what the terminal indices are, (and to explore scripting) I wrote this little utility.

Feel free to suggest any corrections or additions.

Cheers,

Barrie

Oh, and thanks to Chris Davis for the "leg up" that got me this far.

B.

Download File:post-658-1162432064.llb

If your user info is true and you are using 8.2 you may be out of luck. I think parts of scripting were closed after 7.1.x. I'm still using 7.0. You might try copying the create constant or control out of my example and pasting it in your code to see if it works.

BTW, don't feel dumb. I wanted to know more, and so I had to devote some more time and effort. This is not a casually learned topic. Althought with my examples, I hope to make it easier to get started learning the basics.

Thanks Chris!

Just to confirm, your VI runs fine in 8.x and cut-and-paste does as well.

Phew! I feel better now. I re-loaded both 7.0 and 7.1 and voila! everything is there. At first glance, there is a HUGE difference in what is exposed between 7.x and 8.x but there is also a big difference in VI server as well, so maybe there is a different paradigm.

I think part of the change is the because "create constant or control" is no longer truly valid after the addition of the pane. I notice that that method is shown in red in 8.20, which means ???? deprecated??? Wiring a pane reference to "create constant or control" does NOT solve the problem.

Makes you wonder if the shipped LV is different now from the NI internal dev version or if there are new functions not visible on the palette (like New VI Object) or if there is an new, better hidden .ini key or ????

Until these mysteries are revealed, I guess the only approach is to develop the functions in 7.x and then open them in 8.x to take advantage of other new features.

As an aside, until now, the additional properties and methods were just a curiosity for me, but I see XControls as a really great feature that is fairly tedious to implement, particularly if you want to add a lot of properties or methods to the control.

I think scripting could really simplify this.

NI probably has this in the works, but that's the risk one takes.

Cheers!

Does anyone have a simple OOP implementation they could send me to take a look at .... i have gone through the examples etc... and for whatever reason i dont think i am "getting it"....

thanks

Dan

I feel your pain. I was in the same boat until recently, and even now, I'm not much further along.

There are at least three issues here:

- There is the concept of OOP in general.

- There is the implementation of OOP in LabVIEW (At least two flavours)

- The concept of how the G paradigm fits in with OOP

In a nutshell, OOP provides enforced mechanisms to encapsulate and restrict access to areas of code. Interface points are written which operate on the protected code via methods and properties. A second key point is the concept of inheritance and classes. There's more to it, but that's all I'm going to say about OOP because I'm sure no expert, and there are lots of articles on the Web.

Third parties have implemented a form of OOP in LabVIEW and it is referred to as GOOP. The product is offered by Endevo (www.endevo.se). An overview of OOP, GOOP and early version of GOOP is available on the National Instruments website here.

As of LV 8.20, NI has implemented OOP which is usually referred to as LVOOP.

A notable difference between the two G implementations is that GOOP operates "by reference" and LVOOP operates "by data". LVOOP tries hard to provide GOOP features while still maintaining the dataflow paradigm.

Personally, I have heard OOP hyped for so long and so often, that I had trouble "getting it". It does have some useful features but there a more than a few people out there that are asking the question "Has OOP delivered on all the promises?" and OOP definitely has its detractors. (No flames please ).

For my money, OPP has a long way to go to beat sliced bread.

This is just my own $.02.

Hope it helps.

Cheers!

I'd like to make more examples, and posting them to a single place would be helpful in the future when we want to point someone to a complete consise example of how to get started with scripting. I know the code repository has methods to source code control. What about the knowledge base?

This is a great example for me because it shows that I am missing something fundamental.

I have poked around scripting a bit, but never got very far. Now I think I know why.

I have modified my .ini and can now see lots of new toys, but when I try to re-create Chris' vi, the Method "Create Constant or Control" is not exposed. It appears that I'm only getting part of the picture.

I'm feeling kinda dumb right now, anyone care to enlighten me?

Cheers!

Nothing beats SequoiaView.

I second that! Seqoia Rocks! :thumbup:

Hi Barrie, that sounds like a good idea, and you seem to be using LabView version 8.0, but is it possible to just make a screenshot of the wiring on how you would set this up, (i'm really sorry but I only started using labview resently).

ou and I couldn't find this Robot.vi example, and where is this Example section in this forum cos I couldn;t find it, I can't see the link anywhere.

Thanks a bunch

This is a very quick example of the basics. Of course you will want to break out the pattern creation from the display loop, but it should give you a good starting point. As for the fancy stuff, you're on your own.

The robot vi is located in LV examples, probably in C:\Program Files\National Instruments\LabVIEW 7.1\examples\picture\robot.llb

The Picture control is a much underused tool. You can really have fun with it!

Good luck and let me know what you come up with.

Barrie

This is a very quick example of the basics. Of course you will want to break out the pattern creation from the display loop, but it should give you a good starting point. As for the fancy stuff, you're on your own.

The robot vi is located in LV examples, probably in C:\Program Files\National Instruments\LabVIEW 7.1\examples\picture\robot.llb

The Picture control is a much underused tool. You can really have fun with it!

Good luck and let me know what you come up with.

Barrie

PS If the VI looks like a mess, it's because I created it on my laptop, which is wide screen. GRRRR! Windoze graphics.

And no comments from Macophiles, I've heard it all before.

Download File:post-658-1158892153.vi

Sorry but I have LabView version 7.1. and I can't open the example, possible you can convert it on 7.1 version???

Thnx

If you want to have smooth rotation, a pict ring would be cumbersome, (too many pictures).

This sounds like a perfect application for using the Picture Control.

The turntable picture consists of just a number of circles, filled with different colours.

I would set it up this way:

Set up a cluster array. Each cluster specifies a circle centre, radius and fill colour.

A simple rotation transform on the array would put all the circles where you want them w.r.t. the centre of the picture control.

Once the coordinates are transformed, a loop passes the coordinates to the Draw Circle primitive (in the Picture Control Palette).

If you want to get fancy and use shading, refer to the Robot.vi in the examples directory. There are some good subroutines there. (Shading is just radius+1 then draw an arc of 180 deg.)

Good Luck,

Barrie

The Simpson Desert?!? Sounds like you need a drink!

That'd be right. I did crack a tinny or two when I got back to Melbourne.

Although I agree with you in principle, I can't stress one thing enough: up-front design. You really need to spend some time (ie: money) at the start (especially since it's a multi-component system) and that'll save you a bunch later on. Whilst you might not be concerned about making a system perfect, with a decent amount of fore-thought, all the components should fall into place with a little thinking about the glue to interface them together.

I agree completely, the choice of interface points and division of tasks is key. No amount of horsepower can compensate for bad architecture. My point is that some sloppiness has an economic advantage. The question is: How sloppy is too sloppy? The concept is an anathema to good programmers.

(I haven't been out to the Simpson in years - where were you?)

All over actually, but it was mostly the Simpson and the Strzeleki; Moomba, Dullingari, Birdsville, Innaminka, Della, Gidgealpa. Our break in civilization (?) was Broken Hill.

Hello All:

I have just ended my exile in the Simpson Desert in Australia and I'm now on to a new project. I expect it to have around 500+ VIs and about 8 separate processes.

My new task needs determinancy and it needs a GUI. One obvious solution is some kind of RT based front end coupled to a PC.

Unfortunately, I also need a graphical display that also has a good update rate and determinancy, something that RT can not provide.

There are a number of ways I can go, but that is not the topic of this post.

When is overkill really overkill?

Processors, memory and disk space are so cheap, that it's tough to avoid the tendency just to find the latest and greatest and use it. As a matter of fact, that is what I think I should do. I might even use 2 PCs and an RT box.

Having all this power means that the code may not be as efficient as possible, but tuning, setting threads and priorities etc. all takes time, and as we all know time is money.

Perhaps this thread is partially out of guilt, but part of being a good system designer is being pragmatic. Many of us here are also businesspeople.

So, I thought I would just throw this out to the group and get some feedback.

Disclaimer: Before any purists jump on me, I know we would all like our apps. to be clean, efficient, elegant and optimized, but we also have to eat. Apps that don't get delivered, don't get paid for. No pay, no :beer:

I look forward to your thoughts.

LabVIEW does not support this directly. You will probably need to call external code to achieve this.

FWIW, I talked to NI about this some time ago. They recognize it as a problem and there are steps being taken to address it.

They were unclear as to what those steps were, but at least they are working towards some sort of improvement.

B.

Here is an interesting post from info-labview:

/snip

"It began to believe that in order to be more profitable, because profitable

was not enough profit, it had to build a system to follow and restrict the

users of FabMIEW using a secret activation procedure."

/endsnip

In the last few years it has become very fashionable to demonize corporations. Considering Enron, WorldCom, Nortel and others, this is understandable but really very silly. This is like hating humanity because some people rob banks.

- Is NI profit driven?

I sure hope so. I want NI to not only survive, but flourish because I have invested a great deal of time learning how to make the most of LabVIEW's features. (Note, I did not say mastering ). I want that product to get better and more ubiquitous.

- Has NI been taken over by evil corporate zombies that want to imbed a chip in license holders so their precious product will not be used unless it's paid for?

I don't know. I do know that every time I have contacted NI about potential licence violations their response has always been reasonable. As long as I follow the spirit of the SLA, I have never had a problem. Keep in mind, NI has listened to complaints about their licensing approach and relaxed their licensing policy to reflect the realities of how people use their software. That doesn't sound like the "big bad wolf" to me.

Just to be clear, I am not an apologist for NI. Whether I buy an NI license or an audio CD, I feel strongly that I can use that product in any reasonable and legitimate way that I see fit. As a licensed user, I don't think I should be punished, limited or inconvenienced because of pirates. That is their problem, not mine. For example, DRM is a flawed system and as such, it will ultimately fail.

Recently NI has implemented a new system to try to ensure that their product is not used illegally. Apparently it has some problems. That said, I have triggered sensors in a retail store after I have paid for a product. I don't hate security systems because of that. Hey, S**T happens. NI is fixing it, and life goes on.

As more active LabVIEW users pay for the product, one of two things (or both) will happen:

- NI will be able to drop the price.

- NI will become more successful.

Either way, I win.

- Is LabVIEW too expensive?

LabVIEW is a tool. IMHO it is a very good tool and it does not come cheap. I do not compare the cost of LabVIEW to Word, XP or Final Fantasy. The volume and market is totally different. I only look at what LabVIEW can do for me and how it can make me more productive and, ultimately, successful. If there is a better/cheaper product out there, I will use it, either concurrently or as a replacement. G is certainly not the first language that I have learned and it probably won't be the last. If you have an emotional attachment to a piece of software, I respectfully suggest that you re-evaluate your priorities.

I find it ironic that many of the grumblers (statistically, that is) will likely have some investments or IRAs with stock holdings and they want those stocks to do well so they can have all the trappings of the good life. Those same people will charge as much for their services as the market will allow and gauge their worth based on other developers and their skills i.e. worth. Those same people would likely be very upset if someone misappropriated their work product and cheated them.

How is NI's attitude any different?

Well, I suspect that this post may set the cat amongst the pigeons, but I will gladly respond to any rational rebuttals.

Cheers!

Barrie