Application Note #2437

Transcription

1 Application Note #2437 The CW Command This application note describes the CW Galil command. The CW command has three uses: it (1) prints the controller s copyright message, (2) sets or clears the most significant ASCII bit of unsolicited characters sent by the controller, and (3) controls whether the program pauses when the output communication buffer is full. This note describes each of these uses in detail. CONTENTS 1 COPYRIGHT MESSAGE (CW; CW0; CW?) MARKING UNSOICITED CHARACTERS (CW1; CW2) UNSOICITED CHARACTERS Commands in an Application Program TR Error Messages ASCII AND HOW UNSOICITED CHARACTERS ARE MARKED WHEN TO MARK (CW1) WHEN NOT TO MARK (CW2) SECOND ETHERNET HANDE GETTING UNSOICITED CHARACTERS IN AN APPICATION PROGRAM ROUTING UNSOICITED MESSAGES WITH CF (ETHERNET CONTROERS ONY) PAUSING PROGRAM WHEN FIFO IS FU (CW,0; CW,1) EXAMPE CONTROERS WITH A SINGE-BYTE UART ETHERNET WHEN TO PAUSE (CW,0) WHEN NOT TO PAUSE (CW,1) USAGE NOTE: ONE FIED AT A TIME

2 1 Copyright Message (CW; CW0; CW?) The original use for the CW command was to print a message containing copyright information for the controller (figure 1). :CW Copyright (c) Galil Motion Control, Inc All rights reserved Figure 1. Copyright message output from the CW command Note that CW0 and CW? do the same thing as just CW. 2 Marking Unsolicited Characters (CW1; CW2) This section explains in detail the difference between solicited and unsolicited characters, how the characters are marked, and when to mark and not to mark. 2.1 Unsolicited Characters Two kinds of characters are generated by a Galil controller: solicited and unsolicited (figure 2). PC C program TPX 0: Controller # MG"" WT100 JP# Figure 2. Unsolicited ( ) and solicited (0:) characters. Solicited characters are output by the controller in response to a command sent in on the communication port (e.g. PCI bus, Ethernet, or RS-232). For example, if a host PC sends the command TPX to the controller, the controller might respond with the string 0: indicating the position of the X-axis. All solicited responses end with a colon (:) preceded by a carriage return and line feed. Unsolicited characters are those output by the controller that are not in response to a command sent in on the communication port. These fall into three categories: (1) Commands that produce communication output in a Galil application program, (2) TR1 debugging trace output, and (3) error messages. Unsolicited responses do not end with a colon, but do end in carriage return and line feed (unless {N} is used with the MG command)

3 2.1.1 Commands in an Application Program Certain Galil commands produce communication output (namely MG). When these commands are called from a host PC, their responses are solicited; however, when they are placed in a controller application program, they produce unsolicited characters. Figure 2 above shows a simple application program that repeatedly calls the MG command. Terminal output follows: : Figure 3. Output from the program in figure 2 After the controller responds to the XQ command with a colon (:), it begins running the application program and repeatedly prints the unsolicited character. Commands that produce communication output follow: AW, BS, IN, A,, S, V, MG, QA, QH, QR, QU, QZ, RP, R, SC, TB, TC, TD, TE, TH, TI, T, TP, TS, TT, TV, TZ, U, WH TR1 Turning the debug trace output on also produces unsolicited characters (figure 4): :TR1 :0 # 1 MG"" 2 WT100 3 JP# 0 # 1 MG"" Figure 4. TR1 output for the program in figure Error Messages The last way the controller produces unsolicited characters is when an error occurs. If we add an invalid line to the program in figure 2 and run it, the controller generates an unsolicited message containing a question mark, the line number, and the source code on that line (figure 5). Subsequently issuing TC1 will display a string indicating the reason for the error. :S 0 # 1 MG"" 2 WT100 3 invalid line INVAID INE INSERTED 4 JP# 5 :?3 invalid line :TC1 1 Unrecognized command Figure 5. Example of an error message (unsolicited) - 3 -

