Tim_S

I set my version of log-file object up as a generic file, so I passed in file name and root path to the class. I also set them up to be accessible as parameters, which is very useful for diagram space when you have lots of settings for the class. I can reuse the log file class by setting it up this way. You may have design requirements that would promote another path. Tim

I see two approaches. One is there is a generic configuration class that reads data of a particular format, but doesn't care what that data is (akin to the XML or INI routines). The other is the parents have a dynamic dispatch configuration read and write VIs that are overridden by the children. The child would call the parent routine then perform its own configuration read/write. You have something simple in finding some very fundamental items such as, say, TCP communication or log files. Tim

drjdpowell brings up a good point; you're trying to dive in to the deep end with the 100-lb weights on (do you float? sink? who knows!). Your instrument class could contain everything to communicate TCP, USB, etc. That would lead to a larger single class. Implementing the communication method as a class that is used by the instrument class would make for more reusable and code and help debug as you, for example, know (or at least have certainty) that the TCP communication class works, so any bug must be part of the instrument class. It sounds like you've got a big application and some specifications, but haven't spent much time with a whiteboard at the 10,000 foot level. You could put everything in one project. I wouldn't recommend it as it gets highly cumbersome to use. Segmenting out (e.g., "this is the part/project that does error handling and that's all it does") would be my recommendation even if to avoid mental overload Tim

You sound overwhelmed. I'm not a CS nor do I play one on TV, so take any advice with a grain of salt. A class is often taught as a physical thing. The parent is a vehicle with the children being cars, trucks, boats, etc. Taking this to code, a class becomes something like communication, priority queue, language support, analysis, data acquisition, etc. It's something that you would go to the white board to sketch out the view of the system and have a bubble for. That question will get you more answers than people answering. I'm pretty sure wars have been fought over that as well. I've got my preferences, but it depends on if I need every value, current value, streaming data, etc. I'm not familiar with RT, but there are tricks and techniques that are needed for RT that are not in Windows (at least per my coworker who has done some RT work). Dynamic loading will work (in Windows) for loading an unknown number of instruments at run-time. From your description, I would expect supervisory code will load-and-launch, shut down, and handle errors passed back from the instruments. Tim

Okay, I was able to try this out without success. The issue, as I understand it, is the file not found is related to the CommonLibrary:Display Message.vi and not the Child 2.lvplib:Child 2:Child 2.lvclass; this is the distinction shown between Child 1, 2, and 3 where 1 has no subVI, 3 has a subVI that is not part of a library and 2 has a subVI that is part of a library. I noticed this does not happen with VIs that are part of the vi.lib. EDIT - Okay my brain kicked in on something you mentioned about file paths. The Child 1 and Child 3 have a similar root directory where Child 2 has a different root directory one level up as that is where CommonLibrary is located. Making the path .\Child 2.lvplib\Child 2\Child 2\Child 2.lvclass instead loaded it correctly where as Child 1 only needed .\Child 1.lvplib\Child 1\Child 1.lvplib. Tim

I'm guessing your dt is incorrect by a factor of 6. As a suggestion, try a simpler VI and use the diagram cleanup tool to make the code more readable. Tim

I directed the tech support person to this thread and she has been reading it. I didn't have the R&D person handy to boggle at. I will be trying this when I come up for air again (perhaps this year... ). Thanks. I managed to get the source code version working during gasps of air. It's not pretty. The class file had to be in the directory and all of the other files were in a llb with stripped block diagrams. I had to prepend to the file names in the source distribution and include lvanlys.dll in the project outside of the dependencies so I could make sure it didn't get renamed. (Yuk! ) Packed libraries are definitely a preferred and more professional looking method. Tim

There is an issue with using packed libraries in this manner. The issue is when the child class uses VIs from another library the Get LV Class Default Value returns error code 7 (file not found) when the packed library is used. NI R&D through Tech Support has recommended to me to use source distributions instead, which I'm in the middle of trying. See http://lavag.org/topic/14925-code-breaking-after-one-execution/page__view__findpost__p__90248 for the test code I used.

