I have a Sample and Hold block inside a Resettable Subsystem and it is not resetting.

I have a Sample and Hold block inside a Resettable Subsystem and it is not resetting.

Here is the Resettable Subsystem:

Here is the Sample and Hold block inside the Resettable Subsystem.

Here is the behavior. The signals controlled only happen once. The Sample and Hold behaves as if it's stuck permanently.

The sample and hold output does not reset. The initial condition of the Sample and Hold block is 0. I'm expecting the reset signal to reset the Sample and Hold block back to it's initial value of 0. It does not do this.

What do I have wrong?

Thanks,

-Abraxas3d

[Michelle Thompson]

Going through the example here: openExample('hdlcoder/ResettableSubsystemSupportInHDLCoderExample')

and reading the write-up at https://www.mathworks.com/help/hdlcoder/ug/resettable-subsystem-support-in-hdl-coder.html

it sure seems like what we've got with a simpler model should work.

We are still looking for help with getting an S&H block resetting properly inside a resettable subsystem.

-Abx

[Michelle Thompson]

Still not working. Help?

[Fangjun Jiang]

The rising edge of "AGC Burst SH reset signal" is around t=0.0008. The figure couldn't show whether it is working or not.

[Paul]

@Michelle Thompson

Are you refering to Sample and Hold?

It's not clear to me that that block has a "state" that can be reset. It seems that the resettable subsystem is to apply for blocks that have reset ports. There are exceptions (I can't find a full list or other per-block documentation), but that S/H block does not have a reset port.

[Michelle Thompson]

We should see another burst, as we see in the middle of the graph on the first rising edge. The figure is intended to help illustrate the behavior I am seeing. This behavior is contradictory to the documentation for all the blocks involved.

After nearly a month on MATLAB Answers, and after finding three or four other people reporting the same disappointment (Sample and Hold not working inside a Resettable Subsystem) with no answers for them either, I'm starting to think that 1) this feels like a bug and 2) MATLAB Answers is the wrong place to go for help.

[Paul]

"We should see another burst, as we see in the middle of the graph on the first rising edge"

Where is the first rising edge? It looks like there is only one rising edge at just before t = 0.0008. The burst occurs just before t = 0.0005, but there doesn't appear to be a rising edge at that time.

Why do you think the behavior is contradictory to the documentation for all the blocks involved? Of course, it would help if you provided a link to the documentation to which you are referring (as was asked for at least one of the blocks involved).

Based on the green line and your statement in the question, the initial condition for the block is zero, which is the same value of the output of the block after the rising edge hits at just before t = 0.0008.

What should the output of the S/H block if the trigger signal and reset signal have simulatenously rising edges, like if they were both the same signal? Should it sample the input or rese to the initial condition?

If you feel like the observed behavior is a bug, feel free to report it as such. Click on Support -> Contact Us and go from there. You'll get a response from Tech Support within a day or two; they are very responsive. If you go down this path, please post back here with their response.

Answer 1

[Fangjun Jiang]

The "Latch (buffer) input" has to be checked to see this effect. I think the reason is due to the execution order. The SH block always updates its output at its sample hit (rising edge). When this sample hit coincides with the Resettable Subsystem sample hit (rising edge), it got reset first and then got sampled.

The SH block has a state. Using a State Reader block seems to be able to find it. The model is in R2022b.

[Paul]

Are you saying that "Latch (buffer) input" needs to be set in order for the block to reset inside a Resettable Subsystem?

Setting "Latch (buffer) input" also changes the behavior of the block (independent of the Resettable Subsystem question), which the user needs to be aware of.

In 2021a:

get_param(gcb,'IsStateOwnerBlock')

returns 'off' (gcb is the S/H block). Can you check for a different result in 2022b?

[Fangjun Jiang]

It also returns "off".

[Paul]

Interesting. As I understand it from State Reader that setting needs to be 'on' if the block has state that can be accessed by State Reader (and Writer). At least that's how I read it. Now I'm wondering what you were seeing.

Would be nice if there was a block property to indicate if a block has resettable state (in the context of this thread), but I don't see anything along those lines in Common Block Properties