5100 V4.04 Firmware Release

Transcription

1 5100 V4.04 Firmware Release

2 Blank Page Page 2 of 76

3 1.0 OVERVIEW AND FEATURES FILE TRANSFER PROTOCOL (FTP) 7 SUPPORTED FTP COMMANDS TELNET FLASH DISK SCRIPT LANGUAGE 17 SCRIPT FILE NAMING/ACCESS 17 BOOT SCRIPT 17 DATA TABLE FILE NAMING/ACCESS (NOT IMPLEMENTED) 18 SCRIPT EXECUTION 18 SCRIPT/FTP/TELNET COMMANDS 19 disable 19 enable 19 get 21 help 23 set 23 reset 24 run 25 update 25 FILE COMMANDS 26 SPECIAL REGISTERS 27 EXAMPLES SCRIPTS/COMMANDS 28 FTP Sessions 28 Script file SCRIPT GROUPS 29 GROUP [NETWORK] 29 GROUP [SECURITY] 30 GROUP [COMMANDS] SAMPLE 5100.INI FILE FORMATTED MESSAGING 35 MESSAGE STRING TRANSMISSION COMMUNICATION PROTOCOLS 36 OVERVIEW 36 TCP CLIENT/SERVER RAW SOCKET SESSIONS 36 Client 36 Server 37 Lantronix CoBox interface 38 MODBUS 39 Modbus TCP Slave 39 Page 3 of 76

4 Modbus TCP Master 45 Modbus Serial RTU 45 CTNET BINARY PROTOCOL (SERVER) 47 UDP PEER TO PEER 47 Peer-to-Peer Protocol Registers 47 SNTP SIMPLE NETWORK TIME PROTOCOL (RFC-2030) FIRMWARE UPDATES AND VERSION CONTROL LOADABLE C USER PROGRAMMABLE FUNCTIONS AND FILTERS 56 COMPILER 56 DISTRIBUTED C FILES: 56 FEATURES 57 Resource Filters 57 Tasks 57 Communications 57 Motion Control 57 Program Control 57 Expansion 57 Tools 58 RESOURCE FILTER EXAMPLE 58 VIRTUAL TABLE, USER AND QUICKSTEP 59 VTABLE_QS FUNCTION PROTOTYPES AND DEFINITIONS 62 REGISTER ACCESS 62 COMMUNICATIONS 64 DIAGNOSTICS 67 MOTOR CONTROL 67 RESOURCE FILTERS 67 SYSTEM FUNCTIONS 69 THREADING 70 The information in this document is subject to change without notice. The software described in this document is provided under license agreement and may be used and copied only in accordance with the terms of the license agreement. The information, drawings, and illustrations contained herein are the property of Control Technology Corporation. No part of this manual may be reproduced or distributed by any means, electronic or mechanical, for any purpose other than the purchaser s personal use, without the express written consent of Control Technology Corporation. Page 4 of 76

5 1.0 Overview and Features With the release of 5100 firmware revision 4.04 and above, a number of new features are available or have been enhanced. Most of these features are in the area of communications, while a number of significant ones allow for greater programming flexibility. In summary features are as follows:! Flash Disk o Structured support and storage for firmware flash updates o Quickstep program storage and dynamic loading. o Recipe storage o FTP and Telnet interface o Standard disk utilities! Script language o Powerful commands to initialize registers, load datatables, programs, configure the system o Executable from within Quickstep o Executable from telnet and ftp command line o Executable at powerup or reset o Executable from within other script files! Communications o Telnet Server for remote administration interface o FTP Server o Modbus/TCP slave o Modbus/TCP master o Modbus RTU serial slave o UDP Peer to Peer o TCP client/server raw socket interface, bidirectional o CTNet Binary protocol o Up to 7 serial ports, 2 local and 5 virtual TCP to terminal servers or host applications o Configurable connection throttling to enhance overall system performance o String formatted output messages with embedded register values from within Quickstep (printf format). o SNTP Time Server synchronization for real time clock.! Remote diagnostics and updates o Remote firmware updates via ftp and telnet. All firmware field upgradeable. o Module firmware can be stored to flash disk for later updates. o Can determine contents of 5100 modules via telnet along with version info. o Low level logging and debug functions for CTC remote field support.! C User Programming Integration o Loadable, compiled C program modules to enhance features. o Virtual function hooks for! Communications protocols! User background threads Page 5 of 76

6 ! Full register and 5100 resource interface! Quickstep tasking control o Run able C functions as Quickstep tasks o Installable register/resource data filters/conversion for Quickstep access o Full floating point support. o Runs completely in parallel and transparent to Quickstep thereby enhancing its capabilities. Page 6 of 76

7 2.0 File Transfer Protocol (FTP) The File Transfer Protocol FTP is a significant Internet standard for file transfer. The current specification is contained in RFC-959. The 5100 operates as an FTP Server, implementing a sub-set of the standard for operation in a control environment, with a minimum file system. As detailed in Section 4.0, a flash disk is resident within the The primary means to transfer data to and from the 5100 is via FTP. You can download, delete, or transfer files to and from the controller and have the support of a directory architecture that resembles that found on typical computer systems. For more information on FTP, refer to Chapter 3, of the Network Protocols Manual. Supported FTP Commands The following FTP commands are supported by the 5100: cd- Change to a different directory. delete- Delete a file. dir - Displays a directory and the amount of flash memory that is available, used up, or deleted. get - Copies a file from the 5100 to a local directory on your computer. Example: get filename.ext ls - Lists files in the current directory. "ls -l" is equivalent to the "dir" command. ls!<cmd> Invoke a Script Language command, refer to section 5.0 mget - Copies multiple files from the 5100 to a local directory on your computer. Wild cards are limited to files with the same file extension. For example, mget*.html copies all.html files from the 5100 s directory to your local directory. mkdir - Create a new directory inside the current 5100 directory. mput - Copies multiple files to the 5100 from a local directory on your PC. Wild cards are limited to files with the same file extension. For example, mput*.html copies all.html files from your local directory to the 5100 s directory. put - Copies a file from a local directory on your computer to the Example: put filename.ext pwd - Displays the current directory on the Page 7 of 76

8 quit - Quit the FTP session. recv - This command functions the same as "get". rmdir - Remove directory. send - This command functions the same as "put". Note: Only binary file transfers are supported FTP is shipped standard with UNIX, Windows 2000 and XP products. On Windows systems it is typically invoked from the command line, although graphical interfaces are also available (see Section 4.0). When invoked from the command line the user will be prompted for a user ID and a password. The default shipping ID/Password is: User admin Password BlueFusion This is standard for all user login sequences, including Telnet. Failure to enter the proper User ID and Password will result in disconnection. A typical session is shown below as an example: Figure 2.0: Typical FTP Windows command line session Page 8 of 76

9 3.0 Telnet The 5100 supports a full Telnet administrative interface. Telnet is a standard internet remote login application protocol (RFC-854) which is available on almost every computer platform. A number of standard interfaces exist, both graphical and command line. Windows 2000 and XP products ship with a command line interface which can be invoked by typing telnet at a command prompt. Available commands may be display by typing help, once invoked: Figure 3.0: Windows telnet screen Typically all that is required is typing telnet and the ip or dns name of the desired 5100 controller. For example telnet , a sample screen is shown below: Figure 3.1: Telnet login screen for 5100 controller Page 9 of 76

