TCP data stream is interrupted with data logging (write to text)

[dan_fink]

Ahhh I'm sorry, my TCP sender timed out on my network and that's why the values weren't showing up.  

It's working well but the reason I had the TCP read "timeout" Is to help the data sync up (or so i think). Without that the values are shifting between the numeric indicators and thus being logged in different spots.

Is there any way to keep the "open/create file" dialog from popping up UNTIL you push the data log button?

Also, Do you have any hints on how to sync up external sources TCP Read / Write of just have labview wait until the next set of info is received?

I REALLY appreciate the help. Thanks a lot.

[altenbach]

---

dan_fink wrote:

There are still a few concerns with your modified VIs. Neither of them:

1) enable datalogging (via a button press), they start when the VI starts. Not sure if this was your intention.

2) None of the values display on the numeric indicators. (Not sure why, all of the connection info, etc is the same. This is similar to my problem earlier)

3) Even if the values aren't being displayed, after the duration of "logging" when I try to open the file it is empty.

---

1. Datalogging will only start when the button is pressed. The lower loop waits forever until data is placed on the queue in the upper loop. When the button is pressed, the innermost case turns true and data is placed on the queue (or written directly to the file in the other version). (It will ask for the file name at the start of the program and open the file to be ready for writing later).
2. If nothing displays in the indicators, maybe the received string is empty or not formatted as expected. Can you place an indicator or probe on the string wire leaving the TCP read. What does it show? Can you copy and paste it here?
3. Again, this probably has something to do with point (2).

[altenbach]

---

@dan_fink wrote:

It's working well but the reason I had the TCP read "timeout" Is to help the data sync up (or so i think). Without that the values are shifting between the numeric indicators and thus being logged in different spots.

---

Sorry, I don't understand. How quickly does data arrive at the port? It does not seem right for the server to impose any timing constraints. New data needs to be displayed when (and only when!) and whenever it is received. If data should arrive at different or more regular intervals, the client should provide the pacing. The TCP timeout is just that: if nothing arrives, it waits up to 25 seconds. If data arrives it reacts immediately. If no data arrives there is nothing to do. (Sorry, you should probably ignore timeout errors, I took it out for simplifications. It would go before the the error case and stop condition)).

[dan_fink]

Yes I thought that the client should provide the pace as well. Something else is going on because the values of the indicators should stay the same (sensor values aren't being changed) but their values are jumping between indicators... strange.

EDIT: The time values that are being data logged are not consistent, sometimes values are written every second and other times its every two seconds..

[altenbach]

---

@dan_fink wrote:

Yes I thought that the client should provide the pace as well. Something else is going on because the values of the indicators should stay the same (sensor values aren't being changed) but their values are jumping between indicators... strange.

---

How quickly does the data arrive? The indicators are only updated when new data arrives.

You still haven't showed me a raw string as received.

Is 100 bytes enough?

---

@dan_fink wrote:

EDIT: The time values that are being data logged are not consistent, sometimes values are written every second and other times its every two seconds..

---

Maybe you should try to save fractional seconds if timing matters. It could be that your observation is due to rounding to the nearest second.

[dan_fink]

Yup thats what I figured out, the byte to read size wasn't large enough. Is there any way that the VI will automatically change the amount of bytes to read based upon the incoming sting? Similar to what I see in the example tcp file? I'm not 100% sure if this is what is really going on.

Sorry it's lots of little questions,

Image attached.

Thanks again,

[altenbach]

Do you have access to the program that sends the data?

If not, does the data end in a special termination character?

Try to play with different mode settings of TCP read.

[dan_fink]

Also, If I am not to add a time delay, how am I to designate logging on only one second intervals?

Sorry for all the little questions, You kinda threw me head over heals with my VI  

[altenbach · Accepted solution]

Assuming the TCP data arrives at irregular intervals that are sometimes shorter and sometimes longer than a second, you could just write the string to a string indicator in the upper loop.

In the lower loop, read the local exactly every second and write the data to the file.

Here is a quick draft. Of course you could easily add more event cases, e.g. to change the log file name, etc.

[dan_fink]

Awesome! Wow I've really learned a lot today, sorry if I seemed stupid (it's my first VI )  I have much more to go with this project and if I get caught up again I will look for you! 

Thanks again!

-Dan