Cifx API PR 05 EN
Cifx API PR 05 EN
CIFX API
Table of contents
1 Introduction............................................................................................................................................. 4
1.1 About this document ...................................................................................................................... 4
1.2 List of revisions............................................................................................................................... 4
1.3 Terms, abbreviations and definitions ............................................................................................. 5
1.4 References to documents .............................................................................................................. 5
2 Application note ..................................................................................................................................... 6
2.1 Component overview for host applications .................................................................................... 6
2.2 Component overview for netX applications .................................................................................... 7
2.3 Availability of API functions ............................................................................................................ 8
3 API basics ............................................................................................................................................. 11
3.1 DPM layout, devices and channels .............................................................................................. 12
3.2 Basic fieldbus data handling ........................................................................................................ 13
3.3 Fieldbus-specific information and functions ................................................................................. 13
4 CIFX API (Application Programming Interface) ................................................................................. 14
4.1 API header files ............................................................................................................................ 14
4.2 Driver functions ............................................................................................................................ 14
4.3 System Device functions .............................................................................................................. 15
4.4 Communication Channel functions .............................................................................................. 16
4.5 Structure definitions ..................................................................................................................... 18
4.5.1 Driver information ............................................................................................................................ 18
4.5.2 Board information ............................................................................................................................ 18
4.5.3 System channel information ............................................................................................................ 19
4.5.4 Communication channel information ............................................................................................... 21
4.6 Driver related functions ................................................................................................................ 22
4.6.1 xDriverOpen .................................................................................................................................... 22
4.6.2 xDriverClose .................................................................................................................................... 23
4.6.3 xDriverGetInformation ..................................................................................................................... 24
4.6.4 xDriverGetErrorDescription ............................................................................................................. 25
4.6.5 xDriverEnumBoards ........................................................................................................................ 26
4.6.6 xDriverEnumChannels..................................................................................................................... 27
4.6.7 xDriverRestartDevice....................................................................................................................... 28
4.6.8 xDriverMemoryPointer ..................................................................................................................... 29
4.7 System device specific functions ................................................................................................. 31
4.7.1 xSysdeviceOpen ............................................................................................................................. 31
4.7.2 xSysdeviceClose ............................................................................................................................. 32
4.7.3 xSysdeviceInfo ................................................................................................................................ 33
4.7.4 xSysdeviceReset ............................................................................................................................. 34
4.7.5 xSysdeviceBootstart ........................................................................................................................ 35
4.7.6 xSysdeviceGetMBXState ................................................................................................................ 36
4.7.7 xSysdevicePutPacket ...................................................................................................................... 37
4.7.8 xSysdeviceGetPacket...................................................................................................................... 38
4.7.9 xSysdeviceDownload ...................................................................................................................... 39
4.7.10 xSysdeviceFindFirstFile................................................................................................................... 41
4.7.11 xSysdeviceFindNextFile .................................................................................................................. 42
4.7.12 xSysdeviceUpload ........................................................................................................................... 43
4.7.13 xSysdeviceExtendedMemory .......................................................................................................... 44
4.8 Channel-specific functions ........................................................................................................... 48
4.8.1 xChannelOpen ................................................................................................................................ 48
4.8.2 xChannelClose ................................................................................................................................ 49
4.8.3 xChannelDownload ......................................................................................................................... 50
4.8.4 xChannelFindFirstFile...................................................................................................................... 51
4.8.5 xChannelFindNextFile ..................................................................................................................... 52
4.8.6 xChannelUpload .............................................................................................................................. 53
4.8.7 xChannelGetMBXState ................................................................................................................... 54
4.8.8 xChannelPutPacket ......................................................................................................................... 55
4.8.9 xChannelGetPacket......................................................................................................................... 56
4.8.10 xChannelGetSendPacket ................................................................................................................ 57
4.8.11 xChannelReset ................................................................................................................................ 58
4.8.12 xChannelInfo ................................................................................................................................... 59
4.8.13 xChannelIOInfo ............................................................................................................................... 60
1 Introduction
1.1 About this document
This manual describes the CIFX/COMX/netX Application Programming Interface (CIFX API) and
the containing functions, offered for all Hilscher standard devices based on netX controller
hardware.
Aim of the API is to provide applications a target and fieldbus independent programming interface
to netX based hardware running a standard Hilscher fieldbus protocol or firmware which meet the
Hilscher netX dual port memory (netX DPM) definitions, described in the 'netX Dual Port Memory
Interface' manual (see reference [1]).
The API is designed to give the user easy access to all of the communication board functionalities.
In addition, Hilscher also offers a free of charge cifX Toolkit (C-source code based) which allows to
write own drivers based on the Hilscher netX DPM definitions including the CIFX API functions (the
toolkit is described in a separate cifX/netX Toolkit manual, see reference [2]).
2 Application note
2.1 Component overview for host applications
Hilscher offers the CIFX API on different platforms and as different applications (DLL / library or C
source code). Usually the API comes with an operating system driver or with the CIFX Toolkit.
The use of the API also implies the physical hardware connection to the netX hardware. While a
device driver uses memory functions to access the DPM, the toolkit also allows the implementation
of alternative hardware access functions like DPM via SPI or custom access functions like DPM via
a custom USB protocol.
The netX Transport DLL is a special implementation of the CIFX API, including hardware access
via serial interfaces (e. g. USB/serial/Ethernet connections). This component is able to convert
CIFX API function calls either into appropriate packet based commands (rcX packets, described in
reference [1]) or into a dedicated binary format which enables the execution of the API functions on
a remote system (similar to RPC - remote procedure calls).
CIFX / netX
Device Driver
CIFX Toolkit
CIFX Toolkit
Hardware Interface
Physical DPM Physical USB / serial / Ethernet
via SPI DPM access
Note: Not all of the physical connections can be made available on every host system
(e.g. SPI on Windows).
CIFX API | Programming Reference Guide
DOC121201PR05EN | Revision 5 | English | 2018-08 | Released | Public © Hilscher, 2012-2018
Application note 7/118
User Application
CIFX - API
Notes:
3 API basics
As described before, the CIFX API is the common, fieldbus protocol independent, function
interface to Hilscher CIFX/COMX and netX based devices.
It is based on the Hilscher netX DPM (dual-port memory) definition and abstracts the access to the
netX based hardware and the Hilscher netX protocol firmware running on the netX.
The API offers a set of functions grouped into 'Driver' related, 'System Device' related and
'Communication Channel' related functions.
Each of the group covers device specific functions by providing a set of API functions necessary
for the specific handling.
The DPM layout divides the interface to a netX device into several areas (channels) where each
channel has its own structure, predefined information and functionality and can be handled
independently from other channels.
A standard netX firmware offers up to 8 channels with three different channel definitions.
System Handshake
4 x Communication Channel 2 x User Channel
Channel Channel
Dual-Port Memory
0 65535
Channel Definition:
The Handshake Channel is necessary for special device functionalities like interrupt handling and
DPM access synchronization and therefore it has no user API functions offering access to this
channel.
CIFX API function names correspond to the function groups and channel definitions.
xSysdevice..........() Functions and functionalities corresponding to the system channel
functionalities
xChannel..............() Functions and functionalities corresponding communication channel
and its needs
xDriver…..............() Functions to handle multiple devices in a common way
Other information like configuration, diagnostic and device specific administration functions are
also based on the asynchronous data transfer mechanism.
Note: A complete description of the fieldbus data handling can be found in the netX Dual Port
Memory Interface manual
Note: Fieldbus specific information and functionalities can be found in the corresponding
protocol API manuals (e. g. PROFIBUS DP Master Protocol API 15 EN.pdf).
Function Description
xDriverOpen Opens the driver, allowing access to every driver function
xDriverClose Closes an open connection to the driver
xDriverGetInformation Retrieves driver information (e.g. Version)
xDriverGetErrorDescription Retrieves an English description of a cifX driver error code
xDriverEnumBoards Enumerate through all boards/devices the driver is managing
xDriverEnumChannels Enumerate through all channels located on a specific board
xDriverRestartDevice Restart a device
xDriverMemoryPointer Get/Release a pointer to the dual port memory.
This function should only be used for debugging.
purpose
Table 7: Driver functions
Function Description
xSysdeviceOpen Opens a connection to a boards system device
xSysdeviceClose Closes a connection to a system device
xSysdeviceInfo Get System device specific information (e.g. mailbox size)
xSysdeviceReset Perform a device reset
xSysdeviceBootstart Perform a device boot start.
This will activate the 2nd Stage bootloader. An available firmware will not be started.
Note: Only possible on FLASH based devices.
xSysdeviceGetMBXState Retrieves the system mailbox state
xSysdeviceGetPacket Retrieves a pending packet from the system mailbox
xSysdevicePutPacket Send a packet to the system mailbox
xSysdeviceDownload Downloads a file/configuration/firmware to the device
xSysdeviceFindFirstFile Find the first file entry in the given directory
xSysdeviceFindNextFile Find the next file entry in the given directory
xSysdeviceUpload Uploads a file/configuration/firmware from the device
xSysdeviceExtendedMemory Get a pointer to an available extended memory area
Table 8: System Device functions
Function Description
xChannelOpen Opens a connection to a communication channel
xChannelClose Closes a connection
Asynchronous services (Packets)
xChannelGetMBXState Retrieve the channels mailbox state
xChannelGetPacket Retrieve a pending packet from the channel mailbox
xChannelPutPacket Send a packet to the channel mailbox
xChannelGetSendPacket Read back the last sent packet
Device Administrational/Informational functions
xChannelDownload Download a file/configuration to the channel
xChannelReset Reset the channel
xChannelInfo Retrieve channel specific information
xChannelWatchdog Activate/Deactivate/Trigger the channel Watchdog
xChannelHostState Set the application state flag in the application COS flags, to
signal the hardware if an application is running or not
xChannelBusState Set the bus state flag in the application COS state flags, to
start or stop fieldbus communication.
xChannelControlBlock Access the channel control block
xChannelCommonStatusBlock Access to the common status block
xChannelExtendedStatusBlock Access to the extended status block
xChannelUserBlock Access user block (not implemented yet!)
Cyclic Data services (I/O's)
xChannelIORead Instructs the device to place the latest data into the DPM and
passes them to the user
xChannelIOWrite Copies the data to the DPM and waits for the firmware to
retrieve them
xChannelIOReadSendData Reads back the last send data
Cyclic Data services (I/O's, PLC optimized)
xChannelPLCMemoryPtr Get a pointer to the I/O memory block
xChannelPLCActivateRead Instruct the firmware to place the latest input data into the I/O
memory block (no wait for completion)
xChannelPLCActivateWrite Instruct the firmware to retrieve the latest output data from
the I/O memory block (no wait for completion)
xChannelPLCIsReadReady Checks if the last read activation has finished
xChannelPLCIsWriteReady Checks if the last write activation has finished
Function Description
DMA services
xChannelDMAState Activate/Deactivate DMA mode
Bus synchronous operation
xChannelSyncState Wait for synchronization events or trigger / acknowledge a
sync event
Notification services (only available in Interrupt mode)
xChannelRegisterNotification Register a notification callback
xChannelUnregisterNotification Un-register a notification callback
Table 9: Communication Channel functions
Command: CIFX_INFO_CMD_SYSTEM_INFORMATION
SYSTEM_CHANNEL_SYSTEM_INFORMATION
Element Type Description
ulSystemError uint32_t Boot-up/System error, when trying to handle device
ulDpmTotalSize uint32_t Total size of the dual port in bytes
ulMBXSize uint32_t Size of the system mailbox in bytes
ulDeviceNumber uint32_t Device number (as found on the matrix label)
ulSerialNumber uint32_t Serial number (as found on the matrix label)
ulOpenCnt uint32_t Number of times this device is open
Table 12: System channel information
Command: CIFX_INFO_CMD_SYSTEM_INFO_BLOCK
SYSTEM_CHANNEL_SYSTEM_INFO_BLOCK
Element Type Description
abCookie uint8_t[4] System channel identifier MUST be "netX"
ulDpmTotalSize uint32_t Total size of the dual port in bytes
ulDeviceNumber uint32_t Device number (as found on the matrix label)
ulSerialNumber uint32_t Serial number (as found on the matrix label)
ausHwOptions uint16_t[4] Array of hardware options for all four possible ports of the netX
usManufacturer uint16_t Manufacturer ID
usProductionDate uint16_t Production date code
ulLicenseFlags1 uint32_t Hilscher dedicated license flags (e.g. fieldbus license)
ulLicenseFlags2 uint32_t Hilscher dedicated license flags (e.g. additional information)
usNetxLicenseID uint16_t Special netX user license information
usNetxLicenseFlags uint16_t Dedicated netX user license information
usDeviceClass uint16_t Hardware device class (e.g. CIFX / COMX etz.)
bHwRevision uint8_t Hardware revision
bHwCompatibility uint8_t Hardware compatibility list
bDevIdNumber uint8_t Device identification number (rotary switch)
bReserved uint8_t unused/reserved
usReserved uint16_t unused/reserved
Table 13: System channel info block
Command: CIFX_INFO_CMD_SYSTEM_CHANNEL_BLOCK
SYSTEM_CHANNEL_CHANNEL_INFO_BLOCK
Element Type Description
abInfoBlock uint8_t[8][16] Channel information in the system channel
Table 14: System Channel - Channel Info Block
CIFX_MAX_NUMBER_OF_CHANNEL_DEFINITION =8
CIFX_SYSTEM_CHANNEL_DEFAULT_INFO_BLOCK_SIZE = 16
Note: To evaluate the content of the abInfoBlock array, refer to the netX DPM Interface
Manual and the rcX_User.h, structure NETX_CHANNEL_INFO_BLOCK.
Command: CIFX_INFO_CMD_SYSTEM_CONTROL_BLOCK
SYSTEM_CHANNEL_SYSTEM_CONTROL_BLOCK
Element Type Description
ulSystemCommandCOS uint32_t System channel host COS flags
ulReserved uint32_t unused/reserved
Table 15: System channel control block
Command: CIFX_INFO_CMD_SYSTEM_STATUS_BLOCK
SYSTEM_CHANNEL_SYSTEM_STATUS_BLOCK
Element Type Description
ulSystemCOS uint32_t System channel device COS flags
ulSystemStatus uint32_t Actual system state
ulSystemError uint32_t Actual system error
ulBootError uint32_t Error code from the second stage bootloader (only valid if
Cookie="BOOT")
ulTimeSinceStart uint32_t Time since system start in seconds
usCpuLoad uint16_t CPU load in 0,01% units (10000 => 100%)
usReserved uint16_t Reserved for later use
ulHWFeatures Uint32_t Information about hardware features (e.g. MRAM / RTC)
abReserved uint8_t[36] unused/reserved
Table 16: System channel status block
CHANNEL_INFORMATION
Element Type Description
abBoardName uint8_t[16] This is the name of the board which can be used for opening a channel or
the system device on it.
abBoardAlias uint8_t[16] This is an alternate, user-definable name for the device
ulDeviceNumber uint32_t Device number (as found on the matrix label)
ulSerialNumber uint32_t Serial number (as found on the matrix label)
usFWMajor uint16_t Major version number of firmware
usFWMinor uint16_t Minor version number of firmware
usFWBuild uint16_t Build number of firmware
usFWRevision uint16_t Revision version number of firmware
bFWNameLength uint8_t Length of firmware name
abFWName uint8_t[63] Firmware name
usFWYear uint16_t Build year of firmware
bFWMonth uint8_t Build month of firmware (1..12)
bFWDay uint8_t Build day of firmware (1..31)
ulChannelError uint32_t Communication channel error from the "Common Status Block"
ulOpenCnt uint32_t Number of calls to xChannelOpen for this channel
ulPutPacketCnt uint32_t Number of successful transmitted packets
ulGetPacketCnt uint32_t Number of successfully received packets
ulMailboxSize uint32_t Mailbox size in Bytes
ulIOInAreaCnt uint32_t Number of I/O Input areas
ulIOOutAreaCnt uint32_t Number of I/O output areas
ulHskSize uint32_t RCX_HANDSHAKE_SIZE_8BIT (0x01) or
RCX_HANDSHAKE_SIZE_16BIT (0x02)
ulNetxFlags uint32_t Actual netX communication flags (usNetxCommFlag)
ulHostFlags uint32_t Actual host communication flags (usHostCommFlags)
ulHostCOSFlags uint32_t Actual applicaton COS flags (ulApplicationCOS of Control Block)
ulDeviceCOSFlags uint32_t Actual communication COS flags (ulCommunicationCOS of Common
Status Block)
Table 17: Channel information structure
4.6.1 xDriverOpen
This function opens a connection / handle to the cifX driver.
Function call:
int32_t xDriverOpen( CIFXHANDLE* phDriver)
Arguments:
Return values:
4.6.2 xDriverClose
This function closes a connection / handle to the cifX driver.
Function call:
int32_t xDriverClose( CIFXHANDLE hDriver)
Arguments:
Return values:
4.6.3 xDriverGetInformation
This function retrieves all driver specific information, like version number, build date, etc.
Function call:
int32_t xDriverGetInformation( CIFXHANDLE hDriver
uint32_t ulSize,
void* pvDriverInfo)
Arguments:
Return values:
Example:
DRIVER_INFORMATION tDriverInfo = {0};
int32_t lRet = xDriverGetInformation(NULL, sizeof(tDriverInfo), &tDriverInfo);
if( lRet == CIFX_NO_ERROR)
{
}
4.6.4 xDriverGetErrorDescription
Look up function for driver errors. The function returns a human-readable error description (English
only).
Function call:
int32_t xDriverGetErrorDescription( int32_t lError,
char* szBuffer,
uint32_t ulBufferLen)
Arguments:
Return values:
Example:
// Read driver error description
char szError[1024] ={0};
xDriverGetErrorDescription( lError, szError, sizeof(szError));
4.6.5 xDriverEnumBoards
Enumerate all currently handled boards/cards of the driver.
Function call:
int32_t xDriverEnumBoards( CIFXHANDLE hDriver,
uint32_t ulBoard,
uint32_t ulSize
void* pvBoardInfo)
Arguments:
Return values:
Example:
int32_t lBoardRet;
do {
BOARD_INFORMATION tBoardInfo = {0};
lBoardRet = xDriverEnumBoards(NULL, ulBoardIdx++, sizeof(tBoardInfo), &tBoardInfo);
if(lBoardRet == CIFX_NO_ERROR)
{
}
} while(lBoardRet == CIFX_NO_ERROR);
4.6.6 xDriverEnumChannels
Enumerate all available channels on a board/card.
Function call:
int32_t xDriverEnumChannels( CIFXHANDLE hDriver,
uint32_t ulBoard,
uint32_t ulChannel
uint32_t ulSize
void* pvChannelInfo)
Arguments:
Return values:
Example:
int32_t lChannelRet;
do {
CHANNEL_INFORMATION tChannelInfo = {0};
lChannelRet = xDriverEnumChannels(NULL, ulBoardIdx, ulChannelIdx++,
sizeof(tChannelInfo), &tChannelInfo);
if(lChannelRet == CIFX_NO_ERROR)
{
}
} while(lChannelRet == CIFX_NO_ERROR);
4.6.7 xDriverRestartDevice
The function can be used to restart a netX board. The driver processes the same functions like on
a power on reset (reset the hardware and download the bootloader, firmware and configuration
files etc.).
A restart is necessary on PCI based netX boards if a running firmware should be updated or
changed. Because on such boards the firmware is not stored in a FLASH file system and updating
the firmware while it is running in RAM is not possible.
On Windows based systems a restart can also be performed using the Windows Device Manager
to deactivate/activate the board.
Note: A restart is only performed if no application has an open handle to the board or one of
its communication channels.
Function call:
int32_t APIENTRY xDriverRestartDevice( CIFXHANDLE hDriver,
char* szBoardName,
void* pvData);
Arguments:
Return values:
4.6.8 xDriverMemoryPointer
Return a pointer to the dual port memory of a board/channel. This function should only be used for
debugging purposes, because the function only maps the card memory into the processes memory
area.
Function call:
int32_t xDriverMemoryPointer ( CIFXHANDLE hDriver,
uint32_t ulBoard,
uint32_t ulCmd,
void* pvMemoryInfo)
Arguments:
Return values:
MEMORY_INFORMATION Structure:
/*****************************************************************************/
/*! Memory Information structure */
/*****************************************************************************/
typedef __CIFx_PACKED_PRE struct MEMORY_INFORMATIONtag
{
void* pvMemoryID; /*!< Identification of the memory area */
void** ppvMemoryPtr; /*!< Memory pointer */
uint32_t* pulMemorySize; /*!< Complete size of the mapped memory */
uint32_t ulChannel; /*!< Requested channel number */
uint32_t* pulChannelStartOffset;/*!< Start offset of the requested channel */
uint32_t* pulChannelSize; /*!< Memory size of the requested channel */
} __CIFx_PACKED_POST MEMORY_INFORMATION;
Example:
//=============================================================================
// Test memory pointer
//
//
//=============================================================================
void TestMemoryPointer( void)
{
unsigned char abBuffer[100] = {0};
// Open channel
uint32_t ulMemoryID = 0;
unsigned char* pabDPMMemory = NULL;
uint32_t ulMemorySize = 0;
uint32_t ulChannelStartOffset = 0;
uint32_t ulChannelSize = 0;
long lRet = CIFX_NO_ERROR;
4.7.1 xSysdeviceOpen
Open a connection to a system device on the passed board.
Function call:
int32_t xSysdeviceOpen( CIFXHANDLE hDriver,
char* szBoard,
CIFXHANDLE* phSysdevice);
Arguments:
Return values:
4.7.2 xSysdeviceClose
Close a connection to a system device.
Function call:
int32_t xSysdeviceClose( CIFXHANDLE hSysdevice)
Arguments:
Return values:
4.7.3 xSysdeviceInfo
Query information about the opened system device.
Function call:
int32_t xSysdeviceInfo( CIFXHANDLE hSysdevice,
uint32_t ulCmd
uint32_t ulSize,
void* pvInfo)
Arguments:
Return values:
4.7.4 xSysdeviceReset
This function performs a firmware restart. Depending on the hardware and the implementation in
the firmware, this could be a software restart or a complete hardware reset.
Usually a software reset is performed.
Function call:
int32_t xSysdeviceReset( CIFXHANDLE hSysdevice
uint32_t ulTimeout)
Arguments:
Return values:
4.7.5 xSysdeviceBootstart
Perform a boot start on the hardware. This is necessary if the 2nd Stage Bootloader should be
activated while an executable Firmware is available.
Note: This function is only available on so called FLASH based devices where the 2nd Stage
Bootloader is stored in the FLASH of the hardware.
Function call:
int32_t xSysdeviceBootstart( CIFXHANDLE hSysdevice
uint32_t ulTimeout)
Arguments:
Return values:
4.7.6 xSysdeviceGetMBXState
Retrieve the current load of the system device mailbox. This Function can be used to read the
actual state of the channels send and receive mailbox, without accessing the mailbox itself.
Note: Mailboxes are used to pass asynchronous data back and forth between the hardware
and the host system. The amount of concurrent active asynchronous commands is
limited by the hardware.
Function call:
int32_t xSysdeviceGetMBXState( CIFXHANDLE hSysdevice,
uint32_t* pulRecvPktCount,
uint32_t* pulSendPktCount)
Arguments:
Return values:
4.7.7 xSysdevicePutPacket
Insert an asynchronous command (packet) into the system device send mailbox to send it to the
hardware. This function uses the system device mailbox.
Function call:
int32_t xSysdevicePutPacket( CIFXHANDLE hSysdevice,
CIFX_PACKET* ptSendPacket,
uint32_t ulTimeout)
Arguments:
Return values:
4.7.8 xSysdeviceGetPacket
Retrieve an already waiting, asynchronous data packet from the system device receive mailbox.
Function call:
int32_t xSysdeviceGetPacket( CIFXHANDLE hSysdevice,
uint32_t ulSize,
CIFX_PACKET* ptRecvPacket,
uint32_t ulTimeout)
Arguments:
Return values:
4.7.9 xSysdeviceDownload
Downloading files to the board via the system device.
Due to the limited size of the mailbox these downloads are slower than using the channels mailbox
and should only be used if the channel's firmware is not running yet.
Download mode definitions can be found in the cifXUser.h file.
Available download modes:
Definition Mode Description
DOWNLOAD_MODE_FIRMWARE 1 Download a firmware file (file extension *.nxf)
DOWNLOAD_MODE_CONFIG 2 Download a fieldbus configuration file (file extension *.nxd)
DOWNLOAD_MODE_FILE 3 Download any file (file extension *.*)
DOWNLOAD_MODE_BOOTLOADER 4 Special download mode only supported by the 2nd Stage
bootloader to update itself in FLASH memory
DOWNLOAD_MODE_LICENSECODE 5 Download a license file (file extension *.nxl)
License files containing license flags which are stored on the
hardware.
DOWNLOAD_MODE_MODULE 6 Download a firmware module file (file extension *.nxo)
Firmware modules are dynamically loadable and require a so-
called base firmware
Function call:
int32_t xSysdeviceDownload( CIFXHANDLE hSysdevice,
uint32_t ulChannel
uint32_t ulMode,
char* pszFileName,
uint8_t* pabFileData,
uint32_t ulFileSize,
PFN_PROGRESS_CALLBACK pfnCallback,
PFN_RECV_PKT_CALLBACK pfnRecvPktCallback,
void* pvUser)
Arguments:
Return values:
4.7.10 xSysdeviceFindFirstFile
Start enumerating a directory on the device. This call will deliver the first directory/file entry on the
device if available.
Function call:
int32_t xSysdeviceFindFirstFile( CIFXHANDLE hSysdevice,
uint32_t ulChannel,
CIFX_DIRECTORYENTRY* ptDirectoryInfo,
PFN_RECV_PKT_CALLBACK pfnRecvPktCallback,
void* pvUser)
Arguments:
Return values:
4.7.11 xSysdeviceFindNextFile
Continue enumerating a directory on the device. This function must be called with a previously
returned directory entry structure from xSysdeviceFindFirstFile().
Function call:
int32_t xSysdeviceFindNextFile ( CIFXHANDLE hSysdevice,
uint32_t ulChannel,
CIFX_DIRECTORYENTRY* ptDirectoryInfo,
PFN_RECV_PKT_CALLBACK pfnRecvPktCallback,
void* pvUser)
Arguments:
Return values:
4.7.12 xSysdeviceUpload
Upload a given file from the device.
Function call:
int32_t xSysdeviceUpload( CIFXHANDLE hSysdevice,
uint32_t ulChannel,
uint32_t ulMode,
char* pszFilename,
uint8_t* pabFileData,
uint32_t* pulFileSize,
PFN_PROGRESS_CALLBACK pfnCallback,
PFN_RECV_PKT_CALLBACK pfnRecvPktCallback,
void* pvUser)
Arguments:
Return values:
4.7.13 xSysdeviceExtendedMemory
netX based PCI hardware is able to offer a second PCI memory window used to accesses
additional hardware memory, independent of the existing Hilscher dual-port-memory resource.
Depending on the netX hardware, the type of memory resource could differ. Current hardware
offers a MRAM (Magneto resistive Random Access Memory) resource.
The type of additional memory, assembled on the hardware, is defined by information in the
hardware security memory. The information is used by the bootloader and firmware to detect and
initialize access to the additional memory and the information is also stored in the
NETX_SYSTEM_STATUS_BLOCK (see ulHWFeatures) to be accessible by a user application.
The xSysdeviceExtendedMemory() function offers a command parameter to allowing reading
information and getting/returning the pointer to the extended memory.
Function call:
int32_t xSysdeviceExtendedMemory( CIFXHANDLE hSysdevice,
uint32_t ulCmd,
CIFX_EXTENDED_MEMORY_INFORMATION* ptExtMemData);
Arguments:
Return values:
ulMemoryInformation:
Extended Memory
31..16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RAM Type:
0 = None
1 = MRAM 64*16 Bit (1 MBit/128 KB
Reserved
Access Type:
00 = No access
01 = external access (host)
10 = internal access
11 = external and internal access reserved
Unused set to 0
Note: ulMemoryType defines the type of the assembled/offered memory by the hardware.
The type is defined in the hardware security memory.
CIFX_EXTENDED_MEMORY_INFORMATION structure:
/*****************************************************************************/
/*! Extended memory information structure */
/*****************************************************************************/
typedef __CIFx_PACKED_PRE struct CIFX_EXTENDED_MEMORY_INFORMATIONtag
{
void* pvMemoryID; /*!< Identification of the memory area */
void* pvMemoryPtr; /*!< Memory pointer */
uint32_t ulMemorySize; /*!< Memory size of the Extended memory area */
uint32_t ulMemoryType; /*!< Memory type information */
} __CIFx_PACKED_POST CIFX_EXTENDED_MEMORY_INFORMATION;
Example:
//=============================================================================
// Test memory pointer
//
//
//=============================================================================
void TestExtendedMemoryPointer( void)
{
CIFXHANDLE hSysdevice = NULL;
int32_t lRet = CIFX_NO_ERROR;
uint8_t abBuffer[100] = {0};
if ( CIFX_NO_ERROR != lRet)
{
ShowError( lRet);
} else
{
CIFX_EXTENDED_MEMORY_INFORMATION tExtMemory = {0};
while( 1 == 1)
{
// Read 100 Bytes
memcpy( abBuffer, pbExtMem, sizeof(abBuffer));
printf("Type (A) for again and (S) to stop the extended read/write test:\n");
if( 'S' == (toupper (_getch())) )
{
break;
}
}
lRet = xSysdeviceExtendedMemory( hSysdevice, CIFX_FREE_EXTENDED_MEMORY_POINTER,
&tExtMemory);
if(lRet != CIFX_NO_ERROR)
{
// Failed to free the memory mapping
ShowError( lRet);
}
}
}
// Test done
printf("\n Extended Memory Pointer test done\r\n");
4.8.1 xChannelOpen
Open a connection to a communication / user channel on the given board.
Function call:
int32_t xChannelOpen( CIFXHANDLE hDriver,
char* szBoard,
uint32_t ulChannel,
CIFXHANDLE* phChannel)
Arguments:
Return values:
4.8.2 xChannelClose
Close a connection to a communication channel.
Function call:
int32_t xChannelClose( CIFXHANDLE hChannel)
Arguments:
Return values:
4.8.3 xChannelDownload
Download a file via the communication channel.
Download modes are defined and described in the xSysdeviceDownload() function (see section
xSysdeviceUpload on page 43)
Function call:
int32_t xChannelDownload( CIFXHANDLE hChannel,
uint32_t ulMode,
char* pszFileName,
uint8_t* pabFileData,
uint32_t ulFileSize,
PFN_PROGRESS_CALLBACK pfnCallback,
PFN_RECV_PKT_CALLBACK pfnRecvPktCallback,
void* pvUser)
Arguments:
Return values:
4.8.4 xChannelFindFirstFile
Start enumerating a directory on the channel. This call will deliver the first directory/file entry on the
channel if available.
Function call:
int32_t xChannelFindFirstFile ( CIFXHANDLE hChannel,
CIFX_DIRECTORYENTRY* ptDirectoryInfo,
PFN_RECV_PKT_CALLBACK pfnRecvPktCallback,
void* pvUser)
Arguments:
Return values:
4.8.5 xChannelFindNextFile
Continue enumerating a directory on the channel. This function must be called with a previously
returned directory entry structure from xChannelFindFirstFile().
Function call:
int32_t xChannelFindNextFile ( CIFXHANDLE hChannel,
CIFX_DIRECTORYENTRY* ptDirectoryInfo,
PFN_RECV_PKT_CALLBACK pfnRecvPktCallback,
void* pvUser)
Arguments:
Return values:
4.8.6 xChannelUpload
Upload a given file from the communication channel.
Function call:
int32_t xChannelUpload ( CIFXHANDLE hChannel,
uint32_t ulMode,
char* pszFileNam e,
uint8_t* pabFileData,
uint32_t* pulFileSize,
PFN_PROGRESS_CALLBACK pfnCallback,
PFN_RECV_PKT_CALLBACK pfnRecvPktCallback,
void* pvUser)
Arguments:
Return values:
4.8.7 xChannelGetMBXState
Retrieve the current load of the given communication channel mailbox. This Function can be used
to read the actual state of the channels send and receive mailbox without accessing the mailbox
itself.
Note: Mailboxes are used to pass asynchronous data back and forth between the hardware
and the host system. The amount of concurrent active asynchronous commands is
limited by the hardware.
Function call:
int32_t xChannelGetMBXState( CIFXHANDLE hChannel,
uint32_t* pulRecvPktCount,
uint32_t* pulSendPktCount)
Arguments:
Return values:
4.8.8 xChannelPutPacket
Insert an asynchronous data packet into the given communication channel send mailbox to send it
to the hardware.
Function call:
int32_t xChannelPutPacket( CIFXHANDLE hChannel,
CIFX_PACKET* ptSendPacket,
uint32_t ulTimeout)
Arguments:
Return values:
4.8.9 xChannelGetPacket
Retrieve an already waiting, asynchronous data packet from the given communication channel
receive mailbox.
Function call:
int32_t xChannelGetPacket( CIFXHANDLE hChannel,
uint32_t ulBufferSize,
CIFX_PACKET* ptRecvPacket,
uint32_t ulTimeout)
Arguments:
Return values:
4.8.10 xChannelGetSendPacket
Retrieve the actual data packet send by the host, from the communication channel send mailbox.
This function is none destructive. It does not guarantee any data consistency, because data are
read without any synchronization.
The function is mainly used for debugging aids.
Function call:
int32_t xChannelGetSendPacket( CIFXHANDLE hChannel,
uint32_t ulBufferSize,
CIFX_PACKET* ptRecvPacket)
Arguments:
Return values:
4.8.11 xChannelReset
Reset the given communication channel. The reset function offers a following two modes:
CIFX_ CHANNELINIT Re-initialization of a communication channel
CIFX_ SYSTEMSTART Restart the whole card
Function call:
int32_t xChannelReset( CIFXHANDLE hChannel,
uint32_t ulResetMode,
uint32_t ulTimeout)
Arguments:
Return values:
4.8.12 xChannelInfo
Retrieve the global communication channel information.
Function call:
int32_t xChannelInfo( CIFXHANDLE hChannel,
uint32_t ulSize,
void* pvChannelInfo)
Arguments:
Return values:
4.8.13 xChannelIOInfo
Retrieve I/O information about the communication channel.
Function call:
int32_t xChannelIOInfo( CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t ulAreaNumber,
uint32_t ulSize,
void* pvData)
Arguments:
Return values:
4.8.14 xChannelWatchdog
Enable, trigger or disable the host watchdog. The watchdog function is used by a communication
channel to supervise the processing of the user application. If the watchdog is configured it will be
activated with the first call of the function xChannelWatchdog() passing the command
CIFX_WATCHDOG_START. Once activated, the application must trigger it cyclically, during the
configured watchdog time. The watchdog supervision is deactivated by passing
CIFX_WATCHDOG_STOP in the call of xChannelWatchdog().
Function call:
int32_t xChannelWatchdog( CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t* pulTrigger)
Arguments:
Return values:
4.8.15 xChannelConfigLock
Lock the configuration of the channel against modification. If the configuration is locked, the
fieldbus stack does not allow doing a configuration update.
Function call:
int32_t xChannelConfigLock( CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t* pulState,
uint32_t ulTimeout)
Arguments:
Return values:
4.8.16 xChannelHostState
Toggle the 'Application Ready State Flag' in the communication channel host handshake flags.
This function is used to signal a communication stack the presents of a user application.
How the fieldbus stack uses the information is stack depending. Usually the stack will use the
information to verify if the I/O data in the I/O image are valid.
Function call:
int32_t xChannelHostState( CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t* pulState,
uint32_t ulTimeout)
Arguments:
Return values:
4.8.17 xChannelBusState
Toggle the 'Bus State Flag' in the communication channel handshake flags. Using this flag, the
host application allows or disallows the firmware to open network connections. If set
(CIFX_BUS_STATE_ON), the netX firmware tries to open network connections; if cleared
(CIFX_BUS_STATE_OFF), no connections are allowed and open connections are closed (See
reference [1] for further information).
In generally a fieldbus stack allows the configuration of the field bus start-up behavior. This can be
either 'automatic startup' or 'controlled startup'. If the stack is configured in 'controlled startup' (i.e.
the 'Bus State Flag' is cleared) it will not activate the bus communication until it receives a
CIFX_BUS_STATE_ON state in its handshake flags.
Note: Setting the ‘Bus State flag’ to CIFX_BUS_STATE_ON successfully does not
necessarily mean that the fieldbus stack has established a connection to the fieldbus
system. The routine will signal an absent connection by returning the error code
CIFX_DEV_NO_COM_FLAG (even though toggle of the ‘Bus state flag’ has
succeeded).
Function call:
int32_t xChannelBusState( CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t* pulState,
uint32_t ulTimeout)
Arguments:
Return values:
4.8.18 xChannelControlBlock
Reading / writing the communication channel control block.
Function call:
int32_t xChannelControlBlock ( CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t ulOffset,
uint32_t ulDataLen,
void* pvData);
Arguments:
Return values:
4.8.19 xChannelCommonStatusBlock
Read the channels common status block.
Function call:
int32_t xChannelCommonStatusBlock ( CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t ulOffset,
uint32_t ulDataLen,
void* pvData);
Arguments:
Return values:
4.8.20 xChannelExtendedStatusBlock
Read the communication channels extended status block.
Function call:
int32_t xChannelExtendedStatusBlock ( CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t ulOffset,
uint32_t ulDataLen,
void* pvData);
Arguments:
Return values:
4.8.21 xChannelUserBlock
not implemented yet!
4.8.22 xChannelIORead
The function reads the input process data image of a communication channel and afterwards it
instructs the fieldbus protocol to update input data image with actual (latest) fieldbus data.
If the function returns error CIFX_NO_COM_FLAG, the protocol stack does not have an active
network connection and the input data are not up to date. The protocol stack must be started and
configured (see errors CIFX_DEV_NOT_READY / CIFX_DEV_NOT_RUNNING).
Note: On the basis of the implementation, xChannelIORead() delivers the input data from the
"last" call of xChannelIORead() and not the "latest" input data from the fieldbus system.
This has the advantage that the function has not to wait for the data update of the
fieldbus protocol which could need a significant time which are several hundred
microseconds up to milliseconds depending to the configuration and the number of
devices connected to the fieldbus system. But also the limitation that the age of the
input data are depending of the cycle time used to call xChannelIORead().
Function call:
int32_t xChannelIORead( CIFXHANDLE hChannel,
uint32_t ulAreaNumber,
uint32_t ulOffset,
uint32_t ulDataLen,
void* pvData,
uint32_t ulTimeout)
Arguments:
Return values:
4.8.23 xChannelIOWrite
The function writes the output process data image of a communication channel and instructs the
fieldbus protocol to send the data to the fieldbus system.
The function can also be used to initialize the output data image the first time, before the fieldbus
system starts the network data transfer. The fieldbus protocol will always be informed to update the
internal output data image by the written data, even if the functions detects that no bus
communication is running (error return CIFX_NO_COM_FLAG).
The only requirement is a started and configured fieldbus protocol (see errors
CIFX_DEV_NOT_READY / CIFX_DEV_NOT_RUNNING).
Note: The function xChannelIOWrite() does not wait until the data are taken by the hardware
or physically transferred by the fieldbus system, because this depends at least on the
fieldbus connection and the cycle time of the fieldbus system which are usually
unknown.
Function call:
int32_t xChannelIOWrite( CIFXHANDLE hChannel,
uint32_t ulAreaNumber,
uint32_t ulOffset,
uint32_t ulDataLen,
void* pvData,
uint32_t ulTimeout)
Arguments:
Return values:
4.8.24 xChannelIOReadSendData
Read back the actual content of the output process data image from a communication channel.
Function call:
int32_t xChannelIOReadSendData( CIFXHANDLE hChannel,
uint32_t ulAreaNumber,
uint32_t ulOffset,
uint32_t ulDataLen,
void* pvData)
Arguments:
Return values:
Some of the PLC programs (Programmable Logic Controller also known as SoftPLCs) are using an
own process data image layout. Such programs need to copy the process data, from the local
buffers, necessary for the standard xChannelIORead()/xChannelIOWrite() functions, into their own
data image layout. In such a case, process data are always copied two times. First time between
the cards I/O process data image and the local function buffers offered by the application and the
second time between the local buffers and the PLC specific process images.
PLC functions are design to save the copy between the cards I/O process data image and the local
function buffers (done by xChannelIORead()/xChannelIOWrite()).
Therefore xChannelIORead() and xChannelIOWrite() are split into separate functions. One function
to get data pointers to the input and output process data image which can be used by the
application to directly access the cards I/O process data image. And two other functions to control
and synchronize the access to the cards I/O process image data between the user application and
the fieldbus protocol, running on the card.
xChannelPLCMemoryPtr
Getting the data pointers to the cards I/O process data image
xChannelPLCActivateRead() / xChannelPLCActivateWrite()
Activate the data exchange of the cards I/O process data image with the fieldbus protocol
running on the card
xChannelPLCIsReadReady() / xChannelPLCIsWriteReady()
Check if the fieldbus protocol has finished the access to the crads I/ process data image and
if the application is allowed to access the data
Important for the use of the functions is a prior call to the xChannelPLCMemoryPtr() function. This
will deliver the necessary pointers to the I/O process data image.
Note: If the PLC functions are used, the application is responsible to synchronize the data
access between the host and the communication channel.
4.8.25.1 xChannelPLCMemoryPtr
Retrieve a memory pointer to the I/O data area for a PLC (Programmable Logic Controller). This
enables an application to write data directly to the dual port memory (I/O data image) without doing
a combined handshake like in xChannelIORead() or xChannelIOWrite().
Before closing an application, all retrieved pointers should be released to avoid system memory
leaks. Releasing a pointer is done by calling xChannelPLCMemoryPtr() using the
CIFX_MEM_PTR_CLOSE command.
Function call:
int32_t xChannelPLCMemoryPtr( CIFXHANDLE hChannel,
uint32_t ulCmd,
void* pvMemoryInfo)
Arguments:
Return values:
PLC_MEMORY_INFORMATION Structure:
/*****************************************************************************/
/*! PLC Memory Information structure */
/*****************************************************************************/
typedef __CIFx_PACKED_PRE struct PLC_MEMORY_INFORMATIONtag
{
void* pvMemoryID; /*!< Identification of the memory area */
void** ppvMemoryPtr; /*!< Memory pointer */
uint32_t ulAreaDefinition; /*!< Input/output area */
uint32_t ulAreaNumber; /*!< Area number */
uint32_t* pulIOAreaStartOffset; /*!< Start offset */
uint32_t* pulIOAreaSize; /*!< Memory size */
} __CIFx_PACKED_POST PLC_MEMORY_INFORMATION;
Example:
//=============================================================================
// Test PLC Functions
//
//
//=============================================================================
void TestPLCFunctions( void)
{
unsigned char abBuffer[1000] = {0};
uint32_t ulState = 0;
/* Open channel */
CIFXHANDLE hDevice = NULL;
lRet = xChannelOpen(NULL, "CIFx0", 0, &hDevice);
if(lRet != CIFX_NO_ERROR)
{
ShowError(lRet);
} else
{
/* Start PLC functions */
unsigned char* pabDPMMemory = NULL;
uint32_t ulAreaStartOffset = 0;
uint32_t ulAreaSize = 0;
long lRet = CIFX_NO_ERROR;
long lRetIN = CIFX_NO_ERROR;
long lRetOUT = CIFX_NO_ERROR;
if( 0 == ulWaitBusCount)
{
ShowError(lRet);
}
/*----------------------*/
/* Start cyclic data IO */
/*----------------------*/
if( CIFX_NO_ERROR == lRet)
{
printf("\n Press any key to stop \r\n");
while (!_kbhit())
{
// We have a memory mapping, check if access to the DPM is allowed
uint32_t ulReadState = 0;
uint32_t ulWriteState = 0;
/*----------------------------------------*/
/* Check if we can access the INPUT image */
/*----------------------------------------*/
/* Activate transfer */
lRet = xChannelPLCActivateRead ( hDevice, 0);
if( CIFX_NO_ERROR != lRet)
ShowError( lRet);
}
/*-----------------------------------------*/
/* Check if we can access the OUTPUT image */
/*-----------------------------------------*/
lRet = xChannelPLCIsWriteReady ( hDevice, 0, &ulWriteState);
if( CIFX_NO_ERROR != lRet)
{
ShowError( lRet);
} else if( 1 == ulWriteState)
{
/* It is allowed to write the image */
pabDPMMemory_OUT[0]++;
pabDPMMemory_OUT[1] = abBuffer[1];
// Close channel
if( hDevice != NULL) xChannelClose(hDevice);
}
4.8.25.2 xChannelPLCActivateRead
Instruct the communication channel to refresh the input process data image. The end of the update
cycle must be checked by the application using the function xChannelPLCIsReadReady()
Note: Do not call this function while the actual state is 'not finished' (check with the
corresponding xChannelPLCIs......Ready() function), otherwise the result is
unpredictable.
Function call:
int32_t xChannelPLCActivateRead( CIFXHANDLE hChannel,
uint32_t ulAreaNumber)
Arguments:
Return values:
4.8.25.3 xChannelPLCActivateWrite
Instruct the communication channel to refresh the output process data image with the data from
the dual port memory. The end of the update cycle must be checked by the user application, using
the function xChannelPLCIsWriteReady().
Note: Do not call this function while the actual state is 'not finished' (check with the
corresponding xChannelPLCIs......Ready() function), otherwise the result is
unpredictable.
Function call:
int32_t xChannelPLCActivateWrite( CIFXHANDLE hChannel,
uint32_t ulAreaNumber)
Arguments:
Return values:
4.8.25.4 xChannelPLCIsReadReady
Check if the last read request of the I/O data image is processed and finished by the hardware.
Function call:
int32_t xChannelPLCIsReadReady( CIFXHANDLE hChannel,
uint32_t ulAreaNumber,
uint32_t* pulReadState)
Arguments:
Return values:
4.8.25.5 xChannelPLCIsWriteReady
Check if the last write request handshake is processed and finished by the hardware.
Function call:
int32_t xChannelPLCIsWriteReady( CIFXHANDLE hChannel,
uint32_t ulAreaNumber,
uint32_t* pulWriteState)
Arguments:
Return values:
Note: DMA is only possible on PCI based hardware. On none PCI based hardware, this
function is not available and will return with an error
Function call:
int32_t xChannelDMAState( CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t* pulState)
Arguments:
Return values:
Note: Notification functions are only available for devices running in interrupt mode.
Available Notifications
Note: "I/O Data Transfer" notifications depending on the so called “I/O Exchange Mode”
configured on the device. These modes are defining how notifications are created by
the device state changes. The callback functions are called if the driver detects a state
change in the device handshake flags. How the application processes the notification is
part of the application development and must correspond to the configured mode
settings of the device. Handshake modes are described in [1].
Handshake modes are defining which part (device/host) is the active part.
Buffered Host Controlled: I/O Read Buffered Host Controlled: I/O Write
Application DPM netX Device Fieldbus Application DPM netX Device Fieldbus
1 Input Input
1 Input Input
2 Input Input
2 Input Input
xChannelIORead()
xChannelIOWrite()
Output Output Output Output
Input Update
3 Done Input Input
3 Input Input
Output Update
Output Output Done Output Output
Note: In these modes, the notifications just inform the application when the input data are
copied from the device local input buffer to the DPM and when the output data are
copied from the DPM to the device local output buffer. There is no synchronization with
any fieldbus data cycle.
Buffered Device Controlled: I/O Read Buffered Device Controlled: I/O Write
Application DPM netX Device Fieldbus Application DPM netX Device Fieldbus
I/O read data
1 available Input Input
1 Input Input
I/O waiting for
output data
Output Output Output Output
2 Input Input
2 Input Input
3 Input Input
3 Input Input
xChannelIORead()
xChannelIOWrite()
Output Output Output Output
Note: The application determines when read input or write output data. The notification
informs the application when read or write is possible. There is no synchronization with
any fieldbus data cycle.
The configured I/O data exchange (host controlled/device controlled) can be read from the
communication channels "Common Status Block" (bPDInHskMode / (bPDOutHskMode). The block
can be read and evaluated by the user application using the xChannelCommonStatusBlock()
function.
The "Common Status Block" is described in the "netX Dual-Port Memory Interface DPM Manual".
Note: Possible data exchanges modes are fieldbus protocol specific and described in the
corresponding fieldbus "Protocol API" manual.
1 1 Sync event
xChannelSyncState() Start bus cycle recogniced Bus event
Sync Flag Sync Flag
2 Sync command 2
done
Sync Flag Sync Flag
xChannelSyncState()
The configured synchronization mode (host controlled/device controlled) can be read from the
communication channels "Common Status Block" (bSyncHskMode). The block can be read and
evaluated by the user application using the xChannelCommonStatusBlock() function.
The "Common Status Block" is described in the "netX Dual-Port Memory Interface DPM Manual".
Following synchronization mode definitions are available:
/* Block definition: Synchronization Mode */
#define RCX_SYNC_MODE_OFF 0x00
#define RCX_SYNC_MODE_DEV_CTRL 0x01
#define RCX_SYNC_MODE_HST_CTRL 0x02
Note: Possible synchronization modes are fieldbus protocol specific and described in the
corresponding fieldbus "Protocol API" manual
Note: The registered callback function will be invoked as soon as the callback is registered
and the corresponding event is valid. This could also happen while the user application
is still in the xChannelRegisterNotification() function call.
Arguments:
4.8.27.5 xChannelRegisterNotification
Register an event callback for channel events.
Depending on the event type additional information is passed in the callback. If a callback is
already registered for the given event, the function will return an error.
It is not possible to register multiple applications for the same notification.
Note: The registered callback function will be invoked as soon as the callback is registered
and the corresponding event is valid. This could also happen while the user application
is still in the xChannelRegisterNotification() function call.
Function call:
int32_t xChannelRegisterNotification( CIFXHANDLE hChannel,
uint32_t ulNotification,
PFN_NOTIFY_CALLBACK pfnCallback,
void* pvUser);
Arguments:
Return values:
4.8.27.6 xChannelUnregisterNotification
Un-registers a previously registered notification event callback function for channel events.
Function call:
int32_t xChannelUnregisterNotification( CIFXHANDLE hChannel,
uint32_t ulNotification,);
Arguments:
Return values:
General Definition:
In interrupt mode, the drivers register notification function is used to handle synchronization events.
A user application is able to register a callback function for synchronization events
(CIFX_SYNC_EVENT). The registered callback function will be executed if either the device is
signaling a synchronization event or if the device acknowledges a synchronization command
initiated by the host application.
Device Synchronization Mode
The host has to register for a synchronization event and if the event occurs (callback function
is invoked) the host has to acknowledge the event using the
xChannelSyncState(...CIFX_SYNC_ACKNOWLEDGE_CMD...).
Host Synchronization Mode
The host calls xChannelSyncState(...CIFX_SYNC_SIGNAL_CMD...) to signal a
synchronization. The registered callback function will be invoked if the device acknowledges
the command.
xChannelSyncState() offers a pointer to an error counter buffer (pulErrorCount). This counter can
be used by the user application to determine the lost of a synchronization signals.
A changing error counter value between two subsequent xChannelSyncState() calls indicates a
lost signal. This means, in "Host Controlled Mode", the device was not quick enough to process the
previous command and in "Device Controlled Mode", the host has not acknowledged the
synchronization signal until the next synchronization signal was initiated.
The configured synchronization mode (host controlled / device controlled) can be read from the
communication channels "Common Status Block" (bSyncHskMode). The block can be read and
evaluated by the user application using the xChannelCommonStatusBlock() function.
The "Common Status Block" is described in the "netX Dual-Port Memory Interface DPM Manual".
Currently the following synchronization modes are defined.
/* Block definition: Synchronization Mode */
#define RCX_SYNC_MODE_OFF 0x00
#define RCX_SYNC_MODE_DEV_CTRL 0x01
#define RCX_SYNC_MODE_HST_CTRL 0x02
Also the synchronization error counter (bErrorSyncCnt) and the synchronization source
(bSyncSource) can be evaluated from the "Common Status Block".
Note: Fieldbus synchronization must be supported by the used fieldbus protocol stack.
Please consult the corresponding fieldbus "Protocol API" manual to make sure
synchronization is supported.
Note: Fieldbus synchronization is a time critical process and should be processed as fast as
possible. On Windows operating systems, responds times to synchronization events
are not guaranteed and can lead in serious jitter. Usually synchronization will be
handled in interrupt mode.
The xChannelSyncState() function can also be used in polling mode using a timeout
and the CIFX_SYNC_WAIT_CMD command, but this will not change the Windows
operating system respond timing issues.
Function call:
int32_t xChannelSyncState(CIFXHANDLE hChannel,
uint32_t ulCmd,
uint32_t ulTimeout
uint32_t* pulErrorCount)
Arguments:
Return values:
UNREFERENCED_PARAMETER(argc);
UNREFERENCED_PARAMETER(argv);
if(CIFX_NO_ERROR != lRet)
{
printf("Error opening driver. lRet=0x%08X\r\n", lRet);
} else
{
/* Example how to find a cifX/comX board */
EnumBoardDemo(hDriver);
if(CIFX_NO_ERROR != lRet)
{
printf("Error opening SystemDevice!\r\n");
} else
{
SYSTEM_CHANNEL_SYSTEM_INFO_BLOCK tSysInfo = {0};
uint32_t ulSendPktCount = 0;
uint32_t ulRecvPktCount = 0;
CIFX_PACKET tSendPkt = {0};
CIFX_PACKET tRecvPkt = {0};
/* System channel successfully opened, try to read the System Info Block */
if( CIFX_NO_ERROR != (lRet = xSysdeviceInfo(hSys,
CIFX_INFO_CMD_SYSTEM_INFO_BLOCK,
sizeof(tSysInfo),
&tSysInfo)))
{
printf("Error querying system information block\r\n");
} else
{
printf("System Channel Info Block:\r\n");
printf("DPM Size : %u\r\n", tSysInfo.ulDpmTotalSize);
printf("Device Number : %u\r\n", tSysInfo.ulDeviceNumber);
printf("Serial Number : %u\r\n", tSysInfo.ulSerialNumber);
printf("Manufacturer : %u\r\n", tSysInfo.usManufacturer);
printf("Production Date : %u\r\n", tSysInfo.usProductionDate);
printf("Device Class : %u\r\n", tSysInfo.usDeviceClass);
printf("HW Revision : %u\r\n", tSysInfo.bHwRevision);
printf("HW Compatibility : %u\r\n", tSysInfo.bHwCompatibility);
}
return lRet;
}
if(CIFX_NO_ERROR != lRet)
{
printf("Error opening Channel!");
} else
{
CHANNEL_INFORMATION tChannelInfo = {0};
CIFX_PACKET tSendPkt = {0};
CIFX_PACKET tRecvPkt = {0};
/* Read and write I/O data (32Bytes). Output data will be incremented each
cyle */
uint8_t abSendData[32] = {0};
uint8_t abRecvData[32] = {0};
uint32_t ulCycle = 0;
uint32_t ulState = 0;
if(CIFX_NO_ERROR != lRet)
{
printf("Error setting host ready!\r\n");
} else
{
/* Switch on the bus if it is not automatically running (see configuration
options) */
lRet = xChannelBusState( hChannel, CIFX_BUS_STATE_ON, &ulState, 0L);
if(CIFX_NO_ERROR != lRet)
{
printf("Unable to start the filed bus!\r\n");
} else
{
if(CIFX_NO_ERROR != lRet)
{
char szBuffer[256] = {0};
xDriverGetErrorDescription(lRet, szBuffer, sizeof(szBuffer));
printf(" State = 0x%08X <%s>\r\n", lRet, szBuffer);
} else
{
printf(" State = 0x%08X\r\n", lRet);
}
printf("----------------------------------------------------\r\n");
return lRet;
}
6.1 Overview
Driver Initialization Optional: Board and Channel Enumeration
xDriverOpen()
xDriverEnumBoards()
xDriverEnumChannels()
Channel Handling - Channel Open
xChannelOpen()
Optional: Reading Board Information
xChannelHostState() xSysdeviceOpen()
- CIFX_HOST_STATE_READY
xChannelConfigLock() xSysdeviceInfo()
- CIFX_CONFIGURATION_UNLOCK
xSysdeviceClose()
Stack Configuration
Optional: Open PLC Memory Pointer for PLC Functions
xChannelPLCMemoryPtr(...CIFX_MEM_PTR_OPEN...)
xChannelConfigLock()
- CIFX_CONFIGURATION_LOCK
xChannelBusState()
- CIFX_BUS_STATE_ON
xChannelBusState()
-CIFX_BUS_STATE_OFF
xChannelConfigLock()
- CIFX_CONFIGURATION_UNLOCK
xChannelHostState()
- CIFX_HOST_STATE_NOT_READY
Optional: Close PLC Memory Pointer for PLC Functions
xChannelPLCMemoryPtr( ..CIFX_MEM_PTR_CLOSE..)
xChannelClose()
Driver De-initialization
xDriverClose()
Driver Initialization
Optional: Read the channel I/O memory pointers if the PLC functions xChannelPLC... are
used for I/O data transfer
xChannelPLCMemoryPtr(...CIFX_PLC_MEM_PTR_OPEN...)
xChannelHostState(...CIFX_HOST_STATE_READY...) Signal Application is online
Wait until channel is READY if the timeout <> 0
Standard Timeout = 1000ms
xChannelConfigLock(CIFX_CONFIGURATION_UNLOCK) Unlock the configuration
Driver De-initialization
via rcX Packet via Database (.NXD) via rcX Packet via Database (.NXD)
xChannelWatchDog(...CIFX_WATCHDOG_START...)
xChannelPLCWriteReady() xChannelPLCReadReady()
no
xChannelIORead()
xChannelIOWrite() Write output data directly to the Read input data directly from the
cards DPM cards DPM
xChannelPLCActivateWrite() xChannelPLCActivateRead()
Cyclic end?
yes
xChannelWatchDog(...CIFX_WATCHDOG_STOP...)
Deactivate Watchdog
7 Error codes
Error code Symbol / Description
0x00000000 CIFX_NO_ERROR
No error
8 Appendix
8.1 List of tables
Table 1: List of revisions...................................................................................................................................................... 4
Table 2: Terms, abbreviations and definitions ..................................................................................................................... 5
Table 3: References to documents ..................................................................................................................................... 5
Table 4: List of API functions – Driver functions .................................................................................................................. 8
Table 5: List of API functions – System Device functions.................................................................................................... 8
Table 6: List of API functions – Communication Channel functions .................................................................................. 10
Table 7: Driver functions ................................................................................................................................................... 14
Table 8: System Device functions ..................................................................................................................................... 15
Table 9: Communication Channel functions ...................................................................................................................... 17
Table 10: Driver information structure ............................................................................................................................... 18
Table 11: Board information structure ............................................................................................................................... 18
Table 12: System channel information .............................................................................................................................. 19
Table 13: System channel info block ................................................................................................................................. 19
Table 14: System Channel - Channel Info Block ............................................................................................................... 20
Table 15: System channel control block ............................................................................................................................ 20
Table 16: System channel status block ............................................................................................................................. 20
Table 17: Channel information structure ........................................................................................................................... 21
Table 18: General Error Codes ....................................................................................................................................... 109
Table 19: Driver-related error codes ............................................................................................................................... 110
Table 20: Device / Communication-related error codes .................................................................................................. 112
Copyright
Important notes
Utmost care was/is given in the preparation of the documentation at hand consisting of a user's
manual, operating manual and any other document type and accompanying texts. However, errors
cannot be ruled out. Therefore, we cannot assume any guarantee or legal responsibility for
erroneous information or liability of any kind. You are hereby made aware that descriptions found
in the user's manual, the accompanying texts and the documentation neither represent a
guarantee nor any indication on proper use as stipulated in the agreement or a promised attribute.
It cannot be ruled out that the user's manual, the accompanying texts and the documentation do
not completely match the described attributes, standards or any other data for the delivered
product. A warranty or guarantee with respect to the correctness or accuracy of the information is
not assumed.
We reserve the right to modify our products and the specifications for such as well as the
corresponding documentation in the form of a user's manual, operating manual and/or any other
document types and accompanying texts at any time and without notice without being required to
notify of said modification. Changes shall be taken into account in future manuals and do not
represent an obligation of any kind, in particular there shall be no right to have delivered
documents revised. The manual delivered with the product shall apply.
Under no circumstances shall Hilscher Gesellschaft für Systemautomation mbH be liable for direct,
indirect, ancillary or subsequent damage, or for any loss of income, which may arise after use of
the information contained herein.
Liability disclaimer
The hardware and/or software was created and tested by Hilscher Gesellschaft für
Systemautomation mbH with utmost care and is made available as is. No warranty can be
assumed for the performance or flawlessness of the hardware and/or software under all application
conditions and scenarios and the work results achieved by the user when using the hardware
and/or software. Liability for any damage that may have occurred as a result of using the hardware
and/or software or the corresponding documents shall be limited to an event involving willful intent
or a grossly negligent violation of a fundamental contractual obligation. However, the right to assert
damages due to a violation of a fundamental contractual obligation shall be limited to contract-
typical foreseeable damage.
It is hereby expressly agreed upon in particular that any use or utilization of the hardware and/or
software in connection with
Flight control systems in aviation and aerospace;
Nuclear fission processes in nuclear power plants;
Medical devices used for life support and
Vehicle control systems used in passenger transport
shall be excluded. Use of the hardware and/or software in any of the following areas is strictly
prohibited:
For military purposes or in weaponry;
For designing, engineering, maintaining or operating nuclear systems;
In flight safety systems, aviation and flight telecommunications systems;
In life-support systems;
In systems in which any malfunction in the hardware and/or software may result in physical
injuries or fatalities.
You are hereby made aware that the hardware and/or software was not created for use in
hazardous environments, which require fail-safe control mechanisms. Use of the hardware and/or
software in this kind of environment shall be at your own risk; any liability for damage or loss due to
impermissible use shall be excluded.
Warranty
Hilscher Gesellschaft für Systemautomation mbH hereby guarantees that the software shall run
without errors in accordance with the requirements listed in the specifications and that there were
no defects on the date of acceptance. The warranty period shall be 12 months commencing as of
the date of acceptance or purchase (with express declaration or implied, by customer's conclusive
behavior, e.g. putting into operation permanently).
The warranty obligation for equipment (hardware) we produce is 36 months, calculated as of the
date of delivery ex works. The aforementioned provisions shall not apply if longer warranty periods
are mandatory by law pursuant to Section 438 (1.2) BGB, Section 479 (1) BGB and Section 634a
(1) BGB [Bürgerliches Gesetzbuch; German Civil Code] If, despite of all due care taken, the
delivered product should have a defect, which already existed at the time of the transfer of risk, it
shall be at our discretion to either repair the product or to deliver a replacement product, subject to
timely notification of defect.
The warranty obligation shall not apply if the notification of defect is not asserted promptly, if the
purchaser or third party has tampered with the products, if the defect is the result of natural wear,
was caused by unfavorable operating conditions or is due to violations against our operating
regulations or against rules of good electrical engineering practice, or if our request to return the
defective object is not promptly complied with.
Please be advised that any subsequent improvement shall only be free of charge if a defect is
found. Any form of technical support, maintenance and customization is not a warranty service, but
instead shall be charged extra.
Additional guarantees
Although the hardware and software was developed and tested in-depth with greatest care,
Hilscher Gesellschaft für Systemautomation mbH shall not assume any guarantee for the suitability
thereof for any purpose that was not confirmed in writing. No guarantee can be granted whereby
the hardware and software satisfies your requirements, or the use of the hardware and/or software
is uninterruptable or the hardware and/or software is fault-free.
It cannot be guaranteed that patents and/or ownership privileges have not been infringed upon or
violated or that the products are free from third-party influence. No additional guarantees or
promises shall be made as to whether the product is market current, free from deficiency in title, or
can be integrated or is usable for specific purposes, unless such guarantees or promises are
required under existing law and cannot be restricted.
Confidentiality
The customer hereby expressly acknowledges that this document contains trade secrets,
information protected by copyright and other patent and ownership privileges as well as any related
rights of Hilscher Gesellschaft für Systemautomation mbH. The customer agrees to treat as
confidential all of the information made available to customer by Hilscher Gesellschaft für
Systemautomation mbH and rights, which were disclosed by Hilscher Gesellschaft für
Systemautomation mbH and that were made accessible as well as the terms and conditions of this
agreement itself.
The parties hereby agree to one another that the information that each party receives from the
other party respectively is and shall remain the intellectual property of said other party, unless
provided for otherwise in a contractual agreement.
The customer must not allow any third party to become knowledgeable of this expertise and shall
only provide knowledge thereof to authorized users as appropriate and necessary. Companies
associated with the customer shall not be deemed third parties. The customer must obligate
authorized users to confidentiality. The customer should only use the confidential information in
connection with the performances specified in this agreement.
The customer must not use this confidential information to his own advantage or for his own
purposes or rather to the advantage or for the purpose of a third party, nor must it be used for
commercial purposes and this confidential information must only be used to the extent provided for
in this agreement or otherwise to the extent as expressly authorized by the disclosing party in
written form. The customer has the right, subject to the obligation to confidentiality, to disclose the
terms and conditions of this agreement directly to his legal and financial consultants as would be
required for the customer's normal business operation.
Export provisions
The delivered product (including technical data) is subject to the legal export and/or import laws as
well as any associated regulations of various countries, especially such laws applicable in
Germany and in the United States. The products / hardware / software must not be exported into
such countries for which export is prohibited under US American export control laws and its
supplementary provisions. You hereby agree to strictly follow the regulations and to yourself be
responsible for observing them. You are hereby made aware that you may be required to obtain
governmental approval to export, reexport or import the product.
8.4 Contacts
Headquarters
Germany
Hilscher Gesellschaft für
Systemautomation mbH
Rheinstrasse 15
65795 Hattersheim
Phone: +49 (0) 6190 9907-0
Fax: +49 (0) 6190 9907-50
E-Mail: [email protected]
Support
Phone: +49 (0) 6190 9907-99
E-Mail: [email protected]
Subsidiaries
China Japan
Hilscher Systemautomation (Shanghai) Co. Ltd. Hilscher Japan KK
200010 Shanghai Tokyo, 160-0022
Phone: +86 (0) 21-6355-5161 Phone: +81 (0) 3-5362-0521
E-Mail: [email protected] E-Mail: [email protected]
Support Support
Phone: +86 (0) 21-6355-5161 Phone: +81 (0) 3-5362-0521
E-Mail: [email protected] E-Mail: [email protected]
France Korea
Hilscher France S.a.r.l. Hilscher Korea Inc.
69500 Bron Seongnam, Gyeonggi, 463-400
Phone: +33 (0) 4 72 37 98 40 Phone: +82 (0) 31-789-3715
E-Mail: [email protected] E-Mail: [email protected]
Support
Phone: +33 (0) 4 72 37 98 40 Switzerland
E-Mail: [email protected] Hilscher Swiss GmbH
4500 Solothurn
India Phone: +41 (0) 32 623 6633
Hilscher India Pvt. Ltd. E-Mail: [email protected]
Pune, Delhi, Mumbai Support
Phone: +91 8888 750 777 Phone: +49 (0) 6190 9907-99
E-Mail: [email protected] E-Mail: [email protected]
Italy USA
Hilscher Italia S.r.l. Hilscher North America, Inc.
20090 Vimodrone (MI) Lisle, IL 60532
Phone: +39 02 25007068 Phone: +1 630-505-5301
E-Mail: [email protected] E-Mail: [email protected]
Support Support
Phone: +39 02 25007068 Phone: +1 630-505-5301
E-Mail: [email protected] E-Mail: [email protected]