Jump to content

didierj

Members
  • Posts

    363
  • Joined

  • Last visited

    Never

Everything posted by didierj

  1. 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
  2. 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".
  3. 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
  4. 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. I wouldn't try to write to the cluster itself (by plopping the cluster onto the block diagram). Since you can instanciate several objects from the same class your data isn't stored in the typedef cluster, but somewhere behind a reference. The primitives "get data to modify" and "set modified data" allows you to read/write from/to the data without suffering race conditions. after calling "get data to modify" your data is locked until you call "set modified data". a second "get data to modify" will wait until the lock is released . 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
  5. :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 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.
  6. 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
  7. Try to avoid asking the same question in different subforums. How can I call...
  8. 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.
  9. 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
  10. 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
  11. 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
  12. 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
  13. Another question: Do you have the "pro" Version of LV (not base or full)?
  14. ... 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
  15. 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.
  16. Did NI remove this (IMHO) useful property in LV8?
  17. Seems we're getting control back: Property and Method Selection... Dynamic Generation of...
  18. 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. 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. 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?
  19. If I remember correctly The footer (and of course the header) height is automatically increased, if your entered Text requires it.
  20. 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.
  21. 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.
  22. 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
  23. 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
  24. 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).
×
×
  • Create New...

Important Information

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