Jump to content


  • Posts

  • Joined

  • Last visited


Everything posted by Barrie

  1. A track I never thought got the recognition it deserved was "Skateaway" from Making Movies. Awesome!
  2. 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
  3. Brain dead? Yes. Unusual? No so much. This site is good for a few chuckles or at least vicarious comiseration. B.
  4. Barrie


    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.
  5. 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.
  6. 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: .
  7. 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.
  8. 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
  9. 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.
  10. Reminds me of an old bumper sticker that was near and dear to my heart: "Support your local musicians, blow up a disco." B.
  11. Thanks for asking, and NO I don't. Particularly when I have 7.1.1 and 8.20 open at the same time. B.
  12. Can't confirm for sure but you're probably right. I have the DSC package and symfac is installed. B.
  13. 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
  14. 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
  15. 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!
  16. 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!
  17. 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!
  18. I second that! Seqoia Rocks! :thumbup:
  19. 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
  20. 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
  21. 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.
  22. 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.
  23. 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
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.