How to manually switch between more than 2 signals in Simulink - switch-statement

Consider the block Manual switch in Simulink. It enables you to switch manually between two inputs. If you have, more than two inputs, a natural thing to do is to construct a cascade as shown in this picture.
Is there an alternative in case of many inputs, such as one manual switch with n inputs?
Note that I was wondering whether there was a 'manual' way to do this. An alternative would be to use a multiport switch and set it with an initialisation script.

A Manual Variant Source can be used. You can edit mask parameters to specify the number of inputs

One way to approach this would be to use a Multiport Switch.
This allows you to switch between several outputs based on the value of the first input (which you can tie to a constant block).
This way, when you start a simulation, you can choose the desired input by changing the value of the constant block in your model.
Mathworks Multiport Switch Help

Adding to the accepted answer, I achieved it using a Multiport Switch and a Rotary Switch.

Related

Do I use foreach for 2 different inspection checks in activity diagram?

I am new in doing an activity and currently, I am trying to draw one based on given description.
I enter into doubt on a particular section as I am unsure if it should be 'split'.
Under the "Employee", the given description is as follows:
Employee enter in details about physical damage and cleanliness on the
machine. For the cleanliness, there must be a statement to indicate
that the problem is no longer an issue.
As such, I use a foreach as a means to describe that there should be 2 checks - physical and cleanliness (see diagram in the link), before it moves on to the next activity under the System - for the system to record the checks.
Thus, am I on the right track? Thank you in advance for any replies.
Your example is no valid UML. In order to make it proper you need to enclose the fork/join in a expansion region like so:
A fork/join does not accept any sematic labels. They just split the control flow into several parallel ones which join at the end.
However, this still seems odd since you would probably have some control for the different inspections being entered. So I'd guess there's a decision which loops through multiple inspection entries. Personally I use regions only for handling interrupts. ADs are nice to a certain level. But sometimes a tabular text (like suggested by Cockburn) is just easier to write and read. Graphical programming is not the ultimate answer (unlike 42).
First, the 'NO' branch of the decision node must lead somewhere (at the end?).
After, It differs if you want to show the process for ONE or MULTIPLE inspections. But the most logical way is to represent the diagram for an inspection, because you wrote inspection without S ! If you want represent more than one inspection, you can use decision and merge node to represent loop that stop when there is no more inspection.

Washing machine petri net

It is my first time doing a Petri net, and I want to model a washing machine. I have started and it looks like this so far:
Do you have any corrections or help? I obviously know its not correct, but I am a beginner and not aware of the mistakes you guys might see. Thanks in advance.
First comments on your net's way of working:
there is no arrow back to the off state. So once you switch on your washing machine, won't you never be able to switch it off again ?
drain and dry both conduct back to idle. But when idle has a token, it will either go to delicate or to T1. The conditions ("program" chosen by the operator) don't vanish, so they would be triggered again and again.
Considering the last point, I'd suggest to have a different idle for the end of the program to avoid this cycling. If you have to pass several times through the same state but take different actions depending on the progress, you have to work with more tokens.
Some remarks about the net's form:
you don't need to put the 1 on every arc. You could make this more readable by Leaving the 1 out and indicating a number on an arc, only when more than one tokens would be needed.
usually, the transitions are not aligned with the arcs (although nothing forbids is) but rather perpendicular to the flow (here, horizontal)
In principle, "places" (nodes) represent states or resources, and "transitions" (rectangles) represent an event that changes the state (or an action that consumes resources). Your naming convention should better reflect this
Apparently you're missing some condition to stop the process. Now once you start your washing will continue in an endless loop.
I think it would be nice to leave the transition graphics unshaded or unfilled if it is not enabled. Personally I fill it green if it is enabled.
If you want someone to check if you modeled a logic properly in your Petri Net then it would be nice if you include a description of your system logic in prose.

Temporal logic for modelling events at discrete points in time causing states/changes over a period of time

