AK protocol via TCP/IP?

[cmh]

Hi,

I (or rather our customer) want to use an AK protocol to communicate over TCP/IP. This means that I want to read from TCP/IP until the end control character <ETX> is read instead of reading a specific number of bytes. Can this be done?

My apologies if this is already answered somewhere else which I could not find.

Martin

[smercurio_fc]

You have to specify the number of bytes to read with the TCP/IP Read, but nobody says it can't be 1. You will basically need to read in a loop, and stop when you see the <ETX> control character. You will need to set a low timeout on the Read so that it returns quickly in case there are no bytes, and you will need to ignore a timeout issue. This means you will not be able to catch a true timeout, but you can replace this with your own timeout in the loop which checks, say, that you receive the <ETX> within a certain amount of time.

[Thom99]

Hi there

Does anyoune have some sample vi for AK protocol via TCP/IP?

This would be very helpful for me. 

Thanks a lot in advance

Thom

[Unchained]

Hello,

I am also looking for a ak protocol sample. Would be nice someone could help me to get my ak working. Remote devices are V&F Airsense.net and IAG FAS04.

Thank you.

[Mark_Yedinak]

---

@smercurio_fc wrote:
You have to specify the number of bytes to read with the TCP/IP Read, but nobody says it can't be 1. You will basically need to read in a loop, and stop when you see the <ETX> control character. You will need to set a low timeout on the Read so that it returns quickly in case there are no bytes, and you will need to ignore a timeout issue. This means you will not be able to catch a true timeout, but you can replace this with your own timeout in the loop which checks, say, that you receive the <ETX> within a certain amount of time.

---

This is not true. You can still catch a timeout. You simply have to watch for it in the code itself. You use the short timeout for the read while also setting your data timeout. Every time you have a successful read you set you reset your internal timer. (You can use a shift register with the current time.) When you encounter a timeout on your short read check your total timeout value. If you exceed it then pass the timeout error to the caller. Otherwise go back and try another read.

Another approach that can be used to read larger chunks of data in one read is to read a single character using your total timeout value. Then read blocks of characters with a shorter timeout value but one that is less than the time between your data packets. This approach works well in a command/response type of situation. You would still need to test and see if you read the <ETX> character or not.

Yet another approach would be to us VISA. With VISA you can set what the termination character is and then simply let VISA handle it for you.

[CoastalMaineBird]

I had to solve this recently.  Basically, the solution I used involves my own buffering.

READ (Inmediate) with ZERO time out.

2... Append whatever is received to the local buffer

3... MATCH PATTERN with a string of \02.*\03

4... If found, then a message is available. do a STRING SUBSET with offset = 2, and length of STR LENGTH - 3 to strip the <stx>, don't-care, and <etx> off.

5... If FOUND, then set the BUFFER to whatever is AFTER the match.  If NOT found, set the buffer to whatever is BEFORE the match (which will be the whole buffer).

6... Check for TIMEOUT and treat it as NOT an error.

(I'm in an intense environment and can't wait around for messages).

400 is just a number I chose to cover the longest expected single message.  That gives us the best chance to receive a message in a single operation.

It'll still work otherwise, though.

For multiple devices, simply manage multiple clusters, each with a buffer and CONN ID.

1...  

[jcosgrove]

Thanks this thread has been useful.

I am new to TCP and am wondering if I am able to use the same connection ID for reading and writing ak messages over TCP. 

Thanks Again

[CoastalMaineBird]

I am new to TCP and am wondering if I am able to use the same connection ID for reading and writing ak messages over TCP. 

Yes.  Once established, the connection is exactly like a telephone connection. Either party can talk.

See these articles for details.

BEWARE:  The AK spec says that each message starts with an <stx> character and then a DON'T CARE character.

In fact, a lot of instruments DO care, and want that character to be a space.

[CoastalMaineBird]

Attached is an LV2013 LLB file with RECEIVE and SEND routines, if anyone is interested.

NOTE:  The above code, which I submitted Apr 2013, has an error:

If the buffer contains TWO complete received messages, then the expression "\02.*\03" will select everything between the FIRST <stx> and the LAST <etx>, which is incorrect behavior.

The correct expression is "\02.[~\03]*\03" which means <stx>, any char, any number of chars EXCEPT <etx>, <etx>.

That is corrected in the samples given.

WIth this change, if the buffer contains two or more messages, then only the first is extracted: the subsequent ones are left in the buffer (for extraction next call).

I should point out that the actual TCP Receive is not in this example code. The TCP receive is elsewhere, with a timeout of 0.  Pass in the ERROR and DATA RECEIVED into this RECEIVE vi.

[jcosgrove]

Thanks for the suggestions.