Graeme

Hi all,

I have a requirement to generate a list of all COM ports present on the localhost. Twist is, the list should be in numerical order, not the alphabetical(ish) order that the VISA Find Resource function returns. I have a VI or two that does the job but, as ever, a bit clunky and prone to failure under some circumstances. Can't help feeling there's a neat way to do it, it's just that I can't see it. It would be great if a solution could cope with the VISA Find Resource function returning the raw VISA name (e.g. ASRL2::INSTR) or its machine alias (e.g. COM2).

In addition, asking the VISA Find Resource function to return ASRL?+::INSTR returns all COM ports but the parallel port (LPT1) too (ASRL10::INSTR). For the life of me I can't come up with a regular expression that excludes the parallel port. Thoughts most welcome.

Regards.

Ha ha, I like it crelf, very witty indeed. Fortunately I'm Scottish though, just happened to have lived in England most of my life, so not too fussed about the cricket (just as well). Soccer's a bitter pill to swallow though...

Thanks again guys.

Graeme.

Hi again crelf,

From your comments in your post I've deduced how your VI (probably) does it. What a beautifully simple solution. Many thanks to you and Michael for pointing me down this road. I think this is what I'm after.

Graeme.

Hi crelf,

I'm only running LV8.0 so can't open your 8.2 VI. You couldn't save it for the previous version and re-post, could you? Many thanks.

Graeme.

Michael, I've got something working. Is the attached VI (IndicatorClearerPanel) the sort of thing you meant? I've also attached my "flattened" version of it to see if anyone has any comments. Certainly with your method (if I've got it right) it's much more obvious what's going on, quite intuitive really. It would be interesting to compare the execution speeds but I can't do this as I'm only running the Base Development system.

Regards, Graeme.

Download File:post-5820-1167657933.vi

Download File:post-5820-1167657950.vi

Omar, thanks for the suggestion but I don't think that'll work for me. I want to clear my front panel indicators but leave my front panel controls with their current values. I think the VI property you suggest clears everything, both indicators and controls.

Michael, your method is interesting. Didn't know it existed! However, I can't seem to create a valid reference for the Panel property node, always get the invalid object reference error when I run it (any suggestions because I like the sound of this technique?). However, if I use your suggestion but use a Pane property node I can get this to work along the lines that you suggest.

To achieve what I want to date I've been using either of two similar methods, one based on the invoke nodes Contol Value: Get All [Flattened] and Contol Value: Set [Flattened], and the other based on the invoke nodes Contol Value: Get All [Variant] and Contol Value: Set [Variant]. These both give me the ability to return only indicator information and hence set only indicator values. Each has a potential problem though.

The variant method returns no type descriptors. This means I have to adopt an ugly, brute force, inefficient approach. I have string and Boolean indicators that I want to clear. So I set ALL these indicators to an empty string then set ALL these indicators to a Boolean false. This works but of course generates errors: you can't set a string indicator to a Boolean false nor a Boolean indicator to an empty string. To avoid seeing the errors I break the error cluster wire appropriately and disable the sub-VI's automatic error handling. Yuck!

The flattened method does return type descriptors. This means that I can see what type (string, Boolean etc.) the indicator is then clear it (set it to its default value) appropriately. What worries me here though is what if one day NI decide to change/re-assign LabVIEW's type descriptor values? My code won't work. Are the type descriptors liable to change or are they set in stone?

Regards, Graeme.

Hi everyone,

Without boring you all with the tedious details I have a requirement to programmatically clear (set to their default value) front panel indicators (e.g. string and Boolean). There may be many indicators (~100) on the front panel so addressing each individually (via property nodes, say) is not a practical option. A catch-all solution, such as the "Clear indicators when called" VI property (but programmatically), is required. The idea is to create a sub-VI that will do this and that can be re-used in many different applications to carry out this action.

Now, I have come up with a few solutions to this, ranging from very clunky to just about acceptable. However, I would be most interested to see how you LV gurus out there might go about the problem, as I'm always keen to find the neatest solution to such problems. I'd also be interested to know if this requirement is something that others have needed in the past. I'll post my solutions (well I call them solutions!) if anybody's interested.

Happy New Year to you all. Best wishes.

Thanks for the replies so far everyone. I've only just got back to the forum after a few days away so have only had a quick look at the posts, not had a chance to try the suggestions yet, but will ASAP. The example I referred to, but stars_n_moons22 was good enough to link to, was cited as poor but due to some comments posted on it it was possible to gather the following.

1) When using the TCP Wait On Listener you must close the connection ID AND the listener ID (I wasn't doing the latter).

2) You may need a short time delay to allow the connection to close before re-opening it.

My application involves more than just TCP. I've got it running so it works about half the time!!! Timing may be an issue with some other aspects of my VIs. It's a real can of worms. To boot, I'm not convinced that my company's product that I'm trying to communicate with boots up in the correct state every time.

Jack Hamilton, I'll check it out. When you say "reliable TCP/IP is not easy" do you mean in general or just via LabVIEW?

eaolson, well...take your point. I notice most of the LabVIEW example VIs use the function to which you refer and don't use they way I've done it. I've had a look inside the TCP Listen function to see what made it tick. To be honest, it was a bit beyond me.

BTW (off topic), why do NI create these white functions that we can open? Why not just make them regular functions? It always gives me the impression that the regular functions are not quite there and they've had to come up with a fix.

Anyway, thanks again. If I find out more I'll post.

Regards, Graeme.

Hi everyone,

Well this is my first post here so here goes. LabVIEW (7.1, 8.0, 8.20 if I'm lucky) user for only a year and a half. You can probably see my details as I filled them in for registration - see my background! Addicted to LabVIEW though - it's brilliant!

To the point. In a sub-VI I use a TCP Create Listener followed by a TCP Wait On Listener (server). When the connection is made I then use a TCP Read to get the data. Afterwards I close the connection (TCP Close) - OK so far. The next sub-VI opens (trys to) a TCP Open Connection (client) using the same port as in the previous VI. Says it can't. The server has refused the the connection or the port is already in use. Can't remeber which as I'm writing this from home, not at work, sorry.

Anyway, found an NI page that says if you've used a Create Listener and a Wait On Listener closed with a TCP Close you can't open a connection to that port again until LV is shut down, unless you've close the connction in a rather strange way that the page offers an example for.

Anyone any experience of this? Any comments would be most welcome.