I am looking for an appropriate formalism (i.e. a temporal logic) to model the following kind of situation
There can be events happening at discrete events in time (subject to conditions to be detailed below).
There is state. This state cannot be expressed by a fixed number of variables. However, it is possible to express it with a linear list/array, where each entry consists of a finite number of variables.
Before any events have happened, the state is fixed.
At any point in time, events are possible. They have a fixed structure (with a few variables). The possible events are constrained by the current state.
Events will cause an immediate change of the state.
Events can also cause continuous state changes. For example, a variable (of one of the entries of the array mentioned above) changes its value from 0 to 1 over some time (either immediately or after a specified delay).
It should also be possible to specify discrete points in time in the form "the earliest point in time after event E where some condition C holds", and to start a continuos state change at such a point.
Is there an existing temporal logic to model something like this?
It should also be possible to express desired conditions, like the following:
Referring to a certain point in time: The sum of a specific variables of all the entries of the array may not exceed a certain threshold.
Referring to change over time: For all possible time intervals, the value of a certain variable (again, from each entry of said array) [realistically, rather of some arithmetic expression computed for each entry] must not change faster than a given threshold.
There should exist a model checker that can check whether for all possible scenarios, all the conditions are met. If this is not the case, it should print one possible scenario and tell me which condition is not met. In other words, it should distinguish between conditions describing the possible scenarios, and conditions that have have to be fulfilled in those scenarios, and not just tell me "not possible".
You need a model checker with more flexible language. Technically speaking model checking of systems of infinite state space is open research problem and in general case algorithmically undecidable. The temporal logic is more typically related to propreties under the question.
Considering limited info you shared about your project, why do not you try Spin/Promela it is loosely inspired by C and has 'buffers' which can be considered to be arrays. At the least you might be able to simulate your system?

Bumpless transfer in FRP

I can build a PID controller in the Haskell FRP library netwire using loop from the ArrowLoop instance provided for Wires.
I can also implement switching between controllers or between a controller and a manual input using switch.
How can I implement bumpless transfer, for example using the "tracking" strategy explained here (or in any number of control engineering articles/books)? Another strategy might be acceptable if it has good performance, but the tracking approach is appealing for my application because it also address anti-windup.
I'm having trouble squinting at the block diagram hard enough to make it look like the type of two (or one?) loop applications.
There are two loops in each diagram. It's helpful when finding loops to redraw the diagrams so that all of the inputs enter the same sides of all of the elements, all of the outputs leave the same other sides, and, if possible, minimize line crossings. In these diagrams, inputs enter the bottom, left, or top of an element, and outputs leave to the right.
The overall system has one loop, feeding the output of the process into the subtraction for the error comparison:
The control system has one loop, feeding the final control output after selection of controller (the PID controller or the manual control) into the tracking PID controller. The overall output is the Output on the far right.
The tracking PID controller has two loops. One is the feedback loop for the derivative. The loop for the derivative could disappear inside another component. The other loop feeds back the output of the PID controller into the comparison between the PID controller's output and the control output actually controlling the process. Note that the order of the P,D,and I branches is different in this diagram to remove the line crossings
Notice that if the tracking PID controller had its own Output connected to Track, the difference from the first subtraction would be 0, and the integration branch would be unchanged by the addition of 0.

UVM: Does setting values to sequence_item before I call start_item(seq_item) cause any issue?

I am setting values to sequence_item before I call start_item(seq_item) any different from setting values after calling start_item(seq_item)?
Yes, you can do this, but realize that start_item() is a blocking task, so the state of your design and testbench may be different before versus after.
The main reason for randomizing a seq_item after start_item returns is to enable the transaction to be randomized based on the current state of the machine. If you don't have a dependency on the testbench state, then there is no functional difference.
I think the bigger issue is to use the established pattern of deferred randomization so that all of your code looks the same and so that anyone copying your code as a template (including you) follows the pattern just in case the order does matter.
Consistency in your code will help prevent bugs.

Resources