ssSetSampleTime()/ssGetSampleTime() in C-MEX s-function
Steve Amphlett
Steve Amphlett
> If I set the sample time to -1 (inherited), using the ssSetSampleTime() macro, the corresponding ssGetSampleTime() macro returns different things (in other routines), depending on where my C-MEX s-function block sits. If it's at the top level of the model, or in a simple subsystem, the value returned is the model's timestep. If it's in a function-call subsystem (or some other triggered subsystems), the value returned is -1. I can't find any help in the Simulink docs. Anyone??
Maybe it's that some subsystems don't have the concept of sample time (because they are triggered), so ssGetSampleTime() always returns -1. For subsystems that do actually have time, it returns the actual inherited time??
Steve Amphlett
> "Steve Amphlett" <Firstname...@Where-I-Work.com> wrote in message <htm6j7$ro7$1...@fred.mathworks.com>...
> > If I set the sample time to -1 (inherited), using the ssSetSampleTime() macro, the corresponding ssGetSampleTime() macro returns different things (in other routines), depending on where my C-MEX s-function block sits. If it's at the top level of the model, or in a simple subsystem, the value returned is the model's timestep. If it's in a function-call subsystem (or some other triggered subsystems), the value returned is -1. I can't find any help in the Simulink docs. Anyone??
>
>
> Maybe it's that some subsystems don't have the concept of sample time (because they are triggered), so ssGetSampleTime() always returns -1. For subsystems that do actually have time, it returns the actual inherited time??
If anybody cares, here are my findings:
The macro ssGetSampleTime() cannot reliably be used to get the block sample rate. Its return value depends on the solver type, whether the block is inheriting its sample rate and whether the block is in a triggered subsystem. This is documented nowhere in the Matlab help system (I opened a support enquiry with TMW about this). Experimentation showed that the macro returns:
If in a triggered subsystem, -1.
If in a block inheriting timestep, running with a variable solver: 0.
If in a block with fixed timestep, running with a variable solver: the fixed timestep.
If in any inheriting block with a fixed solver, the inherited timestep actually used.
So there are 4 distinct behaviours for this macro. But at least it seems (though not verified by either TMW or their docs) that any positive value is ok to use as the block sample time.
Praetorian
Work.com> wrote:
> "Steve Amphlett" <Firstname.Lastn...@Where-I-Work.com> wrote in message <htm744$5e...@fred.mathworks.com>...
> > "Steve Amphlett" <Firstname.Lastn...@Where-I-Work.com> wrote in message <htm6j7$ro...@fred.mathworks.com>...
> > > If I set the sample time to -1 (inherited), using the ssSetSampleTime() macro, the corresponding ssGetSampleTime() macro returns different things (in other routines), depending on where my C-MEX s-function block sits. If it's at the top level of the model, or in a simple subsystem, the value returned is the model's timestep. If it's in a function-call subsystem (or some other triggered subsystems), the value returned is -1. I can't find any help in the Simulink docs. Anyone??
>
> > Maybe it's that some subsystems don't have the concept of sample time (because they are triggered), so ssGetSampleTime() always returns -1. For subsystems that do actually have time, it returns the actual inherited time??
>
> If anybody cares, here are my findings:
>
> The macro ssGetSampleTime() cannot reliably be used to get the block sample rate. Its return value depends on the solver type, whether the block is inheriting its sample rate and whether the block is in a triggered subsystem. This is documented nowhere in the Matlab help system (I opened a support enquiry with TMW about this). Experimentation showed that the macro returns:
>
> If in a triggered subsystem, -1.
> If in a block inheriting timestep, running with a variable solver: 0.
> If in a block with fixed timestep, running with a variable solver: the fixed timestep.
> If in any inheriting block with a fixed solver, the inherited timestep actually used.
>
> So there are 4 distinct behaviours for this macro. But at least it seems (though not verified by either TMW or their docs) that any positive value is ok to use as the block sample time.
Steve,
I've also tinkered with this a while back (sorry, I missed your
earlier posts on the subject). I believe TMW also uses the offset time
to convey some information. There is a macro named
ssSampleAndOffsetAreTriggered and I think it just checks whether both
sample and offset times are set to -1.
Also, other cases where ssGetSampleTime cannot be used reliably are:
If your S-Function uses port based sample times, use
ssGetIn(Out)putPortSampleTime in that case.
If your S-Function has inputs / outputs set to different sample times;
not quite sure what to use in this case but I believe to implement
such an S-Function you need to have port based sample times, so the
first case would apply.
Regards,
Ashish.
Steve Amphlett
> > If anybody cares, here are my findings:
> >
> > The macro ssGetSampleTime() cannot reliably be used to get the block sample rate. Its return value depends on the solver type, whether the block is inheriting its sample rate and whether the block is in a triggered subsystem. This is documented nowhere in the Matlab help system (I opened a support enquiry with TMW about this). Experimentation showed that the macro returns:
> >
> > If in a triggered subsystem, -1.
> > If in a block inheriting timestep, running with a variable solver: 0.
> > If in a block with fixed timestep, running with a variable solver: the fixed timestep.
> > If in any inheriting block with a fixed solver, the inherited timestep actually used.
> >
> > So there are 4 distinct behaviours for this macro. But at least it seems (though not verified by either TMW or their docs) that any positive value is ok to use as the block sample time.
>
> Steve,
> I've also tinkered with this a while back (sorry, I missed your
> earlier posts on the subject). I believe TMW also uses the offset time
> to convey some information. There is a macro named
> ssSampleAndOffsetAreTriggered and I think it just checks whether both
> sample and offset times are set to -1.
>
> Also, other cases where ssGetSampleTime cannot be used reliably are:
> If your S-Function uses port based sample times, use
> ssGetIn(Out)putPortSampleTime in that case.
> If your S-Function has inputs / outputs set to different sample times;
> not quite sure what to use in this case but I believe to implement
> such an S-Function you need to have port based sample times, so the
> first case would apply.
>
> Regards,
> Ashish.
When ssGetSampleTime() returns zero (variable solver, inherited block sample, quite a common combination), all I think to do was to use:
ssGetT(S)-ssGetTimeOfLastOutput(S)
even though ssGetTimeOfLastOutput(S) is not documented. Using non-docs leaves me a bit queasy.
- Steve
Praetorian
Work.com> wrote:
> Praetorian <ashish.sadanan...@gmail.com> wrote in message <71157d0f-7ca1-46c1-a583-67a30832c...@q36g2000prg.googlegroups.com>...
Thanks for that tip, I didn't know about the ssGetTimeOfLastOutput()
macro. But I'm like you, I'm uneasy using undocumented API too.