4 2.2 ASCII and how Unsolicited Characters are Marked Both solicited and unsolicited messages are composed of ASCII (American Standard Code for Information Interchange) characters. ASCII is a 7-bit protocol that specifies 128 character symbols, which correspond to the numbers 0 to 127 (0 to 7F hexadecimal). Most of the ASCII characters correspond to those on a computer keyboard (figure 6) A B C D E F 0 NU SOH STX ETX EOT ENQ ACK BE BS TAB F VT FF CR SO SI 10 DE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US 20 space! " # $ % & ' ( ) * +, -. / : ; < = >? A B C D E F G H I J K M N O 50 P Q R S T U V W X Y Z [ \ ] ^ _ 60 ` a b c d e f g h i j k l m n o 70 p q r s t u v w x y z { } ~ DE Figure 6. ASCII table by hexadecimal code. Nonprintable characters are in grey. Although ASCII is only seven bits, the minimum unit of computer data is the 8-bit byte (figure 7), which allows 256 values. This means that when a character is transmitted, there is an extra bit that is unused: the most significant bit. Several extended ASCII tables have been created that assign non-english characters to the remaining 128 codes, but no true standard has emerged (different computer programs print different characters for a given extended ASCII code). Galil makes clever use of this extra bit by setting it to mark unsolicited characters (if CW1 is set). most significant bit CW hex C hex CW Figure 7. 8-bit byte from the controller s communication output for the ASCII character with CW2 set (top) and CW1 set (bottom) - 4 -

5 2.3 When to Mark (CW1) Unsolicited characters should be differentiated from solicited characters when the controller communicates with a host PC program (and in fact Galil s SmartTerminal sends CW1 upon connection to a controller). The following example shows what happens when unsolicited characters aren t marked. The below C program (figure 8) asks the controller repeatedly for the position of the X-axis and prints the raw string result. By issuing CW2 (the factory default), the program leaves unsolicited characters unmarked and this leaves the potential for the problem described below. Figure 8. C program that repeatedly queries the controller X-axis position without marking unsolicited characters Figure 9 shows the output from the C program while the controller runs the program in figure 2. A normal response to TPX is a number followed by a colon (the C program could easily parse this string and convert it to a number). The second response in figure 9 shows how a response to TPX also contains the character! Since unsolicited characters aren t being marked, the PC has no way of differentiating solicited characters from unsolicited characters. Even worse, if the unsolicited character were a number, there would be no way to tell it apart from the number the C program is trying to get. 0 : 0 : 1 st response (normal) 2 nd response with interleaved unsolicited character Figure 9. Output of the C program in figure 8 when the controller runs the program in figure 2 If the C program had set CW1 instead, the Galil driver would know that the was not an intended response to TPX and the program output would be correct

6 2.4 When not to Mark (CW2) Marked unsolicited characters will show up as non-english characters (figure 10) when you connect to the controller with a terminal that was not developed by Galil (for example telnet or Windows HyperTerminal). As described in section 2.2, this is because the terminal will display its extended ASCII characters since the most significant bit of incoming characters is set. This will be the case unless the terminal knows to force the incoming data to 7-bit ASCII (which is possible with HyperTerminal and is the case for Galil s SmartTerminal). Issue CW2 to read the unsolicited characters in a third-party terminal. Since no third-party terminals are available for Galil bus controllers (such as the DMC-1800 PCI or DMC-1700 ISA controllers), CW should always be set to 1 on these controllers. :S 0 # 1 MG"" 2 WT JP# :CW1 :ÌŠÌŠCW2 NON-ENGISH CHARACTERS : Figure 10. Unsolicited characters viewed in Windows HyperTerminal with both CW1 and CW2 2.5 Second Ethernet Handle For the case of Ethernet, it is possible to mark the unsolicited characters in another way: via a TCP/IP port number (Figure 11). When registering an Ethernet controller, it is possible to choose whether to have the controller send unsolicited characters on the primary handle (port) or a second handle. If using a single handle for both solicited and unsolicited characters (Use primary handle) CW1 is still necessary to mark unsolicited characters. When you choose open second handle, the unsolicited characters come in marked with a different port number, so marking the most significant bit is no longer necessary. Figure 11. Galil controller registration dialog showing how to configure the controller to send unsolicited characters on a second handle - 6 -

