I am still having a little bit of trouble understanding the sensitivity list and it activating a process.
most textbooks say that a process is activated every time an event occurs on a signal inside the sensitivity list.
process(in)
begin
x <= in;
end process;
Now looking at this example, "in" is an input declared in the entity. Now if "in" starts off at 0 and changes to 1 then the process would activate and the value of x would take in value "in". Now suppose after in changed from 0 to 1 that it now stays at constant value of 1. Does this mean the process will not get activated? Will x still give output of '1'? I want to say that it wont get activated and will only activate once in changes back from 1 back to 0. Can someone please confirm?
Within the sensitivity list (I assume this is hardware language, VHDL has the same exact syntax and format), whenever there is some type of signal change (L-> H, 0 ->1, 1-> 0... any change in the variable you listed within the sensitivity list), it will activate the process and the process will execute until completion, which then the process will end. When the process end, signals/outputs (depends on how you interpret them) will be stored on a driver, which will update given signals after some propagation delay.
So from your second statement, yes. If it changes to 0 -> 1, the process activates, if its 1 -> 0, the process activates, and if in remains 1, the process will not be activated. So x's value remains.
Related
So I have my Q and E set to control a Camera that is fixed in 8 directions. The problem is when I call Input.is_action_just_pressed() it sets true two times, so it does its content twice.
This is what it does with the counter:
0 0 0 0 1 1 2 2 2 2
How can I fix thix?
if Input.is_action_just_pressed("camera_right", true):
if cardinal_count < cardinal_index.size() - 1:
cardinal_count += 1
else:
cardinal_count = 0
emit_signal("cardinal_count_changed", cardinal_count)
On _process or _physics_process
Your code should work correctly - without reporting twice - if it is running in _process or _physics_process.
This is because is_action_just_pressed will return if the action was pressed in the current frame. By default that means graphics frame, but the method actually detect if it is being called in the physics frame or graphic frame, as you can see in its source code. And by design you only get one call of _process per graphics frame, and one call of _physics_process per physics frame.
On _input
However, if you are running the code in _input, remember you will get a call of _input for every input event. And there can be multiple in a single frame. Thus, there can be multiple calls of _input where is_action_just_pressed. That is because they are in the same frame (graphics frame, which is the default).
Now, let us look at the proposed solution (from comments):
if event is InputEventKey:
if Input.is_action_just_pressed("camera_right", true) and not event.is_echo():
# whatever
pass
It is testing if the "camera_right" action was pressed in the current graphics frame. But it could be a different input event that one being currently processed (event).
Thus, you can fool this code. Press the key configured to "camera_right" and something else at the same time (or fast enough to be in the same frame), and the execution will enter there twice. Which is what we are trying to avoid.
To avoid it correctly, you need to check that the current event is the action you are interested in. Which you can do with event.is_action("camera_right"). Now, you have a choice. You can do this:
if event.is_action("camera_right") and event.is_pressed() and not event.is_echo():
# whatever
pass
Which is what I would suggest. It checks that it is the correct action, that it is a press (not a release) event, and it is not an echo (which are form keyboard repetition).
Or you could do this:
if event.is_action("camera_right") and Input.is_action_just_pressed("camera_right", true) and not event.is_echo():
# whatever
pass
Which I'm not suggesting because: first, it is longer; and second, is_action_just_pressed is really not meant to be used in _input. Since is_action_just_pressed is tied to the concept of a frame. The design of is_action_just_pressed is intended to work with _process or _physics_process, NOT _input.
So, apparently theres a built in method for echo detection:
is_echo()
Im closing this.
I've encountered the same issue and in my case it was down to the fact that my scene (the one containing the Input.is_action_just_pressed check) was placed in the scene tree, and was also autoloaded, which meant that the input was picked up from both locations and executed twice.
I took it out as an autoload and Input.is_action_just_pressed is now triggered once per input.
I am very new to labview and recently I had been trying to make this sequence loop.
E.g.
myRio's starting position is ((x <0.05) && (y <=0.05) &&( z>0.9))
next while detecting myRio's position changes to ((x<0.2) && (y <= -0.9) &&( z<=0.3)) and then back again to the starting position, it will turn validate this as one correct cycle and change the counter from 0 to 1. and loop this whole sequence again.
Would really appreciate if you could highlight how can I do these kind of sequence looping. Thank you very much.
It sounds as if what you are trying to do is to count transitions between states. A great design pattern for anything involving transitions between states - which covers a large part of what people generally use LabVIEW for - is a state machine.
The link gives an explanation but essentially what you need is:
a While loop with a shift register
a case structure inside the loop whose case selector is wired to the left shift register terminal
some logic inside each case that decides what value to output to the right shift register terminal, i.e. what state to go to next.
In your case you could implement this with just two states:
State 1: Check position and see if we have reached the target position.
If so go to State 2
If not go to State 1 again
State 2: Check position and see if we have got back to the start position.
If so, increment the count and go to State 1
If not, go to State 2 again
However it would be slightly more elegant to use three states:
State 2: Check position and see if we have got back to the start position.
If so, go to State 3
If not, go to State 2 again
State 3: Increment the count and go to State 1.
You can use a second shift register for the counter: initialise it to 0, wire the left terminal across to the right one in States 1 and 2 (leaving the count unchanged) and increment it in State 3.
You can use an integer value or a string for the case selector, but the best practice is to use an enum which you save as a typedef. This allows you to reorder, rename, add or remove states later on without breaking existing code.
A: if
:: q?a -> ...
:: else -> ...
fi
Note that a race condition is built-in to this type of code. How long
should the process wait, for instance, before deciding that the
message receive operation will not be executable? The problem can be
avoided by using message poll operations, for instance, as follows:
The above citation comes from http://spinroot.com/spin/Man/else.html
I cannot understand that argumentation. Just Spin can decide on q?a:
if q is empty then it is executable. Otherwise, it is blocking.
The given argument raised a race condition.
But, I can make the same argument:
byte x = 1;
A: if
:: x == 2 -> ...
:: else -> ...
fi
It is ok from point of Spin's view. But, I am asking, How long should the process wait, for instance, before deciding that the value of x will not be incremented by other process?
The argumentation is sound with respect to the semantics of Promela and the selection construct. Note that for selection, if multiple guard statements are executable, one of them will be selected non-deterministically. This in turns implies the semantics such that selection (even though it can non-deterministally execute guards) needs to determine which guards are executable at the point of invocation of the selection statement.
The question about the race condition might make more sense when considering the semantics of selection and message receives. Note that race condition in this case means that the output of the selection might depend on the time for which it needs to invoke the receive (i.e. whether it finishes at a point at which there is a message in the channel or not).
More specifically, for the selection statement, there should be no ambiguity in terms of feasible guards. Now, the message receive gets the message from the channel only if the channel is not empty (otherwise, it cannot finish executing and waits). Therefore, with respect to the semantics of receive, it is not clear whether it is executable before it is actually executed. In turn, else should execute if the receive is not executable. However, since else should execute only if ? is not executable, so to know if else is executable the program needs to know the future (or determine how much should it wait to know this, thus incurring the race condition).
Note that the argument does not apply to your second example:
byte x = 1;
A: if
:: x == 2 -> ...
:: else -> ...
fi
since here, to answer whether else is eligible no waiting is required (nor knowing the future), since the program can at any point determine if x == 2.
On the website I am writing, there is an object called person which holds a variable called balance. At one point I call the set method and change balance's value to 100 from 0.
I noticed there was a problem when the at the end running my program the value of balance was back to 0. Placing a break point where it changes balance with the code
User.person.balance = Date.Parse(txtBal_Updated.Text)
it goes through the setter and changes the value from 0 to 100. I stop the program right after this change and use the tracer to look at the value of balance and it say 100. But if I look at person and through person to balance it shows that it is 0. Then when I look back at balance it has suddenly changed back to 0 without me stepping through the program at all. I am very confused how an objects value can change without the program running.
What is the thing that you call “your program” ? Is it some JavaScript in a Web page ? How do you run it ?
What is “the tracer” ? With what tool(s) you inspect the variables ?
Your problem makes me think strongly of variable scope. You may experience some garbage-collecting too.
You focus on the variables themselves. In your situation, I suspect first the instrumentation.
I can just speak a little English so I hope you can understand what I said.
I fork a child process , then I do ADD in child process. EX: 56+48=104
If the value lower than 255 , I can use "wexitstatus(status)" to get the answer.
But if the value higher than 256, it would be wrong !
How can I do?
If the program returns an exit code > 255, the program is simply wrong and needs to be fixed. That's against Unix standard. If you're not using standard Unix, you're probably going to need specialist help from within your organisation contacts.
From manpage for wait():
WEXITSTATUS(stat_val)
If the value of WIFEXITED(stat_val) is non-zero, this macro evaluates to the low-order 8 bits of the status argument that the child process passed to _exit() or exit(), or the value the child process returned from main().
It's limited to 8-bits, which means 1 byte, which means the int from WEXITSTATUS can only range from 0-255. In fact, any Unix program will only ever return a max of 255.
Additionally, many OS's/programs reserve > 127 for system designated codes, so you shouldn't even use anything above that.
If you need more return codes than 126 (since 0 is no error), consider writing it to STDOUT and hooking that.