jbjorlie

I understand, I think. Are you suggesting the DD VI takes the "from file" object as its dynamic input and takes the parent as another input? It would then use the "from file" object to typecast the new child... It's not really "Instrument" class, it is Instrument Control class and "Control" is actually Control Mediator. I think it is OK to call View a child of Instrument Control in this case. View is communicating with and launched by Control Mediator. Control Mediator cannot be a parent of View but it does need to retain some View parameters to pass between Views. At times there will be no View open & something needs to retain the information or I will have to go fetch it from all the Models again. I suppose you are right, I can just have the mediator send the necessary information to the View but then I have to store it somewhere. That is why Control Mediator is a sibling with View and child of Instrument Control. Poor naming perhaps but I retain that right as a LabView programmer and not a computer scientist

I just posted this on AF site but thought KNOW the LAVA LVOOP group would have some elegant solutions: I have a Child of Actor.lvclass called INSTRUMENT. INSTRUMENT has children VIEW and CONTROL. I launch the desired VIEW from an VI owned by CONTROL and I need to insure this new VIEW object inherits INSTRUMENT's current data. The picture below shows my problem. I choose which VIEW to launch from a path, so it's wire will be of type LVObject until run-time when the correct class is chosen by the file name. I thought of placing a ToMoreSpec Class into the LVObject reference but that will screw up the selection of the Actor Core wont it? There must be a way to do this without making a case structure holding all possible VIEW objects, right?

Without getting off-topic too much here, don't you guy's think someone wanting to pass the CLD exam would want to take the fastest route to success? I know I have heard people here and there stating that the CLA exam was difficult due to the time limit. Isn't writing LVOOP code just going to make it harder? I love learning and using LVOOP. It seems like an improvement for scalability and save time over the life-cycle of a project, but unless NI makes a change to the test format itself, what's the benefit of using it for the exams? That said, LVOOP is massively under-exampled so on the idea. (BTW ShaunR, I see u no longer have your "lvoop bugs" jingle. R u now a convert?)

yes, it has to

As a fellow newcomer to LVOOP & LapDog I just wanted to plug them both ! My previous code involved some use of the Variant + String messaging and a bunch of plain old LV-Level1 code from myself and the previous demented LabView guy around here (LabView, I have come to KNOW, is the most commonly used programming language among lunatics...myself included). Anyhoo...My 2 cents is that LapDog may be the best teaching tool for LVOOP out there! It allows me to keep parts of my code that use message-driven case structures with minimal adaptation. Once I have exchanged LapDog for the old Queue I can add a "default" case to accept the message object and dynamically dispatch it! That's great for VIs where I don't have time to wrap every case into a method or I need to adapt to somebody else's code. Also, for cases where you just need a single value(int, bool, string) you can just use the "native" message types.If you use a lot of cluster-variants in the old code it may be less feasible to replace but most of my messages had the string doing all the work.

Thank you, that pretty much clears everything up! I do already have this "Command" class except I named it "Messages". Hope that name is OK... Not really a problem adding the downcast & I understand the "why" better now. Could I put the downcast into the Command class Do.vi and then override it for all my child Do methods? I have trouble understanding the override in general vs. the Dynamic Dispatch. For example, in the Actor Framework, there is an ActorCore.vi override where the parent ActorCore.vi unbundles xxxQueue from the parent class and uses it for Do message receiving... How is it possible to work on the parent object when the input object is a child which may not have xxxQueue in its object cluster? Does a child class also contain all the info of its parents? That last part is probably a new topic but also probably something obvious & I don't want you guys to exile me to the dark side...

I'm sure the root of both problems is the same, thanks! Have you received any update on the CAR? How can you check the status of a CAR?

I wrote a big windy response to this and then clicked on one of your pictures...bam! response deleted...I hope HTML 5 fixes that kind of thing. Anyway, here's what I said: Perfect! Thanks for the graphic response, it's just what I had in mind only couldn't get quite right. I love that you pointed me to the OpenG Get Data Name vi. That solves the problem of needing a front panel control and property nodes to get the name. I'll have to save as variant but that may be better anyway. One question: Why not use a typedef? I do believe that to be untrue based on all the interest of other posts on the subject!

I have no answers but run into this all the time. Help us, please! I have found that making sure the background of the labels and scale numbers are not transparent seems to help. It also seems to help if I initialize the scales with the same number of digits in width. Another one is to make sure the plot area is small enough to allow all the scales to appear without re-sizing. None of those work reliably or very well...I hope somebody has a solution. Did you post this on the dark side? Jeremy

Hello everybody, I hope Daklu can add some input to this question but it may apply to LVOOP in general so here goes. Background: I am using LapDog messaging to send Objects as messages. I have classes which are children of Message.lvclass. The DeQueue message element is, I believe, an object of Message.lvclass Problem: It is not possible to direclty wire the message output from "DeQueue Message" to the input of a Message child class object's vi. Here is how I wired it with failure: This was a success: Is there a more correct way of doing this? Ultimately, I would like to have dynamic dispatch vi's that DO based on the class of message from the DeQueue vi. Thus avoiding much of the need for the case structure. Actor Framework-ish without the strict overhead.

