Is there a way to make numden coefficients remain variable in autocode?

[SG1]

I am using a model which contains numden blocks whose coefficients are set using %variables. When I generate autocode for this model, the autocode uses hardcoded values to define these blocks. If I then run the autocode outside of the matrixx environment, and assign a new value to one of those %variables, there is no affect on the numden block's output. Is there a way to keep these coefficients variable in the autocode?

[galen]

The first thing to check is make sure that you have an Xmath variable defined with some initial values before you generate code. If this is not the case, the code generator will generate code with the block values (as constants).
The other issue you pointed out was that you were trying to "change" the values of the autocode output. This would indicate that your code generation template process is allowing you to do this.

[TWK]

Galen is right on making sure that the num den block has a varable assigned and that there is a var(variable) value on the stack.

A way of ensuring this is to assign a variable in system build numden block, with your mouse select the var, and press p. this pushes the varable on the stack, you should see this in the xmath window.
if you are using realsim the following applies:
to change this variable at run time you need to press the button on the ia client bar that says ( i believe)change variable.

another window will open up and you select the variable with the change button, and press the update button to change the variable on the target at run time.

you can also connect to the target from the xmath window with the attach_realsim command and t
he rve_update command.

good luck

twk

[SG1]

Thanks for the help. Yes, I do have numerator and denominator variables defined with initial values. It looks like when the autocode is generated, those initial values are used to convert the transfer function to state space... and the resulting state space values are hardcoded in. The numerator and denominator variables still exist in the autocode, but they are not used in the numden block's calculations. The values I was then trying to change were the values of the numerator and denominator variables. I was able to successfully change those variables' values, but since they are not referred to in the calculations for the numden block, their values have no affect on the results. What I was wondering is if there is any way to make the autocode use those numden var
iable names in its numden calculations, instead of the hardcoded state space values.

[galen]

Another thing to check when you generate code is the option to "use percent vars". If this option is not selected, it will still hard-code the parameters.
If you have selected this option, and are still getting hard-coded constants, then maybe post what template you are using (standard, user-customized, etc.)

[SG1]

I do have "vars=1" included in the autocode command. There are many other block types in the model, and all blocks are coded using %vars except for the numden blocks.

[TWK]

1) In order for Autocode to include these %vars variables , the variable has to exist on the stack before autocode is run. Also as Galen mentioned, The vars option must be selected.

2) how are you running your autocode, using realsim & AC104, or some other hardware platform.

if you are using realsim and AC104, you can update the variables at run time as i outlined earlier.

if you are using some other platform, you need to have another calibration tool linked into your code.

[galen]

Ok, It looks like this really is a limitation/(bug) of the autocode process. I hadn't used this block much before so I verified you're situation. I also discovered that it (autocode) demonstrated similar behavior for the Pole/Zero block as well. It may take a user code block or possibly a BlockScript block to implement the dynamic feature that you have described.

[Carl L.]

This behaviour is documented in the AutoCode Users manual. It is described in the 6.2.2 and 7.0 manuals in section 2.1.4 (Limitations/Restrictions).
The four blocks that do not generate parameterized code are:
State Space Block
Num, Den Block
Gain, Zeros, Poles Block
Gain, Damps, Freqs Block
It seems reasonable that you should be able to parameterize these blocks, so I will add it as a suggestion.

Carl L
National Instruments

[TWK]

Ah Yes I remember this now, and I think the reason vars was not supported for these blocks was these were dynamic blocks and changing just one of the elements without changing all could cause stability issues.

So in the request to provide for this capability, the possible and to prevent instability issue should be considered.