Thanks again for your reply! Baud rate, parity etc. are correct (I can read manually back these settings from my device).
How can I check if I need a null modem or straight through cable?
How can I confirm that I send the carriage return, the line feed and the escape – how do I have to set this in my program?
Sorry for asking such perhaps stupid questions – so far I had seldom big LabVIEW problems, but since the RS232 interface is totally unknown to me, I really need detailed help.
You have not mentioned which model of balance you have. One manual I checked has a very nice cable diagram and complete specifications on the RS-232 protocol. It uses somewhat unusual factory settings: Odd parity and hardware handshake.
It is quite easy to verify the string being sent. Just wire a string indicator to the write buffer input to the VISA Write. Set the display style to '\' Codes Display or Hex Display.
Thanks johnsold, I adapted my program as you suggested – but still no data.
The model is: Sartorius E 12000S (e.g. here is a short manual: http://www.sartorius-lab.net/uploads/1/0/6/2/10629561/e5500s_e8100p_e12000s_instructions.pdf). And yes, it uses odd parity (as set in my program). But I cannot judge if this is an unusual setting since this is my first RS232 interface (and at the moment I hope it will be the last).
Regarding the cable: In the manual is written which pin is used and if I understand my 25-pin (device connection) to 9-pin adaptor (at my USB adaptor) correctly, it should work fine.
Perhaps after some hours of sleep I will find with the support of you/the forum members a solution (perhaps the model number is of help for you).
Anyway, thank you so far for all your efforts!
I was not able to find a more detailed manual for this balance in the internet (I fear it is too old); I have the manuals in print form.
But I found a manual which is very similar to my one:
E.g. the general specifications are on p. 55. Here it differs slightly from my manual:
Standard: I have additionally RS423
Handshake: I only have CTS and DTR (and nowhere in my manual is mentioned if and how this can be changed)
Transmission rates: my maximum is 9600 baud
Synchronization: I have 1 stop bit
Data output: I have 22 characters.
On p.60 you can find the data input formats and on p. 61 you can find the command ESC P CR LF which I have to use to get data of my balance.
The pin assignment is on p. 66, but this differs a lot from my one.
I will try to find a manual of my device in the internet. If I do not find one, I could scan in the relevant parts of my manual.
Might be a stupid idea but have you tried to send an uppercase P instead of the lowercase p? If it is an old device, its interpreter may not account for case insensitive commands.
Other than that, going from your VI in your post 8 I don't see any other reason that it won't work if cabling and serial port settings are ok, which of course is hard to check without at least some basic RS-232 tester such as a breakout box with LEDs that show the physical states of the lines.
Thank you for this hint – I tried to use P and p but this has no effect.
But it is good to know that such an experienced user as you thinks that my vi should work.
Due to the responses here, I think at the moment that I do something wrong with the device itself.
So, tomorrow I will meet a guy who has used this balance successfully together with a computer (decades ago ;-).
I will keep you up to date when I have new information!
I usually use something like this for testing serial port connections. It shows with LEDs the logical state of each line and allows easy detection of cabling problems such as swapped data lines or wrong use of handshake lines. It also allows to rewire the lines individually so you can easily test various forms of wiring schemes other than the one-to-one connection. Another more simple solution looks like this here. It does show the state of the LEDs but doesn't allow to rewire the connections.
One inside joke is that RS-232 is an acronyme for "resolder pin 2 to 3 and vv."
The manual you posted clearly states that the commands are case sensitive (pg 61).
Have you tried the Automatic Data Output mode, also known as auto print? In that mode it should sned data continually. It would ease the troubleshooting process on your receiving end.