Controlling multiple testers trough Telnet

[JanneT.]

Hi!

I'm developing testing environment which should control 20 testers simultaneously trough Telnet. Is it possible to use LabView Internet toolkit's Telnet VI(s) to control 20 connections? (2 connections seems to be working if they are defined under same VI).

Also if I have understood correctly it's possible to create re-entrant subVIs with LabView. How I can use this feature and is it possible to use it if you have more than one layer of subVIs? (see hierarchy image. VI 1 is main VI and all VIs under it (2 - 5) should be re-entrant so it would be possible to control 20 testers. Can LabView handle 20 simultaneously prosesses?).

[JanneT.]

And here is that image 🙂

[AESulzer]

Janne,

I see no problem with opening 20 Telnet connections with LabVIEW provided they are unique connections. There is obviously a limit out there, but that limit may not even be set by LabVIEW and I think 20 would be more than safely under any limit.

As far as reentrancy, a subVI of a reentrant VI is not automatically made reetrant. If you wanted those subVIs to be reentrant as well, then you would need to set them as reentrant in their own properties. There is an excellent discussion of this concept on this post.

Regards,

Message Edited by AESulzer on 06-09-2005 05:45 PM

[JanneT.]

Hi!

That link was very helpful. Thanks!

I still have one problem with reentrant VI's. In my application it's possible that two or more tasks are simultaneously reading same file. Is it possible to modify "read lines from file" VI more intelligent so it will try read file again after some time if file is in use during first attempt? Now if file is in use, task stops and test fails.

[AESulzer]

Janne,

A file I/O VI like the one you mentioned is actually a perfect example of a VI that should not be reentrant. Any VIs that access an outside resource (such as a file) should not be reentrant for the same reason as the symptom you cited: it opens the door to potential resource conflicts. It therefore makes sense that file I/O VIs should not be reentrant so that if one instance of the VI is already executing, then another instance will have to "wait its turn" before it can execute. Thus, my advice to you would be to remove the reentrancy from that VI.

Regards,