Serial I/O system

From uCtrl.net

Contents 1 Information 1.1 Software 1.2 Modules 2 Communication 2.1 Strings 2.2 String types 2.3 Status code

Information

The system works like a serial data bus, every module uses a serial port. But what port is irrelevant as long as the correct module number is connected to the port. Serial Server checks this and gives an error if this is not the case. All modules are identified by a unique address, it consits of three numbers, like 001, 002. It's sent in the beginning of every command string and the module will only respond to this address. Addressing is not really an issue when dealing with serial modules, because the RS-232 only allows two nodes. But in this system all the communication strings are gathered when communicating with Serial Client. The addressing makes it possible for Serial Client to read the different modules apart, and for Serial Server to send the right command to the right module when receiving from client. In the future I hope to use something like a terminal server, but at the moment I manage with a Rocketport 8-port serial interface. The reason that I chose RS-232 as a communication protocol was because of the cost. Interfacing with RS-232 is very cheap, only one device is needed: the MAX202. By using bluetooth it should be possible to make the modules wireless, but I have not tested this.

The brain of the entire system is Serial Server, without it running nothing happens. No triggers or timers work, no analog values are read and no timeout monitoring. So the biggest challenge is to code the Serial Server, it's the bottleneck for any command or action. To make it fast and versatile enough is a major task, that I have not yet quite mastered. The modules have more potential then I use at the moment. Now the system is used for GUI and graphs, but no real automation happens. Serial Server is currently written in Visual Basic, not the best choice. But it started that way and just kinda kept growing, but now my program is having some difficulties keeping up to date when a lot is going on. It's possible to request the status of any in- or output if the server should miss it when it occurs. But Serial Server remains the weakest link.

Software

• Serial Server
• Serial Client
• Mrtg graphs

Modules

• 001 OMU2
• 002 OSID
• 003 OESU
• 004 DEIM
• 005 ASIM

Communication

The protocol is self-made and specifications are as follow:

Strings

Input:

001:i:1:0:154

Module number:i=input:input number:input value:checksum, value can be digital (0/1) or analog (0-999).

Output:

001:o:3:1:132

Module number:o=output:output number:output value:checksum, value can be digital (0/1) or analog (0-255).

Status:

001:s:00:1:165

Module number:s=status:status code:status value:checksum

Set or request:

???:o:01:1 will set output 1 active.
???:o:01   will return the output 1 value.
???:i:01   will return the input 1 value.

String types

• a : Analog value
• e : Event
• i : Input
• o : Output
• s : Status
• ! : Module status

Status code

• 00 : Module booted (not in use on all modules)
• 01 : Lifesignal (sent every 20. second)
• 02 : Brown-out (too low voltage to the AVR controller)