LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

Hello, I am currently working on a senior design project where my team is developing a control system for a small wind turbine. We are adding sensors and wireless systems to the turbine. The sensor data will be collected then sent out using a TCP connection. The Labview will act as the listener and post the values to the web.

 

I am having trouble with data logging however.

 

I would like it to where you put in the time you want the data logger to be active, then push a button and the data logger will record the incoming values on the TCP connection and create a CSV text file.

 

Whenever the data logging loop is running, the stream of sensor data stops so all of my recorded values are the same for the duration.

 

Any input would be appreciated.

 

Thanks!

Mechanical Engineering
Colorado State University
0 Kudos
Message 1 of 21
(5,046 Views)

What you could do is have a server that when connected to, stop logging, write the log over the TCP connection and restart the logging.  Here are some VI block diagrams to give you some direction.  Hopefully they will help you.

 

 

A

 

TCP-Simple-Server.PNG

TCP-Simple-Client.PNG

TCP-Read-Chunk.PNGTCP-Write-Chunk.PNG

TCP-Kill-Server.PNG

0 Kudos
Message 2 of 21
(5,012 Views)

You are making several mistakes:

 

 

  1. I have no idea what that orange numeric is supposed to do. NEVER do equal comparison with orange wires. Change it to I32 and replace the inner while loop with a FOR loop.
  2. Why is there a inner loop at all? You are writing the same old stuff N times. Redundant!
  3. Remove the wait where you write to the file. Why would you delay all write iterations by 1 second, at the same time stalling the entire program, including the TCP by N seconds?
  4. Why is there a file open dialog, again stalling the entire program until a path is entered?
  5. Why do you ask for a new path every time you save? Shouldn't it append to the existing file?
Solution:
The file open belongs before the outer loop, keeping the file open for the duration of the run. Close after the main loop.
Append data.
The file operation and the TCP operations belong in individual loops that run in parallel.

 

0 Kudos
Message 3 of 21
(5,000 Views)

Me thinks you posted to the wrong thread. 😄

 

 

A

 

[edit] Oh, I guess you are referring to the OP.  Sorry, I can't read LV 10 so, I didn't even think what you were referring to. Doh!

0 Kudos
Message 4 of 21
(4,994 Views)

Ok so I've got it to work and I will post pictures since that seems to be easier. Now when I press the data log button it will record the incoming TCP data. However, I cannot figure out how to have the incoming data be sent to the numeric indicators in either case (true or false). That is why I have two separate tabs with indicators that will show the TCP data. Any hints on how to use just one set of indicators for the whole system?

 

Also, the oen second delay in the loop is because I am recording the data at one second intervals. The constant File prompt is because while the VI is running, when you press the button you can start a new data log without having to reset the VI.

 

Thanks!

labview front panel.png

labview 2.png

labview 1.png

Mechanical Engineering
Colorado State University
0 Kudos
Message 5 of 21
(4,985 Views)

 


@dan_fink wrote:

Ok so I've got it to work and I will post pictures since that seems to be easier. 


 

No, it is not easier, because we cannot run or debug a picture.

 

From what I can tell from the zoomed out images, You are just complicating the issue by duplicating the TCP code. You are still stalling the entire VI at the file dialog. You still have way too many stacked loops.

 

Try to rewrite it as a simple state machine. Don't duplicate shared code!

 

0 Kudos
Message 6 of 21
(4,977 Views)

 


@Been bitten by LabVIEW wrote:

Me thinks you posted to the wrong thread. 😄


 

Well, I actually opened the VI and looked at it. 😮 Your answer is completely off, because it deals with servers and such. You attach 5 pictures with little to no explanation. That's not really helpful.

0 Kudos
Message 7 of 21
(4,973 Views)

Yes from what Labview has been showing me, the only way to TCP Read the data AND write it to a file, the TCP READ block MUST be inside the same loop as the WRITE TO TEXT file. I do NOT want to datalog the information all the time, only when you press the button.

 

I have tried sticking the TCP read outside of any loops (outside the write to text loop) and when I do this, the TCP does NOT READ any information and the VI writes the SAME values into the text file.

 

Really without you showing me an example or what I SHOULD BE doing, you aren't helping much.

 

If I could use the labview help to solve the problem, I wouldn't be on the forum.

 

New file attached///

Mechanical Engineering
Colorado State University
0 Kudos
Message 8 of 21
(4,970 Views)

 


@dan_fink wrote:

Yes from what Labview has been showing me, the only way to TCP Read the data AND write it to a file, the TCP READ block MUST be inside the same loop as the WRITE TO TEXT file.


 What you are saying is wrong. You are well advised to study this in more details. There are many ways to communicate between multiple parallel loops (local variables, queues, action engines, etc.)

 

 


dan_fink wrote:

I have tried sticking the TCP read outside of any loops (outside the write to text loop) and when I do this, the TCP does NOT READ any information and the VI writes the SAME values into the text file.


 

That advice makes no sense. Unless you want to read only once, it must be in a loop. right?

 

Here is a simple rewrite using a queue to relay data to the parallel loop that writes to the file in parallel. I also attached a single loop version that simply writes to the file. I would recommend the queue version.

 

These programs are proof of concept and incomplete.

 

I was not able to test the code because I don't have your network environment, thus there are probably bugs. Still, it should give you some ideas. What is the exact format of the string received via TCP?

 

I also did not understand your wait statements. You delay the loop rate by 1 second, yet you set the TCP timeout to 300ms. Since the loop does not spin unless data arrives, you probably don't need an extra wait.

 

(Sorry, Your diagram was way too big for my laptop screen so I had to shrink it a bit ;))

 

 

 

Message 9 of 21
(4,952 Views)

Ok, this is what I was looking for, another approach. I will look into the "queue" concept. I see what you did with parallel loops and NOW I understand what you meant.

 

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.

 

Thanks for the help, I will look into these new methods / structures.

 

Also, Sorry about my big diagrams, I am working on a 24" widescreen monitor.  Smiley Happy

Mechanical Engineering
Colorado State University
0 Kudos
Message 10 of 21
(4,947 Views)