Very good quote! If I ever throw that into a presentation I'll give you credit. As for the holiday dinner, it wasn't so much of getting sidetracked than of many related but distinct conversations going on at once. Not bad, just hard to follow for my experience level. Thanks for all your input, I am glad you came back with some pitfalls of SV's and I am now thinking of messaging all my process values, LED's and whatnot. The result will depend on my skill, I suppose, and if it is too slow or creates too much complexity in message handling I may give your vi registers a try for those needs. The registers are completely self-sufficient, yes? If I remember right, they just drop onto the block diagram without the need for any database or administration type vi's? Do you think they will be highly portable to future LV versions?

Great information fellas, I hope I can return the favor somehow someday. Thank you, I had the model looking more like the set of instrument drivers and not the loops that control them. Now it is much more clear how I should be approaching this AND how to name what. There are many more questions coming but I need to take what I've learned and put it into action first. Also, I'm leaving the Actor Framework to a smaller project in LV2012 and walking the LapDog through this one It sure is tempting to try and use them all though! Why is it so painful and expensive to be an early adopter?

I assume your "Model" is self sufficient and processes internal events through its own "mediator(s)" thingys? If not, what happens when a change in the process value necessitates some additional actions on behalf of the model? Overheating! Turn heater off, ... Does that go through the VIEW and back down? Maybe I am assigning too much responsibility to the Control and it should not be doing things like running PID loops? With that in mind, this updated flowchart may be inaccurate but I would appreciate more feedback on this:

Excusing my horrible flowchart design, are we talking about something like this?

Hey, that seems like a reasonable way to go. Thanks for taking the time to paint a picture. I can just subvi that for loop and have a nice plug-in file reader where all I need to do is delete unused defaults from the array CONST_Config... but then I have a front panel control in the subvi don't I. This is only a problem because I want to know all the config key options in one maintainable list somewhere. Are you talking about changes in what the possible keys are from v1 to v2, etc? If so, that's what I mean by wanting a master list of possible keys to use for initializing any "actor" class. On the mundane vs clever note, After spending many nights learning LVOOP and complex messaging systems I sometimes think spaghetti would be easier to follow. However, the flexibility and maintenance of LVOOP seems worthwhile. So long as I can get config data into the objects in a standard lexicon/typedef of keys and figure out some way to standardize my message objects for masses of actors all will be good. BTW - LapDog rocks! Perfect blend of "LV-legacy" and LV-OOP messaging capabilities.

I have searched extensively and cannot find the example anywhere in the 2012 Beta. Could you point me to it please?

Yup, looking at that while you were writing this...now looking for eraser... You've been to Kazakhstan too 'eh? Looking forward to it. Does NI only allow beta downloads from USA? Texans never could play nice with foreigners. I think I'm getting how to do that but now I'm looking forward to the example in 2012. It's only 638 MB away...630MB!

I do expect the user to make changes, especially the PhD's! I like that, but for troubleshooting with a customer on the other side of the world it is just easier to have them send me one config file. Won't this land you in the Program Files directory? That's where my .exe is and I thought you cannot write to that in Windows 7 without Admin privileges? I used to store the config.ini file there but was thinking of moving it to the root directory and allowing edits through the application builder. I don't want to bury it in AppData or UserFiles/x/y/z/1000FoldersDeep. This application normally runs on an embedded PC with not much else on it so I want to store test files, test setup files, and config files in a big folder that's easy to get to in a couple of touchscreen taps. It's hard enough getting in/out of windows folders with a touchscreen and desktop shortcuts seem to get lost often by users with big greasy fingers.

That's what gets me, having to carry a "dictionary" to tell me what I'm unflattening...even worse, a dictionary for every class. I think I would prefer to just save it all as text and change it once it is needed. Then I can convert it to an int or dbl, path or string, depending on what I need the value for at that moment. This bothers me that you cannot treat an object as a control cluster privately. I had the thought that I could use the Actor's object as the config cluster since the only other thing it carries is a CallerQueue. Using my Actor-ish / M-V-C (I'm now reading that book you referenced!) / LapDog abusing framework, I only need the Actor object for LaunchActor so it doesn't seem to create more overhead by loading all the config info right into it. Just can't figure out any way to pull the label.text property out of an object's controls. It seems silly to need a typedef to represent an object. I guess if the object is just wrapped around the typedef it's ok but I don't like all those extra bits in my project. Looks like I'm sticking to this unless somebody tells me it just "ain't right". I'm not ready to add XML to my LVOOP newly-stuffed neurons just yet.

Here I use 2 typedefs to compose a config object. One for string key values and one for numeric. This way I can fill in default values and only use the config.ini file to override those defaults. This VI is called when I want to initialize a particular controller (UCA Temp controller) and the object out will go into a Dynamically Dispatched Launch.vi Is this ridiculous? Suggestions for a simpler way?

