Sample and hold block (Simulink) - initial value dominates at t = 0?

Hi all !
In my testing of a simulink sample and hold block, I notice that the time (t = 0) output of the simulink sample and hold block (during a simulink simulation) will be equal to the 'initial value' setting (such as the default initial value of 'zero'). This is probably expected behaviour.
However, if I have some applications (simulations) where I would like the sample-and-hold block to capture the sample-and-hold's input value at t = 0 (such as an input value of '1'), then is there a method or setting that overrides the 'initial value' of the sample-and-hold block?
I've provided an example of my current situation here. The simulink file is from Matlab R2013b.
The simulation (running with fixed-step solver) simply involves a counter (that counts from 1 to 7). The counter just counts the rising edge events of the pulse generator. The pulse generator produces only regular squarewaves. The rising edge of those square-waves triggers the counts of the counter.
The sample and hold block is set up to sample the output value of the counter at each rising-edge trigger event of the counter's input.
The following behaviour is noticed with the simulation:
When the simulation runs ----- the output of the counter at time t = 0 will be '1', so that there is a step of '1' at time t = 0 for the output of the counter.
The sample-and-hold does not capture the output = 1 value of the counter associated with time t = 0.
Instead, the sample-and-hold block at time t = 0 captures the 'initial value setting' of the sample-and-hold block (ie. setting of '0'). And if I had chosen to change the initial value of the sample-and-hold block to some other value (such as -9), then the output of the sample-and-hold block would be some other value (such as -9).
Extra notes: The simulink fixed-step sampling period is 'base_sample_period, set to 5 nanosecond' (which is set in View -> Model Explorer -> Callbacks -> InitFcn*). And the pulse generator produces regular square-waves with a period of 5 microsecond.
I've included a couple of screen-shots. The first image shows the counter output (seen with a 'scope') - showing a step of '1' at time t = 0.
The second image shows the output of the sample-and-hold block, where the step of '1' is not there at time t = 0. That is, the sample-and-hold is not capturing the t = 0 step jump of the counter?
Is there a general method that everybody uses where we can get the sample-and-hold to capture the t = 0 value of the counter?
Thanks very much for any help in advance!

 Accepted Answer

I don't have the DSP System Toolbox so have replaced the Sampe and Hold with a Triggered Subsystem which exhibited the same problem you describe when it uses its Trigger default "compatibility (no trigger on first evaluation)" Instead if you set the Trigger to "zero" it will sample at time zero.

5 Comments

Hi Pat!!!!! Thanks very much for your post and your time, and also for showing me a way to achieve what I needed to do. That is really great. Genuinely appreciated. I ran your simulation file a moment ago, and it's excellent.
I notice that those options for the Initial Trigger Signal State options - such as 'compatibility' and 'zero' etc, are not available in R2013b. But fortunately I have Matlab 2017b and also Matlab 2019. The Trigger block has those options for those versions of Matlab.
Thanks again Pat!
My pleasure Kenny. I learn just as much by working on code/models developed by others, so it's win-win for us all.
Thanks Pat! Totally agree with you!
Pat - I notice something that's not critical in terms of scope behaviour. But just seeing whether you see the same thing in your matlab.
In my matlab 2017b, I placed a 'stop' block, which makes the simulation stop when the counter reaches '1' for the very first time. The 'display' blocks will show the 1 --- which is expected. And I notice that the scopes remain blank - not showing a spike with amplitude 1 at time t = 0.
Do you get the same thing when you run this attached file?
I do notice that the '1' step does show up at t = 0 when I remove the 'stop' block though, which is nice.
Scope exhibits the same behavior in 2019b. Pretty weird isn't it. It will still do this even if you insert a unit delay before the STOP. But if you manually change the time span on the time axis of the scope to something much smaller (1e-8) the trace will show up as long as there are at least two sample. If you select the scope to log the data to the workspace you will see that the time zero values are what you wanted.
Thanks again Pat! I confirm your observations. You're absolutely right there. I agree - very interesting.
The 'display' blocks will register the value for a sample occurring at t = 0, while the scope displays no spike at t = 0 for a simulation having just a single sample taken at t = 0.
And the scope will display what I want to see (graphically) when there are at least two samples taken.
Thanks for the nice recommendation about using the scope to log the data to workspace! I didn't think of doing that before. And sure enough ----- for a single sample taken at time t = 0 only ---- the workspace results is showing (in the logged scope array) a value of 1 associated with time t = 0. The scope detects the value, and logs it, and is just not plotting it.
Greatly appreciated! Thanks Pat!

Sign in to comment.

More Answers (0)

Categories

Products

Release

R2013b

Asked:

on 10 Jan 2021

Edited:

on 12 Jan 2021

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!