VISA READ wait for termination character not working

[emime]

Every command is going through but the stage motion (m+vector+CR) doesn't finish before the program ends and moves on to the instruction instead of waiting for the end of the movement. So when I want it to move in a preprogrammed pattern it skips commands.

[Mark_Yedinak · Accepted solution]

To me this sounds like you are receiving the command responses. What might be happening is that the device is responding before it completes the task. You may need to query the current position and only proceed once the position reaches its desired location. I have not worked with those devices so this is just speculation on my part. It may just be a case where you need a bit more intelligence in your control application.

[crossrulz]

---

@emime wrote:

Here is the user manual for external devices.

MP-285A_QuickRef_ExternalControl.pdf (sutter.com)

---

Ah, more information.  Now for the kicker: you do NOT want to be using the Termination Character here.  The data is transmitted in a hex/binary/raw data format, which means your termination character could actually be found in the actual data.  So you need to know how many bytes to read and verify.  So if you send the Get Current Position command (c\r), then you read 13 bytes and verify the last byte is a Carriage Return (0x0D).  If that passes, you can parse the 3 I32 values.  I recommend using Unflatten From String with the data type being a cluster of 3 I32 values.

[billko]

---

@crossrulz wrote:

---

@emime wrote:

Here is the user manual for external devices.

MP-285A_QuickRef_ExternalControl.pdf (sutter.com)

---

Ah, more information.  Now for the kicker: you do NOT want to be using the Termination Character here.  The data is transmitted in a hex/binary/raw data format, which means your termination character could actually be found in the actual data.  So you need to know how many bytes to read and verify.  So if you send the Get Current Position command (c\r), then you read 13 bytes and verify the last byte is a Carriage Return (0x0D).  If that passes, you can parse the 3 I32 values.  I recommend using Unflatten From String with the data type being a cluster of 3 I32 values.

---

Isn't it strange that the response definitely terminates with a <CR> yet the response is binary info?  Seems like a major "oops" to me!

[Mark_Yedinak]

---

@billko wrote:

---

@crossrulz wrote:

---

@emime wrote:

Here is the user manual for external devices.

MP-285A_QuickRef_ExternalControl.pdf (sutter.com)

---

Ah, more information.  Now for the kicker: you do NOT want to be using the Termination Character here.  The data is transmitted in a hex/binary/raw data format, which means your termination character could actually be found in the actual data.  So you need to know how many bytes to read and verify.  So if you send the Get Current Position command (c\r), then you read 13 bytes and verify the last byte is a Carriage Return (0x0D).  If that passes, you can parse the 3 I32 values.  I recommend using Unflatten From String with the data type being a cluster of 3 I32 values.

---

Isn't it strange that the response definitely terminates with a <CR> yet the response is binary info?  Seems like a major "oops" to me!

---

Yes, that is a poor implementation of a protocol.

[mcduff]

At the risk of starting a flame war, which I will not respond to, do the following,

1. Get rid of the termination character on receive.
2. Use Bytes at Port. (There are use cases for it, this is one of them.)

Example below, 2015 version attached.

mcduff

[crossrulz]

---

@mcduff wrote:

At the risk of starting a flame war, which I will not respond to, do the following,

1. Get rid of the termination character on receive.
2. Use Bytes at Port. (There are use cases for it, this is one of them.)

Example below, 2015 version attached.

mcduff

---

1. Absolutely the termination character should not be used here.

2. There is a place for the Bytes At Port.  This is not one of them.  The VISA Read already handles the timeout situation.  No need to add more complexity.  We have the protocol documented, so use it (even if the protocol is a POS).

[mcduff]

---

@crossrulz wrote:

---

@mcduff wrote:

At the risk of starting a flame war, which I will not respond to, do the following,

1. Get rid of the termination character on receive.
2. Use Bytes at Port. (There are use cases for it, this is one of them.)

Example below, 2015 version attached.

mcduff

---

1. Absolutely the termination character should not be used here.

2. There is a place for the Bytes At Port.  This is not one of them.  The VISA Read already handles the timeout situation.  No need to add more complexity.  We have the protocol documented, so use it (even if the protocol is a POS).

---

The timeout handles the case for a 13 Byte receive message at the serial port; if the return is less than 13 bytes, then you wait for 10s. If the response if more than 13 bytes then you lose information.

The "Get Status" command returns 33 bytes, some other commands return 1 or 2 bytes. So the OP can modify each serial read to have the correct number of bytes for the response, or can implement something a bit more general and reuse the code throughout the application. The former seems more complicated to me, but I am not a knight.

mcduff

[billko]

---

@crossrulz wrote:

---

@emime wrote:

Here is the user manual for external devices.

MP-285A_QuickRef_ExternalControl.pdf (sutter.com)

---

Ah, more information.  Now for the kicker: you do NOT want to be using the Termination Character here.  The data is transmitted in a hex/binary/raw data format, which means your termination character could actually be found in the actual data.  So you need to know how many bytes to read and verify.  So if you send the Get Current Position command (c\r), then you read 13 bytes and verify the last byte is a Carriage Return (0x0D).  If that passes, you can parse the 3 I32 values.  I recommend using Unflatten From String with the data type being a cluster of 3 I32 values.

---

Sorry, Mcduff, I have to vote for this one.  Except I'm not sure about the \r that is part of the response.  Will it just show up at the rest of the binary string output of the unflatten from string?

[mcduff]

---

@billko wrote:

---

@crossrulz wrote:

---

@emime wrote:

Here is the user manual for external devices.

MP-285A_QuickRef_ExternalControl.pdf (sutter.com)

---

Ah, more information.  Now for the kicker: you do NOT want to be using the Termination Character here.  The data is transmitted in a hex/binary/raw data format, which means your termination character could actually be found in the actual data.  So you need to know how many bytes to read and verify.  So if you send the Get Current Position command (c\r), then you read 13 bytes and verify the last byte is a Carriage Return (0x0D).  If that passes, you can parse the 3 I32 values.  I recommend using Unflatten From String with the data type being a cluster of 3 I32 values.

---

Sorry, Mcduff, I have to vote for this one.  Except I'm not sure about the \r that is part of the response.  Will it just show up at the rest of the binary string output of the unflatten from string?

---

I agree the above is a good way to measure Position; it's just not applicable for any other command. I assume the OP wants to do more than just get position, maybe status updates, maybe the ability to interrupt moves, etc. Use something general to communicate with the device, then use something specific, like unflatten form string, to parse specific commands.

mcduff