Error 53 (Manager call not supported) from using Property Node:(Value)

[Ascen]

I am developing a application that needs both an extendable computation engine

and a GUI that needs to both receive from and update values to the computation

engine. For the extendability, I use classes with inheritance, and for the engine-GUI

splitting I use a forked reference to the data cluster.

However, when using Property Node : Value (or Value(Signaling)), I get

the Error 53. I find it confusing, as it referes to Networking Error

codes, which I did not expect to occur with just cluster references.

To make matters worse, the location in the code generating this error seems to vary.

Here is the code: ClassExperiment.zip

My own guesses would have to do with badly done initialization or problem with

threading, as several different loops write to same reference.

What usually generates such an error, and how would one go about to avoid them?

Is there a good documentation on usual causes and solutions to most usual errors?

[Ascen]

QUOTE(Ascen @ Oct 31 2007, 05:37 PM)

However, when using Property Node : Value (or Value(Signaling)), I get

the Error 53.

...

Here is the code: ClassExperiment.zip

My own guesses would have to do with badly done initialization or problem with

threading, as several different loops write to same reference.

As I still haven't been able to figure the issue out, I created a reduced model

of the data structure that still creates the same error. That model is Main_test2.vi

within that zip-file above.

There definitely is something fishy about passing that reference handling with classes

as datatype in that array. I also tested the similar structure without the classes,

and that worked perfectly. With probes in place you can see that the initializer sets

the cluster values correctly, but somewhere along the wire the reference or the value

is somehow messed up.

Is there some known issues with the classes by-ref that are documented somewhere?

What could possibly cause this error?

[Norm Kirchner]

I've looked at your code and you're definetly doing awkward things with the references. But I need to better understand how you are trying to access this data.

Typically you do not want to get values of controls using a reference. ESPECIALLY ones that are using LVOOP. LVOOP is REALLY intended to stay on the wire and I'm not surpirsed that you're ending up w/ issues when trying to access them via reference.

Yeah.. just took another look at the code....you're doing some weird wiring. I think that the topic title is too specific and scared ppl away from replying, it did for me at first at least.

[Justin Goeres]

Well, Norm's comments motivated me to take a look, I'll tell you that . I certainly can't tell you what Error 53 means in that context. The fact that it resolves to a networking error code looks like a red herring to me.

Norm is right, you're doing some pretty funky stuff combining references and objects like that. My initial wild-###### guess would be that the problem might stem from the fact that you have your objects buried way down inside a pile of array/cluster relationships that you're accessing via a strict reference. Maybe when the cluster reference is being created (in your sub_InitCtrlArray_test1.vi), the strict reference is incorporating type information about the .lvclass buried down inside of it, in a way that breaks when you get the Value property of that reference later and the type of the .lvclass objects has changed in the meantime?

Hey, check this out... If you change the cluster reference to a non-strict one (i.e. set the Application Data Output indicator in sub_InitCtrlArray_test1.vi to NOT Include Data Type) the error no longer occurs! That gives me more confidence that it's a strict/non-strict reference typing problem. It's still a bit odd, though, that the Variant value of the cluster doesn't seem to include anything about the Controller Selection Array. Or maybe I'm missing something. I'm certainly blowing through this quickly.

My advice? Refactor your code so it's more, um, kosher .

EDIT: Nevermind, the Variant actually does at least have the size of the array, so there's something in there. I just misread the indicator. My other points still stand, though

[Ascen]

First of all, thanks for taking the time to have a look at the code. I was getting

desperate already.

QUOTE(Norm Kirchner @ Nov 2 2007, 12:17 AM)

I've looked at your code and you're definetly doing awkward things with the references. But I need to better understand how you are trying to access this data.

Typically you do not want to get values of controls using a reference. ESPECIALLY ones that are using LVOOP. LVOOP is REALLY intended to stay on the wire and I'm not surpirsed that you're ending up w/ issues when trying to access them via reference.

The odd data structure and by-reference usage stems from several user requirements that all need to be met:

 * The system as a whole is to be a software based simulation platform, that in time might be extended to

    also interface with DAQ equipment and controllers.

 * The system needs to be extendable controller- and process-wise, the same simulator engine should be possible

    to use without changes when different controller schemes are implemented.