10 Graphical Telnet programs are also available. One example is from MidaSoft another would be WS_FTP from Ipswitch ( MidaSoft is: Once a telnet screen is invoked and User Login and Password (admin/bluefusion as with FTP) sequence satisfied, numerous commands are available. These commands are detailed in Section 5.0, Script Language. Each Script Language command is accepted within FTP (ls!<cmd>), Telnet, or as the contents of a script file. Below is the MidaSoft screen showing the help screen display: Figure 3.2: Telnet graphical screen displaying help commands for 5100 controller Page 10 of 76

11 Figure 3.3: Telnet graphical screen displaying help commands for 5100 controller, cont d As can be seen from above there is an extensive assortment of commands. The above does not include the low level debug functions available for advanced users, figure 3.4. Refer to Section 5.0 for more information in this regard. Page 11 of 76

12 Figure 3.4: Telnet graphical screen displaying low level debug commands Page 12 of 76

13 4.0 Flash Disk A flash disk, with an approximate size of 900K bytes, is available for general use. The disk may be read or written during program operation, with write operations only causing a slight degradation in system performance. The disk appears much like that of your typical personal computer; in fact, many of the standard commands of MSDOS TM are available for administration via telnet. Simplified administration can be done using a number of low cost shareware ftp programs, such as FTP Voyager, Below is a typical FTP session using a graphical representation. Figure 4.0: Typical FTP graphical session (FTP Voyager) Page 13 of 76

14 General usage and configuration is beyond the scope of this document but as a brief introduction, it functions much like typical PC Windows program where the top two window regions are for the remote 5100 device, the middle two are your local hard disk, and the bottom two are for display only showing current operations, command status and file transfers. Typically the left window region (top two) is for directory tree information and the right two is for sub-directory and file operations, exactly like Windows Explorer. The flash disk is made up of a reserved _system directory created at the root of the drive; within this folder are a number of other subdirectories with special functionality. Figure 4.1: Graphical system directory representation Figure 4.2: Command line Sub-Directories: o Datatables All Quickstep loadable datatable images are required to be here. o Firmware All modules, monitor, and communications firmware that is to be loadable using the update command must be located here (see Section 10). o Messages The message.ini file, for formatted output messages must be stored here. o Programs All Quickstep programs (.dso files) should be placed here if they are to be run from scripts or telnet commands using the run program qsprog.dso type command. o Scripts All system scripts,.ini files, except messages, should be placed in this sub-directory. Page 14 of 76

15 Disk administrative tasks can be generally done either via FTP or telnet, supporting the standard dir, cd, mkdir, rmdir, delete, type commands. Directory references use the forward slash /, like UNIX, not the backward slash like MSDOS TM, in order to be compliant with standard ftp programs. Also note that all filenames are case sensitive and you are limited to 79 characters total for directory and filenames, combined. When using the FTP graphical approach, right clicking the mouse on the relevant window typically allows you to create your own subdirectories, while dragging and dropping a file to a folder causes a transfer to occur and the file to be stored to the flash disk. Figure 4.3: FTP graphical folder creation The only exception to this is dragging and dropping either a firmware update or a Quickstep program (.dso,.sr,.bin file extensions), to the root directory / will cause that file to be cached in dynamic ram instead of written to the flash disk and then immediately activated upon complete transfer. If it is a Quickstep program, the system will be stopped, the program loaded into non-volatile memory, and restarted with the new program, if a.sr or.bin file the appropriate firmware update will be applied. Refer to the firmware update section for any special system resetting required since VBIAS is turned off during an update to ensure system safety. A telnet reset command must be initiated to reboot the system properly. The flash disk must be periodically re-formatted if files are deleted a lot. This is because deleted files are marked as deleted but reclaiming their space and erasing flash is typically too time consuming in a real-time control environment. As such, the telnet administrative session or a script file can be setup to execute the format flash command whenever needed. One nice thing of most graphical FTP programs is they allow for directory synchronization. This means if you keep a backup of your files at the PC you simple have to tell the software to synchronize the folders and all data will be restored after a format. The available disk space may be displayed at any time by using the dir command within a telnet or ftp session. The amount of space consumed by deleted files will also be soon, refer to Figure 2.2, next to the last line where it referenced Deleted , this refers to 732 bytes currently wasted by deleted files. Page 15 of 76

16 As with anything that is flash based, the technology is limited to the number of write operations you can perform before it is no longer useable. Due to this limitation you should not perform continual writing to flash from within a program. It is really meant to be written to a limited number of times and read as often as you like. Even with this limitation, it is rather large, you can have up to 100,000 erase cycles before you can expect errors to occur. This should be more than sufficient for any operation. Note that when transferring firmware updates and Quickstep files to the system root directory no flash write operations occur. Page 16 of 76

17 5.0 Script Language The 5100 supports a powerful script command language that can perform numerous operations either under program control, or via a ftp/telnet command line interface. The individual commands can also be executed, standalone when ftp/telnet is used. Some of the functionality available is: Under Quickstep Program Control: 1. Save and load data tables from a resident flash disk (not implemented). 2. Save sets of registers and restore from flash disk. Saving dynamically creates a new script file for later playback. 3. Load alternate Quickstep programs for execution. 4. Ability to run script command files (.ini files). Nested scripts are also allowed. FTP/Telnet: 1. Retrieve firmware version information on all processors in the system along with what modules are installed. 2. Update of firmware for all processors, including modules. 3. Control of Quickstep program state, RESET, RUNNING, RESTART 4. Query of Quickstep program state. 5. Ability to read/write registers and blocks of registers. 6. Ability to run script command files (.ini files). 7. Load alternate Quickstep programs for execution. 8. Advanced remote diagnostics. Script File Naming/Access Script files are text files consisting of various commands as defined in the Script Command section of this document. All script files must reside within the flash disk directory /_system/scripts and are of the naming convention Script001.ini, Script002.ini, The 001, 002 numeric part of the file name reference the value that must be written to the Script Register (12311) in order for that script to be executed. For example for a Quickstep program to run Script001.ini it would write a 1 to the Script Register. That task would then run the Script to completion before any other task was allowed to execute. Upon execution a read of the Script Register will return the number of the last script executed. A read of the Script Result Register (12312) will return a 1 if successful, else and error code. Boot Script At power up and system reset a script file by the name of 5100.ini will automatically be executed if it is resident on the flash disk within the /_system/scripts sub-directory. All script commands are valid within this initialization file in addition to special unique system configuration sections. Also transferring this file to the 5100 will cause immediate exection of all sub-sections except [COMMANDS]. A reset will be required to activate Page 17 of 76

18 any IP address informational changes, ie., ip, subnet mask, or gateway. Beware the if you change any IP information using CTMON the 5100.ini file will be automatically deleted. This is necessary since a reboot would cause the 5100 to override any CTMON settings. Data Table File Naming/Access (not implemented) Data table files are in a special binary format, allowing for fast transfer and are not compatible with Quickstep Program generated files. All data table files must reside within the flash disk directory /_system/datatables and are of the naming convention Datatable001.dat, Datatable002.dat, The 001, 002 numeric part of the file name reference the value that must be written to the Data Table Transfer Register (12313) in order for that table to either become the current table or the values of the current table to be written to it. Writing a 1 to the Data Table Transfer Register causes the current data table to be written to Datatable001.dat. Writing a 1001 to the Data Table Transfer Register causes the contents of Datatable001.dat to be transferred to memory, the contents becoming the current data table. Upon execution, a read of the Data Table Transfer Register will return the number of the last data table loaded. A read of the Data Table Result Register (12314) will return a 1 if successful, else and error code. Script Execution Scripts are executed either via an FTP/Telnet session command line, from within another script, or by writing a value to the Script Register. When executed by a Quickstep program, via the Script Register write, the script is run to completion, atomic to that step. When executed by an FTP/Telnet session it is run totally in the background and in parallel to Quickstep execution. If issuing critical commands it is recommended that an enable safe command be executed first. This command stops the execution of quickstep. It is actually good practice to have a enable safe command in the beginning of the script file whenever FTP or external communication may cause a script to execute. This command guarantees no Quickstep task will be executing when the script is executing. enable safe has no effect if executed by a Quickstep program triggered task, since it is atomic to that task. This command is automatically done during firmware updates. Page 18 of 76

19 Script/FTP/Telnet Commands Note: The screen examples shown for the commands described below are from a PC telnet session, refer to the section discussing telnet for more detail. They may also be run from within FTP using the ls command with the command surrounded by double quotes and an! preceding the command. For example, disable debug, becomes ls!disable debug. Refer to FTP for more detail. Typically either telnet is used or the commands are stored on a single line within a text.ini file. disable disable debug Turns the low level debug functionality off. Typically this is reserved for CTC personnel. disable safe Allow quickstep programs to run again after they have been placed in a safe state with the enable safe command. Programs are resumed with the first task being allowed to run from where it left off. Figure 5.0: disable safe command disable sntp monitor Disables UDP debugger printouts of sntp packet information. By default it is disabled. enable enable debug Turns the low level debug functionality on. The low level debugger allows you to monitor the state of various program threads, view logs thread logs, read/write bytes of memory, check the state of program mutexes, etc. Typically things only CTC personnel would be interested in while trying to diagnose a problem remotely, hence a detailed explanation of the commands is not given other than its help screen, which may be of interest to some: Page 19 of 76

20 Figure 5.1: enable debug command enable safe Set a program to a safe stopped state. A flag is set that allows Quickstep to finish executing its present instruction at which point communications is allowed to continue but the program is not. Typically it is best to do a set restart to restart the programs after being placed in a safe state. Optionally disable safe may be executed to resume where you left off (begins with the first task running again from where it left off). safe state is required for loading new data tables, etc. At present most commands automatically invoke the safe state prior to execution so it is not necessary to use this command. Reference those commands directly to see if a safe state is not automatically invoked. Figure 5.2: enable safe command enable sntp monitor Enables UDP debugger printouts of sntp packet information. Typically used to verify operation by technical support. By default it is disabled. Page 20 of 76

21 get get datatable Datatable###.dat (not currently implemented) Loads the named Quickstep data table from the flash disk directory /_system/datatables, making it the active data table. It is suggested that the set safe command be executed prior to this command to ensure the Quickstep program is not accessing the current data table. Note that the.dat image is a binary file with a special format, designed for fast, direct loading and replacement of the existing data table. It is not the same format output by the Quickstep development system. This command may be executed directly within a script, via the command line of FTP/Telnet, or by writing the number ### specified within the file name, to the Data Table Transfer Register. For example to load Datatable002.dat, write a 1002 to the Data Table Transfer Register. get date or date Display the settings of the real-time clock, example: Figure 5.3: get date or date command get register ##### Displays the current value of a data register, during an FTP/Telnet session. When this command is run within a script the contents of the register can be written to another script for later playback, if desired. Reference the section below detailing script recording capabilities. To read a block use the syntax #####-#####. You may also list other registers, using a comma delimiter, for example #####-#####, #####-#####, ##### Note that a? is returned as a value if not a valid register. Figure 5.4: get register command get status Displays the current program status during an FTP session. Page 21 of 76

22 Figure 5.5: get status command get throttles Displays detailed information with regards to connection throttling settings. Connection throttling allows you to balance the load on the controller between response time to a request and allowing other things to run. Typically you want to respond quickly to a request but if another request is immediate you may want to delay in responding. This is important since some network computers will poll as fast as possible, requesting information immediately after a response. In general this results in performance degradation. Throttling gives the best of both worlds, respond immediately to a certain number of requests but then delay if the host requests information too rapidly. The get throttles command returns two sets of data in a format that can be redirected to a script file if desired. The first block is the default values for each supported protocol type, the second block are all currently active connections, if any: Figure 5.6: get throttles command Note that for the default values the ip= setting. get versions Displays the current firmware revision levels, serial number, and MAC Address of the unit, along with what modules reside in what slots. Figure 5.7: get version command Page 22 of 76

23 help A complete help screen is available via the help command. Individual help for different group may be invoked by typing help followed by the group. For example help set would display: Figure 5.8: help set command Refer to the telnet discussion in Section 3.0 for further display examples. set set datatable Datatable###.dat (not currently implemented) Writes the existing data table, in memory, to the specified data table file on the flash disk within the subdirectory /_system/datatable. Command is executed directly from within FTP/Telnet, a script file, or by a Quickstep program writing ### to the Data Table Transfer Register. set register ##### = ##### Sets a register to a particular value. A block may be set to a particular value by using #####-##### as a range. Figure 5.9: set register command set reset Sets the current Quickstep program state to RESET. set restart Restarts the current Quickstep program. Page 23 of 76

24 set running Resume the execution of Quickstep programs, from a stopped state. set stopped Sets a Quickstep program to the stopped state. set throttle {conntype=} {protocol=} {ip=} {port=} {packetcnt=} {pause=} {inactivity=} Set the connection throttling parameters for a particular network connection or change the default values used for a particular protocol. Reference get throttles for a higher level description of throttling. Parameter settings are as follows, if one is not included on the command line the default will be used: {conntype=} NETWORK, default (only type currently supported). {protocol=} UDPBINRY, TCPBINARY, CTNETBINARY, or ANY (default) {ip=} ip address of node, Example: , if (default) then sets default values used for new connections. {port=} unsigned short value 1024 to 65536, -1 means any port (default). {packetcnt=} number of packets/requests that can be requested consecutively, if - 1 (default) then use default value for protocol type selected. {pause=} milliseconds to pause after a burst, if 1 (default) then use default value for protocol type selected. {inactivity=} idle time before reset consecutive packet/request counter, if 1 (default) then use default value for protocol type selected. Below is an example of changing the default pause time for TCPBINARY protocol connections from the default of 50ms to 175ms. Note that the protocol type must be included when changing the defaults, protocol ANY is only for setting an actual ip address, not the default: Figure 5.10: set throttle command reset reset This command will cause a watchdog reset to occur, resetting the unit as is done during a power up sequence. Any network connections will be lost. Page 24 of 76

25 run run script Script###.ini Execute the named script. The script file must be resident on the flash disk in the /_system/scripts subdirectory. run script Script###.ini > Script###.ini Execute the named script and any registers that are read, their contents are written to the output named script in such a way that if the output named script file is executed the register values will be written back to their corresponding registers. This command would cause a get register command to have a line written to the designated.ini file. See the register alternate get/set command defined below. run program qsprogram.dso Loads the named Quickstep program for execution from the flash disk directory /_system/programs and begin its execution, replacing the present program in memory. This is identical to transferring a program over the serial port or via FTP to non-volatile memory. The program will stay in battery backed memory until it too, is replaced. update update comm Re-flash the Atmel serial communication chip on the main board. The file comm.sr must be resident in the /_system/firmware subdirectory for a successful update to occur. update 5130 Re-flash any analog modules found on the bus. The file 5130.sr must be resident in the /_system/firmware subdirectory for a successful update to occur. update 5140 Re-flash any servo modules found on the bus.. The file 5140.sr must be resident in the /_system/firmware subdirectory for a successful update to occur. update 5150 Re-flash any stepper modules found on the bus. The file 5150.sr must be resident in the /_system/firmware subdirectory for a successful update to occur. update modules Re-flash all modules and Communications firmware with that available on the flash disk. The firmware files must be located in the /_system/firmware subdirectory. ##### Read the specified register, same as get register command. To read a block of registers use #####-#####, for example to read 1000 to 1050, would be entered. You may also list other registers, using a comma delimiter, for example #####-#####, #####- #####, ##### Page 25 of 76

26 ##### = ##### Write a value to the specified register, same as the set register command. Note this is the output format used by the run script Script###.ini > Script###.ini command for playback. To clear a block enter the same syntax as with a read, for example to clear 1000 to 1050 to 0, = 0 would be entered. File commands cd Change the current working directory: Figure 5.11: cd command delete Delete a file in the current directory. Syntax delete filename. dir Display the current directory contents: Figure 5.12: dir command mkdir Create a new directory/folder in the current directory; a path other than the current may also be given. Page 26 of 76

27 Figure 5.13: mkdir command pwd Display the current path. Figure 5.14: pwd command rmdir Remove a directory contained within the current directory. Special Registers Script Register Register 12311, writing a numeric to this register will cause the corresponding script to be executed, for example: write a 4 and Script004.ini is executed. Script Result Register Register 12312, 1 = successfully executed, else error code (TBD). Data Table Transfer Register Register 12313, writing a numeric to this register will cause the current data table to be saved to the corresponding script, writing the numeric within the filename will cause an existing file within the flash disk to be loaded into memory, becoming the current data table. For example: write a 4 and Datatable004.dat is loaded and its values made the current table. (to be implemented in a future release) Data Table Result Register Register 12314, 1 = successfully executed, else error code (TBD). Flash Disk Space Register Register 12315, contains the approximate free space available on the flash disk. Page 27 of 76

28 Examples Scripts/Commands FTP Sessions ls!get versions < version information displayed> ls!set safe < Quickstep in Safe Mode> ls!update modules < results displayed > ls!set restart < Quickstep restarted> Script file # This is a comment line # set register 1000 to a 2 set register 1000 = 2 # this is another comment 1000 = 2 # this is another way to do the same thing # # read a bunch of registers, if the script is run with the > Script###.ini command then # contents of the register will be sent to the file for later replay, otherwise the read will # be done but data thrown away. # read the contents of to get register # read registers 100 to 500 as a block but using the shorter command # run another script file from within this file run Script002.ini # save our existing data table file (could be done by Program without script # but not with this type of filename, ### not needed in name) save datatable CurrentRecipe.dat #load in a new one load datatable AlternateRecipe.dat Page 28 of 76

29 Script Groups Group [NETWORK] The Network Group is used to define communication address parameters, such as IP addresses, ports, protocols to enable, etc. It is used as a logical text separator within a Script file. IP_ADDRESS This is the IP address identifying this 5100 board on the network. Enter each of 4 octets, separated by a dot. A change will only be recognized during powerup. SUBNET_MASK This is the IP subnet mask of the network that we are operating on. Enter each of 4 octets, separated by a dot. A change will only be recognized during powerup. GATEWAY_ADDRESS This is the IP address that packets are to be sent to if they do not reside on your network. Typically a router address. If none is present enter which is the factory default. A change will only be recognized during powerup. ETHERNET_MAC_ADDRESS This is the 6 byte unique address of the 5100 card which is transmitted in the header of every network packet as an identifier. It must be unique and is assigned by Control Technology. Information with regards to the assigned address is included with the board. All Control Technology addresses begin with 00.C0.CB, the remaining three bytes are unique to each board. By default the serial E2Prom is loaded at the factory with the proper ID and this line is not required except to reinitialize non-volitale storage. A change will only be recognized during powerup. CTCNET_DEVICENODE This is the single byte, unique address that this 5100 is to be known by on the network if the CTCNET protocol is to be used. By factory default it is set to 0, not enabled. A change may be made dynamically. A zero, 0, will disable the protocol and conserve CPU resources. BINARYUDP_SERVER_PORT This is the IP port that the 5100 should listen for CTC Binary Protocol UDP request packets on. By default it is set by the factory to port A change will only be recognize during powerup. A zero, 0, will disable the protocol and conserve CPU resources. BINARYTCP_SERVER_PORT - This is the IP port that the 5100 should listen for CTC Binary Protocol TCP request packets on. By default it is set by the factory to port A change will only be recognize during powerup. A zero, 0, will disable the protocol and conserve CPU resources. PEERTCP_SERVER_PORT This is the IP port that the 5100 should listen for CTC Peer to Peer register request packets on. See [PEER_INITIALIZATION] for details of how to access and initialize peer to peer operation. By default it is set by the factory to port Page 29 of 76

30 4500. A change will only be recognize during powerup. A zero, 0, will disable the protocol and conserve CPU resources. MODBUSTCP_SERVER_PORT - This is the IP port that the 5100 should listen for ModBus TCP register command packets. See Section X.X for more information on the use of ModBus. By default it is set by the factory to port 502. A change will only be recognize during powerup. A zero, 0, will disable the protocol and conserve CPU resources. MODBUSTCP_CLIENT_PORT - This is the IP port that the 5100 should initiate and ModBus TCP register command packets on. Unlike Server mode, in this case we are the client and expect to be communicating with another host or controller server process. See Section X.X for more information on the use of ModBus Client protocol. By default it is set by the factory to port 502. A change will only be recognize during powerup. A zero, 0, will disable the protocol and conserve CPU resources. THROTTLE _CONNECTION These are the parameters with which to throttle a network connection. Some protocols, such as CTNET poll the controller at high speed but many times the data is not needed that quickly or it is only needed in bursts. This parameter allows you to set the number of packets that can be processed within a particular timing window and an inactivity timer to reset the delay for burst mode. THROTTLE_CONNECTION = {protocol} {IP info} {port info} {timing parameters} Group [SECURITY] The SECURITY Group restricts access to the 5100 controller. You can toggle certain communication protocols ON/OFF and can enter ranges of IP addresses for the different services that are available. As a security measure, these IP addresses are checked before access is granted to a resource. The standard method of requesting a username and password is not required. Multiple entries are allowed and each is checked until permission is granted or no more entries exist. An entry consists of an IP address (or range of IP addresses) followed by a list of what is allowed (a blank entry indicates that everything is allowed). The default setting allows all accesses when security is not defined. Each IP Address has the following options that you can enable or disable: FTPREAD - Allows FTP file read-only access. FTPRW - Allows FTP read and write access; does not allow formatting or loading programs. PEERUDP - Allows peer-to-peer communications using UDP. BINARYUDP - Allows binary protocol UDP communications. BINARYTCP - Allows binary protocol TCP communications. Page 30 of 76

31 MODBUSTCP - Allows Modbus Server protocol TCP communications. CTCNET - Allows certain nodes to have access using the CTNet protocol. It is defined by setting the first three octets to 0 and the last octet to the allowable address (0.0.0.#). Place at the beginning of the list to speed up access. The default setting is that all nodes are allowed. The following examples show how these options work: WEB - Allows Web read access. FTPREAD - Allows FTP file read only. FTPRW - Allows FTP read and write, no format or program loading. PEERTCP - Allows peer to peer communications via TCP. BINARYUDP - Allows binary protocol UDP communications. BINARYTCP - Allows binary protocol TCP communications. MODBUSTCP - Allows Modbus Server protocol TCP Communications. CTCNET Allows certain nodes access using the CTCNET protocol. Defined by setting the first three octets to 0 and using the last one to list the address allowed. (0.0.0.#). Place at the beginning of the list speed up access. By default all nodes allowed Examples: # Allow CTCNET nodes 10 to 20 to have access #This allows all access, no restrictions from this IP Address WEB # Web only, no FTP access from this IP Address WEB FTPREAD # Web, and FTP access from this IP Address PEERTCP #Only peer comm. allowed in this range # Range of IP addresses allowed full access Group [COMMANDS] The COMMAND Group allows you to run the commands defined within the script language inside a file. By default if no section name is given this is the section assumed. Each command is sequentially executed so take care that it is the proper sequence. For example to set register to a CTCNET node of 50 enter: = 50 this does the same thing as defined in the NETWORK group. See the sample 5100.ini file for further examples. Page 31 of 76

32 7.0 Sample 5100.ini File Sample 5100.ini text file, each line terminated with a CR LF: [NETWORK] IP_ADDRESS = SUBNET_MASK = GATEWAY_ADDRESS = # to disable CTCNET_DEVICENODE = 35 # CTCNET Protocol device ID for us # Setting any of the below PORTs to 0 will disable comm. protocol. #BINARYUDP_SERVER_PORT = 3000 # Binary protocol UDP port #BINARYTCP_SERVER_PORT = 6000 #Binary protocol TCP port #PEERTCP_SERVER_PORT = 4500 # Peer to Peer Communications TCP Port #MODBUSTCP_SERVER_PORT = 502 # Modbus/TCP Comm.TCP Port #MODBUSTCP_CLIENT_PORT = 502 # Modbus/TCP Comm TCP Port #SERIALREDIRECTION_SERVER_PORT = 4250 # Serial Redirection TCP Port # Below is based in milliseconds BACKPLANE_DEFAULT_TIMEOUT = 250 # Dualport Backplane packet timeout PEER_DEFAULT_TIMEOUTS = 500 # Single request Peer packet timeout [SECURITY] # If below is left undefined then all IP addresses are allowed with all permissions #Otherwise each Address can be limited to access permissions # IP address may be followed by any of the following, if blank all access is allowed # else if anything is specified only that listed is allowed # WEB - Allows Web read access # FTPREAD - Allows FTP file read only # FTPRW - Allows FTP read and write, no format or program loading # PEERUDP - Allows peer to peer communications via UDP # PEERTCP - Allows peer to peer communications via TCP (not implemented yet) # BINARYUDP - Allows binary protocol UDP communications # BINARYTCP - Allows binary protocol TCP communications # MODBUSTCP - Allows Modbus protocol TCP Communications # #This allows all access (supervisor, no restrictions) # WEB # Web only, no FTP access # WEB FTPREAD # PEER #Only peer comm. is allowed # # Unrestricted access available to this address # # Range of IP addresses allowed general access [COMMANDS] Page 32 of 76

33 # Registers are initialized in the order given, values are in decimal # Any block not monitored will be filled in with zero's. Add other Peer blocks as # required # Controller = 4 # Set the number of registers in block first for allocation = 12 # Now set peer IP address = = = = = 2 # Set protocol to Modbus Master = 0 # Set back to way was = 8001 # Set the register to start monitoring = 50 # Set number of milliseconds between updates # Controller = 4 # Set the number of registers in block first for allocation = 12 # Now set peer IP address = = = = = 2 # Set protocol to Modbus Master = 0 # Set back to way was = 8001 # Set the register to start monitoring = 50 # Set number of milliseconds between updates # It is even possible to monitor our own registers and have them available for both local # and remote reference. Below a number of IO points are monitored. The register # list is also that required for the special Binary Protocol TCP System IO command 0x53. #Analog Out = 128 # Set the number of registers in block first for allocation = 12 # Now set peer IP address to ourself = = = = 8001 # Set the register to start monitoring = 50 # Set number of milliseconds between updates, writing timer starts poll #Analog In = 128 # Set the number of registers in block first for allocation = 12 # Now set peer IP address to ourself = = = = 8501 # Set the register to start monitoring = 50 # Set number of milliseconds between updates, writing timer starts poll #Digital Out = 10 # Set the number of registers in block first for allocation Page 33 of 76

34 21040 = 12 # Now set peer IP address to ourself = = = = # Set the register to start monitoring = 50 # Set number of milliseconds between updates, writing timer starts poll #Digital In = 10 # Set the number of registers in block first for allocation = 12 # Now set peer IP address to ourself = = = = # Set the register to start monitoring = 50 # Set number of milliseconds between updates, writing timer starts poll #Regs 901 to = 100 # Set the number of registers in block first for allocation = 12 # Now set peer IP address to ourself = = = = 901 # Set the register to start monitoring = 50 # Set number of milliseconds between updates, writing timer starts poll Page 34 of 76

35 Formatted Messaging Message String Transmission The 5100 is capable of transmitting string-formatted messages, similar to the format supported by the C function sprintf. Each message may consist of just text and/or embedded references to any number of registers, whose values will be substituted just prior to transmission. Message format definitions are stored as records in a file called message.ini which is located in the /_system/messages subdirectory of the flash disk. Each line of message.ini is considered a record, from 1 to a maximum of 50 messages. Messages are written to the default communications port set in register 12000, which is the standard Serial port selection register in Quickstep. The selection of which record to dynamically format and write out the communications port is by writing to the Message String Transfer Register (12316). A read returns the status of the write, with 0 meaning success. The 5100 supports up to 7 communication ports, two of which are dedicated to RS232 and the remaining 5 assigned by the program as bidirectional TCP redirector ports. The redirector ports appear to Quickstep as RS232 ports, but actually either connects to a remote terminal server or host based application program Typically a message consists of text with a sprintf formatted specification, followed by r####, where #### is the desired register. Therefore to read register 8501 to be exactly 5 characters with preceding 0 s: %05dr8501 would be inserted in the test string. Note the %05d is the same as a printf / sprintf and actually uses the exact same function, only enhanced. This means %05Xr8501 would cause hexadecimal values to be generated. Sample strings using the previous example could be entered in the message.ini file as: Analog Value = %05dr8500\r\n Analog Value = %05dr8501\r\n If the above is the only two entries in the message.ini file then writing a 2 to the Message String Transfer Register would cause the second line to be processed and the following to be written out the RS232 port if a 583 were in register 8501: Analog Value = 00583<CR><LF> Where <CR> = 0x0d and <LF> = 0x0a. Note that writing a 1 would have referenced the first string, thus reading register More complicated strings can be created, referencing any register or combination of registers. Note that no completely formatted string may exceed 255 bytes and not record entry in the message.ini file may exceed 132 bytes/line. Page 35 of 76

36 9.0 Communication Protocols Overview Numerous communication protocols are supported and others are constantly being added. Refer to the CTC Website for the latest availability. TCP Client/Server RAW Socket sessions Up to 5 TCP Client/Server RAW Socket sessions are supported by the These socket sessions provide a virtual pipe to the other side with no formatting of data done by the To the 5100 they merely appear as another serial port. This interface is extremely useful for connection to external programs, such as Visual Basic or Ethernet based terminal servers such as the Lantronix described below. Client A TCP Client RAW Socket session is when the host computer runs a TCP Server and the 5100 connects to it. Typically a well know IP address and public TCP port number is available for this connection. Once the connection is made any data sent to the actively selected 5100 serial port is sent to the host and anything sent by the host to the 5100 is placed in its receive buffer, exactly like a 5100 serial port. In order to initiate a connection a number of registers must be setup. Similar to the Peer to Peer register block, the RAW Socket session block is based at register block to 22049, one block for each serial port supported. The actual block used has nothing to do with the serial port itself when referenced from Quickstep, it is configurable as a parameter within the block. Currently there are 2 serial ports within the 5100, ports 3 to 7 are virtual ports that may be assigned as desired. Remember that Server connections will use the next available port when allowing connections from a host client therefore it is important to reserve your port first prior to enabling a Server register block. Registers are defined based on their offset from their base, repeating after each 10. Therefore beginning at register 22000: 22XX0 Serial port ID register, offset 0 22XX1 Client/Server register, offset 1, to initiate connection set to a 0, if 5100 is a server set to a 1. Therefore in this case this would be a 0, we initiate the connection. 22XX2 Most significant octet of IP Address to connect to, IPA, offset 2 22XX3 IP Address octet, IPB, offset 3 22XX4 IP Address octet, IPC, offset 4 22XX5 Least significant octet of IP Address to connect to, IPD, offset 5 22XX6 Port to connect to (client) or listen on (server), offset 6 22XX7 Connection status register, offset 7, on read, -1 = not initialized, 0 = offline, 1 = Page 36 of 76

37 online, write a 1 to initiate connection or start server thread. 22XX8 Index register to offset to data, offset 8. Recommend using serial port buffer, not this interface but available to mimic the peer to peer interface. 22XX9 Data array, offset 9. Recommend using serial port buffer commands, not this interface but available to mimic the peer to peer interface. An example for a script program to initialize a connection to a host at IP address (Lantronix detailed in the next section) and port 3001 is shown below, note the port id register, must be setup first: = 3 # setup this client connection as port = 0 # set that we are the server = 12 # most significant octet of ip address = = = 185 # least significant octet of ip address = 3001 # TCP port to attempt connection to = 1 # To initiate a connection write a 1 to the status register then read it until it # is a 1 # which means connected, 0 is offline, -1 is not initialized. Once register is read as a 1 then port 3 will appear as a standard serial port to a Quickstep application. As with any serial port the port must be selected first, by writing the port number to register 12000, prior to transferring data or initiating commands. The port is available for reading and writing upon connection to the host., register = 1. Should a connection ever be lost, will contain a 0 and a read of (Message status register) will return a 1, indicating transmitter busy, or in this case, offline. With TCP the transmitter will never be busy unless offline. The 5100 will periodically retry the client connection. Server A TCP Server RAW Socket session is when the host computer is the client, connecting to the 5100 on a public TCP port number. Once the connection is made any data sent to the actively selected 5100 serial port is sent to the host and anything sent by the host to the 5100 is placed in its receive buffer, exactly like a 5100 serial port. In order to allow a server to be active the same registers as detailed in Client, must be configured except a 1 is placed in register 22XX1 and our port number to listen on is stored in 22XX6: Registers are defined based on their offset from their base, repeating after each 10. Therefore beginning at register 22000: 22XX0 Serial port ID register, offset 0 22XX1 Client/Server register, offset 1, to initiate connection set to a 0, if 5100 is a server set to a 1. Therefore in this case this would be a 1, we listen for connections 22XX2 Most significant octet of IP Address to connect to, IPA, offset 2 (set to own) 22XX3 IP Address octet, IPB, offset 3 Page 37 of 76

38 22XX4 IP Address octet, IPC, offset 4 22XX5 Least significant octet of IP Address to connect to, IPD, offset 5 22XX6 Port to connect to (client) or listen on (server), offset 6. Desired public port number. 22XX7 Connection status register, offset 7, -1 = not initialized, 0 = offline, 1 = online 22XX8 Index register to offset to data, offset 8. Recommend using serial port buffer, not this interface but available to mimic the peer to peer interface. 22XX9 Data array, offset 9. Recommend using serial port buffer commands, not this interface but available to mimic the peer to peer interface. A server thread will be launched as soon as a 1 is written to the status register. Note that only one connection is allowed at a time since all information is directed to and from a 5100 virtual serial port. If more than one connection attempt is made to the same port number defined in the configuration block, it will be initially accepted and then rejected. Lantronix CoBox interface The Lantronix CoBox-DR1-IAP Device Server ( is one of several serial to Ethernet converter devices supported by the 5100 TCP RAW Client socket protocol. To the 5100 this device is communicated to over TCP port 3001 and becomes a simple virtual serial port to Quickstep. It operates exactly as a resident local port, supporting the same communication protocols. Even a serial port version of CTMon or a 4010 User Interface can be connected and run over this interface, allowing for easy port expansion. The CoBox also allows for loadable Communication Protocols for further enhancements. These protocols are beyond the scope of this document and reference to Lantronix s web site should be made for those. By encapsulating serial data and transporting it over Ethernet, devices such as the CoBox- DR1-IAP, allow virtual serial links to be established over Ethernet and distributed virtually anywhere within a plant or global enterprise. Figure 9.1: Lantronix CoBox Serial to Ethernet Converter Page 38 of 76

39 Modbus The Modbus Protocol is a messaging structure developed by Modicon in It is used for master-slave/client-server communication between intelligent devices and has become an industry standard. Details of the protocol may be found at the web site for further details. There are numerous deviations of the Modbus protocol of which the 5100 supports those described within this section. Tools used to test the protocol are available from a number of sources. The 5100 was tested using those available from namely their ModScan32 for RTU Slave testing and ModSim32 for Master. Modbus TCP Slave The Modbus TCP Slave protocol allows a TCP master to periodically poll the 5100 to collect desired information. The protocol allows for interfaces to such things as coils, analog, register, etc. Since the 5100 is able to access anything via its register interface, only the Holding Register commands are supported; Write Single Register (function code 0x06), Write Multiple Registers (function code 0x10), and Read Holding Registers (0x03). Figure 9.2: Modbus Function codes from Modbus.org, Modbus Application Protocol Specification, May 8, 2002 You should also note that Modbus registers are 16 bits in width and that of the 5100 are 32 bits, since Modbus is Big Endean, this means reading register 1 in the 5100, the high 16 bits equates to Modbus register 1 and the low 16 bits to Modbus register 2. Modbus Page 39 of 76

40 register 3 would be the high 16 bits of the 5100 register #2. A maximum of 50 Modbus registers can be read at once, or sequential registers. As a demonstration of the functionality of the 5100 Modbus TCP/Slave interface this section details the interface of Win-Tech s ModScan32 software and how it applies with regard to our product. As mentioned before, we only support the Holding Register interface. Upon installation of ModScan32 a screen such as Figure 7.3 will appear. Note that the Address field is set to 1, but the display screen starts at This is Modbus nomenclature. Address of 1 is the same as the upper 16 bits of the 5100 register 1. Note Length is set to 50, the maximum allowable number of Modbus registers in a single read, Device ID is ignored since TCP is point to point. Figure 9.3: ModScan32 Master Scanning Program (only Holding Register supported) Figure 9.4 shows the setup for an interface to a 5100 with a TCP address of and the Modbus Slave running a server on the standard port of 502: Page 40 of 76

41 Figure 9.4: ModScan32 Master Scanning Program TCP Connection Setup In order to do a single register write to a Modbus 16 bit register double click that register. Below shows changing Modbus register (Address 2) to a value of 5, this would translate to the lower 16 bits of Quickstep register 1. Remember Modbus Address 1 is the upper 16 bits. Figure 9.5: Single register write, value 5 to Changing a number of register all at once is known as a Write Multiple Register access. This can be done using the Extended Access option: Page 41 of 76

42 Figure 9.6: Write Multiple register (Preset Regs) selection The Preset Multiple Registers will appear. Note that in TCP the 5100 ignores any slave or node identifiers since it is a single device and not acting as a gateway. Set the Modbus register you wish to start changes with and the number of registers to change, up to a maximum of that you are viewing: Figure 9.7: Preset Multiple register dialog In this case we will change Addresses 1 to 10 to sequential numbers 1 to 10: Figure 9.8: Select number of multiple writes to do As shown below the current register values are displayed in the dialog box. Page 42 of 76

43 Figure 9.9: Preset Multiple register dialog viewing existing values Note below that each register value has been changed, also we scrolled down so we could get to register 10. Click Update and note the changed register values from the previous display, is no longer 5 but now 2. Figure 9.10: Preset Multiple new values entered Upon clicking the Update key, the new values are written to the 5100 registers and new values read back using the Read Multiple Register command. Page 43 of 76

44 Figure 9.11: New values written and read back, Quickstep registers 1 to 5, Modbus 1 to 10 Should any errors occur a Modbus exception will occur. One such common error is attempting to read too many registers or illegal registers. Below is what is returned if > 50 Modbus registers are attempted: Figure 9.12: Modbus Exception Example > 50 registers Page 44 of 76

45 Editing the 75 appropriately will update the error. Below is an example of displaying registers in the block of the controller is the system tic counter, real time clock/date values can also be seen incrementing in other register dynamically. Note that is the high 16 bits of and (13002 X 2) is the base lower 16 bits. Modbus TCP Master Modbus Serial RTU Figure 9.13: Display of 5100 system tic, dynamically updating TBD (not released) The Modbus Serial RTU protocol functions exactly like that of Modbus TCP with regards to how to access information and ModScan32 operation (see figure 9.14 for serial port setup versus TCP). There are some key differences since an RS232 connection is used versus a network connection. They are as follows: 1. Only COM1 can be used for Modbus Serial RTU protocol. COM2 uses an intelligent controller chip which does not currently support the protocol. COM2 support may be added in the future. Page 45 of 76

46 2. The virtual TCP communication ports may also be used but only for point to point operations with a single address present. In other words the communications traffic of other Modbus nodes should not be present (can be on COM1). This is necessary because Modbus specifies a 3.5 character quiet time between packets and a maximum of 1.5 intercharacter delay during the continuous transmission of a packet data stream. The virtual ports can not guarantee these timing constraints, although from a high level protocol viewpoint, the ports do comply. 3. By default the Modbus protocol is disabled on the serial and virtual ports. To enable the port it must be the active port in the register and the Modbus Slave address value must be written to register Note that by default the slave port address is 2 and that any value written as the Modbus slave address will be that used on all serial ports, system wide. Note that writing a value of 0 to will disable Modbus on that port only and not effect the system wide address. 4. When Modbus is enabled on a serial port using CTCMON no further communications will be available on that port except with Modbus. In other words you will loose your CTCMON link if talking on the same port. Figure 9.14: ModScan32 Master Scanning Program Serial Connection Setup Page 46 of 76

47 CTNet Binary Protocol (Server) The CTNet binary protocol is a high-speed, non-routable protocol that has checksum and error reporting capabilities. It is used in cases where data integrity, response time, and processing time are the major criteria. Data transmission is fast for the following reasons: o Both the commands and data are represented in binary form instead of ASCII. o The information density is higher and fewer characters are transmitted during large data transfers. o The controller can use the data as is and does not have to perform binary to ASCII conversion. This results in shorter execution times. Note that the binary protocol is non-routable. Nonroutable protocols do not contain a networking layer (IP stack), so they cannot cross a router and are limited to local subnets or intranets. However, lack of an IP stack reduces overhead by at least 20 bytes/packet. A smaller packet size increases the transmission rate, which is ideal for industrial controllers. Routable protocols such as TCP/IP result in a larger packet and more processor overhead to process. A node number is used in place of an IP address. This node number is defined by writing to Register You can also determine the node number by reading the value in Register Set this value within the 5100.ini file by defining the CTNET_DEVICENODE parameter. For more information on the CTNet binary protocol, refer to the CTC Serial Data Communications Guide. UDP Peer to Peer Peer-to-Peer Protocol Registers The 5100 can only perform peer-to-peer operations with other 5100 modules. It is not compatible with the 2217 communications module but is with the The 5100 s peer-topeer registers let it communicate directly with other 5100 modules without requiring a dedicated server. It can also gather register information locally for different network protocols. Registers are read/write registers that are reserved for peer-to-peer networks. Each block of 10 sequential registers is assigned to a designated peer node and defines the peer environment for that connection. You can retrieve data from and automatically update up to 100 sequential registers with a single request. This register block is used for many functions by different network protocols (Peer-to-Peer, Modbus TCP Master, etc.) that all interface with the registers in the same manner. Registers are defined below. Page 47 of 76

48 21XX0 - First Octet IP Address Register (Most Significant) - R/W This is the first octet of the IP address (XXX ) that is used to make peer requests. 21XX1 - Second Octet IP Address Register - R/W This is the second octet of the IP address (000.XXX ) that is used to make peer requests. 21XX2 - Third Octet IP Address Register - R/W This is the third octet of the IP address ( XXX.000) that is used to make peer requests. 21XX3 - Fourth Octet IP Address Register (Least Significant) - R/W This is the fourth octet of the IP address ( XXX) that is used to make peer requests. Once a peer connection is attempted, you cannot change the IP octet register settings. 21XX4 - Start Register - R/W This register stores the starting register address in the controller for peer-to-peer communications. You can change this register number after a peer connection is attempted, but the number of sequential registers must stay the same (see Register 21XX5 for more information). 21XX5 - Sequential Number Register - R/W This register stores the number of sequential registers (starting with Register 21XX4) you want to read during a peer-to-peer session. The value 1 represents a single register and the maximum number of registers allowed is 100. Configure this register before setting up any other registers. Do not change this value during a peer-to-peer transaction or all data will be lost and new values will have to be entered. If you modify this register, it lets you reset the peer connection. 21XX6 - Poll Timer Register - R/W Set this register to 0 for a single read request. Specify a value (in units of ms/count) if this register is going to receive periodic updates from the server controller (the controller sending information to the register). The minimum value allowed is 50 ms. For example, the value 500 would refresh the data registers with new peer data every ½ second. You can write to this register at any time. Writing a 0 to this register while actively conducting a peer-to-peer session cancels the periodic update and causes a new single read transaction to occur. A time-out (Status Flag Register 21XX7 = 0) occurs if the server has not refreshed peer data in a time equal to 2-½ multiplied by the poll timer value. You can access this register at any time once you have initialized the Sequential Number Register (Register 21XX5). Data registers are mentioned in numerous places throughout the listings below. These registers are represented by Register 21XX9, which is a phantom register. For more information, refer to the 21XX9 listing in this section. Page 48 of 76

49 21XX7 - Status Flag Register - Read-Only This register reflects the current status of the data registers. Its value is based on any requested operations. Typically, you initiate an operation and then wait for a status of 1. Possible values are: 0 - Offline; no connection is present. 1 - Last request is successful and completed. Data is available in the data registers if requested Requested operation has failed Busy; connecting to the desired host Busy; reading data Busy; writing data Aborted operation; out of local memory or resources. 21XX8 - Index Offset Register - R/W This register lets you access each of the requested sequential data registers. It works in conjunction with Register 21XX9 and acts as its pointer. You can store the number of a general or special purpose register in 21XX8 and 21XX9 can then access the resource contained in the pointer. The first register (with an index of 0) is the Start Register (Register 21XX4). 1 is the next register, and so forth. Once Register 21XX5 (the Sequential Number Register) is initialized, you can change this register s value at any time. For more information on how pointer registers function, refer to the Register Reference Guide. The index register also has a few special features when you set it to 1000 or above. Modifications are made by writing to the data register and setting the index register appropriately as described below: Peer Request Time-Out Register - The timer starts when a peer node request is initiated and stops (times out) if no response is received within the time specified by this register. Retrys only occur if automatic updates are active (Register 21XX6 is set to a value other than 0). Defaults are 500 ms for single register reads and time-out value*2.5 for automatically updated register read transactions Peer Request Failed Index Register - This register indicates when a peer transaction fails and an error occurs. The Status Flag Register (21XX7) is set to a value other than 1. Any data that was read or written when the error occurred has an offset value that is stored in If you read the data register, it returns the offset failure value. Data written before this offset value is valid. For example, if your process continuously updates 50 registers and the register returns a value of 25, it means the process failed while trying to write the 25 th element of data. All data written before this element was written correctly. Page 49 of 76

50 Peer Request Retry Counter Index Register - This debugging register points the data register to the retry counter. Quickstep can set this register to any value. The register is incremented by 1 when a time-out occurs because of waiting for data from a peer node Peer Request Protocol Index Register - This register tells the data register what protocol to use for setting the peer block registers. You must set this register before setting the Start Register (21XX4). Default mode is 0 for UDP Peer-to-Peer protocol. 2 is used for ModBus TCP Master mode Peer Request TCP Client Port Index Register - This register points the data register to the destination TCP Port address for your connection. You must set this register before setting the Start Register (21XX4) is currently used for ModBus TCP Master mode with a default port number of 502 (the industry standard) Peer Request ModBus Master Unit ID Index Register - This register points the data register to the Unit ID field value used in the Modbus Master request packet. The default ID is 00 but you can set it to any desired value. This ID affects all subsequent transmissions and allows multiplexed nodes to be addressed in a ModBus environment Peer Request ModBus Master Exception Index Register - This register tells the data register where the last Modbus Exception error code is stored from a previously received message. Referencing this register helps to interpret failure types Peer Request Initiate Write Block Index Register - This register writes a block of registers (beginning with the Start Register) to a destination at the other end of the connection. The number of registers written is defined by Register 21XX5. To write to a single register, set the index to the desired offset and then write to the data register. Do not attempt to access the data register during a block write operation Peer Request Write Block Index Registers -This register points the data register to a temporary storage array and makes 2000 equivalent to an index offset of 0. Because data is written locally, you can write multiple values before initiating the write sequence by setting this register to Automatic polled updates cannot overwrite data values until the register is set to a non-2xxx value. 21XX9 - Data Registers/Peer Request Time-Out Register - R/W This phantom register contains peer data that is read or written in a peer transaction. It is a window into a register array in the controller. The array size is set by Register 21XX5 and the offset is specified by Register 21XX8. Data integrity is indicated in Register 21XX7. For more information on how phantom registers function, refer to the Register Reference Guide. For more information on peer-to-peer networking, refer to Technical Note No. 32, Setting Up Peer-to-peer Connections Between Two Controllers. Page 50 of 76

51 SNTP Simple Network Time Protocol (RFC-2030) The 5100 supports the Simple Network Time Protocol (SNTP) as a client connecting to a server. This protocol provides a means to synchronize a computer system clock to that of the world clock, via the internet. Government agencies provide this service for computers to query the current atomic clock time and adjust their clocks appropriately. For more detailed information reference and The time returned is based on Coordinated Universal Time (UTC), which is Greenwich Mean Time (GMT). As such, there is no adjustment for daylight savings time or time zones, that must be done locally. To avoid daylight savings time problems it is recommended that you base the controller time on GMT but provisions have been provided to automatically set the clock based on the time zone you are in, using an offset from GMT. Use of SNTP is not a requirement but typically real time clocks can be expected to drift up to 30 seconds per week. The 5100 will drift up to 12 seconds, depending on the tolerance of crystals, components, etc. Synchronization allows the real time clock to be automatically set with regards to date, year, day of week, and time. By default the 5100 will use the IP address of , port 123. Updates will be performed once/day and the clock is set to GMT. This may be changed by modifying the following registers: First Octet IP Address Register (Most Significant) for SNTP Server - R/W This is the first octet of the IP address (XXX ) that is used to connect to the SNTP server. Default is Second Octet IP Address Register ) for SNTP Server - R/W This is the second octet of the IP address (000.XXX ) that is used to connect to the SNTP server. Default is Third Octet IP Address Register ) for SNTP Server - R/W This is the third octet of the IP address ( XXX.000) that is used to connect to the SNTP server. Default is Fourth Octet IP Address Register for SNTP Server - R/W This is the fourth octet of the IP address ( XXX) that is used to connect to the SNTP server. Default is 18. The unit must be reset for a new IP address to take effect SNTP Server Port to connect to - R/W This register contains the TCP port that should be used for SNTP connections. The Default is 123. Default is SNTP Update Time - R/W Page 51 of 76

52 This register contains the number of seconds before the next synchronization request with the SNTP server. For example 3600 would be an hour, would be 24 hours. Default is When a change in time is made to this value it typically takes about 1 minute before the new value will take effect. Power cycling of the 5100 is not required SNTP Offset from GMT - R/W This register contains the number of seconds to add or subtract from GMT. The default is 0, which means to set the clock to GMT would be the value used for Eastern Standard Time during daylight savings time. Note that the value is both positive and negative. Note that a 1 must be written to register whenever the above changes are made in order to store those changes to non-volatile storage. Page 52 of 76

53 10.0 Firmware Updates and Version Control All 5100 Firmware is field upgradeable via an Ethernet FTP connection. This typically consists of transferring either a binary or S Record file to the controller. There are numerous different files available, each to update differing functionality and modules. The currently define filenames for firmware are: Firmware files that are transferred to the 5100 have special names that can not change and that are case sensitive. These files are: LAN5102.sr1 Main Quickstep operating environment firmware, typically 1.3 meg file S record file which can not be stored directly to the flash disk, root only for immediate update, since its file size exceeds that of the disk. quickstep.sr same as LAN5102.sr1 except an alternate name bin Analog Module firmware, about 3K binary file. comm.bin Main board communications controller firmware, about 2K binary file sr Servo Module firmware, about 350K S Record file sr Stepper Module firmware, about 350K S Record file. monitor.sr Main board SH2 boot monitor file, rarely updated, about 100K S Record file. File transfers to the root directory of the 5100 file system are temporarily stored in dynamic memory and then immediately begin re-flashing the appropriate module (refer to Section 4.0). Small firmware files be stored on the flash disk in the /_system/firmware sub-directory to allow updating of modules via the telnet update command, at any time. Quickstep programs are automatically stopped during re-flash operations and once all firmware is updated a reset command must be initiated to turn VBIAS back on and restart the application program. Note: Upon initiating a firmware update the 5100 LED3 will provide the following visual feedback: 1. Flash once then turn off during the erase cycle. 2. Rapidly flash at different rates as blocks are programmed. 3. Flash 3 times at completion to signify the flash has been programmed correctly. Any other flash sequence signifies an error code that should be reported to CTC Technical Support. Once firmware has been updated and the unit reset it is best to observe the current revision levels of firmware and to confirm that the modules updated are operating properly. This can be done by issuing the telnet get versions command, reference Figure 5.6. Page 53 of 76

54 As an example, the following shows the process of updating the 5100 main board communications controller chip with a file called comm.bin. There are two approaches. If you are near the unit you may simply invoke an FTP session and send the comm.bin file to the root directory: Figure 10.0: Sending comm..bin to root directory for re-flash via FTP You will notice LED2 rapidly flashing and then stopping. Although the controller is still functional it is typically recommended that either power be cycled or a reset command be initiated prior to use. From FTP this would be ls!reset. Note the double quotes are required and connection would be lost since the watchdog timer will force a reset. A better way to do an update is to have the comm.bin (or other image file) stored on the flash disk in the /_system/firmware subdirectory. Then invoke Telnet and issue the update command. In addition to the flashing LED2 you will get descriptive feedback during the reflash process and if an error should occur it will be displayed: First begin with storing the file to the /_system/firmware directory. Using the graphical FTP interface is simply a drag and drop but the command line interface is shown below for more detailed information: Figure 10.1: Transfering comm.bin to /_system/firmware directory Now invoke a Telnet session and run the update comm command: Page 54 of 76

55 Figure 10.2: Updating comm.bin from Telnet Note that there will be a several second delay after the Programming Complete message and the return of the BlueFusion> prompt, this is normal and your LED2 is flashing 3 times during this period. Now re-flash any other firmware you desire, then enter the reset command which will cause your connection to be dropped since the unit is essentially rebooted. When re-flashing the main program, LAN5102.sr1, the process is the same as depicted in figure You simply connect to the 5100 via ftp, don t change directories and issue the command send LAN5102.sr1, this assumes the file exists in the directory you invoked ftp in. The file will be transmitted to dynamic ram with the normal Quickstep program running in the background. Once loaded properly the Quickstep program will be halted and you will see LED 2 off for a few seconds then flash once, delay, then flash rapidly while re-programming the unit. DO NOT POWER OFF during this time period. After about 40 seconds the rapid flashing will stop and it will reset itself, in about 5 seconds the program will restart automatically and you will be back online and operational. No power cycling is needed. Page 55 of 76