Time until next Event loop

I'm making a class that will load some data, and fire an
event when it's finished loading... and I'm just not sure how to
set it up so that people won't miss the event trigger when it's
asked to load an extremely small amount of data.
My first version started the load in the constructor, but I'm
worried it will finish loading before execution returns to the next
line of actionscript, i.e. before the user can assign an event
listener for the 'complete' event, in which case the event handler
will never be called.... however, there are examples in the flash
docs that function exactly like that, so maybe I'm
misunderstanding?
Do all events wait until all functions have finished running
before firing? Or should objects that risk firing events extremely
soon after their construction be used in such a way to manually
check if any events were missed on the way to assigning the
handler?

OK, that's what I thought...
But in the case of the XML example, what other way is there
to do this? It seems like the URLLoader object begins loading as
soon as it's constructed... is it a better idea to go
var myLoader:URLLoader;
myLoader.addEventListener("complete", xmlLoaded);
myLoader = new URLLoader(myXMLURL);
or would the writing of a new object into that variable
overwrite any 'listener' connections in it? (If that's how that
works?)

Similar Messages

When the integral function is placed inside a wait until next ms multiple is it reset at the beginning of each loop?

When the integral function x(t) is placed inside a wait until next ms multiple while loop is the Integrator reset to zero every time the loop executes?

Hi,
the function works on a discrete amount of data. Hence every call to it replaces the values used first time around.
I've attached an example in LabVIEW 7.0 that uses a pulse generation vi to allow the manipulation of the array sent into the integral object, and then it's easy to calculate what the integral of the data would be.
Hope that helps
Sacha Emery
National Instruments (UK)
// it takes almost no time to rate an answer
Attachments:
integral.vi ‏39 KB

HT5527 i am unable to find icloud in my system preferences. What do i do? I don't have time to get to apple until next week and now im going to lose a bunch of data bc i can't update my icloud starage.

i am unable to find icloud in my system preferences. What do i do? I don't have time to get to apple until next week and now im going to lose a bunch of data bc i can't update my icloud starage.

You say you have iOS6: you can perfectly well pay to extend your free storage as an ex-MobileMe subscriber.
If you wish to continue your current storage level, the instructions are here:
http://support.apple.com/kb/HT5527
Scroll down to 'How do I purchase my current plan?' and expand the section applicable to iOS.

Problem using local variable in event loop

