TCP WRITE FUNCTION CAUSING NOISE

[doc_d]

Kindly go through the vi below. I am using string A + carriage return for monitoring my devices from A to E. Now I want to write command as A + setpoint value + carriage return. When I write my command, my monitoring strings are getting noise. What is a proper way to send the command over tcp?

Operation I need is as following:

1. continuous reading data from device A to E (This data string consist of parameters like current pressure, setpoint, temperature etc. )

2. If I write setpoint on any device them my data string will have changed setpoint value

[billko]

Is the noise like humming, or is it random screeches?  You'll have to describe this "noise" a little bit better.

[doc_d]

Check upper right corner for the reference in thepicture. If I send command the data string is having random characters or misplaced. 

I need to read data continuously but when I send command for setting setpoint data stream is getting distorted. Is there any way I send command over other connection ID so that this while loop's connection ID doesn't get affected? Because if I will send on same ID it will generate error.

Note: I need to continuously read whole data stream because I need to monitor real time parameters included in data stream.

[GerdW]

Hi doc,

---

@doc_d wrote:

Check upper right corner for the reference in thepicture. If I send command the data string is having random characters or misplaced. 

---

The images look different than the VI you attached earlier…

---

@doc_d wrote:

I need to read data continuously but when I send command for setting setpoint data stream is getting distorted. Is there any way I send command over other connection ID so that this while loop's connection ID doesn't get affected? Because if I will send on same ID it will generate error.

---

Which error do you get? Any error numbers?

I guess the manual of your device will explain how to read the datastream when sending random commands in between: this is not a problem of LabVIEW, but a problem of the communication protocol of your device!

[billko]

It seems like Alicat has extensive support for LabVIEW.  Have you tried using their drivers and software instead?

If you need to send them with different IDs, just create new ones, but that's probably not the issue.  We need to see the manual that tells us what to send and what we expect to receive.

[Kevin_Alicat]

Hi doc_d,

I'm a test engineer here at Alicat, and I thought I'd respond just in case this issue hasn't been resolved via troubleshooting yet.

Is the issue that you are performing the sending of the setpoint command in parallel to the ongoing data communication loop? If so, your data coming back garbled would make sense if two devices are responding at the same time over the same serial line.

For Alicat's multidrop RS-232 or 485, the communication should definitely be performed sequentially with no send occurring until the previous data transmission on the same line is complete. If performing the communication in multiple loops/locations within the same program, you should be able to make use of the synchronization palette such as notifiers or queues to only perform the setpoint send after the set of data queries have completed, or to push all the serial transactions through a queue to be handled by a single data transaction loop.

You'd probably want to include a similar method of preventing the data readings from occurring if the setpoint command hasn't completed yet if the setpoint can occur at any time (a 5 second wait after a data read should be enough for a few setpoint writes, but if they're fully asynchronous you'd hit the same issue if the setpoint happened right before a data read was going to occur).

Alternatively, if you're able to place the setpoint change inside of the same vi/loop as the data queries, you can likely set up a case structure to only enact the setpoint change command if something occurs (setpoint change button pressed, setpoint value altered, etc.) and then you can ensure that it happens sequentially by placing it directly before/after the data reading functions.

Please let me know if I misunderstood the issue or if you have any other questions, and I'll be happy to assist.

[Kevin_Alicat]

Right after sending that message I realized that if I were doing this for myself, I'd do it using a functional global for the send/receive of the data that would be able to open the TCP port on the first call, and then perform the data reads/setpoint writes as selected by the state selector control.

You'd want to ensure it's non-reentrant, and then you're basically left with a little sub-VI that you can drop anywhere you want (including in different loops) and there should be no data collisions because the data send/read commands are all going through a single source.

Attached is a quick image example

[billko]

---

@Kevin_Alicat wrote:

Right after sending that message I realized that if I were doing this for myself, I'd do it using a functional global for the send/receive of the data that would be able to open the TCP port on the first call, and then perform the data reads/setpoint writes as selected by the state selector control.

You'd want to ensure it's non-reentrant, and then you're basically left with a little sub-VI that you can drop anywhere you want (including in different loops) and there should be no data collisions because the data send/read commands are all going through a single source.

Attached is a quick image example

---

I've never used Alicat products, nor their drivers, but this particular post here makes my trust in Alicat LabVIEW support increase by at least 500%.

[doc_d]

Thank you for your assistance. I understand the problem now. I have one more query though, If I want to send data on multiple devices then should I do it in same case structure "send data" or do I have to make case for each device. Same question for reading the data. 

[doc_d]

Thank you for your reply. Yes, they have support for labview drivers and vis but I could not find one matching with my requirement because I am using  USR-TCP232-302 for which there are no drivers or VIs available.