GregFreeman

I know this went a bit off track, and admittedly I haven't read (see: understood) all discussions. But, I can see a benefit of must implement in a current app I am writing. I want all child classes of my parent "output" class to implement a "write data" method so they fit nicely into my framework. It makes sense, any output should have a method to write to that output. The problem is the connector panes need to be different. Think about a digital write vs. an analog write. I want these to be enforced in all my "output" child classes, but I can't because one needs an array of booleans, the other an array of doubles. Go ahead, throw the tomatoes.

deleted

I seem to be posting ad nauseum these days, so thanks for bearing with me. I finally get to architect a large system and put my lot-o'-smaller-system-practice to good use. This software will be on two different systems, with slightly different configuration so I'm trying to make it easily adaptable to both. The difference will be in the data channels acquired, processed, and their corresponding action when some condition is met. So, for example, I may have a channel and when it is out of a specified range it sets a digital out or closes a relay, or sets another analog voltage etc. My idea was to have a "condition check" class that was injected into a channel data class. That way I could define subclasses of check condition such as range check, frequency check, digital line change check with a must override "condition met" VI. This would allow me, between systems, to easily define new classes for checking data changes and plug them in. I then wanted to also inject a class defining what to do when condition is met. For example, close relay, set digital out, notify user etc. This all seems like it will be extremely flexible which is great, but it breaks down for me due to the fact that it's on a per channel basis. I could process 50 channels and x number of them could all have a digital out to set based on a met condition. If all those digital outs are in the same DAQmx task, I don't want to make 3 individual calls to the DAQmx write function. I want to compile them all into one message "set these digital outs on this task" with an array of the lines to set so I can call the DAQmx Write function a single time. So what I'm wondering is 1) is my best bet when processing channels to keep track of all the conditions I will set on a per channel basis, then have a method to compile all the ones I can into a single message (i.e. set all these digital lines on this task) or 2) Is there a better way that would greatly simplify this? Thanks, and Happy Easter!

Confirmed. I don't see anything blatantly obvious that you're doing which would cause this. You aren't closing your references on shutdown, but this is crashing almost immediately. I did noticed if I slowed the bottom loop down I didn't have an issue, but I also didn't run it the same amount of iterations as the loop ran set at a 10 ms wait. Sorry for the limited testing, but I have atleast confirmed this. Someone else may see something you're doing that could cause this, but with my quick look nothing glaring popped out at me.

Has anyone used this for LabVIEW development? Any feedback on this compared to other virtual machines like VMware etc?

I went to Purdue and have seen both of these! My Facebook was blowing up with them the last couple of days. There's a more recent one; thrift shop parody but I will have to get the link to it later.

I believe this also makes them ascii sortable by date

That's what I've done for now (well, combobox). Thanks!

Let me know if anyone can reproduce (or not reproduce). The interesting thing is there is a config dialog example I downloaded a while ago that saves configs that have DAQmx device references like this and it works fine. I'm not going to attribute it to user error yet, but it was a long day so maybe I'm missing something obvious here.

See attached VI. Place a probe on the wire coming out of the Unflatten from XML. When the file is reloaded, the device is empty in the private data. If you look in the XML file, it's there. Is this expected behavior? I'm using LV 2012, I haven't confirmed on other versions. issues.zip

Just curious, have you run into an issue with memory, storing all that state data for a single change?

Hmmm, maybe I didn't look carefully enough. I'll browse through it again.

So I have been contemplating and am going to think "out loud" here. I think this is basically what you are saying Shaun, but I'm going to reiterate in my own words. I am talking solely about value change events here. The stuff with the graphs charts etc is nice, but I don't believe state changes to a graph are captured by the event structure, so you'd have to be polling for any property changes. Man, it would be nice if changing properties fired event...anyways, I digress. My thought is have an "Undoable" object with must override undo and redo methods. Then, this base class can hold a reference to the control that was changed. There can be child classes for string undo, int undo, etc all the common data types. That would allow for a programmer to implement app specific undo/redo methods for things like clusters and arrays of clusters and so on, but also reuse the classes already written for string control changes, numeric changes etc. These "undoable" child classes would simply hold the previous data. So, when an undo happens, they have the control ref and the previous value and can set the UI control to that. One issue I can see is determining which undoable child class to instantiate based on the control type which had its value changed. I guess I could have some sort of "undo type factory" or something along those lines. Again, just thinking outloud. Would this work?

So I found Fabiola's example here and I really like it. However, I would like to make something a bit more generic, where the input item is an object rather than a cluster. The different objects that represented undoable operations would have a must override "undo" and "redo" method which would handle how changes to that object are undone or redone. Problem is, I have to start inheriting everything from some base "undo/redo" class in order to force must overrides. I feel I am skirting around the edge of why interfaces are valuable in JAVA. I could just implement an undoable and redoable interface for my GUI objects I want to have undo redo operations for. Has anyone implemented this in a bit more generic way that ports from app to app? Fabiola, if you're reading and you can voice your opinion or any changes you've made since that code was posted I'd appreciate it! Thanks.

