Hi Claes,

Thanks for your quick response. I'm going with the noinvert bit solution for now. Had not noticed the noinvert flag, before. Thanks for that tip. Once more experience is gained, I may eventually try a macro method using the source code for examples.

Best Regards,

/Ron

A subgraph is needed to aid in building several summary graphics containing multiple custom class objects. For illustration purposes, a standard PID controller is used as a similar example. For a PID controller, there exists a beautiful object graphic. Likewise, my custom class object has an object graphic available. An operator summary graphic is needed, where a dozen or so PID controllers are shown in a table type format. To aid in building multiple operator graphics, a subgraph is needed for a single row, where an object name is entered per subgraph and referenced by several values in a row:



The goal is to use the same subgraph for each row, specifying a different object name for each. For this example, $object is shown but may not be the correct reference parameter? $object works for object graphs, but how does this work for a subgraph? Any insight would be helpful.

/Ron

Hi Ron,

When you edit the subgraph, open 'File/Graph attributes' and set DynType1 to HostObject and RecursiveDynamic to 1. Now you can use $hostobject to reference the connected object, eg $hostobject.PV##Float32.

/Claes

Hi Claes,

Thanks to your advice, several nice subgraphs have been built and working using $hostname. Is there support for multiple $hostname variables in one subgraph? (for example $hostname2, $hostname3, etc.) I see no obvious capability, but wanted to ask anyway. There is plenty of display horsepower to do everything needed plus some.

Regards,

/Ron

Hi Claes,

Referencing rt_plc_arithm.c for code examples, several custom class objects have been built successfully using a similar methodology as found for Summer. On several occasions, it has been noticed that unconnected input pointers don't contain a NULL address. A simple program was written to verify:



Results are below:



Interestingly, **ptr for unconnected inputs returns the associated input value. It appears for an unconnected input, the connection pointer points to the input value location, instead of NULL. That makes sense as a default, but it means (*ptr != NULL) is not a valid test for an unconnected input.

Do you agree with this conclusion? If yes, can you suggest a method to check for an unconnected input for custom class objects? Maybe, check to see if the pointer address is not equal to the memory address of the associated input value? Or perhaps, check to see if the input selector flag is on?

Update: The conditional statement below correctly tests for an unconnected input:

pwr_tFloat32 **ptr; /* Pointer to an input connection pointer */
pwr_tFloat32 *pcx; /* Pointer to local associated input value */

ptr = &o->ibl05P; /* memory location of an unconnected input pointer */
pcx = &o->ibl05; /* memory location of associated input value */

if (*ptr != pcx) /* if input connection address != local input value address */
{ // connected }
else
{ // not connected }



/Ron

Hi Ron,

Every input consists of two elements, a pointer and a place for a value. The idea is that either you connect the input, and then the pointer points to the connected output attribute, or you set a constant value, and in this case, the pointer points to the constant value.

For an input named 'In', the pointer is o->InP and the place for a value is o->In. A test for if the input in connected is

if (o->InP != &o->In)
// Connected

In the code you can either consequently use the pointer, or you can set the value to the pointed value

o->In = *o->InP;

and then use the value (o->In) in the code. Note that if the input is not connected, the expression above does nothing as o->InP points to o->In.

/Claes