Simulink: How do I change the value of a gain block with code?

I would like to change the value of a gain block with Matlab code. I tried using the ModelWorkspace along with assignin, but the problem with this method is that I cannot generate C code from it.

What is the best way to modify a variable gain block and still be able to generate C code from the Simulink block diagram?

Thank you.

[Robert]

Your intent is not clear. What do you mean you cannot generate code using a variable in the model workspace?

[J H]

Hi Robert.

In my Simulink block diagram I have a gain block with a Simulink variable for the gain. The Simulink variable is defined in the ModelWorkspace.

I am trying to modify that Simulink variable each iteration based off a Simulink signal.

My current method (which does not work) is feeding the control signal into the input port of a MATLAB function block. The MATLAB function block determines what to change the Simulink variable to via a switch statement and tries to modify the Simulink variable using the assignin() command.

The problem that I am having is that MATLAB gives me an error stating that the assignin() command is not supported for code generation. I am going to need code generation to generate C code later.

My question is: How do I accomplish the above while still supporting code generation?

Thanks.

[Robert]

Thanks for clarifying.

When you say "iteration" are you referring to each time step in the simulation or each run of the model from start to stop?

If you want to change the gain before each time you call the model, you could use a script that sets your variable then runs the model in a loop over each value of your gain. In normal and accelerator modes this is pretty straightforward. In rapid accelerator it is a little more tricky but still manageable.

If you are trying to modify the gain while the model is running, perhaps a multiplication operator would be more suitable.

[J H]

Thank you.

Yes. I am trying to modify the gains while the model is running.

I was considering using a multiplication operator; however, I have several (50+) locations (within several subsystems) where the gains are used. Consequently, my model would become very messy if I had to route signals through multiplication operators instead of using variable gains.

Is there any other way that I could accomplish this task?

Thanks again.

[Robert]

I think I understand your question now. I took a crack at answering it, below.

Answer 1

[Robert]

From our conversation in the comments:

• You have 50+ gain blocks scaling signals in your model.
• You intend to generate C code from that model.
• You want the gain blocks to have time-varying gain – similar in behavior to a multiplication block but without the added clutter of extra signals.
• You were able to modify the gain values "on-the-fly" using an embedded MATALB function that used assignin to alter the gain value stored in the model workspace.

Were you designing this model before implementing it, I would recommend you use multiplication blocks instead of gain blocks. Now that your model is implemented and the 50+ gain blocks are in place, it might be excusable to bend the usual modeling best-practices and use GoTo and From tags with global scope to make a subsystem that uses a multiplication block but fits neatly in the spaces you now have gain blocks (one input, one output). To accomplish this, you would need to:

1. Add a global goto tag to your control signal
2. Create a subsystem in a library with one inport and one outport
3. Add a multiplication block and a from tag to your subsystem to multiply your input by the (now variable) gain
4. Use replace_blocks to swap out all the relevant gain blocks with your new pseudo-gain

You could replace the blocks by hand, in which case you don't strictly need a library, but with 50+ blocks to replace – and possible change in the future – you would be better off using a library and replace_block.

I haven't used global GoTo tags in code generation before but I don't see why they wouldn't be supported and noting in the documentation (that I have found) indicates that they aren't).