I have a state machine from which I want to monitor various controls, including "Start" and "Stop" buttons. Not every state needs to monitor the controls. At present, most states run timed loops. In the first state that reads the front panel, I have an Event structure (inside a While loop) that monitors the various controls' Change Value events. For numeric controls, I update variables (in shift registers) as needed. The "Start" button is used to end the While loop controlling the Event structure, allowing the State to exit to the next state.
My problem comes in subsequent states that employ this same idea. Here, I put a Local Variable bound to the Start button and use the same code, but it frequently happens that when I enter this particular state, I cannot "turn on" the control -- I push the button, but it stays off. Curiously, if it was On when I enter, I can turn it off, but then I'm stuck not being able to turn it on.
I mocked up a very simply routine that illustrates this. There are two sequences (corresponding to the two states). Both use an Event loop with a local variable bound to my Stop button (really this is an LED control with custom colors). I've deliberately moved the "initialization" (the declaration of the control in the block diagram) out of the Event loops -- putting it inside the first loop modifies the behavior in another strange way.
Here's my thinking on how I would expect this to work: The code outside Event Loop 1 should have little effect. Assume the Stop button is initially Off. You will "sit" in Event Loop 1 until you push the Stop button, changing its value to True; this value will be passed out of the Event case and cause the first While loop to exit. You now enter the second sequence. As I understand the Exit tunnel, it defaults to "False", so I'd expect to stay in the second Event loop until I turn the Stop button from On to Off, which will pass out a False, and keep me in the While for one more button push. However, this doesn't happen -- I immediately exit, as though the "True" value of the Stop local variable is being seen and recognized by the Event loop (even though it hasn't changed, at least not in the context of this second loop).
An even more curious thing occurs if I start this routine with the Stop button turned on. Now I start in my Event loop waiting for a change, but this time the change will be from On to Off, which won't cause an exit from the frame. This will be reflected by having the While loop count increment. We should now be in the state of the example above, i.e. in an Event loop waiting for the control to be pushed again, and turned On. However, clicking the control has no effect -- I cannot get it to "turn on".
Where am I going astray in my thinking? What is it about this method of doing things that violates the Labview paradigm? As far as I can tell, what I'm doing is "legal", and I don't see the flaw in my reasoning, above (of course not -- otherwise I'd have fixed it myself!). Note that because I'm using local variables inside Event loops (and I'm doing this because there are two places in my code where I want to do such testing), the Stop control is not latching (as required). Is there something that gets triggered/set when one reads a latched control? Do I need to do this "manually" using my local variable?
I'll try to attach the simple VI that illustrates this behavior.
Bob Schor
Attachments:
Simple Stop Conundrum.vi ‏14 KB

altenbach wrote:
Ravens Fan wrote:
NEVER have multiple event structures that share the same events.
Actually, that's OK. NOT OK is having multiple event structures in the same sequence structure.
See also: http://forums.ni.com/ni/board/message?board.id=170&message.id=278981#M278981
That's interesting. I had always thought I read more messages discouraging such a thing rather than saying it was okay. Your link lead me to another thread with this message. http://forums.ni.com/ni/board/message?board.id=170&message.id=245793#M245793. Now that thread was mainly concentrating on registered user events which would be a different, but related animal.
So if you have 2 event structures they each have their own event queue? So if you have a common event, one structure pulls it off its event queue and it does not affect the other structure's event queue? I guess the inherent problem with this particular VI was that the second event structure locked the front panel. Since the code never got to that 2nd event structure because the first loop never stopped because the change was from true to false. After reading your post and the others, I did some experimentation and turned off the Lock front panel on the 2nd structure, and that prevented the lockup of the program.
Overall, the example VI still shows problems with the architecture and I think your answer should put the original poster on the right track. I think as a rule I would probably never put the same event in multiple structures, I feel there are better ways to communicate the same event between different parts of a program, but I learned something by reading your reply and about how the event structures work in the background. Thanks.

What is going on "under the hood" of the 'Wait Until Next ms Multiple' vi?

Hi,
This question is really for the developers of LabVIEW, and I don't know if they are willing to divulge what might be considered "trade secrets". Anyway, I just thought there's no harm in asking.
I use the Wait Until Next ms Multiple vi and it works great. For example, if I set my program to output a character on the serial port every 20 millisecond (mS), and check the output on an oscilloscope, I see the output at 20 +/-2 mS (that is, 18 to 22 mS). That's quite good and is all that can be expected on a PC running a non-real-time OS such as Windows.
My question is this: Since the default Windows timer has a tick rate of 15.625 (1/64th of a second) (some PC's may default to 10 mS), how does LabVIEW attain roughly 1 mS accuracy? If the same thing is coded in any .NET framework program, such as C# or Visual Basic using any of the available timers (the System.Windows.Forms timer or the .System timer), the timer interval may be set in 1 mS increments, but if you time it you will see it actually has a granularity of 15.625 mS. So instead of getting 20 mS I get 2 ticks, or about 31 mS. So I can get an output every 15.6, 31, 47, 62.5, etc. but nothing in between.
The System.Diagnostics.Stopwatch timer can be use to time code with very high resolution, or to create a high-CPU usage delay loop, but I haven't been able to find an easy way of generating an interrupt (timer tick) at say 1 mS. There are Win API functions that can set the timer to 1 mS on XP and 0.5 mS on Windows 7 and 8 Microsoft, but I have not tried them. (They come with the caveat that another program or process can come along and reset your timer!) There is the "multi-media" timer (now the HPET or High Performance Event Timer"), but it is meant for sound and video at the driver/kernel level, and not for the UI level, as LabVIEW or C# are.
So how does the 'Wait Until Next ms Multiple work? It obviously is timer interrupt-driven because it yields to other processes (which is a primary reason for putting it in your overall While loop). And is it guaranteed on all recent OS versions (mine was timed on an dual core XP OS)?
Thanks for any insight.
Your typical curious engineer,
Ed

Ian,
Thanks for your reply. Yes, I'm sure LabVIEW uses the (default) Windows timer. And yes, 1 mS is not guaranteed due to the preemptive nature of Windows (and even "RTOSs" to varying degrees), which is why I see about plus or minus 2 mS.
Apparently the Windows timer can be set by API calls. See: http://www.lucashale.com/timer-resolution/. Here's a screen shot of his TimerResolution.exe on a Windows 7 PC:
Here it is on my Windows XP PC after I set it to "Maximum" (initially it was 15.625 mS):
Notice that it sets the Maximum to less than 1 mS, which is supposed to be the max, so there are some bugs. Plus the Default button does not reset it in XP, but does work on Windows 7 or 8. (I know this is not the place to "debug" non-LabVIEW applications!)
I'll bet LabVIEW sets it, too. The only caveat, as I said, is it looks like another application can change it, since the hardware timer is a "global" timer. I have not seen this issue in my LabVIEW applications, have you?
I guess I need to do some more digging to see the code to set the timer, but it looks like the developers of LabVIEW have it figured it out.
(FYI, I did notice that running my LabVIEW app (which gives about 2 mS resolution) or a C# app, which gives 15.625 mS resolution, does not affect what TimerResolution.exe reports, so I'm not sure if it's really working correctly. If I figure it out I'll post the results.)
Ed

Question about the Wait Until Next ms Function

Hello,
I met a problem when I tried to use wait until next ms function to control the period of the loop.
I use Labview2009 now. I wrote a VI to sample the current values at 100Hz and then store the samples in a text file. The currents are sampled once in a loop and then wait for next 10ms to begin the next loop. After 360,000 loops (should be an hour), it will creat a new file to store the new samples in the following an hour.
I left the VI runs on CompactRio for the whole weekend. The result I got is shown in the picture below:
24 files should be created in one day. While there were only 3 files created in the firest 24 hours ( from Fri 16:00 - Sat 16:00). And after that it worked very well.
When I checked the first three files (created from Fri 16:00 - Sat 16:00), I found that it didn't sample at 10Hz. It sampled at the frequency of about 20Hz (sometimes 18Hz, sometimes 19Hz).
I am confused by the problem a lot. What may cause it didn't work in the first 24 hours and worked after 24 hours? And How could I fix this problem?
Thank you very much!

You need to show us some code!
This cannot happen in a single loop, but can easily happen if you have e.g. stacked loops or sequences containing multiple wait statements.
Also have a look at these old threads:
Synchronization problems during measurements (using while loop)
accurate timing between events
If accurate timing is important, use a timed loop. Your incorrect times are faster, so I don't think there is a problem with the inner code taking too long.
LabVIEW Champion . Do more with less code and in less time .

Event Loop in SO and failover

Hi, All Forte Experts
I have 2 questions:
1. Would any one tell me where can I put the event loop block in a
Service Object?
I tried to put it in the Init to get a timer.tick event, but the SO
hanged to wait there.
How can I do this to let the SO do something at certain time?
2. I have SO doing failover. Can one sleeping SO get any kind of
information when it becomes alive
after the running SO dies?
Thanks a lot for your help.
Alex
Carpe Diem, Seize the Day !
Alex Lee (Li Zhongling)
Forte, Java/CORBA Group
International Business Corporation
Bangalore 560010, India
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Hi,
Thank you all a lot for your help.
For the second question, I explain the situation here. I have a failover
LockManager SO which contains a LockList. When the first running SO dies, I
want the second one to become alive and restore the state of the first one( I
mean the LockList should not be lost). Then I tried to do it in this way:
1. As Daniel Nguyen suggested in Re:Retaining state on failover of SO
(Jan.19,1999), I put one shared object holding one Locklist on the Router
partition. Let the running SO always refresh its contents.
2. I make the SO Transactionaln with Transaction Dialog Duration. On the
client, every time I start a transaction to add or remove lock through SO, I
try to catch the exception "AbortException" (which means the SO dies). To
handle the exception, I use Releaseconnection, then force the backup SO get the
locklist from the shared object on Router partition. In this way, the backup SO
becomes alive and also restore the state.
I think this works. I will also try your suggestion ASAP. However, would you
please tell me how to control the secondary SO not to start and later to start
it? Every time I try to run the app, all the partition will start. And I guess,
I can not new it.
Thanks.
Rds
Alex
Alex,
1) as Arpad mentioned in his posting, you can start task a method which
contains your event loop from the init method.
as for
2), what I've done in the past is to start both primary and secondary SOs,
where the primary SO's event loop begins at start up, but the secondary SO
is dormant.. I created a "monitoring" SO which listens for remote access
exceptions (or distributed access exceptions) and on the death of the first
SO, the second SO's event loop is started. The other option is to not start
the secondary SO until the primary one fails, but there is a lag time for
the SO to come up.
j
Carpe Diem, Seize the Day !
Alex Lee (Li Zhongling)
Forte, Java/CORBA Group
International Business Corporation
Bangalore 560010, India
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

How to control the looping time of the for loop in 10 microseconds in labview?

I need to create a +/- 9 volt square wave with period of 20us using a D/A card (Not NI card). I can write command to the card using outport provide by Labview. Right now, I can generate square wave with 4ms period which is limited by the resolution of the wait until next ms icon I used inside the for loop. Could anyone tell me how to control the execution time of the for loop to about 10 us? Your help would be much appreciated.

I'm not sure if this will hep, but this answer seems to answer this question
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000029410000&UCATEGORY_0=_30_%24_12_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=microsecond+resolution+1ms&USEARCHCONTEXT_QUESTION_S=0

Wait time within a While Loop

I was always under the impression that Wait Timers (e.g. Wait and Wait Ms Multiple) always executed last within a while loop. As I'm reading up on timing of real-time loops I'm finding that NI suggested using a stacked sequence structure to force timing to run last. Has my assumption of wait timer execution been wrong all this time or do PC and RT systems differ in how loops handle timing?
Thanks,
Craig

So, ok, coming back on this.
Attached you find a small example to show my remarks in the previous post.
How to use it:
The main focus is in the first iterations once "Wait now!" is pressed. So it is usually not of interest to run the "waiting" for more than 5-10 iterations.
In order to see an "understandable" behavior, i suggest to wait at least 100ms. I configured "Time To Wait" to be at least 10 (coercing).
The second focus is "Time Value".
For "Wait (ms)", the "Time Value" will have any number, but increase each iteration by the amount of "Time To Wait".
For "Wait Until Next Multiple (ms)", "Time Value" will be initialized to a value, which is a integer multiple of the "Time To Wait" and will increase each iteration to the next multiple.
My example does not contain parallel code, so it does not show the parallelism of the waiting functions!
Nevertheless, understanding the shown behavior is the key. Because if the code running in parallel to the waiting requires less execution time than the wait function will wait, the behavior will be exactly as shown.
If the parallel code requires more execution time than the waiting, "Wait (ms)" is already finished and therefore the loop will immediatly continue with the next iteration (high CPU load!).
If the parallel code requires more execution time than the waiting, "Wait Until Nexty Multiple (ms)" will wait that long that the "Time Value" is again in line to an integer multiple of the "Time To Wait" (so this one keeps on running in parallel until waiting time is calculated and over). Hence, "Wait Until Next Multiple" will still introduce a waiting time (reduced CPU load), but you will "miss complete iteration slots".
As you can see, using a single "Wait Until Next Multiple" outside the loop for initialization can make sense if the first iteration should also have a "close to normal" execution time.
Please note that the Timed Loop does something similar once started. As it does it during the iterations, the first 1-3 iteration(s) are called "warmup iterations". Most often, the first single iteration is sufficient for this though....
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Attachments:
TimingVI_Behavior_2011.vi ‏29 KB

Multiple "generate user event" in event loop

Hello.
1.) I am wondering if you can user a "generate user event" into an event loop to create a quasi-state machine.
For example create an event loop with the events "event a", "event b," "event c," and so on. The in "event a" put in a function to generate a user event to call "event b". Then "event b" will call "event c" and so on.
2.) If this is possible, then can u put multiple generate user events into a single event loop and have it queue the generate user events up. For example have the "event 1" case use the "generate user event" 3 times (generating "event 7" "event 8" and "event 9.") to call the next three future event cases in that order?
Thanks
Charlie C.

