Multiple events created for a single value (signaling) write

[Natsfan]

 Hello,

I have a program that continually checks to see if a given amount of time has passed (e.g. 10 seconds). I pass the boolean result to a case statement. Inside the FALSE case, I do nothing. Inside the TRUE case I wired the case selector input to a property node: Val(Sgnl) in order to trigger an event. The actual value is not important, I'm merely using it to trigger an event.

When viewing the Event Inspector Window I can see two events are sometimes created simultaneously, which causes problems in the rest of my code. I have the "Limit max instances" option checked in the Edit Events menu, as well as the number of Instances set to 1.

Can someone please explain why this is happening and recommend a solution?

Thanks.

-Natsfan

[RavensFan]

Attach your VI so we can see how you have things configured.

[Bob_Schor]

---

When viewing the Event Inspector Window...

---

 I'm always learning from the Forum -- I never heard of the Event Inspector Window until this question was asked!  I'll need to try it out ...

Bob Schor

[crossrulz]

Can you supply an example of this issue?  My guess is that you are not resetting your timer.

[Natsfan]

I've attached the vi and subvis.

First off, I'm limited to using an NI USB-6009, which is why I'm not using edge triggering.

Basically, I'm monitoring the output on 1 - 4 DUTs which is normally high, but goes low for a short period. This repeats over and over and the tests can run from several hours to several days. Therefore, I don't want to constantly log the voltage output, but instead check every so often (Polling interval) and log to the file for a specified duration. Later, when we do our post-processing we just need to look for 0s and 1s to know that the output switched and the DUTs worked.

Please let me know if you have any more questions.

Thanks,

-Natsfan

P.S. To clarify what I said in my original post, the two events are not created exactly simultaneously. According to the Time column in the Event Inspector Window they're about 3 - 4ms apart if that makes any difference.

[Bob_Schor]

Thank you for posting the code.  This is very strange code -- it is very difficult to figure out what it is that you want to do, but easy to say that you are almost certainly doing it the "wrong way".

Let me give an example of what I mean.  It looks to me that you are monitoring a DI port of your USB-6009 "every so often" and logging to a file the times that it transitions.  There does not seem to be any other "time-locked" process going on, that is, there doesn't seem to be any "When DI0 goes High, turn this on immediately" code.

Well, this is fairly simple to do and to have a time resolution of 1 msec (you can easily lower the resolution to 1 sec or longer, but let's stick with "more precision" for now).  I'm assuming that your input signals are real TTL signals that take on the values of 0 or 5 volts (more or less).  What I would suggest is to, instead, send these signals to the A/D sub-system, which can sample at 1KHz.  Set the sampling to Continuous, 1KHz rate, 1000 samples.  If you put this inside a While loop, every second you will get an array of 1000 points that should be "values near 0" or "values near 1".  Pass this numeric array into a "> 2.5v" comparator to change it to a Boolean, True if TTL High.  Now put this Boolean array through a For loop that looks for "Is this level different from the previous level?" -- every time this is True, you have a transition, and also know whether it became True or became False (information you need for your Output File).  You even have Time, without needing any Timer functions -- the index of the For loop where the transition takes place is the number of milliseconds (if you are sampling at 1KHz) where the transition occurred, while the index of the While loop counting which of the 1000 samples this is becomes the number of seconds.  I'm assuming that "number of milliseconds since the start of the Test" is sufficient information for your output file, but if you want Date/Time of the transition, I suppose you could do that too ...

So what is it that you really want to do?  There's got to be a better way ...

Bob Schor

[Natsfan]

Bob,

Thank you for your response. I'm trying to understand what you've written, but in the meantime let me try to explain as best I can what exactly I'm trying to do. (And yes, I'm sure there's a MUCH better way...)

My test items output 5V for 2.5 seconds, then output 0V for .5 seconds, then back to 5V for 2.5 seconds and so forth and so on. This happens repeatedly for several hours. During this time, if the output doesn't go low something is wrong with that particular test item. Just as bad is if the output is low and doesn't go back to being high. All I really want to do is determine whether these high to low/low to high transitions occurred. And since the tests could last up to 8 hours, I don't want to continously sample every second. I'd prefer to take samples (perhaps 1 sample/second for 10 seconds) every 30 mins or so and if my log file has lows and highs then I know there were transistions at those times, and I have to assume/hope that things were working in between.

Does that clearly explain what I'm wanting to do? And would you still recommend your suggestion?

Thanks,

-Natsfan

[Natsfan]

---

@Bob_Schor wrote:

 Set the sampling to Continuous, 1KHz rate, 1000 samples.  

---

Is there a way to set the sampling to Continous besides the DAQmx Timing vi? I keep getting errors when using that function. Even with the "Digital - Continous Input.vi" example where I deleted the "Sample Clock Source" control, thus supposedly switching to the internal clock. The error message I get basically says the requested value is not supported.

Property: SampTimingType

Requested Value: Sample Clock

You Can Select: On Demand

Even though I told LabVIEW to only show examples for my particular hardware. I believe I've read somewhere that the 6009 doesn't have an internal clock so is there something else I'm supposed to do?

[Bob_Schor]

Thanks for the update.  So basically what you want is a monitor that your TTL signal at 0.2 Hz is still going high and low.  So here's a question -- what do you want to happen if, say, it fails to make a transition, that is, it stays High or Low for, say, 4 seconds (or maybe "forever")?  Do you want to immediately stop the test?  That makes a certain amount of sense to me ...

Given your pulse rate, you can, indeed, do this Digitally (i.e. with a DIO line).  I'm going to assume that what you want is a Monitor system, and that you will stop recording if you detect a missing pulse.  As a side benefit, we'll also detect "way too narrow" pulses.  In either case, we will generate an Error Stop, which you can turn into a Text Message if you want, and will eliminate the need for a Log File (since if there is no problem, there is no Error Log).

We're going to do this in a stand-alone, parallel loop that does nothing but monitor the digital line.  Here's the idea -- create a While loop with a 1 second Wait until next Ms clock.  Inside it, take a single digital sample and save it in the output limb of a Shift Register.  Compare it with the input limb of the same Shift Register -- if they differ, you have a Transition.  On another Shift Register, you have a "clock".  When there is a Transition, you (a) make sure that the Clock is at least 2 (otherwise you have a "too-quick" Transition) then set the Clock to 0.  If it wasn't a Transition, you increment the Clock, and if it is >3, then it is a "Missed" Transition.  You signal a Too Quick or Missed Transition, otherwise you just keep on ticking.

I was going to actually develop some code to do this, but I'm currently having trouble getting into the Forum (or the Web, for that matter), so I'll just send this off.  You might not be familiar with LabVIEW's parallel nature -- one of its great strenghts is the ability to run multiple tasks (like your Testing and this Monitoring Task) asynchronously and at the same time, with a little extra work needed to make sure you stop all of the loops when its time to quit.

Bob Schor

[rpursley8 · Accepted solution]

Add a 1-2 ms wait to your main timing loop.  It is conceivable that  your loop takes less than 1 ms to run and  you are seeing the same time in two subsequent iterations of your loop and that is why you sometimes get two events triggered close together

I wouldn't use a separate loop at all, but control the timing of the timeout event directly.