01-19-2015 01:01 PM
So the network streams API only requires the names of two endpoints on *one* side. That is, there is a defined "listener" and "connecter" just like with TCP. You can tell the cRIO to try to open a stream at //myStreamName and then your host can connect to it without your cRIO ever knowing the name of the computer. If you need to have some metadata you need to share, what I've done in the past is make a listening stream at a fixed address "//crio/myConnListener" and then that stream is used to negotiate everything else.
DNS would also work and it should work just like you'd expect in a normal computer, and you can use a system exec call to flush the dns if needed.
01-19-2015 04:49 PM - edited 01-19-2015 04:50 PM
im curious to know why you can setup a network shared variable to have FIFO property, when that actually does not obey to the FIFO rules? So whats the point in having this option?
01-19-2015 08:29 PM
So there is buffering and streaming. The RT FIFO option is so you can use them in a time-critical loop.
Buffering is described here: http://www.ni.com/white-paper/12176/en/
However since SVs are fundamentally tag-oriented it rarely makes sense (to me) to enable it.
01-19-2015 11:55 PM
good Q Heel, the shared FIFO dose not follow normal FIFO rules, since the host of the FIFO have no idear on how much data there is in the FIFO or who is reading it
01-20-2015 09:38 AM
Exactly, and since you don't have that control and you lack information about the size and contents of the buffer, I can't recommend it.
Note: in my last post I misspoke, I meant to say "so there is buffering and enabling RT FIFOs".
01-20-2015 09:49 AM
Agree about the need for buffering on the network shared variable - but my point to the LabVIEW implementers is: Don't call this a FIFO because this it can only be if it maintains first-in-first out integrity, which it does not. So it confuses the users to call it a FIFO.
01-20-2015 10:14 AM
Its definitely a FIFO and has FIFO semantics, but I agree it would be more immediately understandable if it were called a lossy FIFO/lossy buffer. The actual behavior is what an RT FIFO (or lossy enqueue) does.
02-03-2015 09:55 AM
So now i have made my program with network streams as sugested, and it works great. but if my program crashs i run in to the poblem that my network stream allready exist.
Error text is: An endpoint with the same name already exists
Any good idears or work arounds? since the posts all points to and idear to acces existing streams have bin posted 4 years ago.
And i just want my data to get from A to B 🙂