Leaderboard

Back to top is back.

Ooh, what have I started here !? So basically it's a way of forcing the base method to be invoked even if the immediate parent classes have over-ridden it.I guess this becomes a way of achieving partial inheritance - given my original inheritance tree, a class D can fall back to some methods from class C in the normal way, but if there are some cases where class D wants to make sure class A's method is run, then it implements the methof itself and uses a helper class B which uses this trick to call class A method directly on the class D instances. Of course it would probably have been easier just to reimplement the original behaviour in class D - except that this way the A class private data in the instance of class D can be used directly and the programmer of class D doesn't need to know the details of the class A implementation to access it. On the third hand, it makes my head hurt

You didn't see the data for D change... and *that's* the problem. ;-)Let's take a simple case: Class A has a private field "numeric" (default value 0)Class B inherits from A and has a private field "numeric2". (default value 0)Class C inherits from B and has a private field "numeric3". (default value 0)Class A implements a static dispatch VI "Get Numeric.vi" that returns the value of its private numeric field.Class A implements a dynamic dispatch VI "Increment.vi" that unbundles Numeric, adds 1, and bundles it back into the object.Class B overrides "Increment.vi" to unbundle Numeric2, add 1, and bundle it back into the object. Then it invokes the Call Parent Method.Class C overrides "Increment.vi" to unbundle Numeric3, add 1, and bundle it back into the object. It DOES NOT invoke Call Parent Method. What happens when we call "Increment.vi" and then call "Get Numeric.vi"? If the object is of type A, we dispatch to A:Increment.vi, and Get Numeric.vi returns 1.If the object is of type B, we dispatch to B:Increment.vi, call up to A:Increment.vi and Get Numeric.vi returns 1.If the object is of type C, we dispatch to C:Increment.vi, and Get Numeric.vi returns 0. Would you agree with me that any time I call "Get Numeric.vi" on a C object that I should get zero as the answer? Since C has overridden Increment, there's no other way for that field to be modified. So one of the invariants of C objects is that Get Numeric always returns zero. Now, what happens if, on the diagram of B:Increment.vi, we wire a C object directly to the Call Parent Method node? When we call "Get Numeric.vi" on that C object, we get the answer "1". That violates one of the invariants of C objects. The defined interface of the class is broken. And that's a problem.

Wow. I think you've created a situation I never expected anyone to construct. The answer to your question is easy, but you make me think we ought to kill the functionality you're taking advantage of. And, more than what we (LV R&D) ought to do about it, I really want to know why the heck you are in this situation! Short answer: The Call Parent Method always calls the ancestor implementation of the VI. It does not care about the type of the object on the wire. So Call Parent Method on the block diagram of B:M.vi will always call A:M.vi. Long answer: Somehow you have an instance of D on a diagram of B:M.vi and you are passing that D object to the Call Parent Method node. How did you get this instance of D on the diagram of B:M.vi? Here is how I would have expected that it got there: Top level VI is "Caller.vi" Caller.vi has an instance of D on its diagram Caller.vi makes a dynamic dispatch call to M.vi, which dispatches to D:M.vi. D:M.vi uses the Call Parent Method to invoke C:M.vi. C:M.vi uses the Call Parent Method to invoke B:M.vi. And now you are asking what the behavior will be when B:M.vi uses Call Parent Method, and the answer is A:M.vi. Now, that's what I would have expected. Your question implies that something like this happened: Top level VI is "Caller.vi" Caller.vi has an instance of B on its diagram. Caller.vi makes a dynamic dispatch call to M.vi, which dispatches to B:M.vi. On the diagram of B:M.vi, you somehow obtain an object of type D, either from a diagram constant directly on the diagram or retrieving this D object from some data store (global variable, queue, etc, or maybe just by unbundling data stored in the B object). And now you propose to wire that D object to the Call Parent Method. Please tell me that is NOT what you are doing. It sounds like it is, but it shouldn't be happening. There should never be a reason why you would ever want to do this. If you directly pass that D to the Call Parent Method, you are destroying the data integrity of your D object. Any object assumes that if it provides an override of any method then the ancestor method will never act on that object unless it was because the overriding VI used the Call Parent Method to invoke it. I and my team never discussed this case. The fix for the LV compiler is obvious and easy -- the dynamic dispatch input terminal of the Call Parent Method should only accept wires that propagate down from the dynamic dispatch input of the invoking VI. In other words, only the wires that have the gray background should be able to wire to the dynamic dispatch input of the Call Parent Method, and the VI should be broken if anything else is wired. That is not enforced today, mostly because it never occurred to anyone that you might ever try something like this. I could be completely off base in my understanding of what you're asking. But if I've hit the nail on the head, can you please explain *why* you are passing this D object to the Call Parent Method without climbing up through the hierarchy, starting at D:M.vi? If there's a real-world use case for this, I am going to be absolutely stunned. My bet is that you're just creating a situation in which D is not being updated correctly. Now, it is legit to have this situation (steps 1 to 4 are identical to the previous steps): Top level VI is "Caller.vi" Caller.vi has an instance of B on its diagram. Caller.vi makes a dynamic dispatch call to M.vi, which dispatches to B:M.vi. On the diagram of B:M.vi, you somehow obtain an object of type D, either from a diagram constant directly on the diagram or retrieving this D object from some data store (global variable, queue, etc, or maybe just by unbundling data stored in the B object). You make a new dynamic dispatch call to M.vi, passing the D object as the dynamic dispatch input. This will call out to D:M.vi and may eventually make a recursive call into B:M.vi, if all of the override VIs keep invoking the Call Parent Method. This eventually results in a recursive call to B:M.vi, which will either panic stop if the VI is not reentrant or will allow the recursion if the VI is reentrant. You'd need in that case to make sure that B:M.vi is written such that infinite recursion does not occur. Does this sound more like what you're intending to write?