Of course it is possible, easiest with simply writing signaling properties. (See attached examples, LabVIEW 7.1).
You have to be very careful that you don't create trigger loops, e.g. event A triggers Event B, which triggers Event A ... ad infinitum! :0
Example "Multievents": event 1 triggers event 2, which triggers event 3.
Example Multievents2": event 1 triggers events 2-3-2-stop in sequence.
Message Edited by altenbach on 09-28-2005 01:26 PM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
MultiEvents.vi ‏57 KB
MultiEvents2.vi ‏72 KB

Suggestion: Click Box needs option to display success/failure caption until next click

As it stands right now, if I want to put several click boxes on a page and have the success captions for each appear in the same location, I can only set the success/failure caption to display for a limited amount of time. That is the only way to make the text disappear from the screen. The problem is, I want to have several different click boxes. When the user clicks, the success caption should display. Then the user shoudl be able to click on another click box and have the success caption for that appear in the same location. The problem is the success caption from the previous click box may still be displayed (depending on how long it was set to display for). There really needs to be an option to select that says display until next click. It does no good to guess how long a user will want to read the success/failure text before they decide to click on another text box.
You have the same problem with audio. As it is right now, a user can click on several click boxes and have several different audio tracks playing simultaneously. There needs to be an option to disable the first audio track upon clicking the next click box.
I can't believe this problem hasn't been fixed before this. It is a very annoying problem. I never had half the problems I have with Captivate, when I used Authorware. If there is some kind of work-around I'd like to know what it is.

