didierj

I usually try to make parts of the documentation before and while I wire.

As I usually base my projects on openGoop and state machines the docs that usually have to be created before are:

- state diagram

- class hierarchy (maybe better "class diagram", since openGoop doesn't know inheritance so far)

- use cases

- if needed sequence charts for special parts of the code that might get complicated to understand

Most important is to keep these documents updated while working on the code.

...but as I'm just human, many tools and parts of the code are done in a "quick-and-dirty" manner that lacks of any documentation. :thumbdown:

Didier

if you know what a Tecmar Graphics Master is, then I'm not suprised that your eyesight is deteriorating . The interlaced 640 x 480 drove me NUTS! The only monitor that worked well was a Zenith because of it's slow refresh rate.

My XT (to be frank it was my dad's one ) had this "intelaced 640x480" resolution. So I assume that I owned one of these Tecmar cards. That also reminds me the "portable" my dad used at work: Toshiba, >10kg, orange display, but an AT(!!!). It was known (throughout german speaking region) as "Schlepp-Top" instead of "Laptop".

... need a bigger desk!

I just don't think I want to try to do it all in one bottom-level class.

Seems you are at the point, where you'll have to decide how to structure your program, aka "how will my class hierarchy look like". As I stated there is not ONE AND ONLY best solution. It all depends on the purposes, desired and needed complexity of your application/instrument driver.

An Instrument driver, typically I would build it up in the following manner:

- the create.vi gets standard parameters from its calling vi, like port, baudrate,... (things that might change from application to application and would be stored in the application-ini-file.

- Have a method that pop-ups its frontpanel to change the class attributes. In this vi you can freely use the "get data" "get data to modify" and "set modified data" primitives since you are already in the class. Usually I store the FP-values into the class attributes only after pressing <OK> or (if you have one) <TEST Instrument>.

- Have various methods which only purposes are to get the parameters from a higher-lever vi (e.g. a global configuration-vi) and store them into the class attributes. such methods include just "get data to modify", "bundle by name" tied to the conn-pane-controls and the "set modified data".

- Have various methods that gives the data to a higher-level vi. These methods consists of "get data", "unbundle by name", and the conn-pane-indicators.

- Various methods with further code to accomplish the whole work. Divide the work into pieces that are self-contained (this is one method) but allow to be combined depending on the purpose.

If you divide your instrument into sub-classes (e.g. instr-class & axis-classes) it is up to you to, either supply the instrument-top-class with all the parameters and then it hands them on to the sub-classes, or to get the sub-class-references from the top-class and then pass the parameters directly to the sub-classes.

Both are valid approaches.

To have methods with the contols on their fp and then plop them as sub-panels isn't correctly. On "OO-languages" the fp-elements always belong to the fp-class which will seldom be the instrument class. Passing the value from the fp-element to the class-attributes is done on a event (e.g. "on value change" or "on <OK>").

Didier

If I create a subclass of axis to the instrument class (which is the only class I was previously envisioning) then it seems like I'd be adding a lot of extra GOOP overhead to the access of the axis data. I would be replacing simple INDEX ARRAY and REPLACE ARRAY ELEMENT functions (which would otherwise be buried in the public methods of an instrument-only class) with more complex GOOP public & private methods to do exactly the same thing. Is this really good thing? Why would it make sense?

I said: "in the context of OO programming". Since LV doesn't include classes/inheritance/... for custom use in itself, some things can be done here easier. If you right-click on a property node and select "class" you get the class hierarchy that NI uses for the usable LV-objects (controls, decorations,...). With a different programming language (e.g. Delphi) such stuff (e.g. graph) are a bunch of hierarchically organized classes/subclasses. Even the data of such an graph is not organized in a array but in a "List"-class that includes methods to set/move a pointer to navigate through your data (like a database), methods to read the data as string, double, integer,..., methods to add/remove elements, methods to...

Using OO-methods doesn't end with ONE best solution. In your case I agree with you it is easier to just implement the instrument class.

But is it considered acceptable to just read/update the entire class (typedef'd cluster) rather than individual attributes? If my class (cluster) has 10 attributes (items) in it, then why bother with 10 connector pane connections when I can just use one for the cluster? Am I supposed to be keeping the cluster hidden/private?

I know what you are saying but there has to be some way of educating the new user, be it through added text, added example code, included examples or included documentation. The experienced user, if he gets annoyed enough, would probably know how to find and modify the wizard templates to remove the explanations. As an example of what I am talking about, dataACTS' dqGOOP comes with the best documentation I've seen outside NI, yet the templates themselves only have documentation for the controls and indicators. The only clue about what a template is for comes from its name and block diagram and in some cases the block diagram is rather cryptic. I'm still left wondering under what circumstances I'm supposed to be using a few of these templates:

Agree, I also guessed what was the purpose for few templates.

The one your refer to, is probably intended for some operations that belongs to the class, but doesn't use any class-attributes. As you group methods and attributes that belong together into a class, it can happen, that e.g. acquired data seometime (but not always) need further arithmethics, but doesn't need attributes of the class (which will typically be "VISA", meas-range, timeouts, for an instrument driver).

Working with classes ends up with overhead of code (and resource use), but gaining readability of your code if you correctly group your stuff into the classes.

How deep you create your class-hierarchy is your problem. C# as example, dives quite far, since every variable (you define) is a class itself, allowing to create inherted classes of it, having properties,...

Didier

In my case I arrived at the conclusion of "I need GOOP" when I decided that I needed a common or generic motion control interface that I can use with my projects. This would allow me hide the details of operating a particular brand of controller from whatever higher-level code needed motion control functions. I am hoping that I too can get a little insight into the way GOOP should be used.

:thumbup: I'm always using GOOP-Classes for my datastore (even that my co-programmes shake their heads). In my opinion you can structure your program further than with just sub-vi's. At least you will have to think of how to build up your program BEFORE you begin to wire.

In the past I have used arrays of clusters of data with each (cluster) element of the array being the data for a different axis in the system. But, as I am looking at GOOP, I am wondering "should my class also be an array of clusters of either the static or the dynamic data or should the class be just the cluster itself and I end up with a different class for each axis?" I'm leaning toward the array but perhaps there's a reason why I shouldn't?

In the context of OO-programming you would most probably end up with a "instrument"-class, a "axis"-class that you instanciate n-times as you have n-axes. It might also be that the "axis"-class is just a virtual class that you use a parent class for the different "x"- "y"- "z"-classes. But since OpenGOOP/dqGoop doesn't know inheritance forget the last sentense.

I'm also a bit confused by the various template VI's that are made available after either the dqGOOP or OpenGOOP wizards are run. I believe these are intended to be the starting point for the public methods for accessing the data so in my naivet

Question 1: I don't understand what you mean.

Question 2: Including your .rpt-file into the exe is not possible, they will be alongside of the exe. To include it into the installer, add them as "support files" in the "source files" tab of the app-builder frontpanel.

Didier

Try to avoid asking the same question in different subforums. How can I call...

As a "picky bastard" (didn't anybody else here once stated he was also one :laugh: ) I have seen 2 things that disturbs my eye:

1. Try not to wire overlapping wires (wire that gets hidden behind another).

2. Data flows into a node (sub-vi/control/property node) from left and top and flows out of a node to right and down.

It will make your code much more readable, after having not looked into it for several months.

It is not exactly clear to me, what your problem is, but let me explain 2 cases:

1. If you want to have your sub-vi displayed, then press rmb on the vi-icon and select vi property. from there select category Window Appearance and then check either Top-level application window or dialog.

2. If you want to have different vi's running together pressing 2nd button while first vi still runs), then you will have to use the vi-server method to call your sub-vi's. For infos on this search this site, ni.com, and the lv-examples (check include ni.com examples in the example finder).

Didier

I have finished a software with the labsql,but when the software runs ,the used momory becomes bigger an bigger.at the begining ,memory is 41M,serveral hours later,it is over110M :question:

thank you

Quite hard to give any advice, since there is not too much info.

From what you said, it seems to me, that you open references to the sql-objects, but not close them. Check that every single call to "open reference" is followed (after the work on this reference is done) by a call to "close reference".

Didier

This is how I would like to see it work...

:thumbup:

Nice Idea, with a slight drawback: It makes your code not easier to read. Looking to this code after a few months might get quite painful, because you don't remember which controls are assigned to the property node. Having to double-click on it, check on the frontpanel which controls were selected, go back to diagram and repeat the process for the next property node seems IMHO not really helpful.

Didier

users of the application. sorry abt the confusion. we need to log any changes users make to the db and make sure they only have access to allowed features.

What are the data you store?

If you can use a standard dB like mySQL or similar. They include by themself user-management, change logging and incremental save (the whole history is kept).

If you need a file-based system, check tools like subversion (SCC) They are usually used for version controlling of program development, but I'm sure you could also use it for your purposes.

Didier

and whats next ...

Another question: Do you have the "pro" Version of LV (not base or full)?

I wouldn't write off clusters so soon, since it sounds like your alternative is to wire 20+ boolean controls to a subVI? I'm fairly certain that would fall under the category of "overcrowded"

... Following.

From your first post I understood that you wanted to bundle/unbundle just to pass data into a case structure. But passing 20+ Elements to a sub-vi I would definitely also use bundling.

Regarding the paths: did you consider that in an exe the LV-path is of sort: <base-path>\<exe-name>.exe\<vi-name>.vi

I didn't test it, but did you try if it somehow relates to the "read only" attribute of the file? When copying something from cd and you forget to uncheck this attribute it gives you quite some headache.

Seems logic, but here is no property caled Origin in Front Panel reference... :headbang:

Did NI remove this (IMHO) useful property in LV8?

HI,

Thanks for the reply, figured out myself after 2min from the post .

Now I have another question, anything new with scripting and labview 8? it's a great tool and is funny to get stuck in labview 7 just for scripting

thanks

Seems we're getting control back:

Property and Method Selection...

Dynamic Generation of...

So here I am still streamlining my program to be smaller and easier to modify. First question should be easy; do clusters effect the performance of a program? Example; Passing multiple wires into a case structure vs. putting them in a cluster and while in the case, unbundle by name to an indicator?

I wouldn't recommend this. Use bundle/unbundle more in the case when you want to pass data to a sub-vi and its connector pane would get overcrowded.

Second question, subpanels. When is it a good idea to use them. My program has an area that displays boolean data as FP LEDs and they only get written too. Would it benifit me in any way to make a seperate VI for them, use a cluster, and call the VI into a subpanel? I wish I knew more about how certain things effect program performance.

I use sub-panels, usually as a sort of tab-replacement, e.g. when you have a program that can perform different tasks but only one task is used at a time.

Third question; When using OpenG vi's, after compiling with LabView's application builder, do the users have to do a full install or can they just copy the new exe into the program directory? Or do I have to do more? I ask because I'm using the extension replace vi to change the .exe to .cfg for user config data to be saved but during builds, the more I use OpenG the more beta testers complain of broken features

OpenG is a set of vi's (mostly) written in pure G. So every beta-tester who tests your code in the LV development-environment needs the openG toolkit. In built exe it is no issue. The vi's are compiled into the exe like every other sub-vi. Regarding the licensing, Jim could you enlighten us?

If I remember correctly The footer (and of course the header) height is automatically increased, if your entered Text requires it.

I don't have LV8, so I can't look into your code.

But usually to set an alignement on a panel use the property "Front Panel Window>Origin". It sets the coordinate you supply to the top-left corner.

How can I programmatically change the hight of the footer in a word document.

Do I have to use a property node or can I use the report generation toolkit.

I'm still using labview 7.1 on a windows 2000 platform (2000 office)

Theo

You would for sure need any sort of activeX. The report generation toolkit does nothing else. If you are familiar with the win-API and MSDN you can find the needed property node and class-hierarchy yourself. Ohterwise check the report-generation toolkit, especially the vi's found in <LabVIEW>\vi.lib\addons. If you have the toolkit installed there are a bunch of useful vi's there.

Hi All,

This should be simple. Any ideas on how to read an Excel file with csv extension using LabVIEW? I am stuck at reading the file using the read from spreadsheet file function.

Thanks!

It's what I would have said to use. Just define as separator a comma (instead of the default tab, since "csv" means "comma separated...") and you get a 2d-array with your data. With the index-array select the columns.

...just came to my mind: check that eventual values in your file do NOT have comma as decimal separtor... or you end up with comma as decimal AND element separator, and therefore with a big mess

I know I should post up my code to make this easier but I don't feel it necessary yet. My delema is this; I'd like to move all of my configurable data to a seperate dialog vi. How to go about this is just beyond me right now. I know how to pass in and out of vi's but my large application uses these user configure items in multiple places. Which means I'm using local's in a lot of area's. Not a TON, less than 4 of each but there are a good 20+ configurable user values from file paths to general numeric. In the main program, it's easy because right now the local variables are just that. If I move to a seperate vi for the configurables then there will be no more locals . Oh so confusing. Maybe I should just re-write all of my code in a better architecture because right now I'm getting overwhelmed just looking at it.

For such problems, I usually create one ore more GOOP-Classes (in my case OpenGoop). This way all your parameters (attributes) are grouped in the class and you can create many reading/writing and processing methods with your attributes. You end up with just one reference (to the instanciated object) you pass through your vi's to access the attributes.

Also create a method that displays all your parameters in controls. At runtime you can modify them and with an "OK"-click they are written back to the object attributes and file.

If you follow the rules of GOOP-programming your program will be free of race conditions. For an example check e.g. Popup menu, or the ini-file-vis.

Didier

the husband of a friend of my wife has one and he is having lots of fun with chasing his cats with his robot and his self-developed "cat-chasing"-algorithm... lol

What a coincidence, I just read such an article in the c't magazine (german computer magazine)

... as child we did such "cat-chasing" with remote-controlled cars, also quite funny (for us, not the cat).