hex over tcp?

[DougFerguson]

Since NI has dropped the ENET-232/4 we have had to look else where to handle our serial communication. I am testing a B&B Electronics VERSR4x4 and 2 out of our 3 instruments use ASCII strings with termination characters. This was easy to swap the VISA functions over to TCP. However one of instruments uses hex packets. With VISA the U8 array was type cast to a string and sent via VISA Write no problem. I captured the network traffic and the data packet was 23 characters. I don't know why but VISA sandwiches the data with a bunch of other hex numbers. However when I swap over to TCP the network traffic only shows the original 5 byte hex data.

The orginal data is 7e 05 ff 19 94

Here is the successful VISA write using a ENET-232/4

Here is the unsuccessful TCP write using the B&B VESR4x4

What gives? I have tried to recreate the VISA traffic by artifically creating the full 23 byte data but it doesn't have an effect. I am not sure where the issue lies.

[DougFerguson]

A loopback test of hex to string data works. So why does the instrument not like the data?

[Frankay]

I'm not exactly sure why this may not be working for you, but I have included some resources below that you may not have seen to give you some scope on your code/troubleshooting.

Send/Receive Hex Data with NI-VISA

If that does not work you will most likely want to extract the development environment software out of the equation and try this in MAX.

Sending Hexadecimal Commands in a VISA Test Panel

-----------

Aaron F.

National Instruments

[DougFerguson]

Just to be clear, I am able to send the HEX via VISA with no issues. The issue is when I send it via TCP. I have gone on to see that with a loopback I can send the HEX->string fine over TCP. But VISA seems to add some beginnging and ending characters that the instruments requires. I can't seem to find who is adding them. The VISA configuration says to add add delimeters so I don't know what the issue it.

Given that the loop back tests with VISA and TCP appear to send and recive the simple 5 byte array, why are the TCP packets as observed in post one so drastically different or am I looking at the wrong there all together?

I have a call into the instrument vendor but I am waiting to hear back.

[Frankay]

I was looking for a driver for your device on www.ni.com/idnet but I wasn't able to find anything, and I wasn't even able to a product page for the B&B Electronics VERSR4x4. Is there anyway B&B could provide example code or a driver for their device?

The other option that comes to mind is to contact our sales department at (888) 280-7645 to see if there is a direct recommended replacement for your ENET232.

-----------

Aaron F.

National Instruments

[DougFerguson]

B&B Serial Server

NI's replacement is a USB version, which isn't suitable for our product.

It turns out that the 5 byte data versus the 23 byte data packet is probably a VISA thing and stripped off by the ENET before going to the instrument. Turns out to not have any bearing on the data reaching the instrument.

I have been able to ascertain that the HEX packet over TCP is reaching the instrument, but the response back from the instrument is not reaching the network after reaching the serial server. I have been able to work with B&B to get this far. I think the solution is in the correct timing of the serial server and not in the TCP/IP read within LabVIEW.