didierj

QUOTE(Tomi Maila @ Jun 7 2007, 10:28 AM) Haven't mentioned, but 2nd template starts also as a frontpanel. But either way, please explain me why does it work once and once not? And with the traditional (set control value-) node it works all time. Myself I used this node quite often in my 10 LV-years and hadn't one time problem with it. QUOTE(SciWare @ Jun 8 2007, 01:44 AM) It sounds like an interesting application as well. It is, it's a test-framework. The main.vi is an overview of the test rigs in his lab. Since the ammount of test rigs vary over time, their overview are implemented dynamically in the main (sub-panels). The overview shows the status of each rig. If there are more than the 8 rigs the main can show on one window, the operator can flip pages. With a click on the sub-panel the full-blown test-panel (2nd template) of this rig is opened in a new window, the operator can now interact with the rig. In the main itself the operator can set up a new test-rig (after clicking <OK> the overview gets one more element). The SW & HW are connected with daq & imaq, and everything is stored in a mysql db (have a good server for all the datapoints ). The framework is well thought-out, built full modular. And it should be something to show to customers (who buy his products) when they visit the facility. Didier

Hi there, Long time I didn't post something... ...well, a friend of me showed me recently an odd behaviour in a program he wrote in LV7.1.1. The architecture is: main.vi calls a template (with vi-server) and embeds it as a subpanel. From this subpanel and also from main.vi a 2nd template is called with vi-server. The reference of a sciware-goop object is given to this 2nd sub-vi with the node "set control value (variant)"... seems complicated but there is the clue. In the development environment everything works like a charm. But from the moment a built app is done, the "set control value (variant)"-node that resides in main.vi returns error 1, but not the one in the subpanel . The goop-ref points to the same object. Do I replace the node in main.vi with the traditional "set control value" (which needs a flatten to string), everything works again. To me quite strange, since the goop-ref was also given to the subpanel with the "set control value (variant)"-node, and there it works. The only answer I could give was "???" ...or did I oversee something, since I don't use LV that much anymore? Didier ps. have to ask him to break down his program, or do it myself

QUOTE(TiT @ Mar 8 2007, 01:58 PM) In this sentense there are 2 point in favour of Labview: 1. the New Beetle is affordable by the masses 2. I doubt that one could drive the ferrarri with less gaz as the beetle.

Thank you all for these recomforting words... my heart is sick QUOTE(Mike Ashe @ Mar 9 2007, 05:15 PM) ...count on that. But I think it won't happen too soon, my workmates also like one or two (or more) :beer: after work. QUOTE ... I mean, how can you seriously contemplate going for too long without threads like http://forums.lavag.org/The-5th-dimension-t4895.html' target="_blank">The 5th Dimension "In the beginning was the Alfa, and his prose was without form, and his logic void, and ..." ...have seen it :thumbup: . "In the beginning was LAVA, then came Alfa and life stopped being as it was!"

QUOTE(Mike Ashe @ Mar 9 2007, 04:53 AM) http://forums.lavag.org/index.php?act=attach&type=post&id=5182 ...right, only a few month away and my brain already begins to blur... might also be a result of the n-dimensional trips one has to do while reading this topic...

QUOTE(PaulG. @ Feb 8 2007, 02:33 AM) The file-server at office is down for the next few hours, so I just read the thread trom start to finish... These "multi-dimensional" stuff scares me a bit. I prefer to stay at my 3D- :beer: , where I know what I get. QUOTE(crelf @ Nov 17 2006, 04:15 PM) :laugh: I just spat a mouthful of tea over my monitors! "Tea" :question: , I thought you were THE "coffee"-man?

QUOTE(tcplomp @ Mar 7 2007, 01:51 PM) In Switzerland the only (main) contractors are Alcatel (since January 1st named Thales) and Siemens. Actually the swiss federal Rail accept only one axle counter system for new projects and it is the one from Alcatel. So guess in which company I work . QUOTE(tcplomp @ Mar 7 2007, 01:51 PM) And yes you can do LabVIEW at 300 km/h in a high-speed train or a 120 km/h normal train. But not in a 40year old suburb train at 80km/h (which seems to be more than this train was designed for).