My suggestion would be that you think a little further outside the box to solve this 'issue'.
It appears to me that you want to display information in captions that appear and disappear based on user interaction, correct? AND you also want audio to play at the same time, but you don't want more than one audio track to play, correct?
To achieve what you want requires at least two separate mouse events. One event triggers the caption and audio to appear. The other must trigger any previous captions to disappear and immediately shut off their audio. Since you don't know which of your objects will be the first one interacted with by the user, all of them must be set up to check for any previously invoked captions and audio before turning on their own caption and audio.
Now all of this CAN be done using Captivate's variables and advanced actions. But there IS a much simpler solution staring you in the face. Why is it essential that all of this MUST happen with mouse clicks? Why not use mouse overs events instead?
Captivate provides rollover caption and rollover image objects for which you can attach audio to the object that appears on rollover. These objects have two mouse events (rollover and rollout). Rollover triggers the caption to appear so that the text displays and it's audio plays, while the rollout triggers the caption to disappear and automatically shut off the audio. This means that the user merely needs to move their mouse around the screen rolling over the hot spots to see information and hear audio. And if you just place a click box or button on the slide to pause the playhead, your user can spend as much time as they want reviewing the content before moving on. You don't have to worry about rewinding the playhead with Advanced Actions because clicks on your content objects would resume play.
These rollover objects can be set up in seconds with audio attached. I'm surprised more Captivate authors don't use them given how easy they are to apply in comparison to other click-driven solutions using Advanced Actions.

