I inherited some LabVIEW that has a time counter on it. Although I don't completely understand it because I am not familiar to LabVIEW and I have been successful to some extent.
What I couldn't make though, is to initialize this counter.
And this is my unsuccessful attempt (it just doesn't progress anymore).
I've seen this question that seems similar, but it didn't help me to solve my problem.
Also, my attempt was based on this NI help: http://zone.ni.com/reference/en-XX/help/371361P-01/lvhowto/initializing_shift_registe/ after which I assumed it would work, but it doesn't.
This does what I believe you're going for. It now resets when first called or when the reset button is pressed. Also, I put a tiny wait in there to avoid unnecessary CPU loading.
The reason your attempt to fix it didn't work is because you were initializing the shift register of the timer every time it ran. That shift register has to be left uninitialized so it can retain the value from the previous run.
Here is example of timer, with reset functionallity. It is done as FGV - functional global variable.
Below are screenshots of the each state:
Related
I'm new to Anylogic and created a simple traffic model. Only use 'carSource', 'CarMoveTo', 'Car Dispose' blocks to set the car routes. But After I ran the model, it worked for a while, then all the cars froze without any error occurring. ’Events‘ panel also stopped. How to solve it?
Most likely your model is running into an infinite loop somewhere in the logic. The first place to check would be all your loops that might become infinite,e.g Do loops, Do-while loops, iterator for loops where you perhaps change the counter variable manually...
If you have the professional version of AnyLogic the best option is to run the model in debug mode until you get this to the point where it freezes and then press pause. You will then see where in the code the model is getting stuck.
If this does not work you might need to start putting traceln in major functions and see ing you can spot the last traceln that gets printed and keep on adding more and more until you can find the point between two traceln where the model freezes
I had the same problem, that after a certain time, all cars froze and there wasn't a signle error.
The problem on my side was that the stop line was too close to the intersection, so I moved it a little bit farther.
I have a UIAnimation that pulls out a message log, but I need to populate the message log using a for loop as well. I have the animation taking place before the for loop begins, however, the animation doesn't actually begin until after the for loop finishes executing (even though the loop is located after the UIAnimation).
I've tried putting the contents of the for loop within an autoreleasepool (did not work)
I've tried running the for loop on a background thread, however, most of the code within the loop needs to be executed on the main thread, and I haven't had success with that approach.
The for loop is very large, and most of the code is irrelevant to the question, so you can set this up using any UIAnimation, and any relatively time consuming for loop...
for example:
let someView = UIView(frame:CGRect(x:self.view.frame.size.width,y:0,width:self.view.frame.size.width,height:self.view.frame.size.height))
someView.backgroundColor = .red
UIView.animate(withDuration:0.3,animations:{
self.someView.frame.origin.x = 0
})
//You can wrap this with something like:
//DispatchQueue.global(qos: .background).async(execute: {
//But this^ doesn't work on the majority of the code within the loop
for i in 0...1000{
print("hopefully this loop takes a few seconds to finish executing")
print("mainthread tasks being executed")
print("populating UITable in my particular case, and rendering Images/Video/text")
}
The closest that I can get to making it better is to add a "completion" to my UIAnimation, (which will allow the UIView to pull out completely/immediately) but then there is still a second of wait time before the first messages appear...
Also, I am populating a UITableView within the for loop. Not sure if that has any extra relevance to the primary issue I'm having or not...
I'm pretty familiar with DispatchQueue and the differences between async/sync. If you have any potential solutions, or ideas, please let me know.
The animation does not happen immediately, when you call UIView.animate. In stead all the animations are collected and run at some appropriate time. This is why the animation only starts after your for loop is done.
So the way to fix it is to get the animation to run before your for loop runs. Now, accepting what you say, that the for must run on the main thread, you have a number of options. You could put the for loop inside a DispatchQueue.main.async{} or somehow throttle it down so that the animation gets going first. Your idea of using the completion is a good one but you mention some practical issues you picked up with it. So either solve those practical issues, try to run the for inside a DispatchQueue.main.async{} or even, based on practical considerations, start the for loop on the main thread but somewhere else, say in something like didLayoutSubviews (fixed) or as now together with the animation but after a few millis delay to allow the animation to get going.
It's an interesting question. This made me think!
Yes, you mentioned that you understand differences between async/sync but didn't mention if you tried animating in the main thread.
Did you try putting the
UIView.animate(...) in DispatchQueue.main.async{}?
When you are stepping through Swift code in Xcode (9/10?), there is a green bar on the right with something like:
You are supposed to be able to drag the partial-hamburger-menu upwards to rewind the statement pointer to re-run code. However, every time I try it it moves back as expected, but then 100% of the time I step from that point I get:
Is there a trick to this?
You can move the pointer to the next statement to be executed to either a previously executed statement or a not-yet-executed statement, but in order for that to work the stack needs to be in the correct state, and so do the variables in memory.
In my experience, the outcome is usually a crash.
You'd need to drop down to the assembler code and examine it in order to figure out what's really going on, and might need to patch variables and/or the contents of the stack in order for your code to survive the change of program counter. I've never invested the time to try to do that, however. As a result I find the feature pretty much useless, and have given up on it. (I've worked in assembler a LOT in years past, but never learned enough about ARM assembler to be able to read it well, much less hack registers, memory, and the stack to make moving the program counter work.)
Earlier this month I asked this question 'What is a runloop?' After reading the answers and did some tries I got it to work, but still I do not understand it completely. If a runloop is just an loop that is associated with an thread and it don't spawn another thread behind the scenes how can any of the other code in my thread(mainthread to keep it simple) execute without getting "blocked"/not run because it somewhere make an infinite loop?
That was question number one. Then over to my second.
If I got something right about this after having worked with this, but not completely understood it a runloop is a loop where you attach 'flags' that notify the runloop that when it comes to the point where the flag is, it "stops" and execute whatever handler that is attached at that point? Then afterwards it keep running to the next in que.
So in this case no events is placed in que in connections, but when it comes to events it take whatever action associated with tap 1 and execute it before it runs to connections again and so on. Or am I as far as I can be from understanding the concept?
"Sort of."
Have you read this particular documentation?
It goes into considerable depth -- quite thorough depth -- into the architecture and operation of run loops.
A run loop will get blocked if it dispatches a method that takes too long or that loops forever.
That's the reason why an iPhone app will want to do everything which won't fit into 1 "tick" of the UI run loop (say at some animation frame rate or UI response rate), and with room to spare for any other event handlers that need to be done in that same "tick", either broken up asynchronously, on dispatched to another thread for execution.
Otherwise stuff will get blocked until control is returned to the run loop.
What is the best way to handle this situation on an iPhone device: My program ramps the pitch of a sound between two values. A button pressed calls a method that has a while loop that does the ramping in small increments. It will take some time to finish. In the meantime the user has pressed another button calling the same method. Now I want the loop in the first call to stop and the second to start from the current state. Here is the something like what the method should look like:
-(void)changePitchSample: (float) newPitch{
float oldPitch=channel.pitch;
if (oldPitch>newPitch) {
while (channel.pitch>newPitch) {
channel.pitch = channel.pitch-0.001;
}
}
else if (oldPitch<newPitch) {
while (channel.pitch<newPitch) {
channel.pitch = channel.pitch+0.001;
}
}
}
Now how to best handle the situation where the method is called again? Do I need some kind of mulitthreading? I do not need two processes going at the same time, so it seems there must be some easier solution that I cannot find (being new to this language).
Any help greatly appreciated!
You cannot do this like that. While your loop is running no events will be processed. So if the user pushes the button again nothing will happen before your loop is finished. Also like this you can’t control the speed of your ramp. I’d suggest using a NSTimer. In your changePitchSample: method you store the new pitch somewhere (don’t overwrite the old one) and start a timer that fires once. When the timer fires you increment your pitch and if it is less than the new pitch you restart the timer.
Have a look at NSOperation and the Concurrency Programming Guide. You can first start you operation the increase the pitch and also store the operation object. On the second call you can call [operation cancel] to stop the last operation. Start a second operation to i.e. decrease the pitch and also store the new object.
Btw: What you are doing right now is very bad since you "block the main thread". Calculations that take some time should not be directly executed. You should probably also have a look at NSTimer to make your code independent of the processor speed.
Don't use a while loop; it blocks everything else. Use a timer and a state machine. The timer can call the state machine at the rate at which you want things to change. The state machine can look at the last ramp value and the time of the last button hit (or even an array of UI event times) and decide whether and how much to ramp the volume during the next time step (logic is often just a pile of if and select/case statements if the control algorithm isn't amenable to a nice table). Then the state machine can call the object or routine that handles the actual sound level.