7 2.6 Getting Unsolicited Characters in an Application Program There are two ways to retrieve unsolicited characters in a custom application program (for example written in C or Visual Basic): (1) If you are using DMCWin32 (the free Galil Windows API), use the Galil API function DMCGetUnsolicitedResponse. (2) If you are using the Galil ActiveX Toolkit, use the DMCShell event DMCResponse (not to be confused with the DMCShell.DMCResponse property, which gives only solicited responses to DMCShell.DMCCommand). Either of these returns only characters whose most significant bit is set with CW1 (or characters which came in on a separate Ethernet handle, if this was set up as described in section 2.5). 2.7 Routing Unsolicited Messages with CF (Ethernet Controllers Only) When trying to retrieve unsolicited messages on an Ethernet controller, both the CW and CF commands must be configured properly. For a bus (e.g. PCI) controller, there is only one place communication output can go: the bus. For an Ethernet controller, which also has a serial port, there are nine places: the serial port and eight Ethernet handles (A-H). Each Ethernet handle corresponds to a different IP address and/or TCP/IP port. By factory default, an Ethernet controller routes unsolicited messages to the serial port (CFS). If you connect to a new Ethernet controller through SmartTerminal and run the program in figure 2 you will not see any output (figure 12). To see the output, issue the WH command, which tells you which controller handle you are currently connected to, and then issue CF to route the messages to that handle: :S 0 # 1 MG"" 2 WT100 3 JP# 4 :WH IHA :CFA : Figure 12. Demonstration of the CF command Use the TH command to show which handles are in use

8 3 Pausing Program when FIFO is Full (CW,0; CW,1) The third use for the CW command has to do with notifying the machine operator that the communication link has been severed. The second argument to CW controls whether the controller will pause its application program if the output communication buffer (bus or serial) is full. This will happen, for example, if the serial link is severed or if the terminal is closed while the controller is sending characters. 3.1 Example This example works on all controllers except for DMC-14x5/6, 21x2/3, and 3xxx. To see the controller pause program execution: (1) connect to the controller through a terminal (2) issue CW,0 (3) download the program in figure 13 # ER 0 MG 1 WT 50 ;'turn red light on ;'print ;'wait 50 milliseconds ER 1000 ;'turn red light off MG 0 ;'print WT 50 ;'wait 50 milliseconds JP# Figure 13. Program to demonstrate program pause (4) run it with XQ and observe the controller s red light blink (5) close the terminal and observe the controller s red light stop blinking (indicating the program has paused execution) - 8 -

9 3.2 Controllers with a Single-Byte UART All controllers pause as described above for CW,0 except for the following controllers, which have only a single-byte UART: DMC-14x5/6, 21x2/3, and 3xxx. For these controllers, CW,0 causes the following error to be generated instead of pausing if the serial communication link is severed: 131 Serial port hardware handshake timeout CW,1 causes no error to be generated, and again the program is not paused. Note that error 131 is special in that it will not stop the application program and it cannot be handled with #CMDERR. 3.3 Ethernet For Ethernet communication, the second CW argument is ignored and the following error is generated instead of pausing if the Ethernet communication link is severed: 123 TCP lost sync or timeout This error can be handled with the #TCPERR routine. 3.4 When to pause (CW,0) The CW,0 (factory default) setting should be used when a host PC program communicates with the controller and is critical to the machine operation. In this case, any controller communication output is deemed important, so if the communication link is severed, the machine will pause to notify the operator that something is wrong. If a PC program consists of a GUI that only displays machine status, it may not be important enough to pause the machine when communication is down. 3.5 When not to pause (CW,1) The CW,1 setting should be used when the controller is running stand alone, without a host PC (or for the case of a bus controller, without a custom PC application program). For a properly written Galil-language program (with no errors), any communication output consists only of debug messages (MG or TR1), which are not critical to the machine s operation, and can be ignored. 3.6 Usage Note: One Field at a Time When setting the pause status (CW,0 or CW,1), the mark unsolicited messages status (CW1 or CW2) cannot be set at the same. That is CW2,1 is invalid, but CW2;CW,1 is valid. (CW2,1 will set the first field and ignore the second.) - 9 -