Execute case structure a certain number of times within a while loop

Hi guys,
I was wondering if it was possible to execute a case structure a specified number of times within a while loop. Basically I'm running a camera where each iteration of the outer while loop displays a frame of a live video feed and I'd like to capture the next x amount of frames (specified by the user) each time the 'Start Capture' button is clicked. The block diagram within the case structure captures and saves an image frame. As the program is written right now, frames will continue to be captured until the 'Start Capture' button is clicked again. Instead of having to click the button again to stop the case structure from executing for each iteration of the while loop, I'd like it to only execute for the next x iterations of the while loop. Any help would be appreciated. Thanks.

Hello Uxorious,
A while loop has a iteration counter that gives an integer value of how many times the loop has iterated. You can utilise this to count the number of frames captured. I assume that the program could be running for any amount of time before clicking start capture, if that is the case then you will need to be able to detect when you have clicked the button and add the desired number of frames you wish to capture to the current loop iteration.
If you use a shift register on the outer loop with the start capture button connected to it (inside the loop) you will be able to compare its current value to its previous value. If it changes from false to true then you can add the desired number of frames to it to give you the loop iteration value where you need to stop.
Then you can compare the current loop iteration value to that number and once reached, you can use a property node to change the value of your start capture button back to false.
One final thing, don't forget to initialise the shift register I suggested to false so that you don't run the risk of missing the first time you press the button.
I hope that makes sense.
Alistair
Best regards,
Ali Bailey
National Instruments
Don't forget to Kudos useful posts!

