
parsec
Members-
Content Count
17 -
Joined
-
Last visited
Community Reputation
2About parsec
-
Rank
Active
LabVIEW Information
-
Version
LabVIEW 2016
-
Since
2002
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
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
-
Opening re-entrant subVIs in LabVIEW 2017 does not launch clones
parsec replied to parsec's topic in LabVIEW General
Thanks for the workaround. -
Opening re-entrant subVIs in LabVIEW 2017 does not launch clones
parsec replied to parsec's topic in LabVIEW General
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?
-
Network streams - multiple windows executables to compact RIO target
parsec replied to parsec's topic in LabVIEW General
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 -
Network streams - multiple windows executables to compact RIO target
parsec replied to parsec's topic in LabVIEW General
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. -
Network streams - multiple windows executables to compact RIO target
parsec replied to parsec's topic in LabVIEW General
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 -
Network streams - multiple windows executables to compact RIO target
parsec replied to parsec's topic in LabVIEW General
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 -
Network streams - multiple windows executables to compact RIO target
parsec replied to parsec's topic in LabVIEW General
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 -
Network streams - multiple windows executables to compact RIO target
parsec replied to parsec's topic in LabVIEW General
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 -
Network streams - multiple windows executables to compact RIO target
parsec replied to parsec's topic in LabVIEW General
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
-
Concerning bug(?) when retrieving control references from typedef
parsec replied to parsec's topic in LabVIEW General
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