DMM+Switch example: how to make TCP continuously listen?

[ylflex]

Dear community,

I'm adding TCP functionality into this example: Switch - Scanning with a DMM - Handshaking (NI-SWITCH).

I added a TCP client into this example (TCP listen, etc). The TCP server was taken from an example. However, in reality, the TCP server is another program that does the same job.

The programs can do the following: server sending "OK", client receiving "OK", DMM is then triggered to measure devices specified by the switch.

The problem is: when my client (Client+DMM+Switch) finished one cycle (receive, trigger, measure all devices), it will go into error when TCP server is sending the "OK" message again! I had to mannually disconnect, re-connect, re-send the "OK" from the real TCP server. So, the client does not run "continuously". By continuously I mean to receive message for second time, thrid time, etc...without needing to reset the TCP server!

So, how to bring the client back to wait/listen mode, after one full cycle (receive, trigger, measure)?

Please help!

[User002]

Hi, @ylflex,

The problem is: when my client (Client+DMM+Switch) finished one cycle (receive, trigger, measure all devices), it will go into error when TCP server is sending the "OK" message again! I had to mannually disconnect, re-connect, re-send the "OK" from the real TCP server. So, the client does not run "continuously". By continuously I mean to receive message for second time, thrid time, etc...without needing to reset the TCP server!

So, how to bring the client back to wait/listen mode, after one full cycle (receive, trigger, measure)?

---

Disclaimer, I have never used the niDMM functions, nor have I used TCP. So this is purely based on looking at your VIs and trying to figure it out.

First, to make sure I understand:

• You're using your TCP server (not the attached TCP server VI, but an equivalent TCP server) to send "OK" to the Switch...vi.
• When you send a message from the server to the Switch...vi, the Switch...vi behaves as expected.
  • It gets the message
  • It acquires the measurements
  • It writes the measurements to file
  • It replies with its "OK"
• Then, an error occurs in your TCP server? Or in the Switch...vi?
• Is the error a LabVIEW error that you can lookup? Or just "an error", meaning that things are running as expected?

Second, here are a couple more questions regarding the Switch...vi. These are more out of ignorance than anything.

• In the While Loop with the green 10 (niDMM Read Status.vi) and the green 11 (niDMM Fetch Multi Point.vi), you're choosing to fetch the maximum of "Samples to fetch at a time" or "Backlog". So if you have a big Backlog, it'll fetch all at once, and if you have a small Backlog, it'll try to fetch more than the Backlog. Is that right? Or do you want to use the minimum?
• For the measurement array coming out of the while loop is in a "Last Value" tunnel. Do you only want to save the last measurement array?

Hope this helps you keep moving forward...

-joeorbob

[ylflex]

Thanks for the answers!

1. For TCP part, it's the other TPC server (written in unknown language, unknown framework) that has to disconnect/reconnect, before sending another command. My LabView TCP client can run continuously, and take a second command, without any errors and stops. 

So, is there anything I can do to this TCP client, so that it can continuously listen??? I can't change the TCP server because it's controlled by our partner.

2. Regarding backlog, I'm not totally sure. I only need to measure 4 resistors, therefore I put 4 in "number of samples to fetch".

[User002]

---

@ylflex wrote:

Thanks for the answers!

1. For TCP part, it's the other TPC server (written in unknown language, unknown framework) that has to disconnect/reconnect, before sending another command. My LabView TCP client can run continuously, and take a second command, without any errors and stops. 

So, is there anything I can do to this TCP client, so that it can continuously listen??? I can't change the TCP server because it's controlled by our partner.

2. Regarding backlog, I'm not totally sure. I only need to measure 4 resistors, therefore I put 4 in "number of samples to fetch".

---

...Am I understanding the workflow properly? Here's what I've understood:

• Your partner has a TCP server.
• You have made a LabVIEW TCP client.
• You use the partner's TCP server to send an "OK" message to your LabVIEW TCP client.
• Your LabVIEW TCP client receives the "OK" message, replies with its own "OK" message, and then measures the values and records them in a file.
• Your partner's TCP server receives the "OK" message and tries to send another "OK".
• At this point, your partner's TCP server has an error, and your LabVIEW TCP client is still running/listening as expected.
• The ONLY fix is to disconnect and reconnect the connection from the side of the partner's TCP server.
• After the partner's TCP server has been disconnected and reconnected, it sends another "OK".
• Now (instead of the partner's TCP server having an error), your LabVIEW TCP client (which is still running*) receives the "OK" message, responds with an "OK" message, and measures/records values.

*By still running, I mean that the LabVIEW TCP client has not had an error, you have not pressed the Stop button, and it has not been aborted. It's still running its While loop.

Do I understand correctly?

-joeorbob