"Port limit exceeded" error on my MASS FLOW CONTROLLER

[bev2]

Based upon you controller set up, which format on page 6 are you expecting to receive?

Did you verify by issuing the query command similar to "A??D*<cr>"?

When I search for what MFC defines as a command, I do not see what the command is?  The only reference I see in the document is a note about the Gas register.  

[doc_d]

I have received the valid response my only problem is when I write setpoint value the response is getting distorted.

As you can see there are commands as A+CRLF which gives me one of the strings from page 6. This string is getting noisy whenever I write command for setpoint.

Thank you.

[bev2]

Examples of good versus "noisy" data?

[doc_d]

HERE...

[GerdW]

Hi d,

---

@doc_d wrote:

HERE...

---

These are only pictures of data, but not the data itself!

What about attaching code with those data set to default in your indicators?

What is the expected response for a setpoint command?

[doc_d]

I have attached VI before(with same pictures named: beforesending and aftersending) currently I am not with device for a while. Although the expected response should be like attached pictures. You can see when I send "1" set value for "C" you can see value of setpoint in C string(data out 2 indicator) which is +1.0000. Now if I send "2" then this value will change to +2.0000.

Another thing I noticed is when I tried to flush buffer with TCP read with 100 byte and 100ms it works for a while and then shows timeout error.

Is there any example regarding flushing buffer for TCP IP?

[GerdW]

Hi d,

---

@doc_d wrote:

I have attached VI before(with same pictures named: beforesending and aftersending)

---

Your latest attachment is "Read test - to check.vi" from message #4: there are still no changes even though you received suggestions?

---

@doc_d wrote:

Another thing I noticed is when I tried to flush buffer with TCP read with 100 byte and 100ms it works for a while and then shows timeout error.

Is there any example regarding flushing buffer for TCP IP?

---

In your last attachment this "TCP buffer flush" is not included. How are you doing that? Mind to attach your latest code?

Why do you need to flush the buffer anyway? All you need to do is to read ALL responses to ALL commands you are sending to your device(s)!

Suggestions:

• Use FormatIntoString to create your commands instead of NumToFloatString followed by ConcatString…
• Use just one loop with just one TCP reference wire.
• Use a statemachine-like approach: create one command, read it's response. Next state will send next command. Next state is selected by event structure: either timeout (read current data from MFC) or ValueChange event (send new setpoint).
• You may also use a QMH-like structure instead: have the UI-handler loop (with your event structure) send "actions" to your TCP-handler loop. An "action" will be the next device command to send…

[doc_d]

I understood your concern thanks for replying. Let me show you my code only for one data for your ease.

The data stream is getting shifted as shown in the picture. So if I want to read anything from this string using substring function I get different value. More devices causing more distortion.

See VI and pictures below for reference.

Thank you.

[GerdW]

Hi d,

---

@doc_d wrote:

The data stream is getting shifted as shown in the picture.

---

This usually happens when you read more/less bytes from a buffer than is expected in the response message.

Again: which response do you expect from your setpoint command? Do you expect the very same message length as you get from a "simple" current state request?

---

@doc_d wrote:

So if I want to read anything from this string using substring function I get different value. More devices causing more distortion.

---

It seems there is some kind of termination in your messages: They start with "B" and end with "CH4" (as it seems).

You might use those substrings to correctly find the start and end of each message…

I still suggest to implement the whole communication within just one (1) loop:

• No need to open two TCP connections to just one target.
• for each command write you can (more) easily read the corresponding response message…

Like this:

[AeroSoul]

I just realised the MFC probably stands for Mass Flow Controller from Alicat... we use the same thing in our machines, except we connect them to BB9-232 multi-drop breakout boxes with USB connector.

These breakout boxes don't target specific instrument when you are communicating, they send a data packet to all connected devices and only the device targeted with ID responds. IF this is the case with your TCP to RS232 converter then i'm assuming that normally you have just enough delay between messages that each instrument manages to respond separately... but when you set a setpoint then several instruments try to respond at the same time and you get garbage data.

I'd go with what GerdW suggested (and i actually use myself to communicate with these MFCs) and use a state machine like approach. Also add a bit of delay between each command you send, just in case.

-----------------

EDIT:

@GerdW: B is probably device ID from which response came and CH4 is most likely the gas for which this particular MFC was made/used. Which means he gets garbled data even when he's supposedly getting a normal response, since if you look at his image B IDLE STATE.png he gets half of a response from previous command and a B+03 from a new response.