That's where the train of thought led me: I'll open the file, read the list of Objects and their respective channel number, then send the file reference into a ConfigObject.vi for each object I need to configure. Those objects just tack the channel number onto their name and read all the values in that section [(ObjectName).(ChannelNumber)]. I was going to read the key values right into the object since a class "object" is a cluster but I just found out you cannot use a property node to read the name or write the value of items inside a class control. I will have to place typedefs of controls into the object and do it that way.

What I was thinking was to load all the key/vals into an array and then dole it out to the proper config object for each device. That way I am only reading the .ini file at the "Initialization" stage and I can send everything where it is needed as message objects using that handy dandy LapDog. It just seems like that's going back to the old String/variant cluster that LVOOP and LapDog made obsolete. I would have to search though it and transfer the needed values into the CreateConfig(data).vi. BUT, if I have a CreateConfig(file).vi for each Config object then I need a Section in the .ini named after that object. What happens if I use that object for more than one channel? Have the CreatConfig(file).vi take a file and a channel number! Now I think I get it, each object gets its own section and there's an [instrument] section that tells me which objects to launch for each channel. I read [instrument]'s values into a for loop of case structure which creates all my I/O objects. Those objects read their section to get going and now we're ready to blow something up Please let me know if I'm off the mark here.

How does Controller get data from Model if Model only sends messages to View? If my controller is running a PID loop commanding Heat & Cool Models how should it get the Temp from the Thermocouple Model? Does thermocouple send value messages to both View and Controller? Does it send a third value message to the data logger? I've gone from one to two too many Qs! ARGH!

What is the standard, or is there one, for storing configuration data that will be used to initialize I/O channels and GUI "stuff"? Example Part 1: Executable needs to read from a file some UI initialization Info: [GUI] type = touchscreen size = 800x600 InstrumentName = GS342 Language = Englusskie Example part 2: We need to know what class of I/O to use for each channel: [GS342.CH1] ID = MicroFlex ComPort = Com1 PropotionalBand1 = .35 ProportionalBand2 = .67 [GS342.CH2] ID = USB-TCAI Node = 0 InPort = 0 OutPort1 = 0 OutPort2 = 0 Slope = 3894 Offset = 49920 [And on and on...] The "ID" tells me which class to use for that channel and the rest of the stuff has to go into that classes vi set somewhere. My question is: Is there a better way to do this? Remember, users need to be able to change these values and I want them to be readable for troubleshooting. Also, is it best to have a library of all possible values and read them into a typedef cluster or should I read them as an array of Name/Val pairs and then pull them out in the class vi that needs them? I cannot just white them into each class because they change (Proportional Bands need to be tweaked, etc...) I also would like to keep the property options somewhat standardized (ID, Max, Min, Pb, Com, etc...) so when I create new I/O classes I can just unbundle the options I need. Thanks, Jeremy

This thread is starting to resemble a holiday dinner at my parents' house...I do have more questions though and I'll post them later today if anybody is still paying attention. Here's some for AQ or anybody who wants to take a shot at them. I hope they are clear enough. I knew that great mind had to come from around here! However, I had to adapt from BioEngineering to Oilfield Instrumentation to stay in Tulsa so I wouldn't exactly say it's a good spot for a software guy. Without LabView we would be running instruments from a rheostat so I'm glad you're off making it modern. If you ever come through, let me know Yeah, I realized that after trying my best for a few days. After reading the paper and watching your webcast I knew that framework was the answer to all my troubles! However, when you try to mix it in to an existing project it gets messy real quick. You cannot easily follow the Actor Framework by looking at the code, I follow it by looking at the project explorer. When you try to mix the AF in with other LVOOP code & non-OOP code the project looks like alphabet soup. I would think it is desirable to have a framework that can mesh more easily, even with older, uglier code. I must need an AF-Lite...something that allows you to launch an actor, get the queue from it, and then send it messages to tell it what to do. That's it, something a Hard Drive, Air Conditioner, and Fire Suppression can all do: message = start fan, message = increase speed... I understand having a dynamic dispatch for different types of fans but why does Fan need one for different types of fan callers? I'm missing something fundamental here aren't I? Here's my problem: I want to click an .exe, some initialization routine reads a file which tells it to launch, say, a certain type of motor controller as CH1, a thermocouple input and 2 DO's as CH2, an ultrasonic pulsing PCI board as CH3, and then send their queues to a TouchscreenIdle UI, which will send and receive messages from them. The UI has no idea what they are and CH1, 2, and 3 have no idea what the other channels are or what is controlling them. The GUI sends messages asking what controls/indicators to show/hide, labels, etc...to the queues it received from the channels through the initialization routine. Then when somebody presses a button it sends that message through the right queue and the motor turns on. If they want to setup a test, the IDLE UI passes all the queues to Setup UI and so on. It seems like I should be able to use the AF for just the I/O, or for just the GUI's, or for just the Motor Controller since they are all lightly coupled. There is some coupling due to the set of POSSIBLE MESSSAGES being non-infinite but what else? How can I use the AF in this type of program incrementally? Please help a fool understand how to connect to your fool-proof machine!