Fishiness in override?

[bsvingen]

I am trying to use the LVOO2 mechanism of AQ (see this board some place) in state machines. I got it working, but there are one thing I just don't understand. When initiating the state machine, it needs to be initiated with some of the child classes, or the state machine won't do anything because it will never "get out" of the parent class. The strange thing is that I cannot simply use a child class, the wire will be broken. I have to make a vi with a parent output that is wired to a child class inside. When looking at the probes it is evident that there are actually three kind of classes.

1 parent class

2 child class

3 some sort of hybrid parent class with a child inside (pragnent??)

Also, the input must be a dynamic dispatch, but the output cannot be dynamic, since this creates output of the same child class as the input. The output has to be a parent class (again creating this hybrid). Only these hybrids will make the state machine run.

The odd thing is that the "pragnent" class that is supposed to be a child, is not wire compatible with a child. I have included a super simple state machine that shows what is going on. It has three states inc, dec and a random jump.

Download File:post-4885-1236126673.zip

[Daklu]

QUOTE (bsvingen @ Mar 3 2009, 04:32 PM)

I am trying to use the LVOO2 mechanism of AQ (see this board some place) in state machines. I got it working, but there are one thing I just don't understand. When initiating the state machine, it needs to be initiated with some of the child classes, or the state machine won't do anything because it will never "get out" of the parent class.

It's a logic error in your program. All three child classes use 'Set and Test.vi' within their 'State.vi.' The parent class does not. Therefore, when you start the program with the parent class, SSSM:State is executed, bypassing 'Set and Test.' Neither the data nor the object on the wire ever change.

You can't simply add 'Set and Test' to SSSM:State since your child classes make calls to that vi. You need to refactor your VIs so all instances of 'State.vi' do essentially the same thing--return the current data. There are lots of way you could refactor this... I've include one way in the attached file.

QUOTE

The strange thing is that I cannot simply use a child class, the wire will be broken. I have to make a vi with a parent output that is wired to a child class inside. When looking at the probes it is evident that there are actually three kind of classes.

I had no problem hooking up any of the child classes.

Download File:post-7603-1236145110.zip

[bsvingen]

QUOTE (Daklu @ Mar 4 2009, 06:39 AM)

It's a logic error in your program. All three child classes use 'Set and Test.vi' within their 'State.vi.' The parent class does not. Therefore, when you start the program with the parent class, SSSM:State is executed, bypassing 'Set and Test.' Neither the data nor the object on the wire ever change.

You can't simply add 'Set and Test' to SSSM:State since your child classes make calls to that vi. You need to refactor your VIs so all instances of 'State.vi' do essentially the same thing--return the current data. There are lots of way you could refactor this... I've include one way in the attached file.

I had no problem hooking up any of the child classes.

So you are saying that there is fishiness in my programming? I have to look at this later today, but thanks. Did you try the child classes on the original? I used LV8.21 and there was no way. LV even reported an internal error when closing down and starting up again.

[jdunham]

QUOTE (bsvingen @ Mar 3 2009, 11:52 PM)

So you are saying that there is fishiness in my programming? I have to look at this later today, but thanks. Did you try the child classes on the original? I used LV8.21 and there was no way. LV even reported an internal error when closing down and starting up again.

Daklu's version is a lot more sensible, though he's got a dynamic dispatch input on "Test Data.vi" which is probably not what you'd want. I only make that point because the original code had several VIs with a dynamic dispatch input and a specific child class output, and I think that would almost always be bad news.

I didn't quite understand the original posting about the 'pregnant' probes. There are no 'hybrids'. All child classes contain the parent data as well, but you seemed to be talking about a parent class containing the child data. The parent wire can hold a child object, but you won't see the child private data in the probe. Anyway, I recommend adding some different data types to the three child private data classes, and then the probes make more sense.

I would also highly recommend upgrading your LabVIEW, since the LVOOP code has a few major bug fixes between 8.2 and 8.6.1 AFAIK.

[Aristos Queue]

QUOTE (jdunham @ Mar 4 2009, 02:50 AM)

I would also highly recommend upgrading your LabVIEW, since the LVOOP code has a few major bug fixes between 8.2 and 8.6.1 AFAIK.

At the very least, you should get 8.2.1. There are seven major bugs fixed in 8.2.1. They range from annoying UI delays to files saving corrupt.

[Daklu]

QUOTE (bsvingen @ Mar 3 2009, 11:52 PM)

So you are saying that there is fishiness in my programming?

Not at all. The programming was spot on. It was the design that was a bit fishy. (FWIW, I'm constantly reminding myself not to put too much functionality in my class vis.)

QUOTE

Did you try the child classes on the original? I used LV8.21 and there was no way.

Yep, that's first thing I did (after changing the class wires, labelling the class banner, and putting names on the vi icons) was wire up a child object to the shift register. That's what the screenshot is. I am using LV 8.6 though.

QUOTE

LV

even reported an internal error when closing down and starting up again.

Nothing terribly remarkable about that.

QUOTE

...though he's got a dynamic dispatch input on "Test Data.vi"...

Good catch. I started by playing around with overriding Test Data in the child classes before deciding it was easier to just do it all in the SSSM class. It appears I forgot to change the input. (I wish there were an easy way to tell if inputs are dynamic dispatch by looking at the context help window.)

[bsvingen]

There obviously must be a bug in 8.2.1. When I have the help window open, it start kind of "shimmering" when I try to wire the child class directly into the shift register, and the wire gets broken. Have to start using 8.6 I guess.

What I meant with those "pregnant" objects was simply that it would not accept the child class except when going through a parent output first (the bug). It made no sense what was going on.

[bsvingen]

FWIW, here is a 8.2.1 version that works. I modified Daklu's 8.6 version and saved it to 8.2. The object entering will allways be initiated with data, and the state machine is part of the data essentially, not the other way around (that was the logic error of mine, wanting to initialize with a child) . The modification on the data should be done before the test and also include the data class (with the initial data), so I changed that back again. On the real version the test will also include a stop signal, stopping the loop depending on the data, and there should be no more modification on the data after that. The test method could now very well be inside the process method, but it is more evident what the loop does if it is left outside, and easier to get access to. I also deleted several unesessary get/set function calls (like to keep things as clean as possible). Anyway, Thanks Daklu for your help

Download File:post-4885-1236235140.zip