It has been replaced by the ConnectionInformation in current DSPI.
Unfortunately, this doesn't take into consideration a case when a device can have both network and serial connections at the same time :-(.
I, personally, would like to have both. Even though having two channels is a bit complicated, we could use the secondary (serial) connection, for example, to report loosing network connectivity.
Hope this helps,
Properties like BaudRate, IPAddress, and CommandPort are properties contained in the TransportPropertyGroup class. So why isn't SerialPort in the same class?
you can access serialport through PortName field of SerialTransportSettings object.
Below are all fileds of serialtransportsettings:
| Name | Description | |
|---|---|---|
| BaudRate | Gets the serial baud rate. | |
| DataBits | Gets the data bits per byte. | |
| Handshake | Gets the handshaking protocol for the serial port transmission of data. | |
| Parity | Gets the parity. | |
| PortName | Gets the serial port name. | |
| StopBits | Gets the stop bits per byte. | |
| VendorSpecificData | Gets or sets the vendor-specific data.(inherited from TransportSettings) |
I think this is because BaudeRate, IPAddress, CommandPort etc. can be persistent on reader and the Serial Port can NOT.
You can connect/reconnect reader on one serial port or another and there is no way the reader will be aware of which specific COM port number you use on the HOST machine.
Hope this helps,
I was thinking the same thing, and I believe your 2nd answer makes the most sense. All the other properties affect something on the device, while the Serial port does not involve any configuration changes on the device. It used to be part of the properties, and was probably removed for that reason.