Hi LabVIEW'er, Some might have remarked that I was quiet for the last few months... Well, this is because I rarely use LabVIEW since last October. I changed the job! Working till then as a developer, now I act as a project manager (yes, these "useless" ones you could easily put in the same bin as the directors, always behind a word document and doing weired stuff on ms project ) Just to specify: I don't have to wear all day long a tie :!: I work for a company that builds those complicated systems behind the rail signals, to avoid that 2 trains crash into each other. There I make the planning, design and startup of axle counters (a subsytem). So my job is to keep track in ms project, design the system (e.g. connection diagrams), tell the technitian when they have to do what, go onto the rail tracks when everyting is installed and fine-tune the system and last but not least tell the customer (project manager of the SBB: swiss federal railway) how good they are . For the ones that don't know what an axle counter is: The tracks are divided into section of 20m to ~2km length. at the beginning and end of each section is a sensor that counts how much wheels pass. Now when a train runs the first sensor register a certain ammount of wheels. from now on the related section is "blocked" (the signal before this section goes to red). When the train passes the sensor at the opposit side of the section this one also counts the wheels. Now the signal can only become green if the two wheel counts are same. If the counts are not the same someone has to go onto the track and find the carriage the train lost . I decided to change the job, because I missed the "free air", I'm about every other month on the tracks wearing these "ugly" orange and reflecting dresses. Working as a developer for the production systems gives almost no possibility to work outside the company walls. I would have prefered some job as a (LabVIEW, of course) developer for customer, but this good opportunity crossed my way and I jumped on it. Jobs like Michael or Jim have are quite rare. Although my job is to "manage" I haven't put aside "development" totally. My first big project was to "invent" something to facilitate our daily job designing with the office-tools. So I did some weired stuff on Visio with custom shapes and VBA. I'm quite happy with the result and my new workmates too. ... oh, I almost forgot something (for you Michael, an old dept): http://forums.lavag.org/index.php?act=attach&type=post&id=5143 With these two nice "random noise generators" there isn't much time left for some "private" LabVIEW projects. Maybe I can manage to wirework a bit on the way to/from work, just to calm down my emotions. Has anyone ever tried to wire two sub-vi's on a shaking train with a notebook-mousepad?? So, I whish you all the best for the future. Maybe, if time let it, I'll be here occasionally. Didier

Hi Brad, or just so:

I tried the trick with "Tools -> Update Virtuals" with the result that now ALL virtual methods return Error 1031 EDIT: Just found the problem: on the parent class I modified the error in to "recomended", but not on the child class .

I have to disagree with you. OO programming IS A METHOD TO SOLVE A PROBLEM (in the meaning of SW-design)!

In the Main menu go to Help>Find Examples... It's full of codes that you can use/modify/combinde to your needs and they are usable (not like some MS-helps )

I have no problems opening and running them. Try to redownload them.

Although I rarely use the autotool (old habits ), somehow I knew that there is a key to "disable" it. Unfortunately I never remember which key it is (have to try it everytime), nor from where I got this info... maybe from a former presentation at a NI-day or VIP-day.

A dumb question, but to me it sounds that you have changed the baudrate on your computer, but have you done it also on the oscilloscope?

Well, this reminds me my last trip to California. One evening I was sitting in a bar in Frisco, at some time a guy asked me from where I was, since my pronunciation was a bit "strange". I replied that I was from Switzerland. The guy had to think a while and after that he asked if that place near SF or LA, since he didn't know it... ...There must also be a few of these people in Hollywood who don't know that there is an outer world (outside US). ps: where is that picture from CNN explaining "war in Europe" (and meaning the war in Jugoslavia). On this picture Switzerland is referenced somewhere in Poland, just a few miles to far east and north...

C'mon, Everyone knows that FBI and CIA work hand in hand on a global stage...

