Initialisation of iinfo table when using states

[Charley007]

Hi, I'm running into someting weird today and I'm not sure I understand well what to do. Right now what I'm triing to do is to run my software autocoded with part of it autocoded as a UCB.

1- When I'm running the whole software autocoded, everything is fine. Case close!!!!

Then I try to breakup stuff!

2- I toke part of the code and autocoded it using the UCB templates
3- Create a small UCB in the whole code that call the autocoded done in number 2

So in the big software, I have this call to the UCB :

    NAVFAST_DLL_7_sr.STATES = 1;
    NAVFAST_DLL_7_sr.OUTPUTS = 1;
    /* USRxx(INFO,T,U,NU,X,XDOT,NX,Y,NY,RP,IP) */
    NAVFAST_DLL(&NAVFAST_DLL_7_sr, TIME, NAVFAST_DLL_7_u, 83, &X->
                              NAVfast_7_S1[0], &XD->NAVfast_7_S1[0], 325, NAVFAST_DLL_7_y, 62, &
                              dummy_f[0], &dummy_i[0]);

In the UCB (NAVFAST_DLL), I have the call of the INIT part :

    int iinfo[] = {0, INFO->INIT, INFO->STATES, INFO->OUTPUTS};
    double rinfo[] = {T, TSAMP};
    if(INFO->INIT)
    {
        NAVfast2_ucbhook(iinfo, rinfo, U, &NU, X, XDOT ,&NX, Y, &NY, RP, IP);
        INFO->INIT = FALSE;
        return;
    }

After that we got the code that I have autocoded in part 2 :

    void NAVfast2_ucbhook(iinfo, rinfo, U, NU, X, XD ,NX, Y, NY, R_P, I_P)
               int     iinfo[], I_P[], *NU, *NX, *NY;
               double  rinfo[], R_P[], U[], X[], XD[], Y[];
     {
       //... Struct declaration
  
    if( (*NU != 83) || (*NY != 62) || (*NX != 325) ) {
          iinfo[0] = UCB_ERROR; goto EXEC_ERROR;
    }
    if( iinfo[1] == 1 ) {
      Init_Application_Data();
      if( iinfo[3] == 1 && *NX != 0 ) {
         return;
      }
   }
   
    //... Rest of the code

So as you can see here, the first time I inter into the INIT part, the call to Init_Application_Data() and it will exit directly because the iinfo[3] (outputs flag) is equal to 1 and my number of states is different that 0. So it means that all my sub functions are not initialise! After that, I look in the documentation (SystemBuild User Guide 14-4) and found you that I need to call the INIT part twice ?!?!?

    "INIT Mode

    INIT mode is performed once at the start of a simulation. During the INIT
    mode call, the value of the IINFO(2) flag is set to 1. If the UCB reference
    has states, the UCB is called in INIT mode twice.
        • Once while executing OUTPUT mode
        • Again while executing STATE mode"

So does it mean that I have to call the ubchook function with the iinfo[3] = 1 and iinfo[2] = 0 once and then recall this fucntion with iinfo[3] = 0 and iinfo[2] = 1 under the INIT part of the UCB ?

Do like this :

    int iinfo[] = {0, INFO->INIT, 0, INFO->OUTPUTS};
    double rinfo[] = {T, TSAMP};
    if(INFO->INIT)
    {
        NAVfast2_ucbhook(iinfo, rinfo, U, &NU, X, XDOT ,&NX, Y, &NY, RP, IP);
        iinfo[2] = INFO->STATES;
        iinfo[3] = 0;
        NAVfast2_ucbhook(iinfo, rinfo, U, &NU, X, XDOT ,&NX, Y, &NY, RP, IP);
        INFO->INIT = FALSE;
        return;
    }

Thanks

Charles-Etienne
NGC Aerospace

[BobPizzi]

This is an interesting observation about some of details required to implement the 'model of computation' of a SystemBuild model within the generated code.

Before I continue, may I make a suggestion that if you intend to use procedure code outside of a complete autocode-generated system, you might want to consider using the SDK interfaces. Briefly, the SDK is a template-based solution to generate APIs (C, C++ or Ada) to properly call procedure SuperBlocks from 'other' code. It's very easy to use and implements all the necessary details. Consult your version's documentaion for more as the mechanism to activate the SDK have changed between versions but the structure of the APIs are the same.

Now, on to the post...

The most important detail regarding this question is the context of the generated code. In this case, you're using the UCBHOOK mechanism and trying to call that API from other code.

The problem is that the UCBHOOK is designed to be used as "wrapper code" around an autocode procedure and the 'hook' code is intended to be linked back into the simulator as a UCB for simulation purposes. It was not intended to be a general-purpose API call, that's why we created the SDK!

Because the UCBHOOK is designed for use with the Simulator, that code must conform to the requirements of a hand-written SystemBuild UCB. And it is in attempting to match the autocode-generated implementation with what the Simulator does results in some odd code.

What's happening is the code is reflecting a difference in how states are initialized within the Simulator's UCB context and the generated code. Briefly, the simulator must be very generic in how it calls UCB code. The simulator makes many separate calls to a UCB to perform match distinct operations, thus the complexity of the iinfo structure.

Now autocode generated code is not generic, it is optimized. So, in the case of a procedure, a procedure is a form of a discrete superblock with inherited timing attributes. Autocode optimize discrete superblock initialization by initializing it at the same time as the output computation at T=0.0. Therefore, for autocode discrete-based superblocks, there is only ONE init phase and it's coupled with the first OUTPUT phase.

So, since the Simulator does not perform such optimization, the Simulator calls the UCBHOOK several times, as it is documented. This is incompatable with the autocode code, therefore there's code in the UCBHOOK (as you've hilighted) to prevent extra initialization as to match the autocode implementation.

Like I said, the UCBHOOK is designed as a UCB that conforms to the Simulator's 'model of computation'.

If you intend to have your 'outside' code use the ucbhook, you will have to match how the simulator calls UCBs. In the case you describe, calling the UCBHOOK multiple times for initialization is required.

In general, I'd not recommend using the UCBHOOK called from 'outside' code, I'd prefer you use the SDK as the complexity of the simulator's calls to UCBs is not trivial.

Regards,

Bob Pizzi

MATRIXx R&D - AutoCode

[Charley007]

Thanks a lot for the complete response! I'll give a try to the SDK templates.

I'll keep you update

Thanks

Charles-Etienne
NGC Aerospace