Jump to content

jr_BobDobbs

Members
  • Posts

    8
  • Joined

  • Last visited

LabVIEW Information

  • Version
    LabVIEW 2014
  • Since
    2009

jr_BobDobbs's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. Thanks Rolf, that's the route I was figuring I'd have to take, I just thought that I'd consult with the experts here before going there.
  2. I've got a working event logger that uses NLog.dll in LabVIEW. It does 95% of what I would like it to do, but I wanted to implement adding programmatic filtering. To filter a log event, you need to first create a rule (which works fine in LabVIEW), and than add a condition to it's list of Filters. The API reference for the ConditionExpression is here; http://nlog-project.org/documentation/v4.0.0/html/T_NLog_Conditions_ConditionExpression.htm There's an Operator that will convert a string to the Condition object that I need as an input to the ConditionExpression. But, since you can't call that in LabVIEW, anyone have any ideas on how to get around that? I suppose I could write a quick .dll myself that inputs a string and outputs the appropriate Condition object. Just didn't want to go down the path if I didn't have to.
  3. Here's what I think I'm going to go with. The base class is a frame, which consists of a name and the enqueuer for the Client. It has two child classes, Function and Collection. A collection is composed of Functions or Collections and iterates a number of times. So, in my hierarchy, a collection covers the Group and Step requirements, with one caveat. It has to know if it's a group, because if it is it does something special each time it completes an iteration by incrementing a cycle counter managed the Client Actor. The function consists of an Array of actions, or in the case of the Optimized Action, the array of actors and the algorithm for how to optimize those Actions. The optimize algorithm will be a plugin, so it's kind of like a mix of Composite and Decorator. It all breaks down to JSON and seems to work relatively well in the prototype stage tonight. Any thoughts from anyone on possible pitfalls here? For the record, the Client is an Actor to integrate with the rest of the applications architecture which is actor based, also, just passing it's enqueuer to each Frame allows me to maintain the Frame object in the Client, and not have to worry about how each Frame talks back to the Client (since you can't have place an object in the Class Data of a class that belongs to a Class holding the first object in it's Class Data, although I think there's an easier way to say that).
  4. Thank you, I was starting to go a little crazy. It seems over at ni.com depending on the white paper you're reading or which example you're looking at the terms composite and composition are thrown around to describe both rather wily-nilly. I hadn't considered your implementation that you put in your second post, but I'm going to give it a shot. Last night I came up with a base object called Frame, which had an Execute method. Everything inherits from Frame and on creation just passes a JSON message down to each child, cleaving off what it's childrens definitions look like. In the Execute of a Group, Step, and Function it pops the next child from a stack of children, as well as increments the appropriate counter (Cycle, Repetition, etc...) Then each Action is built upon the base class, i.e. a Move action which calls the appropriate drivers to move in it's execute, etc... That way my client just calls Execute on the top-level Frame and it recursively executes all of the actions. I also pass a reference to my Client down the chain so that I can check if we're paused or stopped, etc... This is obviously not the Composite Pattern, more like just inheritance. I've got a working system currently, but my biggest concern is how difficult is it going to be in six months when my boss comes to me and says he wants to put another level between Step and Function. Or, like this morning when they come to me and say that it would be really nice if the Actions could be optimized, like, if DUT1 is lined up to get 3.3V and that in turn lines up some other DUTs in place to get the voltage they require, go ahead and put the voltage on all of them, you know, non-sequentially, which now means my Function object has to evaluate all of it's Actions first and re-arrange if necessary.
  5. Can you point me to this example? Searching the example finder yields nothing, and the only vehicle example I find in the //Object-Oriented Programming folder of examples deals with custom probes as doesn't seem like an example for composition.
  6. This is the pattern I've followed before when writing sequencers (without using OOP, this is my first), but they were just as you described. There were sequences and frames, frames did an action and sequences consisted of frames or more sequences. So that at least is familiar to me. The problem with this particular application is that historically (I'm re-writing existing unmanageable code) they've used this rigid hierarchy and I'm having trouble generalizing it down into a basic frame and sequence problem. The problem I'm solving is not test sequencing, but it's close enough to it that for the benefit of explanation I'll explain it that way since I think we can all understand that (and since I can't explain what we're really doing due to NDA concerns). So, consider that there's 8 DUTs. These DUT's are more or less alike and will be tested by the same piece of hardware. This piece of hardware applies a voltage to each DUT, but can only apply that voltage to one at a time. The amount of voltage that's applied is specific to a sequence that is specific to each DUT. So DUT1 may get [5v, 3.3v, 5v, 1v, 3.3v] and DUT2 may get [3.3v, 1v, 5v, 3.3v]. Which step of each DUTs sequence that we're on is determined by the group. So, there's a Group0 which does some pre-work, but applies no voltage, and starting with Group1 we apply the first voltage. Also, each Group may apply the voltage in a little different way, maybe we pulse the voltage 5 times, maybe we apply a voltage and wait, than apply the same voltage again. This is defined by the Steps. So, all of the DUTs have a Step performed on them, than we go to the next Step. When we run out of Steps we either increment the cycle count of the Group, or move to the next Group if we've reached the last cycle of this particular Group. Steps contain Functions, and each Function is performed fully on a DUT before you move on to the next DUT. So DUT1 has the first Function performed, (which is something like, move the DUT to the voltage source, apply the voltage, wait, stop the voltage), than DUT2 and so on until we've done all DUTs and than we go back to DUT1 and do the next Function. Each Function consists of the specific Actions that define how to apply the voltage, the move, voltage on, voltage off, etc... There's also those random requirements that are thrown in (that always caught me up on my CLD and CLA test) like, the last voltage that we apply always has to be applied at the same time for all DUTs, even if some DUTs have shorter sequences than others (so in the above example the 3.3v of DUT2 would get saved to run with the 3.3v of DUT1) and some certain aspects of a function (repetitions for example) are specific to what voltage we're applying that cycle. Sorry for the wall of text, hopefully it makes sense. But this is the reason I'm a little stumped. I agree that the basic premise of this structure is composite, but I don't know how to generalize this and still capture some of the gotcha's. My first iteration of code had me building a specific object for the Group, Step, and Function, but in reality they basically do almost the same thing. Get the current child, pass it to the sequence engine, increment an iterator, etc... and I had a ton of repeated code, so I knew that was wrong. I guess a specific ancestor for each of these objects fixes the problem of duplicate code, but again than I fall into mis-using the pattern. A client can not handle a Group with a similar interface that it uses for a Step or a Function, because of the small differences I'm seeing in them. Or perhaps I'm looking to hard at the problem and not seeing the whole, which is where the solution really is.
  7. Hi all, first post here, hopefully it's the right place. I posted over on the dark side in the AF forum but was lead into the direction of the composite pattern rather than to use the AF for this portion of my application. The reasoning seems sound, so I didn't want to continue my post in the AF forum and it seems like there's a little more OO talk over here than there. So I read the wiki (http://en.wikipedia.org/wiki/Composite_pattern), and looked at the Graphics example in the OO shipping examples in LabVIEW, as well as the OODesign.com page for it (http://www.oodesign.com/composite-pattern.html) but I'm still a little lost on how to implement it in my application. I'm trying to create a sequence engine, the basic system looks like this; Protocol - the definition of the "sequence". Group - The highest level of heirarchy, contains an array of children called "Step". This iterates between one and N times. Every time a group iterates it increments a variable used in another part of the application. Step - Next level down, has an array of children called "Functions". A step can have anywhere from one to N repetitions, essentially a For loop of "Functions" Function - Next level down, contains an array of "Actions" Action - The base component. This is what actually executes. The composite pattern says that there's an interface object and than a leaf object and a composition object which both inherit from the interface. The leaf is where the action happens, the "Execute" as it were. So I think my Action class is a leaf. But if so than the Function, Step, Group, and Protocol, are all variations on a composition and that seems to not make sense to me. I feel like I'm not looking at this the right way, or if I am, than there's some piece of the puzzle that I'm missing to make this all fall into place in my head. Any help would be appreciated to try and point me in the right direction.
×
×
  • Create New...

Important Information

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