Help with "Wait Until Next Millilsecond Multiple" vi

Hello,
      I'll try to keep this brief and follow up with additional information when necessary. I'm not using the current software so PLEASE let me know if this has been resolved with the newest version. I do plan to upgrade but not this month.
      The vi "Wait Until Next Millilsecond Multiple" isn't working as I expect. Today, if I subtract the millisecond timer value from the real time, I get 10/19/2006 15:13:21.33 (try this yourself - current time -millisecond timer value/1000 = timer origination time). The millisecond timer value output is counting up from there. Since it doesn't originate from an expected predictable time (appears arbitrary). I can't use the vi AS-IS and get my vi to repeat at a predictable interval. If I use 1000 for the input, I expect the timer to end at every whole second in time. However, it ends at about 0.33 seconds later. If I use 60,000 for the input, I expect the timer to end at every whole minute in time. However, it ends at 21.33 seconds after the whole minute mark. My timer appears to be losing time but I can confirm that tomorrow by comparing data. I could create a vi to do the same function but I would like to know if there is a fix for this first.
      I have a running vi to back this up and I will post that and other examples if necessary.
Please Advise, Scott

Hello,
      My mistake. The vi was intended this way. When I read the help information on "Wait Until Next Millilsecond Multiple" it did NOT include the information about the "Tick Count (ms)" because I don't really use it. It states "Returns the value of the millisecond timer. The base reference time (millisecond zero) is undefined. That is, you cannot convert millisecond timer value to a real-world time or date. Be careful when you use this function in comparisons because the value of the millisecond timer wraps from (2ˆ32)–1 to 0."
      So there's no bug here but I do believe that there should be a similar function that would generate the millisecond multiple to be a multiple of real time. So, if you input 60,000 the timer would end at the end of every minute. I really don't see why the base reference time is undefined. LabView can give me the real time. I would guess that LabView could restart the millisecond timer at the start of every day. This would certainly add value to the vi.
      I do want to mention that I've read other threads where people believe that the millisecond timer value is based on real time and they have inadvertantly advised others accordingly.
      I'll just make my own function for now. I'll just use "Get Date/Time in Seconds", calculate the time to wait from the multiple, and divide it into 100 pieces or more (depending on resolution desired) and loop that many times or until the desired time has passed (rechecking time at each loop).
Thanks, Scott

Wait until next ms multiple

Hallo,
ich möchte gerne wissen, was "wait until next ms multiple" in Betriebsystem basierte. ich meine, wenn ich die Zähler 100ms einstelle, dann wird meine Simulation wirklich jede 100ms durchgeführt, oder es hängt von der BS ab?
Können Sie mir ein Beispiel geben?
mfG
Hakan

