Program-object correct use of slot types, setting and getting

[Snaps]

Hello All,

One of my colleagues/friend pointed me to your community here suggesting, I would be able to discuss my problem/dilemma I came across while writing some program-objects.

I am sure my problem comes from the limited knowledge of java and baja as although I do write code (apart from ‘normal’ DDC programming) in C or more hardware close languages the object oriented programming is a bit of a hit and miss with me.

I learnt to use the program-objects from the examples in the module itself mostly and due to this, my first (well most) programs I have interfaced data to my programs via creating slots of baja → StatusNumeric and StatusBoolean, etc. type and then I created ‘handles’ to get and set their values. I think something called dereferencing in java which I think actually means referring to the address of the data and using it that way.

This worked very well but I wrote some new code and as I saw when the slots are generated, the setting and getting functions are all created and also that I can use simple boolean and double, etc slot types which allowed me to ommit the creation of the ‘handles’.

Now interestingly, this works very well too.

I can see, that one big difference (for me) between the two method is the first ‘picks up’ the status of the slot too (in case of a writeable slot, you can set it to null for example) and the slot itself has an icon of a green or purple bar which is the same as you see on Niagara standard blocks (writables, or blocks, etc.). In the other case, the slot created will only ‘show’ the value of the slot and it only has a 3D block (representing an object?) for an icon and (for example) cannot be set to null.

So far you could ask, what is the problem? Yes, correct, no problems BUT:

I accidentally noticed, when I link the slots (inputs) to put the program-object to use on a wiresheet, although the programs run without an issue, its compilation status chages to orange. If I remove the links, the status changes back to compiled.

The only difference I saw with the two different methods used on the slots, is when I use the ‘handle’ type solution, than it will ‘sometimes’ require 2 links to be made for the compilation status to become orange, sometimes one. Agaon, when removed, the compilation state becomes green again.

I wrote a little test code to do the same thing with both methods to filter out other issues in the program itself and they behave the same way as descirbed above. Even the examples in the module behave the same way.

I have checked the kitcontrol blocks to see what slots these use for inputs and outputs but funny enough for example, the ‘Or’ block uses ‘StatusBoolean’ inputs but the ‘ExprLogic’ block in the same place uses simple booleans as inputs. So it does not seem to be coherent.

So, my question(s) to you is the following if you could comment on:

• Which is the ‘proper’ baja type, usage method of slots in a program? The ‘Status’ kind or the ‘simple’ boolean or double, etc. type slot?
• Do you think this ‘change’ to be ‘Program is out-of-date and requires compile’ is a bug or I am causing it due to limited exposure to java/baja?
• Reading up on Tridium’s notes on the Program-Object, should I really try to compile the programs to modules rather as these are ‘for one offs’ or for protoyping/testing?

For reference please see below the two methods I am using to read the different kind of slots:

Slot type is StatusNumeric (InA):

public void onExecute() throws Exception
{
double InputA;
BStatusNumeric InA = getInA();
InputA = InA.getValue();
…

Slot type is double (InA):

public void onExecute() throws Exception
{
double InputA;
InputA = getInA();
…

[Charles_Johnson]

I’m trying to figure out what you’re asking, so give me a little leeway here:

Program objects are great in a pinch. They can be great utilities for things that happen once in a station (or at least have one instance of), but if it’s something that you want to reuse over and over again, it’s best to have it as a component in a module.

As for your slot types, usually people who are linking objects from wiresheets to their program objects will use StatusBoolean, Numerics, etc. Otherwise, if you do not care about the status of the point, you can just use the primitives.

Some people will reference them directly in the code as well. If it’s a simple program, I’ll do that. However, if I know I’m going to be writing some lengthy code or it makes sense to have a helper method, I’ll usually use primitives as variables in my code and reference the BStatus point that I have.

When a program is running, you may go into program editor and see that it may want you to recompile, even though it’s working. This is expected. Sometimes linking slots to program objects marks it as “dirty”, if you will, because the framework detects structural changes to the component. It’s just a quirk and can be ignored.

The 3D block is just a standard icon to represent it’s a component. Changing icons are usually limited to Components in modules, but there are a few instances where you can change the icon of a component.

For the “Orange” state? I would need to see a screenshot of something that went into fault. If you aren’t using a Fault status in your code, it wouldn’t output a fault, unless your input slots are in fault.

[Snaps]

Hi Charles,

Thank you for your reply. You have nailed it, although you say not sure what I meant with my question(s), you got the essence of it really.

Yes, I read up onthe module creation already a little and was expecting, the ‘make a module for it’ statement which is completely, right. It has so many benefits, but I was not able to ventrue into it yet as most of the code I written are short, reusable functions, should not affect the engine too much (yes, I can hear myself and I will start looking into the module route but its hard to find good/clear documentation about it, well at least for someone who has no java experience).

I was hoping you will say ‘its really up to me’ about the slot types, just required confirmation, that both methods (primitives or the points+status kind of approach) are viable and I am not getting myself into a ‘bad habit’ of using one over the other and later have to go through my programs and change them as I have used ‘bad practice’.

In relation to the compilation status, thank you for confirming, than this is a ‘feature’ to change to ‘compilation required’. It kind of felt like it, as you noted the code becoming ‘dirty’ due to its links to the outside world, but again due to the lack of experience, I was not sure about this. This is a relief. About its becoming ‘orange’… when it becomes ‘compilation required’ status, there is a green or orange circle in front of this. When the engine thinks its ‘compiled correctly’ the circle is green, when it thinks it requires compilation, it becomes orange and when compilation fails, its red.

thank you for your answers, they cleared up a lot of things in my mind, and I definitely need to make friends with module making.

Ferenc