"Port limit exceeded" error on my MASS FLOW CONTROLLER

[doc_d]

Can you send it in 2018 version? I cannot open the file. Thank you.

[AeroSoul]

2018 version

[doc_d]

Thank you.

I still have the same problem, I guess when I write my command there occurs a conflict with lower while loop. For example if I write setpoint for B and in lower loop I am continuing to read that data due to this my data is getting distorted.

[AeroSoul]

Do you get a response when setting a setpoint?

If so then you could just add a TCP read after writing a setpoint and discard the answer, just so you empty the buffer.

[doc_d]

Still no results!!! I just put read TCP after every writing command. (connected bytes to read from TCP write: bytes written). 

[GerdW]

Hi d,

---

@doc_d wrote:

connected bytes to read from TCP write: bytes written

---

What's the point of reading the same number of bytes as you have written in your command message? You need to read the number of bytes expected/know as answer…

(What does the manual of your device tell about the communication scheme?)

[doc_d]

I have six devices connected using rs232 communication. I am using 232 to TCP IP convertor and reading the data. Each device has it's unique ID as A,B,C,D,E AND F. If I want to read the data from device A then I'll need to send command "A + CRLF". I am reading continuously in lower loop of my code. While writing setpoint in my device I'll have to write command as "A+ SETPOINT VALUE(X)" This operation is done in upper loop.  

[altenbach]

---

@doc_d wrote:

I have six devices connected using rs232 communication. I am using 232 to TCP IP convertor and reading the data.  

---

You need to be significantly more clear. So you have one external converter that is connected via ethernet to your PC. This external converter has at least six serial ports, each connected to otherwise identical devices, only distinguished by their assigned letter A..F. Is this correct?

At this point it would help to attach your newest VI. I assume that you have implemented all fixes and suggestions. (Even the code by others could be greatly simplified. There is no need to have all that duplicate code).

Then point us to the manual of the devices and of the converter. Also explain all "fuzzy" words such as "continuously". Do you only communicate with one device at a time? Do you only read continuously from one device at a time?

[doc_d]

What I mean is I have 6 devices, they communicate via rs232 serial, all 6 of the devices are connected as daisy chain topology. Now this serial port will be connected with my USR-TCP232-302 converter. This device will have IP and port on which I will be communicating with my Labview.

The operation I need:

1. Send query to every device from A to F continuously(so that I can have real time value of setpoint to show on my labview indicators)get the response in that string I will filter the value I need to show on my Indicators.

2. Whenever I write command for setpoint to my device it should be able to change the value in the device. As an example string "A3+CRLF" will write setpoint 3 in my device.

Now that I have changed the value of setpoint, as I am reading values continuously from device A it will be updated on my numeric indicator.

I hope I have clarified enough. I am attaching manuals for your reference. 

[bev2]

I agree with altenbach.  There is a lot of information missing.  Some items which I believe might help the group with assisting you are (basically reiterating):

• What is the actual device you are communicating with. (Can people access the OEM documentation to determine how it communicates.)
  • It would not be uncommon to have a confirmation returned with a different byte count than a command.
    • Is the buffer being adequately flushed or are you reading before an entire frame is received?  
  • It would help verify when reading a channel that you are interpreting the return data correctly.
    • Includes the formats of the received message.  Unless the devices are padding, I would expect the returned sizes to vary.
  • Does a device timing delay exist between sending a command and until the full data set is available/received.
  • A Wireshark capture to compare with your vi processes would be very helpful.  
• And, just so none of us are assuming, what OS and version/sp of LabView are you using?