Jump to content

jbjorlie

Members
  • Content Count

    31
  • Joined

  • Last visited

Community Reputation

1

About jbjorlie

  • Rank
    More Active

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since
    2011

Recent Profile Visitors

471 profile views
  1. 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
  2. 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?
  3. 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?)
  4. 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.
  5. 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...
  6. 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?
  7. 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!
  8. 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
  9. 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.
  10. 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?
  11. 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?
  12. 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:
  13. Excusing my horrible flowchart design, are we talking about something like this?
  14. 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.
×
×
  • Create New...

Important Information

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