Controllers
C9 CONTROLLER
The C9 System Controller is an interface between the computer and numerous N9 modules. The C9 Controller has the following features:
SYSTEM OVERVIEW
The C9 Controller connects to a PC either directly, with a USB FTDI to RS485 cable assembly, or to another controller already on the controller network. When connecting to another controller already on the network, continue the daisy chain configuration with an 0.5 m M8 cable.
The C9 Controller is designed to be the hub of a single platform system. It controls the N9 Robot and additional modules and accessories to enhance workflow automation. In a more complex system, multiple C9 Controllers may work together on the same controller network to interface with all hardware in the system.
CONNECTIONS
One C9 Controller offers the following connections:
PROGRAMMING EXAMPLES
This section provides a quick reference for basic C9 setup and programming commands.
1. CREATING A CONTROLLER OBJECT
Every command sent over the Controller network from the PC to any North Robotics device is sent from a controller object. In an application with a single C9, the controller object can be created using the following commands in the order shown:
When initializing a controller, its address on the Controller network must be provided. This argument may be passed as either a character, an integer between 1 and 255 (inclusive), or a byte. Controller addresses typically start from "A" (65, as a decimal). The first controller initialized can optionally provide the keyword argument network_serial which specifies the exact device number a serial connection should be opened on. If this argument is not passed, the software will open a connection on the first D2XX device it finds.
If the device found is not the Controller network USB plug, the connection will fail. To determine the device serial number, navigate Tools > List Device Serials in the NorthIDE. If not using the IDE, use:
If multiple controllers are used on the network, only one serial connection should be created. Subsequent initialized controllers should be passed on the existing network object with the network keyword argument. Consider this example in which two C9 Controllers are initialized on the same network:
NOTE: The NorthC9 class can be used to create controller objects for all types of controllers, such as T8s, not just C9s.
2. TESTING CONTROLLER CONNECTIVITY
The get_info() command is used as a ping to test whether or not the controller has connectivity and can be used to verify the controller’s address.
3. CHANGING CONTROLLER ADDRESS
To change a controller's known address (e.g., address "A"), use the following code:
After a hard restart of the device (leave power off for at least five seconds), the following should succeed:
If you don’t know the controller's address, use the set_c9_addr(...) command to broadcast a new address. First, power off any other controllers on the network.
NOTE: Any other controllers on the network that are powered on during this operation will also take on the broadcasted address.
Run the following code:
Restart the device and test connectivity with the new address.
4. UPDATE MOTOR CONFIG FILE
Motor Config files are .txt files prepared by North Robotics. They are uploaded to the Axis Motor Drivers inside the C9 Controller to match the drive to the module it is to control. If the module connected to an axis is changed, that axis' Motor Config file will change as well. North Robotics will send the appropriate Motor Config files with new modules.
To upload a new Motor Config file, use a USB Micro-B cable to connect the corresponding axis' Update Port on the Controller Rear Panel to the PC. The Motor Driver appears on the PC as a Removable USB Device containing the following three files:
CFG.txt
INFO?
VMMCODE.USR
Remove CFG.txt and replace it with the new Motor Config file. Rename the new file to ‘CFG.txt.’ Restart the controller.
5. TOGGLE DIGITAL OUTPUTS
Twenty-four (24) Digital Outputs OUT0 through OUT23 are controlled using the set_output(...) command. This command allows the user to turn an output channel on or off:
The first argument is the Digital Output number. For the C9 Controller, valid inputs are 0-23 (0-5 are connected directly to air, the others are exposed as signals on the Front Panel of the controller). The second argument is the Boolean value the channel should take:
True sets the output high (on)
False sets the output low (off)
NOTE: Python interprets any non-zero value as True, so c9.set_output(2, 1) would turn on output 2, while c9.set_output(3, 0) would turn off output 3.
6. READING DIGITAL OUTPUTS
Digital Inputs are labeled IN 0 through IN 15 and can be queried with the get_input(...) command. Inputs IN 0 through IN 3 are used for emergency stops, though their values can still be queried if desired. Due to internal input addressing, the input channel number passed to the get_input(...) command must be increased by a value of 16. For example, to get the value of IN 4, the numeral 20 is used in the parentheses (channel number 4 + 16 = 20):
Value is of type int and will be either 0 or 1.
7. USING ANALOG INPUTS
To read the current output of either AN 0 or AN 1 (the two Texas Instruments ADS1115 ADCs in the C9 Controller), use the get_analog(...) command:
Use the config_analog(...) command to change the configuration of either of the ADCs:
Refer to the API Reference for a full list of valid analog config enumerations in the ADS1115 class.
8. USING COM PORTS
This subsection describes how to send and receive arbitrary byte strings to non-standard devices and to extend the functionality of any partially supported devices.
NOTE: Interfacing with the Syringe Pump and Balance Clamp modules through their NorthC9 API commands (e.g., move_pump(...), read_scale()) on their default COM ports (COM 0 and COM 1, respectively) does not require any of the code in this section. Commands for those specific modules work out of the box.
To configure the baud rate of a COM port:
To send a string of bytes to a COM port:
The send_com_msg(...) command is intended for exchanging short messages with devices that return a response for every message sent. The first argument indicates the target COM port. The second argument is the string (in single quotes) sent in bytes (b). The command will return the response to the sent request within 300 ms or raise a timeout exception. Requests have a maximum length of 128 bytes and responses are limited to 32 bytes.