I have noticed that a forever (or a repeat () )loop takes time between iterations(without a “wait () secs” block). How long is this exactly?
Testing with this code:
Gave an average of 0.000000994 seconds per iteration, so it seems there is likely no intentional delay outside of processing time.
It runs at around 30 times per second, but it varies...
Related
I am a newbie at ladder logic. The program linked below runs a timer, and updates the delta time between each "frame".
https://www.plcfiddle.com/fiddles/e56c6cf0-d858-4327-b291-7cdc1067ffc1
The preset value for the timer is set to 10, so the timer stops after 10 seconds. I want this timer to run indefinitely. My first guess is to set the preset value to 0 (or a negative number), but this prevents the timer from running at all.
How can I make this function run indefinitely?
No need to run the timer indefinitely, just reset the timer each scan (no such thing as a frame where I come from).
See this updated fiddle.
I am trying to make a gain that decreases every x'th second. This is my solution so far:
I use an initial value block combined with a switch to make it decrease every time the switch is activated. To make it switch every x'th second I use the rem function with the time of the simulation an my x'th second.
Every time the rem function outputs zero the switch triggers and everything is well. The problem is at t=0, because then the rem function returns 0 and triggers the switch. This becomes a bigger problem when I try to introduce a delay block between the Time and Rate Transmition3 block, because then the output is 0 for the delayed time and keeps triggering my switch.
Any ideas how to fix this problem? Maybe using a different approach of triggering the switch?
You could put the REM and Switch inside an enabled subsystem with the condition to be enabled if t>0. Also, the out of the subsystem should be changed in order to give an initial output that is neutral in your system.
Please let know if this helps. Good luck
Is there any primitive to introduce a delay in the running of the NetLogo in between the execution of a model?
You can use the wait primitive to do this.
print "hello"
wait 2
print "there"
will print "hello", wait 2 seconds, then print "there".
That said, I would highly recommend avoiding using wait (and the related every). There are almost always better ways to do things. One big problem with wait is that it makes the speed slider (at the top, under the tabs) almost useless. If you want to just slow things down, use the speed slider. If you want an agent to a wait a little bit before doing something, give it a variable that counts down to 0; when the variable hits 0, then the agent performs the action. That way, the whole simulation doesn't pause, just the agent.
I have two timers running simultaneously. The first timer triggers every 1 second and takes 0.2 seconds to run. The second timer triggers every 20 minutes and takes 5 minutes to run. I would like to have the first timer continue triggering during the 5 minutes it takes the second timer execute its callback. In practice, during the second timer's callback the first timer does not trigger. Is it possible to configure the timers to execute the way I want?
There is a workaround, depending on how your timer callbacks' work is structured. If the long timer callback is running a long loop or sequence of calls to different functions, you can insert drawnow() or pause(0.01) calls to make it yield to Matlab's event dispatch queue, which will handle pending handle graphics and timer events, including your other Timer's trigger.
It's sort of like old-school cooperative multitasking where each thread had to explicitly yield control to other threads, instead of being pre-empted by the system's scheduler. Matlab is single-threaded with respect to M-code execution. When a Matlab function is running, events that get raised are put on an event queue and wait until the function finishes and returns to the command prompt, or drawnow(), pause(), uiwait() or a similar function is called. This is how you keep a Matlab GUI responsive, and is documented under their Handle Graphics stuff. But Matlab timer objects use the same event queue for their callbacks. (At least as of a couple versions ago; this is only semi-documented and might change.) So you can manage their liveness with the same functions. You may also need to tweak BusyMode on your timers.
This is kind of a hack but it should get you basic functionality as long as you don't need precise timing, and don't need the callbacks' code to actually run in parallel. (Whichever timer callback has yielded will wait for the other one to finish before proceeding with its own work.)
If the long callback is really blocked on a long operation that you can't stick drawnow calls in to, you're out of luck with basic Matlab and will need to use one of the workarounds the commenters suggest.
here is question:
i have 2 threads: the main one and the other.
on the main thread i perform anything gui related
on the other thread i perform all my calculations
on some operation i have to stop the second thread for some seconds, waiting the first thread to do something....
my question:
which is the best option and why?
being in the second thread..
use sleepUntilDate
use sleep function
any other option?
the pseudo code is this:
on the second thread:
...
do some calculations
send the results to the first thread and wait for the # of seconds to wait (let's say K)
wait K seconds
+[NSThread sleepForTimeInterval:] is more likely to do what you want if the time suddenly changes. Being in the second thread doesn't affect things.
However, I don't see why the second thread should have to sleep at all. If you want to wait for new data, use something like NSCondition or NSConditionLock to signal when data has arrived.
Alternatively, don't use threads directly at all. You can use NSOperation or performSelectorInBackground: or dispatch_*, to name a few.
EDIT: You need to be very careful when writing traditional thread-synchronization code, and you need to be just as careful every time you edit it to add a new feature. I have some threaded code which I need to think about for a couple minutes to figure out what's going on. Deadlocks are no fun.