Hakan,
"wait until next multiple (ms)" is a vi which is normally used in
loops. i these structures, this vi is the last one to be called. it
defines, how much time passed from start till now and waits until the
next (integer) multiple of the time connected to it. lets make an
example:
preloop-code 50 ms, loopcode 10 ms, time connected to the vi: 100 ms.
1st iteration: preloop 50 + loop 10 = 60 ms already passed when the vi
is called. so the vi waits another 40 ms to make the 100 ms full.
2nd and following iterations: loop 10 ms, so the vi waits 90 ms.
if the time would have been 80 ms preloop and 30 ms loop, the 1st
iteration would have waited 90 ms, so the time would have been overall
200 ms. (2*100ms).
Do not make the mistake to take this vi as a substitute for
hardwaretiming, since every OS except dedicated realtime-systems (linux
for itself is not a realtime-os!) has a jitter depending on the
systemload and running services!
"wait until next multiple (ms)" ist ein vi, das gewöhnlich in schleifen
verwendet wird. in diesen strukturen wird es als letze funktion
aufgerufen. es ermittelt, wieviel zeit von beginn bis zum aufruf
vergangen ist und wartet bis zum nächsten ganzzahligen vielfachen der
angeschlossen zeit. betrachten wir ein beispiel:
prelloop 50 ms, loop 10ms, angeschlossene zeit an dem vi: 100 ms.
erster durchlauf: preloop 50 + loop 10 = 60 ms sind bis zum aufruf des
vis vergangen. es wartet also 40ms um die 100 ms voll zu machen.
zweiter und folgende durchläufe: loop 10 MS, also wartet das vi 90 ms.
wäre die preloop-zeit 80 ms und die loop 30 ms gewesen, so hätte das vi
im ersten durchlauf 90 ms gewartet um die 200 ms voll zu machen.
machen sie aber nicht den fehler, dieses vi als ersatz für ein
hardware-timing zu verwenden; jedes betriebssytem außer echte
"echtzeitbetriebssysteme" (linux von sich aus ist KEIN echtzeitsystem!)
erzeugt einen "jitter"(zeitversatz), abhängig von der auslastung und
der anzahl der laufenden systemdienste!
Norbert B.
NI - Germany
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Wait Until Next ms Multiple.vi explanation

altenbach,
Great examples!!!
I am using an
older code that place a “wait until next ms multiple.vi” in a time loop.
From the feedback
I am getting on the forum, I think I should use CONSUMER AND PRODUCER
ARCHITECTURE TO GATHER THE data. BUT for me to get more time for the project I would
have to explain why the current codes need to be changed.
The only thing
that change in this code when I run it at a smaller distance( angles smaller
than .72) and bigger distance (angles greater than .72 ) are the timing for the
“wait until next ms multiple.vi.” Inside
the time loop I measure the time it take for the wait until ms to finish.
I had run the
code when the angle was smaller than .72 and printed out the Boolean status for
each iteration. And when it was bigger than .72. if interested I have attached
the file. There is no different. The different is only with the timing!!!

sticyfinger wrote:
I am slow. Can you please elaborate on that some more? Sound
interesting. Think that may be related
to what happen to my code. When I measure smaller distance I have to use bigger
numbers for the wait.
Please elaborate how you are measuring. A wait controls, and does not measure, timing. What happens in the code during the wait? How do you measure?
In a nutshell, here are some semi-true analogies:
Wait until next ms multiple
Do something every hour on the hour (60 minutes multiple), i.e. wait until the minute hand points straight up. If your task takes 30 minutes, you get a 30 minute break, if the task takes 50 minutes, you can only take a 10 minute break. If your task takes 61 minutes, you get a 59 minute break, but might lose your job because you missed an assignment.
The first wait is random between 0 and 60 minutes and depends on the time you arrive at the job site.
If the wait is in a loop, the first iteration takes between 0 and x ms. All subsequent iterations are equally spaced unless your code cannot complete in the allocated time.
Wait(ms)
No matter what time it is, wait 60 minutes before continuing. This is often somewhat clouded by the parallel nature of LabVIEW. For example if a wait(ms) is in a loop, the iteration cannot complete until at least x ms have elapsed. However the timer starts in parallel with the other operation in the loop, so even if the operations take a significant amount of time, it won't artificially prolong the loop. However, if you would use a sequence such that the wait is in the last frame, the loop time will be the sum of the code time and the wait time. And so on....
All waits are the same, and independent in when you arrive at the job site.
If the wait is in a loop, all iterations will be approximately x ms unless your code cannot complete in the allocated time. Over time, there could be slight drift due to accumulations of small errors caused by the delay between the loop start and scheduling of the wait node.

Time until next Event loop

Similar Messages

Maybe you are looking for