parsec

Thanks for the workaround.

Thanks, that's a handy tip I wasn't aware of that means I don't have to set the reentrant to launch its front panel. It is still a bit frustrating to figure out which of the clones I am interested in from the browse relationships menu. The reentrant is set to preallocated.

I just installed LabVIEW 2017. I noticed that double clicking on a re-entrant subVI opens the master VI rather than the associated clone (as would happen using previous versions of LV). This is a bit frustrating, as it means the only way to probe a re-entrant subVI is to change the window appearance options to launch the front panel when called. This can become very cumbersome when there are multiple parallel calls on the same re-entrant, as it can be a pain finding the relevant one to probe. Is there an option to change this behavior?

I just had NI support get back to me with a working set of VIs. It seems that this is indeed correct. I see that infinitenothing's solution should also work. I tried the above before but did not manage to get it to work. I suspect I made a mistake somewhere. The following seems to work; Assign the Crio listener the following reader name: arbitrary/random1 Leave its writer url empty. Push the reader name to the shared variable. Read the shared variable on the host. The host reader url should be //CRio-IP/(reader listener name sourced from shared variable, ie arbitrary/random1) The host writer name must be set to //localhost:random2/random3 I'll implement this in my code now. Let me know if you would like me to share the NI project. They made a rather clean demonstration of how to make it all work for me.

I have data flowing in the opposite direction. I start the Rio up with readers and then the exe clients up as writers. I wonder if this makes a difference? I have effectively tried this methodology before, but I will attempt it again copying exactly what you have done.

I have tried unique context names on both ends. The code I shared is one of many attempts at different combinations of context and endpoints names. In one attempt I used the shared variable to send back a set of (random) unique context and endpoint names to the writer, but I had no success this way either. I have engaged NI support so i'll be interested to see if they can make it work. I want them to specifically make it work on a Rio as I don't trust that what works to a dev/executable target on windows will necessarily work on a Rio. From what I can see, the former is somewhat trivial, and the latter not so much. Incidentally, have you guys actually had this working before? (Multiple executables to single Rio)? I'm wondering whether your suggestions are from experience or whether you are extending the methodology for getting multiple executables to a single windows/dev target working to my situation.

I suspected as much. I think I have tried every combination of endpoint and context names possible with no success. I will probably have to change to TCP but it is a huge overhaul. I have even tried the following scenario: Crio has two stream readers listening with unique context and endpoint names. Two executables are made, each with hardcoded context and endpoint names to connect to one or the other stream reader on the Crio. Each executable successfully connects to its assigned stream reader on the Crio independently. Both executables running simultaneously fail to connect to the Crio readers.

I haven't had much success with any of these approaches. I have made a project encapsulating all of the relevant VIs and targets to make it more clear what I am trying to do. Network Streams Project.zip Network Streams Project.zip

I have tried this but I still can't get it to work. I am creating two random strings, so the reader name on the Crio is //localhost:random1/random2 I send random1 and random2 to the Exe/Dev environment host, so that it connects to the reader url //CRIo-IP:random1/random2 I still get the same problem. One stream connects fine, but when I attempt to connect a second stream, I get the 314350 error. Every application now has a unique context name and endpoint name, yet when running a second host it still claims the endpoint context is occupied. Error -314350 occurred at Create Network Stream Writer Endpoint in testingendpoints.vi Possible reason(s): LabVIEW: Another application is already streaming data to an endpoint in the context you specified. If you specified a context name in the reader name or writer name terminal of the endpoint, you must specify an unused context name. If you did not specify a context name, you must specify an unused context name by entering an endpoint URL in the reader name or writer name terminal.

I think I may have failed to explain my problem clearly enough. I acknowledge that streams are 1:1, which is why I have a handler to create multiple independent streams on the Rio. It works as follows: -A random string is generated, which becomes the reader name of the open endpoint on the CRio. -This random string is written to a shared variable. -A windows VI or executable reads that shared variable to know the open endpoint name on the CRio. It then establishes a connection with the listening endpoint on the Rio. -The Rio then generates a new random string, which becomes a new open endpoint. This is written to the shared variable and the cycle continues. The problem is that all of this works fine when connecting multiple windows VIs running in the dev environment to a single CRio. Multiple executables on different computers connecting to a single CRio also work fine. Where I get into trouble is trying to run multiple executables on a single computer connecting to the CRio, or an executable and the dev environment connecting to the single CRio. All of the reading I have done points to this having to do with the context name. The context name is "LabVIEW" when running in the dev environment, which works fine. When running executables, it is apparently the application name, and this seems to be the reason it falls over in the end. There are many forum posts about the topic elsewhere, but I can't seem to adapt their fixes to my situation, i.e. Multiple executables to single Rio. http://forums.ni.com/t5/LabVIEW/Network-Streams-error-314350-Many-executable-to-One-executable/td-p/3235867 I have cleaned up my relevant code to make the problem more clear. Please forgive my inability to attach files here. http://imgur.com/a/pv5iA

Hi, I am trying to connect multiple windows executables to a single compact Rio target using network streams (Only one direction; windows executables send data, CRio receives data). This functionality works fine when using stream senders in the dev environment. I have seen that doing this successfully requires the use of a context name in the endpoint url that contains the application name, however I am having trouble figuring out how to do this since all of the examples I have seen deal with multiple (windows) executables attempting to establish streams to other executables. I have attepted to add context names on both sides (executable and Rio) without much success. Can anyone point me to an example of what needs to be done? I have tried a number of things to no avail. I am unsure of the role of the writer name and writer url in making all of this work. I seem to have trouble attaching images; http://imgur.com/a/9V6vu

Thanks! That fixed it. Why are the refs in AllObjs out of order like that?

I seem to have encountered a bug which could make a lot of my work less reliable. Could anyone shed light on this behavior? I am attempting to obtain properties from controls within typedefs programatically, however the control/tabbing order set in the typedefs seems to be affecting the order in which the control references are obtained in an erratic manner. I can produce two seemingly identical typedef clusters with the same control/tabbing orders displayed whose control references are not in order. Please see the attached image.

I am experiencing a very odd issue when running a VI for a long period of time in the dev environment. After some time the VI goes into this slow stepthrough mode, reminiscent of how subvis are highlighted when an error is found. Has anyone experienced this, and if so, how can I fix it? Additionally, I am encountering an issue where the main VI takes a long time to close, often crashing labview when the abort button is used. The two issues seem to be related. Video attached. VID_20170128_141552.mp4

Sweet, thanks! That worked. I was racking my brain trying to find the property for the control reference. I didn't realise that the Traverse for G objects output reference was not typed to ControlTerminal.