This 'network configuration' window allows you to define the hardware that connects your railway to your computer (Windows PC, Mac or Unix workstation), and how that hardware is connected.
The layout is normally connected through RS232 ports on the computer. These connect to various hardware modules, and these connect to various input or output lines. Each RS232 port communicates with its attached hardware using some kind of message protocol. All of these aspects are defined in the network configuration window.
Alternatively devices may be connected over ethernet, though at present there are no stack header modules available that use ethernet, but of course you are free to design your own. The ethernet support at this stage primarily allows you to write your own software. That software can pretend to be part of a layout, indirectly interface to currently unsupported hardware, or act as some kind of user interface not presently supported by Tcc.
This window is organised as a tree, similar to the display that Windows Explorer or the Macintosh Finder sometimes uses to show the tree of nested files and folders in a Disk. Each 'folder' icon has a small icon to its left. Clicking on this expand icon will open (expand) or close (collapse) the folder.
The left-most icon, at the top of the window is the root of the tree and can be likened to the 'My Computer' icon in windows. Inside this folder is another folder for each interface connecting to your layout, and a folder for each stack of hardware modules on your layout.
Most of the items in the network configuration tree are popup menus. Pressing or clicking on one gives a list of options. For example the top-left-most item (labelled 'New interface') gives a popup allowing you to define a new serial interface, ethernet interface, merg stack or CTI stack.
To open the network configuration window use Menu:Configure->Networks...
Earlier versions of Tcc used to only list (serial) interfaces under the root of the tree, with stacks being inside each interface. These are now separated for the following reasons:
Pressing the New interface box (point at the box and hold down the mouse) brings up a popup menu listing the supported interface types. Select "Serial" from this menu creates an interface folder for a new serial interface.
In the same way that the New Interface box brought up a menu of options, each interface and stack does likewise. Its menu allows you to start and stop the stack or interface, and also to rename or delete it.
Using the rename option you can set the name of a stack or interface can be anything you wish and is just as a reminder of which is which.
The delete option removes the interface (or stack). There is no undo cabability in Tcc, so take care.
If you click on the expand icon (the small icon to the left of the interface box, the appearance is system dependant), then you can see the settings associated with the serial interface you have just ceated.
Firstly you need to define which physical port you are connecting to, so the "Interface" button allows you to select from the available serial ports (if you have any!).
All serial interfaces need a baud rate, number of data bits (normally 8) and number of stop bits. The choices available will depend upon which protocols have been associated with this interface. More of this when we create a stack.
A serial interface works by sending a message to a connected stack, then waiting for a response to be received. The interface can only be waiting for the response to one message at a time. If a message is corrupted or lost (perhaps the stack has lost power) then a mechanism is required to allow the interface to recover.
This means that a serial interface needs a timeout parameter. This limits the time that Tcc will wait for a response. If no response is received after the timeout period has passed then Tcc will give up and send another message.
The timeout parameter is measured in milliseconds.
There are two main factors here:
The message turn around time is simple:
Number of bytes * 10 / baudrateis the time it takes for your message to be sent. Note that the number of bytes should include headers and checksums, so just add 5 to the larger of the number of output bytes or input bytes (CTI stacks are different - normally one byte per module).
For half duplex stack headers like the RPI-C double this time and add a bit for processing. Full duplex headers do not need any extra.
The operating system delay time is much more unpredictable. Operating systems execute several programs at once by sharing CPU time using some kind of scheduling algorithm. If another program (such as a virus checker, or disk defragmenter) needs to run it can stop Tcc for some period of time (from a few milliseconds to a few seconds). Also if there isn't enough memory for that other program to run in, then part of Tcc will be pushed to disk, the other program takes its share and then Tcc is restored from disk.
If Tcc needs to load an image (the script executes the $Load Image command) it hasn't used before then the disk access might interrupt serial comms.
All these delays are very operating system dependant. From experience (and theory) these can be listed from 'best' (lowest expected delays) to 'worst' as:
Using the "New interface" button (top-left box in the window) allows you to create either a Merg stack, or a CTI stack. These are only different in the choices of modules and stack headers used.
Again the stacks own menu allows strat, stop, rename and delete, just the same as for interfaces. You can rename your stack to perhaps reflect its location on the layout.
Each stack consists of a bunch of modules (of the appropriate kind). These are added with the "New Module" button.
The first module listed in a stack is the one closest to the stack header (or computer port for CTI). You can drag them around to resequence them if necessary.
Each Merg stack is connected to the interface via a stack header. This is selected by the "Protocol" button - this tells Tcc how to format the data in a manner that the stack header will understand.
In order to use a stack it needs to be associated with an interface. the "Interface" button allows you to select between the currently listed interfaces (Serial and Ethernet). You need to create the interface before you can connect a stack to it.
Several stacks can be connected to one interface at once. You can use several RS485 RPICs on one interface, or several QTUs. No check is made that the combination is viable however. Connecting an RPIC and a CTI to one serial port won't work (nor can you do it electrically!). Other combinations may or may not work.
Each stack has a "Preferred rate" parameter. This is the number of messages per second it wants to send. Naturally if you set it too high so that the interface cannot support the data rate then it won't go as fast as you say.
The preferred rate can be used to slow down a stack, or to make one stack on an interface run faster than another.
For manually driven layouts a rate of 2 or 3 messages per second might be enough (but also consider input filtering).
For a layout with computer driven trains you might want 10 messages per second.
The final entry in the stack menu is Trace Messages. This causes the next few messages sent and received to be displayed in the Log window.
The format in this log of messages transmitted is the word "Send" followed by a number, and then the message bytes listed in hexadecimal. The message listing includes normal prefixes and suffixes (but not the long string of zeroes associated with CTI messages). The number after the word "Send" is either the message number (incremented each time a message is transmitted), or a plus sign ('+') followed by the number of milliseconds since the previous message. The message number is shown if the previous message logged was NOT immediately prior to the new one.
The format of received messages is the word "Rcvd:" followed by the hexadacimal listing of the received message. If the message doesn't decode correctly then the word "Rcvd" is replaced by "RxBad". If no message is received on a serial port then the word "Timeout" is shown (with no hexadecimal listing of course!).
Press the New interface box and select ethernet from the popup menu.
All ethernet ports use whatever ethernet socket on your computer that they need to use, so we don't have to worry about that, so even if your computer has several ethernet sockets (which is unlikely) you don't need to choose one.
Our ethernet interface configuration starts with defining which machine we are talking to. This remote machine name can be a name (if you have some kind of name service setup with a name given to your target machine, then you can enter the name), or just a plain IP address (of the form nn.nn.nn.nn where each nn is a decimal number between 0 and 255). We consider that all the stacks 'attached' to this interface are on this defined machine. If you want to communicate with some other software on the same machine then leave the box blank, enter "localhost" or the address 127.0.0.1
The model railway interface software at the far end is a 'service', in the same way that ftp (file transfer protocol) and telnet (a remote login capability) are services. Each service has a port number. The transmit port number should be the number of the UDP port that the remote software is listening to (and therefore what Tcc should send to).
The receiving port tells Tcc which port it should listen to, for receiving responses.
If the two ends of the connection are on different computers both numbers can be the same, but if you want Tcc to talk to some other software on the same computer then they each need to listen to different ports. This is only the same as saying if you wanted to connect two pieces of software on the same machine over a serial cable (a null-modem cable) then the two serial ports must obviously be different, perhaps COM1 and COM2. If you were connecting two computers this way they could (but don't have to) be COM1.
Attach stacks to an ethernet interface in the same way you would attach stacks to a serial interface (described above).
Note that the stack addresses at each end must be the same for data to be transferred successfully. If using two copies of Tcc you could define several stacks at each end that attach to the same ethernet interface, and the output data from stack 1 at one end would be transferred to the input data of stack 1 at the other end, and vise-versa. Ditto with stack 2, stack 3 etc.
Why would you want to attach several stacks to one interface? Well if the other end were actually interfacing to real stacks by some other means then it makes good sense.
Why is there no timeout parameter for ethernet interfaces?
A serial interface can only carry one message at a time, and if we try to send a message at the same time that a response was arriving then things are likely to go wrong. So for those protocols that are half duplex (primarily the RPIC protocol) we sit and wait for a response before sending another message.
Ethernet on the other hand is so fast that it would be possible to send messages to half a dozen stacks really quickly, and then wait for the responses to come back. The collision detect and retry mechanism in ethernet makes this a quite normal thing to do.
In fact Tcc handles ethernet interfaces quite differently. It sends packets for each stack, at the preferred rate for each stack. This is totally independant of any replies. Replies that are received are routed to the stack they are for (by looking at the address field of the ethernet prefix). This means that you can have output data running at a different repeat rate to input data.
If the other end of the ethernet link is some software that puts the data onto a serial link, then that software should implement timeouts to protect the serial link itself. It can pass back replies whenever it has one, and ignore output data that it cannot handle (if it gets too much).
Starting a stack means that Tcc starts sending messages to that one stack. If its interface is not already started then it is started, for just the one stack.
Stopping a stack stops messages to that one stack, also stopping its interface if no other stack is using it.
If instead of stopping a stack, you stop an interface then naturally all the stacks using that interface must stop receiving messages. The stacks only change state to stopped if all the stacks on the interface were running. This allows you to control an interface without switching all of its stacks if you just want to use some of them.
Starting a stack that has no stacks already marked as running will cause all its stacks to become started.
Starting a stack which has some stacks already marked as started will resume operation on that set, and leave the others stopped.
The main menu items Configure->Start Network and Configure->Stop Network are the same as selecting Start or Stop for each interface in turn. This means that starting Tcc and then selecting Start Network will cause all stacks on all interfaces to start operating.
There is one way is which the menus Configure->Start Network differ from selecting Start: If (and only if) the network is started using the Configure menu and Tcc is shut down with the network running, then next time Tcc is started (with the same script) the network will automatically restart. The reason it differs in the Network Configuratin window is that those controls are more normally used for debugging, rather than simply starting an operating session.
http://www.cti-electronics.com make ready assembled hardware modules for connecting to your railway. The individual modules are listed here. They connect directly to the RS232 port in a daisy chained manner. The only interface adaptor required is a connector block supplied with the starter kit.
CTI modules run at 9600 baud full duplex (messages are received at the same
time as they are sent, but message rates are as if it were half-duplex).
RPC modules are available to MERG members as self-assembly kits. The RPI-C kit is a PIC-based microcontroller that functions as a stack header. It is available as RS232 (one stack per serial port), RS485 (multiple stacks, but you need an RS485 buffer for the PC) and USB (not supported by Tcc).
The RPI-C used to run only at 9600 baud, but a newer version can also do
faster rates (selected by DIL-switch).
Half duplex is used (the RPI-C receives the whole message before
processing it and then responding).
The RPI-Z is my own creation and consists only of a small AVR microcontroller
and an RS232 buffer. It runs at 9600 baud full duplex (responses are sent at
the same time as commands from the computer).
It runs at 9600, 19200, 38400 baud (auto-select), full-duplex (it responds at the same time as a message is being received).
You might decide that the top few bits define which 'page' of data is being sent and the hardware module will save the bottom bits according to the value of the top bits. The top bits must be assigned by your TCL script - all the MUX module does is send each value in turn repeatedly.
To define how many values are being sent include that number of entries in the Controls: section and define them to be zero bits wide (put :0 after the name). They are zero bits wide because individually they consume no stack space at all. Despite being declared as zero bits wide (meaning send no bits of that data to the stack) these control values can still store the normal 32 bits of data value each.
To define how many bytes of stack receive the multiplexed values open the MUX module in the Network Config window and select byte count from 1, 2, 3 or 4 bytes (TCL variables are 32 bits wide so you cannot send values bigger than that).
To make some value transmit more frequently than others simply store them multiple times in your list of values, spaced out in the list.
If your hardware wants some fixed and some multiplexed data you can intermingle DPR (1 byte) or SRO4 (4 byte) modules with MUX modules in your Network Config.
Prefix Protocol and interface dependant fields Header Protocol dependant Data Module dependant data Suffix Protocol dependant checksum
byte 1 0xAA byte 2 0x55
byte 1 0x55
byte 1 0x41
We receive zeroes from the hardware until the outgoing prefix (0x41, letter 'A') has shifted all the way around the loop.
bytes 1..n zeroes byte n+1 0x41
byte 1 Address Stack address byte 2 Command Always 0 at present byte 3 FSN Forward sequence number
increments with each messagebyte 4 BSN Backward sequence number: same as
FSN of previously received message
byte 1 add+type stack address (4 bits)
and message type (4 '0' bits)byte 2 length length of data+2
byte 1 address stack address
byte 1 address stack address
byte 2 length length of data+2
byte 1 0x00 index to data
byte 1 length length of data
byte 1 checksum
byte 1 checksum
Last updated 23/04/11
© Howard Amos. 2005-2011