A good place to start is the CAN over TCP/IP protocol description. This will have everything you need assuming you have a CS2 in your setup.




If you want to drop the CS2 in favour of something cheaper, you can implement something over actual CAN to e much cheaper track connector box. The protocol is basically the same, just a different phy. There's the railuno project that will get you started on the hardware you need. If you want PC control, you can stick with a USB to CAN converter instead of the Arduino.

https://code.google.com/p/railuino/

Copy the tail end of the link into Google (just the file name, not the whole path) and ask Google to find it. This will give you a translate option.

You will then get a page with the english translation but without the pictures, so you need to read it with the German one as well to get the illustrations that it is referring to.

Here are some hints on the basics:

The CS2 uses UDP to talk to devices on Ethernet. You have a broadcast address set up in the CS2 (in the CAN section). The CS2 will not guess the broadcast address from its DHCP address. This tricked me the first couple of times. For my initial tests I created a simple console program that listens in on the CS2 communication, interpret the packages and displays the orders on the screen. I am on Windows, so I used the .NET Framework with C# for this, and I use the System.Net.Sockets.UdpClient class to communicate with the CS2. You can download the development tools (Visual Studio Community Edition) for free from Microsoft (https://www.visualstudio.com/products/visual-studio-community-vs).

Your program must listen for communication on a given port (I think this is 15730). The port numbers cannot be changed. The CS2 will send 13 bytes long packages so you can throw away any other size. You can also have the CS2 communicate directly with your computer by changing the broadcast address to the IP address of your computer. Your program must still behave the same though.

The broadcast type on the CS2 must be set to "broadcast". This is important, as it will ensure that the CS2 relays any event that happens onto the network. Depending on what you are doing with your program, you want this information. If you set it to "auto" it will not send all the information and you will be left in the dark.

The CS2 to listens on port 15731 on the broadcast address of its network. Meaning that you communicate your packages this way (if your network is 192.168.0.1, the CS2 will listen on 192.168.0.255:15731). The CS2 throws away packages that are not 13 bytes in size. It will try to evaluate on any package that fits the pattern in the CAN documentation. It does not always respond to packages received so your program will need to know what to expect. In my program I have an event handler that handles incoming communication separately from the outgoing and knows how to interpret responses and new orders (e.g. an emergency stop).

The byte array is build up from the first bytes which are (roughly put) the order type and response bit, followed by a device id, then a CS2 sub routine id, and finally the order. Look at the packages in the CAN documentation, you will notice that the layout of these packages change with the order type. So your package interpreter and command handler can use this knowledge to change its interpretation model depending on the first two bytes. On some packages the order type must be combined with the CS2 subroutine id. This goes especially for system commands. E.g. if you turn on the CS2 model clock and hit emergency stop, you will receive an emergency stop and a model clock stop frequency 0 command. These two are both system commands, but the subroutine id let you know which is which.

For my test program I wrote a subroutine that builds the byte array to ship on the network. I find it easiest if only one subroutine has the responsibility for this.

Building a program that sends and receives emergency stop and system go commands is an easy way to get started. I would recommend trying that first.

I hope this helps!

You may find it easier to deal with Ethernet, even with an Arduino, or maybe a Rasberry Pi (I know it does have an Ethernet port on it, not sure about the Arduino).

Then you don't need to get acquainted with the priority bits and modes that CAN has.