First tests of the Isolated IO boards from http://raspihats.com/ This is the 6 in/out module featuring 6 relay isolated outputs and 6 opto isolated inputs. 3 Boards are currently being produced. A relay output board, an isolated input board and the mixed board shown here.

I’ve connected it here to a system under test to simulate a PLC interface for verification. The Raspberry PI is pretending to do the PLC handshake with our equipment to verify its all working to specification.

Taking to the board from the Raspberry PI is exceeding easy, for a start its a HAT module so supports the auto set up that newer PIs support. The only thing you need to do is enable the PIs I2C from the rasp-config tool (see here https://www.raspberrypi.org/documentation/configuration/raspi-config.md)

After I2C is enabled ensure you have the following packages installed via apt-get

sudo apt-get install python-smbus python-pip

then using pip install the raspihats package

sudo pip install raspihats

If you want a video walk through of the setup you can find one below :-

And here is my python test script simulating some of the PLC. The pupose of this script is to simulate some exteral hardware they we do not have to test the machine against. The particular handshake is defined by our specifications but it shows how easy a test script can be written and the RaspiHats modules used

from raspihats.i2c_hats import Di6Rly6
from time import sleep
import time

board = Di6Rly6(0x60)

#force reset

board.do_set_state(3,1)
sleep(1)
board.do_set_state(3,0)

board.do_set_state(4,1)
board.do_set_state(5,0)
#board.do_set_state(7,1) # only 6 relays this is forced 0


while (1):
 sleep(1)

print("Waiting for ready signal")
 #wait for ready signal
 while(board.di_get_state(0)==0):
 print("Not ready")
 time.sleep(1)

print("system is ready")
 print(" .. Moving head to load position and requesting vac")

board.do_set_state(0,1) # req vac

#wait for vac on signal
 while(board.di_get_state(2)==0):
 #do nothing
 time.sleep(1)

print("VAC on requesting a cal cycle")

board.do_set_state(2,1) # req cal cycle


 #wait for done signal
 while(board.di_get_state(1)==0):
 #do nothing
 time.sleep(1)

#read passfail

if board.di_get_state(5)==1:
 print("** ITS A PASS **")
 else:
 print("** ITS A FAIL **")


 board.do_set_state(2,0) # clear cal cycle request

print("robot head in position, signal vac off")

#move head and turn on robot vac then say our vac is on by deasserting vac req signal
 board.do_set_state(0,0)

print("waiting for vac off comfirm")

#wait for vac off signal
 while(board.di_get_state(2)==1):
 #do nothing
 time.sleep(1)

print("Cycle complete")

#loop around and wait for ready signal

I wanted to hook a Raspberry PI into a CanOpen network and have it as a slave device, mainly for logging purposes. I had previously identified CanFestival  as a potential CanOpen stack to be used for this project as it describes itsself as “CanFestival focuses on providing an ANSI-C platform independent CANOpen® stack that can be built as master or slave nodes on PCs, Real-time IPCs, and Microcontrollers” so that is sounding promising.

The other potential stack I had considered was CanOpenNode, this stack wins hands down for implementing on a PIC32/24 as it pretty much works out of the box on those platforms. The devil is always in the details and in this case the detail is the driver, or how the stack connects to the actual can hardware. Both stacks have certain “drivers” that allow them to interface to the host, both stacks as C implementations that just seem to work. But the winner was CanFestival supported socket_can.

Socket_can is an implementation of can using unix sockets, this might not seem like a big deal, but its very efficient. Sockets have built in queuing mechanisms and expose them selves to usespace in a nice friendly way. Through put is not going to be an issue. Other CAN systems use character devices, eg they emulate a serial port and you talk one byte at a time to the character device. This is inefficient and has no queuing, so on busy networks things could go wrong.

The hardware selected was the PICAN board from SK Pang (UK Supplier). Quick delivery, the board arrived next day and I was excited to start playing with it. I am using a Raspberry PI 2 and there are slight differences between the 1 and 2 when setting up the drivers on the PI (hint PI2 is much improved)

Complete instructions can be found on SK Pang’s blog but the TLDR; version is in raspi-config, advanced -> turn on SPI. then add to /boot/config.txt the following

dtoverlay=mcp2515-can0-overlay,oscillator=16000000,interrupt=25
dtoverlay=spi-bcm2835-overlay

Thats it, a reboot later everything should be good the correct kernel modules will load at boot and the can interface will be ready to go.

CanFestival

The purpose of this was CanOpen not just raw can so lets proceed with Festival, we will do this on the raspberry PI as it should be ready to go with code compiling and will save the hassle of a cross compile setup for such a trivial thing.

Download the source code from http://dev.automforge.net/CanFestival-3/ , you can check out the code as a Mecurial repository, or if you don’t know what that is, just download the latest source from http://dev.automforge.net/CanFestival-3/archive/tip.tar.bz2 which will get the latest code as a tar ball with bz2 compression.

wget http://dev.automforge.net/CanFestival-3/archive/tip.tar.bz2
Unpack the code
tar -xvjf tip.tar.bz2
Change directory to move into the source tree, Note at the time of writing the tip ID was 8bfe0ac00cdb when you do this it may have changed so just cd into the folder just unpacked which will be named CanFestival-3-?????????????
cd CanFestival-3-8bfe0ac00cdb
Now configure and build the code
./configure --arch=armv6 --target=unix --can=socket
make
sudo make install

So thats good to go at this point and you should be able to test, an annoying niggle is that the can interface needs to be brought up with the “link” command, i am sure this can be fixed in festival but as it stands out of the box to run the first thing you need to do is :-

sudo /sbin/ip link set can0 up type can bitrate 500000
CanOpenShell load#libcanfestival_can_socket.so,can0,500k,1,1
Where the paramaters for load are library name, can channel, bitrate, nodeID and master(1)/slave(0)

If CanOpenShell starts correctly you should see

 Node_initialisation
Note_preOperational

at this point press enter

You can then sent NMT commands with the ssta/ssto/srst/scan commands eg ssta#0 start all nodes, and you can read and write SDOs with the rsdo and wsdo commands
so you can talk to other CanOpen devices and prove you have a working network.

Creating a node with festival

So how do you actually use festival to do something real? The best example to start with and the simplest is in examples/SillySlave and is a very basic demo of a CanOpen slave on the network. Of cause sillyslave didn’t compile out of the box with the rest of festival and to get it to work do the following, firsty move to the /examples/sillyslave directory and edit the Makefile( eg use nano Makefile -c) on line 42 go to the very end and remove “-lcanlib”

Next you also need to edit main.h and change the following defines in the section marked “Please tune the following defines to suit your needs:”

#define NODE_MASTER 0x1
#define NODE_SLAVE 0x40
#define DRIVER_LIBRARY "libcanfestival_can_socket.so"
#define BAUDRATE 500
#define BUS 0


Next you need to build as follows :-
make mrproper
make

This is important as the SillySlave.c file is out of date and old and needs to be regenerated, only the mrproper target will remove it, not just make make all or clean. What it actually does is generate SillySlave.c from an XML representation of the object dictionay and using another tool this can be converted to/from the EDS/electronic data sheet files that is part of the CanOpen standard.

To run the sample just do :-

./SillySlave


If you have another can node, you can start/stop the node with NMT commands, and it will send a PDO for every SYNC it receives.

The important thing to take home here is main.c is trivial, its the minimum needed to start up the application, SillySlave.c is machine generated and this is the goodness of the object dictionary and how you configure the main parts of your node.

Creating an object dictionary with festival

So the time has come to make the Sillyslave something real, your friend in this process is the objdicteditor tool, which is a python tool

You need to run this from a GUI, either the PI’s X windows or another system (even windows) with python and python wx installed. Lets assume you are using the PI still. Firstly ensure you have the wx widgets for python
sudo apt-get install python-wxtools
Then change to X windows and use a keyboard and mouse to continue
Open a terminal window and CD to the directory containing the canfestival source, then cd into the objdictgen directory and do the following python objdictedit.py Then if you go to File->Open abd browse to the examples/SillySlave directory and open SillySlave.od you can edit the object dictionary from a nice GUI with ease, any changes you make if you save them back to the od file you can then build this into the slave by following the previous steps to build sillyslave with your new changes.

A few finishing words

Sillyslave is very basic, the bare minimum and really the defines for the nodeid and the bitrate are wrong and these should be read from the object dictionary directly. If you need to add more advanced functionality CanFestival has callback hooks which can be used, but i leave developing a real application as an exercise for you to do on your own as this is where the business end of what ever you are trying to do actually starts now all the boiler plate is taken care of.