TCP comm with multiple instruments

[Mark_Yedinak]

Is the data that you are reading distinct messages or simply streams? As Dan mentioned you can push data you have read from the handler to the master. If they are distinct messages do this whenever you have read a complete message. If you wnat the master to request the data the handler can buffer the current data and simply respond to the master's request. The handler would have parallel loops in it. One would strickly read the data. The other would be to respond to messages from the master. The only delay a WAIT would induce would be instaneous when a request for data is received while the data is actually in the process of being received.

[Mark_Yedinak]

I have written a mutli-byte termination reader in the past. Essentially I read a character at a time and do a regular expression lookup on the complete buffer. When I get a match I send that chunk to wherever it needs to go. Other wise I keep building up the buffer. With small messages there really isn't a huge perfromance problem. If your messages are extremely large than you may run into some issues.

[CoastalMaineBird]

TCP implements a packet seq number to ensre that nothing is dropped and everything is in order.

But Ben, the IMMEDIATE mode of TCP-READ says that it returns whatever bytes have been received at the timeout point.

I'm concerned that my TCP READ call (timeout = 0) would occur when the message is halfway thru.

You're suggesting that that can't happen, because partial messages don't get thru, I suppose that makes sense.

But I can't guarantee what the instrument does in any case, so this might be a dead end.

[Mark_Yedinak]

No, TCP has no concept of YOUR messages. It only knows about its data stream. It will guarantee that you get the data in the same order it was sent. If a packet is lost you will get all of the data received up to that point even if data past that has been received. However, as I stated it has no idea what your messages look like and doesn't guarnatee that your read will give you a complete message.

[CoastalMaineBird]

Is the data that you are reading distinct messages or simply streams?

Distinct messages.  This instrument isn't smart enough to just send data,data,data.  It's all a question-answer-Q-A-Q-A...

As Dan mentioned you can push data you have read from the handler to the master. If they are distinct messages do this whenever you have read a complete message.

That sounds feasible.

If you wnat the master to request the data the handler can buffer the current data and simply respond to the master's request. The handler would have parallel loops in it. One would strickly read the data. The other would be to respond to messages from the master.

--- that doubles the amount of load on the thread scheduler. 

[CoastalMaineBird]

I have written a mutli-byte termination reader in the past. Essentially I read a character at a time and do a regular expression lookup on the complete buffer. When I get a match I send that chunk to wherever it needs to go. Other wise I keep building up the buffer.

--- That's exactly the idea I came in with.  I've done it before, but in connection with a single RS232 instrument, and performance wasn't an issue.

With small messages there really isn't a huge perfromance problem. If your messages are extremely large than you may run into some issues.

My messages will be < 200 bytes.

[Mark_Yedinak]

Here is an example using VISA. It will work with TCP primatives as well.

[CoastalMaineBird]

I mentioned before that I did a test:

TCP WRITE (request)

for I = 0 to 250

  Nbytes = TCP READ (immediate, Timeout = 0)

Nbytes came back with the message when I was 200-210 or so.

I have changed that to:

TCP WRITE (request)

for I = 0 to 250

  N = TCP READ (immediate, Timeout = 0)

  Buffer.Concat (Bytes Read)

  Before,After,Where = Match Pattern(Buffer, LF)

  if Where = -1  // not found

    Buffer = Before

  else

    Buffer = After

    Message = Before

  end if

(error checking not shown, but tested).

... and the message comes in at I = 140--150, meaning that the loop slowed down (only 150 loops in the same time as 200 before), but that is still PLENTY adequate , I think (crosses fingers).

 And there is no waiting.

I like the elegance of the spawned handlers idea, but I don't see a performance benefit, so I think I'll try the idea I started with.

Thanks to all who contributed.

[Ben]

---

@CoastalMaineBird wrote:

...

I like the elegance of the spawned handlers idea, but I don't see a performance benefit, so I think I'll try the idea I started with.

Thanks to all who contributed.

---

The big factor that triggers the spawned handlers in my apps is a desire to ensure no single widget hangs the rest.

Have fun!

Ben

[Ben]

---

@Mark Yedinak wrote:

Here is an example using VISA. It will work with TCP primatives as well.

---

Although not exactly the same, the similarity to this code caught my attention.

Ben