There was a poll here. For my part I started with original GOOP (that one from the NI-forum with the password protected vi's :thumbdown: ), moved to openGOOP and now evaluating Goop Developer 2.0 and LabVOOP. Which version you want to use, depends on your needs. "Real" OO implementations (with inheritance,...) are Endevo GOOP, Goop developer 2.0, and LabVOOP: Endevo GOOP has an impressive graphical Project tool, LabVOOP is native LabView. The other ones are older and do just implement static classes.

Depends on the manufacturer... ...Try to find it here

It's more or less what I did, except that I manually click-and-draged each virtual methods conpane to its vi-ref "This VI's Type". But somehow it didn't worked... or should I have dragged highest level conpane to all its children methods "This VI's Type"?

Dear Kurt, I write this request on LAVA instead of Sciware-forum, since it will reach a bigger audience and I hope to see more opinions (from other people who tried it). While using Goop Developer and building a project, it happens "often" (I know it shouldn't ) that a virtual method needs additions on the conn-pane after having created the child-class methods. To my experience this is a crutial step that easily results in a runtime-error "1031, VI Reference type does not match VI connector pane", which is a "pain in the a...<cough>" to resolve ...must have done something wrong, I had to delete and rewrite the child methods . Could you add a step-by-step description regarding this to your tutorial?

For what does anybody need to have the Class object as a control, except to pass the class to a sub-vi? If one can paste a control for initialization purpose, we are back these ugly "c programs witten with LV". Replace the Class object constant with a customizable "constructor-vi" and you are done.

I agree that if initialisation is needed depends on the concept. In LV (and where it doesn't go to the outside world) there is no initialisation method of any datatype. But from the moment the outer world is concerned also NI always uses sort of initialisation/clean-up (see file, daq, visa, ...). OO programming is not only a way to put fancy boxes around parameters and methods, but a concept where one tries to encapsulate everything that belongs to an object. Inheritance in OO programming is a way to generalize the access to an object, just like IVI. You define a standardized interface for every oscilloscope, but in the background you have child classes specialied for e.g. leCroy, HP,... There is (at least) 1 Method in your code that is of the lowest class of your hierarchy in your code, and this is the constructor (at some point in your code you must choose which oscilloscope you want to work with). To my oppinion LabVOOP lacks two main features to be usable in the sense of OO programming: 1. overloading: same vi with different conepane. At the point where you define which sub-class you want to use, you must be able to have overloading, since the different sub-classes might need different parameters. 2. get a ref to the data: It makes it much more complicated to write a program in the producer/consumer concept whithout the ability to access your object (the 1 and only instance of the class) from parallel loops. Let me explain: When you have 2 parallel loops, one with event-structure for UI interaction, another with your own states to do the measurement. If you have your Instrument driver packed in a class and you can access your class by reference, you can easily wire the ref into the event-structure and call e.g. the instrument configuration panel by mouse click without interfering your measurement-loop. On the other hand, in LabVOOP one has to define a state in the measurment loop that calls the configuration panel (since branching the class creates a copy) and therefore it interfers into your measurement and you might loose/miss data. In conclusion I came to the point that the actual LabVOOP is good more for beginner to have an entry point into OO (similar to express-vi's), but when doing bigger programs that have multiple parallel running tasks (like one I did recently with >1000 vi's and 4-8 parallel tasks) LabVOOP is too much restricted to be used as your program structure concept. Didier

...a new experience to create your easter eggs (not these)... :thumbup:

Wow, nice work you have done. I like your ideas. I haven't made my oppinion on which OO method suits my needs better: LabVOOP or the various GOOP's. There is one thing that bugged me since the first 10 minutes I glanced into LabVOOP: how do one access object data in parallel loops? So far I have on suggestion on your proposal: On page 21 (constructor block diagram) you define a class constant and then you invoke explicitly the constructor of the parent class. But you could also replace the class constant with the parent constructor. In all my implementations I did in Delphi the first command of a constructor is a "inherited create" (calling of parent constructor). Didier