parsec

I'm looking for an experienced LabVIEW programmer. This is a unique and rare opportunity to work on a real orbital vehicle and contribute significantly to putting a rocket into space. The position is in Augsburg, Germany, however all day to day activities are conducted in English. https://karriere.mt-aerospace.de/r/z02jtff8igwc1g9/LabVIEW+control+and+systems+integration+engineer+fmd/86153/Augsburg

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

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 t

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

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. Erro

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 strin

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

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