I've updated this with Jim's input, changed the way it closes and set the array indicator to resize with the panel. CaseSelector.vi

Thank you. My next step is to make this into a RCF plug-in. I'd like to take it on this weekend, but I'm getting a PHD today and might not have free time. (In my case, a PHD is a Post Hole Digger - I'm building a fence to keep my chickens from wandering the neighborhood.)

Try this

Sure, the following code will do what you want. As I understand if 1A or 2A exist in a comma separated string then light up 1A or 2A if exists.

I just wanted to inform that after total rewrite of everything (to LVOOP) I reached exactly the same functionality as it was before. That's a progress, isn't it? So now it's time to start extending VIpreVIEW. For the beginning, following Yair's suggestions, I designed a logo: I also attached recently generated swf, as these from previous posts are gone, but I'dont know how to embed it in the post... BBcode is not working. test3.swf Also if someone who got the power could move this topic to uncertified code repository where is much better place for it?

Just took a look on the NI Instrument driver site and there is a driver for a Uni-Trend UT804 So I'd take a look at that and see how they have implemented the protocol, I suspect it would be similar. Also go to the Uni-Trend site for your model there is some software which you can interface to your multimeter which will allow you to read values etc, its not a driver but the useful thing is that it will give you a reality check, also if you build a serial proxy or sniffer you can then look at the packets going back and forth which will give you some insight into what you need to implement in your own driver. But in the mean time definitely do as Francois has suggested and contact the manufacturer and ask for the protocol.

With RS-232, you have to send a query to receive data. You might not see it, but that's what the manufacturer's software does. The same is true from Hyperterminal or LabVIEW. Now, I'm not used to HyperTerminal so I don't know why it bugs you, but with LabVIEW, make sure you check these things: To which COM port is your DMM connected? What is the command (query) to fetch data? (the manual is 55MB and takes forever to download, so I don't think I'll have the patience to finish the download) Have you installed VISA drivers from NI? You should get an error message like this if you didn't: Error -1073807202 occurred at Property Node (arg 1) in VISA Configure Serial Port (Instr).vi->Basic Serial Write and Read.vi Possible reason(s): LabVIEW: (Hex 0xBFFF009E) VISA or a code library required by VISA could not be located or loaded. This is usually due to a required driver not being installed on the system. Using the "Basic Serial Write and Read.vi" example you got from NI examples is exactly where you should start. To query the DMM, you've got to have both "write" and "read" switches to ON position. In the "string to write", put the query command. Then press the start Arrow and you should get the data in "read string". Make sure you have the right COM port selected in "VISA resource name".