New IP Drivers using drvIpac Module Driver:CANopen Carrier Driver:GPFC drvIpac ?? CANopen Tip810 CAN Tip810 mv162GPFCatc40vipc310vipc616 Module driver Carrier driver Generic driver API is hiding architecture of carrier board from driver

.... CANopen Tip810 putcreatedestroyrequestopenget Application interface can be used by device support or any other (non-)EPICS application. Carrier IP module TIP810 drvIpac carrierDrv i.e. GPFC, 162 Get addresses of module regs Direct access Interrupt initialisation etc. CANopen Driver for Tip810

Features of CANopen driver Data transfer is implemented for CAN/CMS data types Scalar datatypes: signed and unsigned int of any length (1..64 bits long), Boolean. Arrays of scalar types (fits in one CAN message) Structures of scalar‘s and arrays Indexed data types: up to 127 elements of scalar‘s, arrays or structures Support for CANopen minimum bootup CANopen node guarding Reconnect modules Report node and bus status to application (EPICS: Alarms)

Implementation CAN objects are created by an application can be destroyed again, if no other application uses it are either INPUT or OUTPUT objects have a list of one or more (for indexed data types only) mailboxes for data exchange CAN I/O requests tells the driver to update (input) or send (output) the mailbox contents are sent through a set of message queues to the driver are not queued if an old request for that object is still in the queue

Post processing is initialised and registered by the application Registration is implemented as linking into a list can be canceled at any time can be set to „one-shot“ or „repeative“ Not implemented now SDO (Service Data Objects) and everything depending CAL (extended) boot-up Emergency Messages String Data Types (on to-do-list)

Usage of CANopen driver in EPICS EPICS device support is using the same driver functions as internal driver mechanisms i.e. node guarding, startup, test creates a buffer with information for the driver (CAN-ID, post processing function pointers and arguments, etc.) creates a CAN I/O object registers for bus and modul error notifications links it‘s buffer into a list for „one-shot“ or „repeative“ callbacks is starting a timer and sets timeout error if it times out is requesting for the I/O

Examples for EPICS database links 1.: A 16-bit word from a CANopen digital input module (same for output) field CAN1- is the bus name created in the startup script N8- node id is 8 -> it‘s a CANopen node -> the default CAN- ID of the „predefined connection set“ is used, node guarding is enabled The data type 16Bit unsigned is default for the longin-support 2.: The second channel of a 4 channel 16 Bit ADC CANopen module field 3.: A CAN message contains 13 Bit of analog input data and 2 Bits of status in the ai-Record: field in the bi-Record: field the type BOOLEAN is default for bi. The second bit located left of the analog value is read into the bi record.

Differences to Andrews tip810 driver * CANopen drv/devSupdrvTip810/devSup CANopen boot-up CMS data types BOOL, INT, shared objects # bytes and shift Lowest Byte firstReverse (little endian) Node guarding CAN-ID or Node-ID addressing (CANopen) CAN-ID desired Mixed operation (CANopen and Layer2) * Please correct me if I‘m wrong