Serial Communication with Agilent Vacuum Pump

[super_strong_dragons_n_stuff]

I'm still getting the same timeout error. Is this what you meant by 0x03, chembo?

I also included the XOR calculation at the bottom that James suggested.

Edit: In the XOR that 83 should be an 80. I fixed that and it equals 82, which is 38 32.

[chembo]

---

@super_strong_dragons_n_stuff wrote:

I'm still getting the same timeout error. Is this what you meant by 0x03, chembo?

I also included the XOR calculation at the bottom that James suggested.

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

Edit: In the XOR that 83 should be an 80. I fixed that and it equals 82, which is 38 32.

---

I don't think you should include the STX (0x02) to the checksum. The manual says '.... XOR of all characters subsequent to <STX> ...

Remove the first element of the XOR calculation. Ans also make sure that all other parameters are correct, i.e. baud rate, stop bits, etc...

I think the reading of the reply is fine now. I don't think you need the 500 milliseconds delay, but you can leave it for now

[super_strong_dragons_n_stuff]

Man I just don't know why I can't get this working. I took out the 02 and fixed the command accordingly. Are these just normal numeric integers? Do I have to do anything special to them? I notice everyone keeps writing 0x03. Is that the same as entering at 3? For example, for the stop bit I just typed in a 3.

Also thanks for helping, everyone. You guys rock.

Edit: Baud rate and all that matches. I can communicate with the controller fine using some software given to me by Agilent.

[chembo]

Well, 3 is the same in decimal or hexadecimal. Since all numbers in the users manual of this device are shown in hexadecimal, I was writing also the 3 as 0x03, which is usually how hexadecimal numbers are shown in text. It is also always a good idea to show the radix of constants (right click/Visible Items/Radix) so that you make sure that your 80 is really an 0x80 and not decimal, which will be 0x50.

You say the the baud rate matches. Is it 9600. The default value of the 'config serial port' is 9600. I would set explicit baud rate, bits, etc...

[Eric1977]

Are you sure your BAUD, DATA, STOP, PARITY, and FLOW CONTROL settings are the same as your device? From your screen shot, your using the default settings - 9600, 8, 1, None, None.

Edit: Chembo beat me to it.

[super_strong_dragons_n_stuff]

---

@chembo wrote:

Well, 3 is the same in decimal or hexadecimal. Since all numbers in the users manual of this device are shown in hexadecimal, I was writing also the 3 as 0x03, which is usually how hexadecimal numbers are shown in text. It is also always a good idea to show the radix of constants (right click/Visible Items/Radix) so that you make sure that your 80 is really an 0x80 and not decimal, which will be 0x50.

You say the the baud rate matches. Is it 9600. The default value of the 'config serial port' is 9600. I would set explicit baud rate, bits, etc...

---

All this stuff matches. The specs are at the very start of this thread. The baud rate is programmable, but I've double checked it is at 9600.

[chembo]

If the configuration of the serial port is correct and your checksum is 0x38 0x34 (I am calculating it as 0x84), then I don't see anything wrong.

Did you try to debug with NI IO Trace. Check it out. It will show you exactly what is going in/out at the serial port. It is located in the Windows start menu (if you are using Windows OS) / National Instruments / NI IO Trace

[jamiva]

chembo is correct. The CRC is calculated as 0x84. The protocol states the CRC is "hexadecimal coded and indicated by two ASCII charaters". So the checksum is appended to your command syntax as 0x38 0x34. You command should look like:

[super_strong_dragons_n_stuff]

I don't see how you got 84, probably because I'm not doing the XOR correctly.

I just got off the phone with one of the controller technicians, and he told me I would need to create a LabVIEW driver since there isn't one in the NI library of drivers. Does this sound like it could be the source of my issues? I have a different device that I communicate with through serial and it didn't require any drivers, so I'm curious if this is a device specific issue.

What do you guys think?

[Dennis_Knutson]

A LabVIEW instrument driver is nothing more than a series of VIs and it is basically what you are writing now.