Problems with VISA...trying to write/read simple command from serial

[Lorenzo!]

Hello!

ok i will explain my problem a little bit more in detail.
the manual of the gas analyser states that i have to write a specific order of bytes to the instrument. this is for example for the function "request date": byte 1: 0x41, byte 2: 0x00, byte 3: ... byte 16: checksum;
i am sending all these bytes in the given order to the serial write vi, and the return count of this function also states that these 16 bytes are sent to the instrument. the response of the instrument should also be a chain of bytes where i could take out the information i need.
 the rest of the vi is the same as in the example " basic serial write and read". the problem is that the serial read does not read any bytes, that is what the read count of the serial read function says. is says 0 bytes read.
i also adapted the serial settings, like baud rate, 1 stop bit, 1 start bit, no parity bit etc.
the manual says that the inter-character time is max 50 ms, and if the instrument is not able to maintain these 50 ms at any time during a response, further transmission for the current response will be stopped. furthermore is states that the user must wait 100 ms between each command sent to the instrument. the timeout for transmitter is 50 ms, the timeout for receiver is 51 ms. the transmission time for one byte is 1.04 ms.
so there is also no error, simply i can not read any data.

i would be very happy if you could help me with my problem!

[Dennis_Knutson]

Well, clearly there is an error in the transmission. Otherwise, you would be be reading something back. The fact that you don't get a LabVIEW error when doing the write is pretty meaningless. There is no verification by LabVIEW of the bytes sent, the com settings, or even if there is anything connected to the serial port. There will be no bytes to be read if the instrument does not get the correct command.

You haven't provided the entire data string, how you calculated the check sum, the name of the instrument, the programming manual, or answered whether you can communicate with a different program, etc. With the VI you are using, enter the data string and then go the the LabVIEW Edit menu and select "Make Current Values Default". Save the VI and post that. Post an electronic copy of the programming manual or a link to it. Double check the type of serial cable you are using. Make sure it is wired the same way that the programming manual describes. You also mention a max inter-character delay. If there is a minimum delay required, you will have to code that into your program.

[Lorenzo!]

ok, i attached the modell and the manuel for requesting the calibration data. the implementation of the bytes to be send looks a little bit confusing, but it should fulfill its purpose. hopefully u can find an error i have made. the cable is working perfectly. attached to the instrument was a demo software, and with this software the instrument is working perfectly. thank u very much for ur help

[Dennis_Knutson]

The creation of the data is pretty convoluted and could be much simpler. I don't have much time to really look at it right now but I did create an indicator at the input to the VISA Write and it appears you are sending 14 bytes. The document you attached seems to imply 16 bytes should be sent. There could be a mistake in the checksums you are calculating. A thread that you might want ot look through is http://forums.ni.com/ni/board/message?board.id=170&thread.id=262115&view=by_date_ascending&page=1.

If you have an example of a complete data string from the vendor, you could use a single string control set to hex display and test that. You could also use a program like portmon to monitor the vendors program and try to duplicate the data that is being sent by that.

[RavensFan]

Your attached Excel file doesn't list anything for bytes 13 and 14.  Maybe they are the missing 2 bytes.

[Lorenzo!]

sorry there was a mistake in the manual, I corrected it and the right one u can find attached. I know the modell is quite complicated but if u probe the data flow which is send to the wisa write the bytes should be all right, thats at least what I suppose according to the instructions in the manual... !?! is there perhaps any error when i calculate the checksum or the checksum of the SABus data? Thank u very much if u could give me again some useful hints!

[RavensFan]

Everything in the output looks good in bytes 1 to 12.  In other words they seem to be in the right order and XOR'ed okay as compared to the excel sheet.

A few things raise questions for me though.

1.  Bytes 3 and 4 are the length of the SABus and have a value of 7, what portion is the SABus, bytes 5-12 are 8 bytes.  Perhaps n is 4?

2.  The checksum is the sum of bytes 1 through 2*n+4.  N=7, so 2*n+4 would equal 18, but the bytes go up to byte 12 (w/o the checksum) and only 14 if you count it. 

3.  Are you sure that the checksum is a single byte duplicated?  You are taking the sum, casting it to a single byte, then repeating it.  Nothing implies that to me.  Perhaps it should be cast to a U16.

4.  It seems unusual to have a checksum within a checksum.  There is byte 11 as a checksum, then later bytes 13 and 14 to wrapup all the other bytes.  Not necessarily a problem here, it just seems odd.

After reviewing my list, I think the real problem lies in either #1 or #3, or both.

[Lorenzo!]

---

@Ravens Fan wrote:

Everything in the output looks good in bytes 1 to 12. In other words they seem to be in the right order and XOR'ed okay as compared to the excel sheet.

A few things raise questions for me though.

1. Bytes 3 and 4 are the length of the SABus and have a value of 7, what portion is the SABus, bytes 5-12 are 8 bytes. Perhaps n is 4?

2. The checksum is the sum of bytes 1 through 2*n+4. N=7, so 2*n+4 would equal 18, but the bytes go up to byte 12 (w/o the checksum) and only 14 if you count it.

3. Are you sure that the checksum is a single byte duplicated? You are taking the sum, casting it to a single byte, then repeating it. Nothing implies that to me. Perhaps it should be cast to a U16.

4. It seems unusual to have a checksum within a checksum. There is byte 11 as a checksum, then later bytes 13 and 14 to wrapup all the other bytes. Not necessarily a problem here, it just seems odd.

After reviewing my list, I think the real problem lies in either #1 or #3, or both.

---

Hello! Thank u very much for your help. I can't test it now, because the instrument had to be sent back, but I also think that point 3 was a main mistake. Furthermore I don't understand the following: 1: Byte 2 says I can choose between Normal mode and Lengthy mode. The manual only says that the first request must always be Normal, but was happens to the rest? Should I change to lengthy or stay in normal mode? The manual says the following: "Use the process command in the lengthy mode to determine when the command is completed. if the command is completed the data are returned. SABus data are available until the pending command is issued in the lengthy mode or another command is issued. NOTE: a lengthy command handler should be implemented. During pending command, only the following commands will be processed: lengthy request of pending command" I also attached the diagram of the command handler. What does that mean to me and what should I implement? 2: When getting the response, Bytes 10-13 are the requested data from the instrument. They are in the format IEEE float. What I want to do is display this data in a diagramm "requested data (y-axis) vs. time (x-axis)". To do this, first I have to pick out the Bytes number 10-13, and then I want to display them. How can I display them? Do I first have to change the format? I would be very happy if u could help me with my problems. Thank u very much in advance Lorenzo

[Rimasaurus]

Hi Lorenzo,

To display bytes 10-13, you can place them in an array and wire the array to a waveform.  Since they are in the IEEE float format, you shouldn't have any problems placing them in the array.

Regards,

Rima

[Lorenzo!]

Hello!
My program is still not running and I am quite confused at the moment.
First of all, the instrument is receiving the right data that I am sending, I checked through an osciloscope! But there is no answer! No Bytes are received, although the instrument should answer even though I send a wrong bit order etc. So I think there is a problem with VISA read, what do you think? Is it helpful to flush the buffer everytime before writing? Or only allow VISA read to read if there are bytes on the channel? Another engineer gave me the hint that this instrument uses hardware handshake (CTS/RTS), and I have to make use of that? How can I implement this, or is this automatic? Another possible reason could be the timeout I set before writing and reading? Could that be?
 I have attached my vi and the manual.
Thank you very much if anyone could help me
Lorenzo