GPIB Receive with Unknown Mode or Count

[sullivnc]

I am talking to a serial device using GPIB Send and Receive.  My problem is that I never know the last character or the length of the data being read.  The last character is based on a checksum, which is calculated based on the response.  But since I don't know the response ahead of time, I can't calculate the checksum.  And so, I never know how many bytes the response will be.  Therefore, I can't tell the Receive function to terminate.  I can set both my mode and count to 256, and I read the proper response, but I always get an error on GPIB Receive, which stops my process.  Does anyone know how I can get around this?  I would appreciate any help.  Thanks.

[billko]

---

@sullivnc wrote:

I am talking to a serial device using GPIB Send and Receive.  My problem is that I never know the last character or the length of the data being read.  The last character is based on a checksum, which is calculated based on the response.  But since I don't know the response ahead of time, I can't calculate the checksum.  And so, I never know how many bytes the response will be.  Therefore, I can't tell the Receive function to terminate.  I can set both my mode and count to 256, and I read the proper response, but I always get an error on GPIB Receive, which stops my process.  Does anyone know how I can get around this?  I would appreciate any help.  Thanks.

---

It sounds like you may not be quite understanding the messaging protocol.  There's always a way to tell when a message ends.  Maybe it's a fixed, knowable length.  Maybe there is some kind of termination character to look for, or maybe there's a header to read that tells you how many more bytes to expect.  Do you have any documentation on what the messages look like?

[sullivnc]

I believe I am understanding it.  The response format is as follows, taken directly from the programming manual:

<Sync character><Length character><Response Status character><Response Message><Cyclic Redundancy Check 1><Cyclic Redundancy Check 2>

It doesn't consistently end with any character.  There is a length character, but it's embedded in the response, so I don't know what it is until after I get my error.  The Cyclic Redundancy Checks is calculated based on the PDF I have attached.  But as you can see, it's calculated based on the actual content of the response packet.

[Minions]

---

<Sync character><Length character><Response Status character><Response Message><Cyclic Redundancy Check 1><Cyclic Redundancy Check 2>

---

You should be scanning the port for the SYNC character.  Once you receive that, the next one will be the LENGTH.  Do you know if the LENGTH corresponds to the size of <Response Message> or for the [(size of <Response Message>) +3]?  The +3 is for the (<Response Status Character>, <Cyclic Redundancy Check 1>, and Cyclic Redundancy Check 2>).  Is a termination character sent during transmission?  Does your code have a running CRC calculation in accordance with the NOTE in section 4.2.3?  If so, then your CRC1_calc & CRC2_calc should match those CRC1 & CRC2 transmitted.

If the message format is always the same, then break it down into useable parts.

[billko · Accepted solution]

---

@sullivnc wrote:

I believe I am understanding it.  The response format is as follows, taken directly from the programming manual:

<Sync character><Length character><Response Status character><Response Message><Cyclic Redundancy Check 1><Cyclic Redundancy Check 2>

It doesn't consistently end with any character.  There is a length character, but it's embedded in the response, so I don't know what it is until after I get my error.  The Cyclic Redundancy Checks is calculated based on the PDF I have attached.  But as you can see, it's calculated based on the actual content of the response packet.

---

Treat this as the last scenario I described - as a message with a header.  Read the first THREE characters because that's your header (but only the first two are important for what we are doing).  I believe LabVIEW will give you a warning that you didn't read all the data, but it should only be a warning, not an error.  The second character will be your length, and it will tell you how many more bytes to expect.  (From the description, I have no idea whether it is a text number or if it is a byte representing the actual value, nor whether the value is for the remaining amount of bytes, or the length of the message with the header included, but the docs should make that clear.)  Now that you know how many more bytes to read, just read the rest of the message.

[sullivnc]

I will try that and let you know how it goes, thanks.

[crossrulz]

---

@billko wrote:

Treat this as the last scenario I described - as a message with a header.  Read the first THREE characters because that's your header (but only the first two are important for what we are doing).

---

Actually, you want to start out by reading 1 byte at a time.  Do this until that byte matches the sync byte.  Then you can read the next byte to get the length and read that many more characters.  At this point, do the CRC check and verify before you do anything with the data.

[billko]

---

@crossrulz wrote:

---

@billko wrote:

Treat this as the last scenario I described - as a message with a header.  Read the first THREE characters because that's your header (but only the first two are important for what we are doing).

---

Actually, you want to start out by reading 1 byte at a time.  Do this until that byte matches the sync byte.  Then you can read the next byte to get the length and read that many more characters.  At this point, do the CRC check and verify before you do anything with the data.

---

I realized too late what the sync byte implied - namely that the data is streaming.  Thank you for correcting me.