I pretty well despise icons as they don't show me more information and take up more space. I wasn't aware that they show more information with objects, etc., yet I don't see that as enough for me to turn them on. I find Daklu's visual identification argument quite convincing as I have quite a few VIs that I routinely go into with dense block diagrams; quick identification is very important to me with these as I regularly are on the phone with someone trying to resolve a problem. Tim

Here here. You didn't use "thingie" or "whachamacallit" in there, so it's not a real technical description. You describe the challenge for me when reading some (okay, many) of the technical/theory conversations is that I'm a EE who has mostly self-taught programming. Tim

Interesting. Thanks for posting the example. Tim

Gak! You're right. That's what I get for multi-multitasking.

Hrm... I'm going to have to go back and look at the Factory pattern. The reading of the configuration is a nice, clean option. I'm not sure how passing the configuration data as a class would work. Does anyone have an example? Tim

Hrm... The only way that I can see to have a dynamic input is to use a variant. It's not my first choice as I'd probably create the child object, use property nodes to set the child-specific parameters, then convert it to the parent object. Tim

Best is very dependent on what you are doing. I'm guessing you are looking to communicate (and keep alive/monitor) devices in parallel to your main task. There's currently a thread discussing Producer/Consumer and similar architectures; it's a good read. That is only a suggestion for the instruments and not for the remainder of your system. I also recommend you look at state machines as a general item to know about. I like to use them when I have a loop talking to an instrument, but that's my style and certainly not the only way to interface with instruments. Talking to 1, 10, or 100 devices is a matter of scaling and PC resources. I find resources is a more limiting factor in there is only so much bandwidth in a RS232 or CAT5 connection, and each loop takes more processor and memory.

Only if you dequeue. Preview Queue Element would be used in this case.

I'm going to have to remember this phrase. Tim

It's taken a long time, but I've gotten a response from NI about why the plugins were not loading:

I don't believe that's possible with the install build specification. You may need a third party installer to do this. abso beat me to it... drivers require additional privileges.

In the Window Size category of the VI Properties is a checkbox "Scale all objects on front panel as the window resizes" (at least that's the English text). I think this is what you are looking for. Tim

This has been interesting to follow. The only thing I think I can contribute at the moment is a "typical" usage I would have. The advantage I see with this is that I don't have a data type to go with the occurrence nor is it necessary. Tim

UPDATE: Still in communication with NI tech support. Tech support tells me that there have been problems with packed libraries and solutions are going to take some time. I've been able to boil down the issue I'm seeing to the attached code. Child 1-3 contain the plugin code. Child Library contains the packed library plugins and the "TEST LOAD.vi". Parent Library is the packed library of the parent object. Parent Object is the source for the base plugin (parent object). Child 1 and 3 load without errors. Child 2 loads with an error 7, which is a bizarre error as the file and name can be verified and, the class and containing VIs are not broken. Child 1's "Parent VI 1" has a One Button Dialog inside of it. Child 2's "Parent VI 1" has a subVI which is part of a class with a One Button Dialog inside of it. Child 3's "Parent VI 1" has a subVI which is not part of a class with a One Button Dialog inside of it. Tim Loading Plugins.zip

Doesn't appear to be a way, but that makes some sense as there is no guarantee of the same VIs being part of both projects. Tim

I agree with asbo that you're going to need to read some manuals. Some thoughts are: Ethernet has a ping to determine if an IP address is used, but that won't tell you what is connected. RS232 will have something or nothing connected to the port. GPIB instruments typically use SCPI commands, so a "*IDN?" will tell you what is there. Some RS232 and Ethernet devices do the same. Tim

The amusing part of that is I'm the opposite... I understand occurrences better than notifiers. Though, in full disclosure, I can't ever recall using notifiers. Tim