Issues Creating Change Detection Event From NI USB-6509 Device

[Frankferd]

Hi all, 

Before starting, I'm am very new to LabView and hardware products in general. If contradict myself please let me know.

Regardless, I have a hardware set up where I'm using an NI USB-6509 device connected to a treadlite ii t-91-sc36 foot switch. Ideally I'd like to be able to do something specific in LabView when the foot switch is pressed but I don't want to constantly be looking for a change in the 6509 devices ports. This method was used before and worked as intended but it felt like too many resources were being used to constantly look for changes. This is where an event structure comes in. I want to register changes in the falling or rising edges of the device as an event. I've seen some examples of how to do this but they don't seem to be working. My vi is able to find the device and there are changes in the ports in terms of being able to see falling and rising edges. It just never goes into the event case and instead goes through the timeout case regardless of whether the foot switch is pressed. So I think that the device is set up and is being read correctly it's just that the changes aren't being registered as events. 

Is this a hardware connection issue or is this how I'm creating the event case in LabVIEW. There is a subvi used in the main vi which just produces the necessary lines that will be looked at. Line1 port 0:7. This will stay the same unless other devices are plugged in. The test type Boolean isn't something important for this discussion. Just a different method of doing what I'm saying here.

In any case, any help would be much appreciated. In terms of telling me that the vi I've attached is completely wrong. Or if I'm not understanding how register events works. Or if the method won't work or anything else. 

Thanks.

[BertMcMahan]

Do a File- Save for Previous and attach that (2022 should be fine). I don't have the latest version installed.

But, if you're going into the Timeout case, then that means your Timeout is wired up, and it's happening before the foot pedal event can happen.

Event structures follow the rules of dataflow, but there's a hidden buffer inside that makes things a bit sneaky. 

Each event structure will execute exactly one time that dataflow reaches it, and it will execute exactly one case when it executes. The Timeout starts when the structure is reached in the code, so if the structure is reached and it has a timeout of 10 ms, then it'll fire the Timeout case after 10 ms and move on.

To rerun the event case, you put it in a While loop (or, technically you could use a For loop, but just, don't do that). Each time the While loop executes, the loop starts afresh.

The sneaky bit is that, when you register for events manually (which is what it sounds like you're doing), the code sets up a buffer for that event. Thus, the events queue up when you're not in the event case, and they're processed later. So theoretically you're able to catch events even while looping through timeout cases, but if your registration is wonky you'll likely never catch the event. So if you can post a backsaved version of code we can take a look.

Also- I haven't used that particular card in that particular way before, but is there an example (Help -> Find Examples) that might walk you through it? Also, have you confirmed it's working by simply polling the device? Sometimes physical wires can break and cause lots of headache 🙂

[mcduff · Accepted solution]

There are some problems with your VI. I don't know how the digital lines are set up as that subVI was missing; so you will need to modify the diagram below to suit your needs. You will have to change the read depending on how you set up the channels.

1. The Read should occur in the event structure not outside it. The change event is meant for slowly changing data. It is either high or low before the change, reading it continuously is not necessary, only read when there is a change.
2. You need to register for the event before starting the task.
3. Close the task and event case properly.
4. Make an event case for your stop button.
5. The timeout is useless in your event structure. -1 means no timeout.

 

[Frankferd]

Thank you for your response. It's given me a better understanding of events in general. I wasn't aware of the queues and how they work but your info will def come in handy with a future implementation. I've already solved the issue with your help and the help of another responder so it should all be good now.

[BertMcMahan]

---

@mcduff wrote:

1. The timeout is useless in your event structure. -1 means no timeout.

---

@OP, you can also leave Timeout unwired and just delete the Timeout case if you don't actually need a Timeout event for whatever it is you're doing.