MATRIXx

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling simAPI function from a UCB based on sa_user.c template

I am importing external C code using the ucb block to be used both under sysbld autocode. Therefore, I am using "sa_user.c" template for the UCB.

The basic functionality works fine under both sysbld and autocode simulation.
 
I would like to use SIM API  functions from the ucb code while running under sysbld. I can protect the sim API function from being called when running with autocode using  "#ifdef SBUSER".

However, the problem is that simAPI function to gather information on the current UCB requires, as input, a pointer to the iinfo structure:
 
    SIMAPI_GetUCBBlockInfo(int *iinfo, SB **SBptr, BLK **BLKptr)
 
The function prototype for main ucb function for this template:
 
void USR01(INFO,T,U,NU,X,XDOT,NX,Y,NY,RP,IP)
     struct STATUS_RECORD       *INFO   ;
     RT_DURATION    T       ;
    .....
 
does not provide access to the iinfo strcutre (which is usaualy  passed as an input argument to the ucb functions based on sybld usr01.c template).
 
Is there a way to get around that?
 
I would try to create an integer array and set the content. However, I do not have any information about what should be the size and values of this array.
 
 
Thanks
 
Farshid
0 Kudos
Message 1 of 4
(8,940 Views)
Hi Farshid,
 
You bring up a very good point, which is that the purpose of the sa_user.c UCB template is to be used by both autocode generated code and SystemBuild.  This means that UCB code cannot used features that are not available in both environments.  The SIM API is one of these, so you will not be able to access those routines with the sa_user.c template.  The alternative would be to use the simulator -style UCB, which is available in a template form in the file usr01.c within the SystemBuild src directory ($SYSBLD/src).
Also note that if you need to use autocode generated UCB (from a procedure superblock), modified to have SIM API calls.  The only way to do that would be to place those calls in the ucbhook wrapper, which confoms to the simulation style interface.
Please let me know if this answers your question.
 
Chris M
Applications Engineer
National Instruments
0 Kudos
Message 2 of 4
(8,904 Views)
Thanks Chris,
 
I can understand your point about the purpose of the "sa_user" style ucb in providing minimum features that are common and supported by both Autocode and sysbld. This makes sense about features that affect the result of simulation such as linearization. However, I do not see any "harm" in being able to do special things (such as calling simapi function that does not affect the simulation result) while running under sysbld (using #ifdef SBUSER to protect autocode from calling unsupported features).
 
I can use the USR01.c, however, I will not be able to generate and run the code for the model (which is essential for us).  
 
Considering the above, The question or problem is  why the  SIMAPI_GetUCBBlockInfo() function requires a pointer to the iinfo structure to bring back pointers to the current block and superblock?
 
The other soultion could have been to allow the user to create a local ucbhook.c file. Currently this does not work since simexe generates a ucbhook (ucbhook.c) on the fly which is compiled and linked into a shared object (which is then being removed at the end of make process).
 
Farshid
0 Kudos
Message 3 of 4
(8,896 Views)
Farshid,
 
That's an interesting idea; provide some subset of SIMAPI routines available in the stand-alone sim, especially the functions regarding gathering information about the UCB block itself. I'll file a feature request on this.
 
It is unusual to have a UCB used in stand-alone code rely on SIMAPI data. Since you state that you have to run the UCB in both sim and code environments, I'd suggest that whatever information you are extracting from the SIMAPI routines be directly placed into the IPAR or RPAR data, which is available in both environments. This is one work-around the absense of the SIMAPI routines in the code environment yet still have your code not duplicated for each environment.
 
 
thanks,
 
Bob Pizzi
MATRIXx R&D
 
 
0 Kudos
Message 4 of 4
(8,857 Views)