I am trying to understand how the auto rescheduling logic is supposed to work.
The recommended values in nagios.cfg are:
auto_reschedule_checks=1
auto_rescheduling_interval=30
auto_rescheduling_window=45
Supposedly this is after they realized the default values (same as above but with window=180) had the potential to have checks that never actually get executed (See https://support.nagios.com/kb/print-19.html).
But.. How are these new values any different?
How I understand it, every 30sec, it takes the next 45sec of checks, finds checks that overlap, and reschedules those evenly across the 45sec.
Isnt it possible for a check to indefinitely get rescheduled into that last 15 seconds of the 45sec window?
Am I missing something? Do rescheduled checks get an elevated priority so they arent rescheduled again? Reading through the code, it doesnt appear they are given any special treatment.
Seems to me that the only way to prevent that is for the interval and window to be the same.
Which means maybe a couple checks occurring right at each 30sec transition may go unnoticed,
but Id rather that than what I am presuming the behavior is with the "recommended" interval=30sec , window=45sec.
Any insights would be helpful!
Related
Im trying to set up when I go through a collision it checks how many current players there are then times them by 2, when I print out the math is correct however it only ever adds one to the actual count on screen, any suggestions would be greatly appreciated!
(My default player count in my game mode is 1.)
Is it correct that you spawn agents in the same location?
If so, you may want to mark NoCollisionFail input of the SpawnAIFromClass as True. Setting this value to False allows UE to abort the spawn in case if newly-spawned actor overlaps with anything solid (in your cast it may be previously spawned actor).
Hope that answers your question.
The documentation suggests I use nm-device-wifi-request-scan-async, but I don't understand how to understand when it's has finished scanning. What's the correct second parameter I should pass, how is it constructed and what do I pass to nm-device-wifi-request-scan-finish?
I've tried using nm-device-wifi-get-last-scan and determining whether the scan has just happened or the last scan was a long time ago, but it doesn't seem to update the time of the scan - i.e., after requesting the scan and printing out the time between nm-utils-get-timestamp-msec and the last scan, it only increases and and decreases only if I restart the whole program, for some reason...
All I really need is to request a scan every x seconds and understand whether it has happened or not. The deprecated synchronous functions seem to have allowed this with callback functions, but I don't understand async :(
nm_device_wifi_request_scan_async() starts the scan, it will take a while until the result is ready.
You will know when the result is ready when the nm_device_wifi_get_last_scan() timestamp gets bumped.
it only increases and and decreases only if I restart the whole program, for some reason...
last-scan should be in clock_gettime(CLOCK_BOOTTIME) scale. That is supposed to never decrease (unless reboot). See man clock_gettime.
but I don't understand async
The sync method does not differ from the async method in this regard. They both only kick off a new scan, and when they compete, NetworkManager will be about to scan (or start shortly). The sync method is deprecated for other reasons (https://smcv.pseudorandom.co.uk/2008/11/nonblocking/).
I'm looking for a way to disable the PID.vi from running in Labview when the event case container is false.
The program controls motor position to maintain constant tension on a cable using target force and actual force as the input parameters. The output is motor position. Note that reinitialize is set to false since it needs previous instances to spool the motor.
Currently, when the event case is true the motor spools as expected and maintains the cable tension. But when the event case state is toggled the PID.vi seems to be running in the background when false causing the motor spool sporatically.
Is there a way to freeze the PID controls so that it continues from where it left off?
The PID VI does not run in the background. It only executes when you call it. That said, PID is a time-based calculation. It calculates the difference from the last time you called the VI and uses that to calculate the new values. If a lot of time passed, it will just try to fix it using that data.
If you want to freeze the value and then resume fixing smoothly, you can use the limits input on the top and set the max and min to your desired output. This will cause the PID VI to always output that value. You will probably need a feedback node or shift register to remember the last value output by the PID.
What Yair said is not entirely true - the integral and derivative terms are indeed time dependent, but the proportional is not. A great reference for understanding PIDs and how they are implemented in LabVIEW can be found here (not sure why it is archived). Also, the PID VIs are coded in G so you can simply open them to see how they operate.
If you take a closer look at the PID VI, you can see what is happening and why you might not get the response you expect. In the VI itself, dt will be either 1) what you set it to, or 2) an accumulation of time based on a tick count stored in the VI (the default). Since you have not specified a dt, the PID algorithm uses the accumulated time between calls. If you have "paused" calculation for some time, this will have an impact on the integral and derivative output.
The derivative output will kick in when there is a change in the process variable (use of the process variable prevents derivative kick). The effect of a large accumulated time between calls will be to reduce the response of this term. The time that you have paused will have a more significant impact on the integral term. Since the response of the integral portion of the controller is the proportional to the integral of the error over dt, the longer you pause the larger the response simply because because the the algorithm is performing a trapezoidal integration over dt.
My first suggestion is don't pause the controller - let the PID do what it is supposed to do. If you are using it properly, then you should not have to stop the controller action. But, if you must pause the controller action, consider re-initializing the controller. This will force the controller to reset the accumulated time term and the response in the first iteration will be purely proportional.
Hope this helps.
I have been making a labview program for kids to moniter energy production from various types of power sources. I have a condition where if they are underproducing a warning will fire, and if they are overproducing by a certian threshold, another warning will fire.
I would like to time how long throughout the activity, each type of warning is fired so each group will have a score at the end. This is just to simulate how the eventual program will behave.
Currently I have a timer which can derrive the amount of time the warning is true, but it will overwrite itself each time the warning goes off and on again.
So basically I need to to sum up the total time that the value has been true, even when it has flitted between true and false.
One method of tabulating the total time spent "True" would be exporting the Warning indicator from the While-loop using an indexed tunnel. If you also export from the loop a millisecond counter value of when the indicator was triggered, you can post process what will be an array of True/False values with the corresponding time at which the value transitioned.
The post processing could be a for-loop that keeps a running total of time spent true.
P.s. if you export your code as a VI snippet, others will be able to directly examine and modify the code without needing to remake it from scratch. See the NI webpage on the subject:
http://www.ni.com/white-paper/9330/en/
I would suggest going another way. Personally, I found the code you used confusing, since you subtract the tick count from the value in the shift register, which may work, but doesn't make any logical sense.
Instead, I would suggest turning this into a subVI which does the following:
Keep the current boolean value, the running total and the last reset time in shift registers.
Initialize these SRs on the first call using the first call primitive and a case structure.
If the value changes from F to T (compare the input to the SR), update the start time.
If it changes from T to F, subtract the start time from the current time and add that to the total.
I didn't actually code this now, so there may be holes there, but I'm leaving that as an exercise. Also, I would suggest making the VI reentrant. That way, you can simply call it a second time to get the same functionality for the second timer.
I have this code
n_userobject inv_userobject[]
For i = 1 to dw_1.Rowcount()
inv_userobject[i] = create n_userobject
.
.
.
NEXT
dw_1.rowcount() returns only 210 rows. Its so odd that in the range of 170 up, the application stop and crashes on inv_userobject[i] = create n_userobject.
My question, is there any limit on array or userobject declaration using arrays?
I already try destroying it after the loop so as to check if that will be a possible solution, but it is still crashing.
Or how can i be able to somehow refresh the userobject?
Or is there anyone out there encounter this?
Thanks for all your help.
First, your memory problem. You're definitely not running into an array limit. If I was to take a guess, one of the instance variables in n_userobject isn't being cleaned up properly (i.e. pointing to a class that isn't being destroyed when the parent class is destroyed) or pointing to a class that similarly doesn't clean itself up. If you've got PB Enterprise, I'd do a profiling trace with a smaller loop and see what is being garbage collected (there's a utility called CDMatch that really helps this process).
Secondly, let's face it, you're just doing this to avoid writing a reset method. Even if you get this functional, it will never be as efficient as writing your own reset method and reusing the same instance over again. Yes, it's another method you'll have to maintain whenever the instance variable list changes or the defaults change, but you'll easily gain that back in performance.
Good luck,
Terry.
I'm assuming the crash you're facing is at the PBVM level, and not a regular PB exception (which you can catch in your code). If I'm wrong, please add the exception details.
A loop of 170-210 iterations really isn't a large one. However, crashes within loops are usually the result of resource exhaustion. What we usually do in long loops is call GarbageCollect() occasionally. How often should it be called depends on what your code does - using it frequently could allow the use of less memory, but it will slow down the run. Read this for more.
If this doesn't help, make sure the error does not come from some non-PB code (imported DLL or so). You can check the stack trace during the crash to see the exception's origin.
Lastly, if you're supported by Sybase (or a local representative), you can send them a crash dump. They can analyze it, and see if it's a bug in PB, and if so, let you know when it was (or will be) fixed.
What I would normally do with a DataWindow is to create an object that processes the data in a row and call it for each row.
the only suggestion i have for this is to remove the rowcount from the for (For i = 1 to dw_1.Rowcount()) this will cause the code to recount the rows every time it uses one. get the count into a variable and then use the variable. it should run a bit better and be far more easy to debug.