Kristof is correct, but to elaborate a little more:
When communicating with RS232 you simply have two endpoints, your PC and external device. You communicate with the device by sending it commands, or it may even send them regardless. It may be simple ASCII text or binary/hex codes. The way it communicates between the two devices is known as the protocol - and your application must implement this protocol to be able to 'talk' to the device.
RS485 is different than RS232, in that you can daisy chain multiple devices on the same serial port that is connected to your PC. Depending on your device it will have its own protocol that it understands which you will need to study and become familiar. This should be supplied with the devices you are connecting to.
Typically, the protocol will have (at least) the following information:
- Device Address - it uses this to distinguish which device you wish to talk to, usually can be set by hardware toggle switches or the like
- Command - the actual command that you wish to send to the unit
- Data - Any extra data you may need to pass for specific commands
So, an example command you might send to the unit will look like (note this is only an example):
$01FF9A
Where:
01
is the module or devices unique address
FF
is the command type
9A
is the data
So here, the module with device address 01
will read the command and deduce 'hey you are talking to me' and then process the command information. All other devices will also receive the data, but will realise that it is not destined for itself.
Usually RS485 devices communicate using Hex data, so your application will need to send hex commands to the external devices, and handle the conversion to from for any relevant responses etc. You may need to look at Serial.Write(byte[], int,int)
to send hex data to the devices.
For a more detailed explanation of .NET serial port class, refer to http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.aspx