Now, for the current design choices made:

1. By-reference:

   I use by-reference because I need to have at least three separate parts that each have different timing and all use parts of the same data:

     a: Process simulation, which runs at around 50/s frequency at its fastest, and 1/s at slowest.

     b: Process measurement display, needs only to update around 4/s frequency

     c: Event (Button pressed) handling part that only proceeds on events fired by GUI buttons that

         either update the process parameters or are used for navigating the multiple-screens-done-with-tabs GUI.

   By-value implementation would lead to separate copies of the data, which would not fulfill

   the purpose of being able to access the same data across the functional parts of the program.

 

   Is there a proven solution for using by-value on a branching program?

 

2. The cluster-array-cluster-array-class -structure

   This stems from both my ignorance and from the requirements that this system reproduce some of the

   behaviour the older system had. Let us call them (1.cluster-2.array-3.cluster-4.array)

   a. Use of classes for controllers. As extendability is required, classes provide a perfect container that each

      contain their own internal data. Classes also can be cast as Parent Controller Class that defines interface methods

      for each Child Controller Class to implement. With these overriding methods it is possible to simply go through a array of controllers

      and have each execute the appropriate method.

   b. What I am trying to accomplish with the 1.c-2.a-3.c-4.a-class -structure is:

       1. cluster is just a container for all the operating data needed in the whole system.

       2. array is a array of "controller slots" - in a real system these controller slots would each correspond to one

          5mA-20mA output channel. In software implementation this will be imitated by having each correspond with

          a given index of an array of output values.

       3. cluster is there to contain information about this "controller slot". As of now, it contains an controller object array and

          a numerical field that indicates the index of the array that contains the selected controller object for this "slot".

       4. array of possible options (controller objects) for this (2. array) "controller slot". The reason why there are

          initialized controller objects in the array (thus leading to N * M initialized controller objects of which only N will be used),

          is that the previous system would save the controller configuration info even if another type of controller

          was selected for the slot. And also because I could not think of a better way to do this.

QUOTE(Justin Goeres @ Nov 2 2007, 01:35 AM)

Well, Norm's comments motivated me to take a look, I'll tell you that

. I certainly can't tell you what

Error 53

means in that context. The fact that it resolves to a networking error code looks like a red herring to me.

... (about strict type references breaking the class type, etc) ...

My advice? Refactor your code so it's more, um, kosher

.

Thanks for the opinion about the Error 53 being a red herring, I've been dumbfounded trying to figure it out.

And please don't get me wrong for snipping your code out from there - I'll have to try out your tricks on my

code before I can comment more on this.

Still, looking at my reasons above, could you give a hint on what would be a more 'kosher' way of implementing it?

EDIT: Made my text a bit more readable.

[Justin Goeres]

QUOTE(Ascen @ Nov 2 2007, 04:08 AM)

The odd data structure and by-reference usage stems from several user requirements that all need to be met:

* The system as a whole is to be a software based simulation platform, that in time might be extended to

also interface with DAQ equipment and controllers.

* The system needs to be extendable controller- and process-wise, the same simulator engine should be possible

to use without changes when different controller schemes are implemented.

Now, for the current design choices made:

1. By-reference:

I use by-reference because I need to have at least three separate parts that each have different timing and all use parts of the same data:

a: Process simulation, which runs at around 50/s frequency at its fastest, and 1/s at slowest.

b: Process measurement display, needs only to update around 4/s frequency

c: Event (Button pressed) handling part that only proceeds on events fired by GUI buttons that

either update the process parameters or are used for navigating the multiple-screens-done-with-tabs GUI.

By-value implementation would lead to separate copies of the data, which would not fulfill

the purpose of being able to access the same data across the functional parts of the program.

What you're building is a fairly complicated system. I think you're on the right track with a by-reference implementation rather than by-value, but the problem is that you're trying to get the best of by-value objects, but trying to access them by-reference (more specifically, you're trying to access them using a reference to a front panel control that happens to contain them as data.)

