stopping a VI while it is still running

[Ham31]

Hi all,

This is my first time posting a question so bear with me.

So this is the thing: I am in charge of a very big project where we can communicate with our devices using the udp protocol.Obviously, I cannot share the whole project. When starting the program we want to search for our devices automatically. I thought about dividing this in two parts:

1. search for all ipaddresses that can be accessed by the computer. This is sort of a brute force approach since at startup we don't know what the ipaddresses of our device are, when DHCP is on.

2. Sending a UDP packet to every accessible IPaddress from (1) to know which device can be communicated with our own protocol.

Keep in mind that this will always run at startup.If we only want to see some results from earlier measurements of the device or do something else with the program where the device is not connected to the PC, it will still run at startup. This becomes quite annoying, so we want to cancel the search then. The search is done with for loops with iteration parallelism on. Is it possible to stop the search VI?

I have already seen that it is not possible to stop for loops with parallelism. If i turn off the iteration parallelism the for loops become very slow so that is a no go for me.So then i thought if it might be possible to stop or abort the VI itself, so I don't know if that is possible?

I will upload the VI in question where i do the 'brute-force' approach. I also let this VI on the foreground to show a progress bar that it is busy with searching.

If there are any question I will try to answer them.

Greetings,

Gerjan Hammink

[thols]

No expert on this matter here. Just a couple of thoughts.

You are using ping. That is TCP right? That means that you could try and ping the broadcast address and see if that works for your devices (article about it here).

Why does it become annoying? I am guessing that the application waits until it is done before you can do anything else or that the process is displayed. Why not change that design so that it is done in the background instead and the list of attached IPs can be updated once it has finished scanning.

You could also try doing everything on the command line, like this. Don't know if that will improve anything though but may be worth testing.

[Ham31]

While it is true that I am using TCP, the device itself communicates with the UDP protocol.

I have tried to ping the broadcast address but i get no results in windows.

Indeed, every time I start the application (either in LabVIEW or as an executable) it waits to search for our own devices and that becomes quite annoying when all you want is to test one particular thing.

About changing the design. The list of IPs is further used to open controller VIs for communication with the devices. The VI where this process is done is also handling the data that is coming back from these controller VI's. If I do it in the background that will  freeze, which I do not want to happen. That probably means that I need to come up with a design so that another process VI can be handling this network thing?

When I made this for the first time I have looked into doing everything on the command line. It is not in particular more efficient I think.

[James_W · Accepted solution]

1) your Close references are the wrong way round, you should close the ref of the Send before the ref of the Ping (as it is a child of the Ping)
2) why don't you just use a (nasty) local in the parallel for loops at the start to determine whether or not to run the Ping

3) you could change the architecture to be complex, but potentially more CPU friendly and more responsive by enqueuing the full list of IP addresses to test (in a producer loop at the start) then having a dequeue which contains the Ping code (re-rentrant) and launching N instances of it. When stop is pressed (event) flush the List of IPs to check (input queue) and no more Pings will be done, - you just need to build a list of output IPs (queue again) and when all finished, sort by name.

James

[Ham31]

Thank you for your input, here are my replies:

1) I have fixed this but, if I may ask, is there a reason to do it like this?

2) Never thought of this, so thanks for this 'dirty' way of stopping the VI earlier.

3) I thought about this for a while but don't really get how this works. You've lost me at "launching N instances". Is this supposed to be in the VI itself? I need to test this a bit.

[wiebe@CARYA]

---

@Ham31 wrote:

Thank you for your input, here are my replies:

1) I have fixed this but, if I may ask, is there a reason to do it like this?

---

There isn't really.

You're closing a reference to the object, not the object. So closing the parent reference first shouldn't close the parent. The parent should stay alive because the child references it. The object should close only if there are no open references.

There are exceptions. For instance closing the last reference to a VI will might cause all closing all references it created.

[wiebe@CARYA]

The .NET nodes can't be aborted. If you'd use a time out of 20000, you'd have to wait 20 sec, or until there's a ping. If you do abort the VI, you'll get a "Resetting VI" dialog, and then have to wait for the (rest of) the time out..

If you want to use them whiteout having to wait for the time out, you'd have to use the ASync functions. You can then catch the PingCompleted and Disposed events with a callback VI, and get the result.

The Async functions also allow you to Cancel the operation.

It also should be possible to start n operations, and wait while they execute in parallel.

Something in the lines of:

The callback might need some close refs.

The userToken can be a chosen object. Any System.Object will work. You get that token in the callback.

[Ham31]

I forgot to say I use LabVIEW 2019 so can you save the VIs for 2019?

[wiebe@CARYA]

Sure, here's a LV13 version.