I have a reusable communications manager I have been writing. I'd like it to be used for CAN, TCP server, TCP client, etc. Anything with Open, close, read write VIs, just inject the proper class at startup. I am using a mediator which launches an "open connection manager." When this connection manager gets a connection, it notifies the mediator, passing it the connection, who then launches a parallel reader and writer. That's the gist of it at least. I got it all working well for the server, but when I went to implement TCP client, I realized I was missing something big. What to do when connections are dropped. This was easy, the server doesn't care, it just listens as always, and the reader & writer will error out and close. But, with client connections, they most likely want to reconnect. With CAN, someone may want something different on a per-application basis. Has anyone managed something like this before? How do you handle it? I'm thinking some error handler with dynamic dispatch and must override will work, but I'm not entirely sure how to implement it all together. ____________________________________________________________________________ Just a more detailed view of my architecture in case it helps: The mediator is passed an app specific child of "transmission" class upon startup (Transmission is an abstract class with all must override VIs, open close read write). This child class would be something like TCP client, TCP server, CAN client etc. The mediator then launches the "transmission open manager" injecting the child class in. So, essentially, your app specific class is injected on a transmission class wire into the "transmission open manager." The manager delegates to this injected class to open connections. When a particular connection is made, it is bundled up into the app-specific child of transmission class, and the class is passed to the mediator. The mediator then launches the reader manager and the writer manager, injects them each with this class and they execute the appropriate read/write VIs via dynamic dispatch. Hopefully this makes sense. It seems to work quite well, but unfortunately I cannot post the code. My idea here is similar to an HAL. If you want to add a new class, say UDP client, you just subclass transmission with your app specific UDP client class, create the must override VIs and you're done. Please ask for any clarifications if needed.

I expect you will be wearing your finest pearl snap button down (up?)

Is this an option if you activate private properties and methods?

Very true, I have a small paragraph telling me what the test is and the parameters to measure, that's it. Basically "measure this data." That is my requirement . (Can you say, "T&M" anyone?). I have gone the route of modertately flexible, with some child parent relationships etc, allowing me to change more easily in the future should I need to. But, I haven't gone to all the great lengths to determine what will need to be DD, how much abstraction do I need, etc. For now, I think this will work just fine.

Shaun, I think you are getting at what I was actually just thinking. For instance, this is all VISA communication (for now, and I expect that won't change). I was thinking of having a file then if the device changed, just update the commands in a file for that device, point the software at the file to be read, then send out the commands through VISA. Now I don't need a class for each device, I can just have a "VISA black-box device" which has a read and write that just wraps the visa read/write functions and sends out the appropriate commands

I think this is my problem: I try to make things overly flexible. Such as asking "what if they use a different device" turns into "what if that different device is tcp instead of gpib or serial etc". And then I over engineer...

So i have a relatively simple test program I'm writing. This system has a device. I doubt this device will ever change, but I suppose it could. This may be a case of "what I want to do is not worth it" I'd like to add an abstract parent class which defines the functions needed for this test. They would all be dynamic dispatch and must override so if the device ever changed, a new class could be written to inherit from the parent class and boom all functions would need to be overridden for this new class. Once they are, the program will still run as if the device was never changed. But, I don't know if with this necessary quick turnaround time it's worth writing a parent class for something like this. This may be a case of real world vs. ideal world but I just wanted some suggestions.

When I am working on programs, I often put my parallel processes in a class called the "<parallel proc name> manager" that has a VI with its loop/process. What I am finding is that these managers will need some subVIs to keep them clean, especially in states where a decent amount of processing is done. I realize then, that these methods are always only being called only by this manager on it's loop/process VI so that said, they are always being called on the block diagram within the class. So, to me, it makes sense to make them private. But, then I end up with managers where all the methods are private, because their only real methods are wrappers to keep the BD's clean. Something seems somewhat off about this and I was just looking for people's thoughts, comments, and suggestions on better ways to handle this.

Empty arrays on the first test

Well....did you try the solution above given by Mellroth..

I think the message mediator approach is a good one. See: Mediator Pattern. I had used this for a while, thinking I was quite novel, and Daklu then told me this pattern actually has a name. Not so novel anymore . What's nice about this is that you can generate generic processes that just spit out messages, and then you can take care of application specific stuff in your mediator. Think, for example, of a generic TCP loop. My TCP manager that I reuse reads a fixed header and then the message data and just sticks it in a queue. It can be reused on every application. I then let my mediator decode the message as it pertains to that application and sends it where it needs to go. Others may have better suggestions, but I doubt you can make something totally generic as far as data storage goes because as I have learned every application needs something a little different. But, you may be able to use OOP to create a data logger class and your application specific code can inherit from this class. You may even be able to create a "Data Logger Manager" process which you can reuse, using dynamic dispatching and delegation to call application specific methods for logging. This way the architecture can stay the same, but the handling of the incoming data can be delegated to your application specific logger class. Does this make sense? To help clarify, I can go back to the TCP manager I have. This Manager holds a "Network Messenger" in its private data. The network messenger can be UDP or TCP. The architecture is the same (open connection, read, write, close, etc) but the specific method that is called will be either TCP read or UDP read/write/close etc based on what object was initialized in the TCP manager If you're not familiar with OOP, this may all be very greek to you and you will have to get some other suggestions. Logging is often very application specific which it makes a bit harder to architect in a totally reusable, never-write-this-again way. But you can take some steps to make it a bit more flexible. Others may have more (see: better) input. Here is an example of a logger from NI's website, but admittedly, I haven't used it so I'm not sure how valuable it is. As far as I can tell, it seems like a valid example, though.