I suspect that what you may need is actual by-reference objects, which are not the same as making a cluster of some data and just getting a reference to it (as you've found ). There are several different ways to do by-reference objects in LabVIEW. At the risk of seeming unhelpful, though, I'm going to pass those recommendations off for other people to handle. Through some quirks of nature I've fallen a ways behind on by-reference objects since LV82 -- I play more in by-value objects lately so I'm not up-to-date on all the strengths & weaknesses of the various options.

QUOTE

Is there a proven solution for using by-value on a branching program?

I don't mean to be snarky, but yes, it's possible to do very complex things with by-value objects. You do have to design the system, however, around the limitations imposed by their by-value nature. Some of the stuff that's easy with by-reference access to an object is either hard or impossible with by-value out of the box. But I find that by-value objects force me to really enforce better encapsulation and looser coupling on my data (which is, of course, the point of objects in general).

Notwithstanding what I just said, though, your situation sounds like a pretty good case for actual by-reference objects.

QUOTE

2. The cluster-array-cluster-array-class -structure

This stems from both my ignorance and from the requirements that this system reproduce some of the

behaviour the older system had. Let us call them (1.cluster-2.array-3.cluster-4.array)

a. Use of classes for controllers. As extendability is required, classes provide a perfect container that each

contain their own internal data. Classes also can be cast as Parent Controller Class that defines interface methods

for each Child Controller Class to implement. With these overriding methods it is possible to simply go through a array of controllers

and have each execute the appropriate method.

b. What I am trying to accomplish with the 1.c-2.a-3.c-4.a-class -structure is:

1. cluster is just a container for all the operating data needed in the whole system.

2. array is a array of "controller slots" - in a real system these controller slots would each correspond to one

5mA-20mA output channel. In software implementation this will be imitated by having each correspond with

a given index of an array of output values.

3. cluster is there to contain information about this "controller slot". As of now, it contains an controller object array and

a numerical field that indicates the index of the array that contains the selected controller object for this "slot".

4. array of possible options (controller objects) for this (2. array) "controller slot". The reason why there are

initialized controller objects in the array (thus leading to N * M initialized controller objects of which only N will be used),

is that the previous system would save the controller configuration info even if another type of controller

was selected for the slot. And also because I could not think of a better way to do this.

That's ambitious (and I mean that in a good way!). I'm afraid your problem is much larger than what you're going to find a pat answer for on a forum like this, but let's see what we can all come up with to kick you in the right direction (so you can at least stop getting stupefying error messages if nothing else ).

I'm reminded of something that a LabVIEW R&D person said to me once (it might've been AQ, but I forget): "If it's in a cluster, you should put it in a class." If you're interested in using the features of LVOOP, I'd put everything in your list above into a tree of classes. That means starting with AppData.lvclass and working down from there (although in practice, I'd start at the bottom of your array-cluster thing and work outward). At each level, think about exactly what each class represents in your physical system, and try to avoid putting apples & oranges in the same class. And remember, it's OK for classes to contain other classes instead of inheriting to them. Membership and inheritance are complementary, but not identical, things.

Now, the problem is that once you've done that you've created a big ol' by-value representation of your system, which doesn't match up with your by-reference access goals. Yeah, that sucks . However, this gives you an object framework to work with. What you need is something to manage those objects. What I might do in a situation like this is create a sort of traffic-cop loop that keeps the AppData in a shift register. It's responsible for doling out individual components of the AppData to other loops that manage those objects. When one of those slave loops needs to update the value of an object, I would provide a messaging framework for it to do so by communicating back to the traffic cop (via queue/notifier/whatever). This is actually not as hard as it sounds, although by-reference may still be the answer for you.

Another semi-random point: Instead of keeping an array of all the Controllers and indexing them with SelectedController, why not have one element called ActiveController and an array called InactiveControllers? That gives you the ability to index them in and out of "Active" status by their InstanceName, without the hassle of having to index/replace in the array every time you want to access the active controller.

Sorry this is all kind of scattershot. You've got a fairly wide-ranging design goal, so there are lots of ways to skin it .

QUOTE

Thanks for the opinion about the Error 53 being a red herring, I've been dumbfounded trying to figure it out.

And please don't get me wrong for snipping your code out from there - I'll have to try out your tricks on my

code before I can comment more on this.

No problem. I'd still love to hear exactly where that error is coming from, but I think only NI could tell us. Which reminds me, you could call them and ask them .