Hi @Martin Ryba,
Thanks for sharing the screenshot and your notes — they helped clarify exactly what’s happening in your masked subsystem. You’re absolutely right: when the mask dialog specifies an explicit numeric type, the parameter comes through as a `Simulink.NumericType` object, which you can pass directly into your MATLAB Function block. The difficulty appears when you choose one of the inheritance options such as “Inherit: Same as first input,” “Inherit: Inherit via internal rule,” or “Inherit: Inherit via back propagation.” In those cases Simulink only gives you a string in the mask workspace because the actual resolved type doesn’t exist until after the model compiles. That’s why your switch statement only sees text and why the port handles you queried are just doubles — the mask initialization runs before compiled attributes are available.
If you truly need the concrete type during mask initialization, the documented approach is to temporarily compile the model, query the compiled port data types, convert the result into a usable `Simulink.NumericType`, and then terminate compilation. A concise pattern looks like this:
ports = get_param(gcb,'PortHandles'); outp = ports.Outport(1); mdl = bdroot(gcb);
% Compile, query, and terminate safely feval(mdl,[],[],[], 'compile'); dtstr = get_param(outp, 'CompiledPortDataTypes'); feval(mdl,[],[],[], 'term');
% Convert the resolved type into fi
ntype = Simulink.NumericType(dtstr.Outport{1});
qtype = fi(0, ntype);
This gives you the `fi` object you’re already passing into your MATLAB Function block, and it works with `fixed.extractNumericType()`. The main caveats are performance (compiling from inside the mask makes the dialog slower), potential recursion issues if the model is already compiling, and the possibility that inactive or variant ports may yield empty results.
Because of those caveats, the cleaner design is often to let Simulink handle inheritance itself: assign the inheritance string directly to the child block’s `OutDataTypeStr` and let the type propagate naturally, with your MATLAB Function block discovering the concrete type at compile time. Another option is to require an explicit numeric type when downstream code generation absolutely demands it. In short, your existing approach is already correct for explicit types, inheritance rules can only be resolved via the compile/query/term recipe if you need them early, and in many cases the safest approach is to rely on Simulink’s propagation engine.
