Illegal rate transition while trying to normalize signal in simulink

1
votes

I have a signal in simulink which I want to normalize so that the highest value of the signal is always 1. So I use a MaxRunningResettable-Block to remember the highest value that passed so far. I then divide the signal by that value.

A little test with a signal generation block, the running resettable block, the divide block and a scope runs just fine. But when I add this normalizing function to my simulink model I get an error: "Model initialization failed - Illegal rate transition found involving Unit Delay"

I don't even need to connect the little test case to my other model. Simply by putting it into my model I get this error. Strangely the RunningResettable-block turns yellow when I copy it - indicating that it has a different sampling rate I suppose. I don't get why this happens. I already tried to add a zero-order-hold-block behind the RunningResettable but that didn't help.

Simulink block sheet with the troublesome RunningResettable-block

As suggest I tried to add another constant block to the R-input of the RunningResettable-Block. I tried several sampling frequencies for that Block (-1, 0, 1/fAb) but that didn't help. Error occuring after adding a constant block to R-input

1
matlabsimulinksample-rate
It looks like the block expects a discrete reset signal but outputs a continuous signal, hence the error. I would suggest maybe trying to connect a (zero) constant block to the R input. You might need to change the sample time parameter of the constant block to make it work. – am304
Thanks for the help! But sadly adding a constant block with different sampling times didn't help. I'll add another picture of the error that occurs. – Matthias La
OK. Another suggestion that has just occurred to me: can you try adding a rate transition block on the output of the signal generator set it to the same sample time as the zero constant block (red colour)? This way, both input to the MinMaxRunningResettable block will have the same sample time. – am304
This seems to do the same as the zero-order-hold I think, so I suppose it works. Thanks! – Matthias La

1 Answers

1
votes

Ok, finally I think that I found my failure. It seems, that the SignalGenerator outputs a continous signal (black). Because in my model there are mostly discrete signals this somehow causes errors. So when I simply add an zero-order-hold block after the signal generator everything seems to work just fine. The sampling frequency of the zero-order-hold has to be adjusted to the rest of the system.

enter image description here