| The Mule™ |
Advanced User Documentation
|Home Barcode Mill Barcode Fonts How to order Email us|
This documentation is for the latest version Mule which includes a USB interface. If you have an earlier model (identified by having 2 round DIN connectors on the end) the documentation is here.
The Mule converts RS232 ASCII data into scancodes which the computer interprets as keystrokes. It can act as a 'virtual keyboard' by emulating a keyboard directly in hardware (KeyWedge Mode) or can utilise the USB port to achieve similar results utilising the Human Interface Driver (HID) provided with many modern operating systems.
The Mule can be used to simplify the interconnection of devices such as Barcode Scanners, Weighing Scales and other technical instrumentation to applications software even if the software authors had not anticipated the need for such interoperability.
The Mule can be used to allow one computer to control another. This has wide application in industrial, technical, scientific, manufacturing and testing environments.
The Mule is supplied with both KeyWedge and USB interfaces. Select either the PS2 KeyWedge, or the USB Keyboard cable assembly.
Push the connector into the square hole in The Mule. Press firmly until the latch engages (listen for a slight click) and the cable cannot be pulled out again.
The Mule USB interface works with virtually all computers which will work with a USB keyboard. Including PCs and Macs. The driver used by the Mule is identical to that used by the keyboard. It is sometimes called the HID (Human Interface Device) driver. All versions of Windows from Win98 second edition will work. For some versions of Windows the original install disks may be required the first time the Mule is used. Drivers can also be obtained for many UNIX like OSs. Please note the driver is provided by the Operating System Vendor it cannot be supplied by us.
The green lamp is lit when The Mule has powered up correctly and is waiting for RS232 data to arrive. The lamp is extinguished during the period it is unable to accept further data while it is transmitting to the KeyWedge or USB cables.
The Mule continuously monitors the voltage of the power drawn from the PC. If The Mule is configured to power the RS232 device from the computer the Overload Lamp will light if the computer cannot provide sufficient power (a brief indication when the computer powers up is normal). If this happens you should reconfigure the links inside The Mule and the RS232 device to use an external power source.
The Mule is usually powered from current drawn from the computer. Optionally The Mule and/or the connected RS232 device may be powered from an external Power Unit. The power supply should provide 9-12v DC at about 300mA. The central pin is positive. Further information can be found in the RS232 and Links sections.
The RS232 connector on the Mule is a 9 pin male 'Dee' connector configured similarly to many PC computers. The pin numbering is shown below.
Pin 4 on the RS232 connector may optionally be used to supply power for the RS232 device. Pin 4 has been chosen for this purpose to provide compatibility with the normal DTR function usually connected here. Pin 9 can be used for the same purpose. Pins 4 and 9 are linked by default although either can be isolated by cutting the PCB track. Cut at point A to isolate pin 4 or Point B to isolate pin 9. (see pcb diagram) The actual power output depends on the way the links are fitted. Refer to the Link Configuration Table.
The Mule requires a RTS/CTS handshake if no loss of data is to be guaranteed under all circumstances. However operation without a handshake is usually possible if your data is sent in bursts of 50 bytes or less with a pause between each burst long enough for the data to be transferred to the computer. Most barcode scanners and similar devices output packets of data in this way. If the Mule’s internal buffer overflows it inserts a 'keyboard overrun' scancode into the data being sent to the computer. Most computers respond to this by sounding a warning beep. If this occurs then characters have probably been lost. An occasional beep sound from the computer is evidence of a RS232 handshaking problem.
RS232 devices using two different RTS/CTS handshake schemes are in common use. One type will transmit whenever the Mule asserts RTS (the CTS line is disregarded). The other will not respond to RTS unless it is asserted only after it asserts CTS. Either scheme may be selected by the DIP Switch. Choose whichever works best. Some devices work equally well with either handshake type selected.
The DIP Switches and Links are located on the circuit board in the positions indicated in the figure. Use the following procedure to gain access to the circuit board.
Make sure The Mule is unpowered. Remove the 4 screws from the sides of the
Mule and lift the cover. After making any changes ensure that no conductive
or other foreign objects have fallen inside. Replace the cover before
repowering the Mule.
The default state for the DIP switches is ALL OFF indicated by the green tinted rows.
After switches are changed it may be necessary to cycle the power before the new configuraton is recognized.
|Switches 1 and 2 determine the RS232 Baud Rate|
|Switch 1: off||Switch 2: off||9600|
|Switch 1: on||Switch 2: off||1200|
|Switch 1: off||Switch 2: on||300|
|Switch 1: on||Switch 2: on||19200 [not guaranteed]|
|Switch 3 sets the RS232 data format|
|Switch 3: off||8 data bits, no parity|
|Switch 3: on||7 data bits, 1 parity bit (odd or even)|
|Switch 4 sets the RS232 handshake type|
|Switch 4: off||RTS asserted when ready. CTS ignored|
|Switch 4: on||RTS asserted only after CTS|
|Switch 5 sets the RS232 wait loop timeout [Note 1]|
|Switch 5: off||100mS|
|Switch 5: on||500mS|
|Switches 6 and 7 set the keyboard scancode types|
|Switch 6: off||Switch 7: off||Regular PS2 and PC/AT scancodes|
|Switch 6: on||Switch 7: off||Old style XT scancodes [Note 2]|
|Switch 6: off||Switch 7: on||XT values sent as AT codes [Note 3]|
|Switch 6: on||Switch 7: on||PS2 numeric pad [Note 4]|
|Switch 8 reverses the keyboard CAPS LOCK state|
|Switch 8: off||Normal operation|
|Switch 8: on||Swap case of alphabetic characters|
|Switches 9 and 10 set the key sending speed. [Note 5]|
|Switch 9: off||Switch 10: off||100 cps (fastest)|
|Switch 9: on||Switch 10: off||50 cps|
|Switch 9: off||Switch 10: on||25 cps|
|Switch 9: on||Switch 10: on||12.5 cps (slowest)|
Defaults are indicated by the green tint.
Damage may occur if more than one link is fitted in each group or if links are altered when the Mule is powered on.
|Link at||Mule is powered from...|
|1A||... external PSU (via regulator in Mule)|
|1B||... direct from computer keyboard or USB circuit|
|Link at||Pins 4 and 9 of RS232 Connector are connected to...|
|2A||... +5v DC. Sourced from external PSU via regulator in the Mule|
|2B||... +5v DC. Sourced from computer keyboard or USB circuit|
|2C||... unregulated DC supply direct from external PSU|
|Link is||Permit or Disable scancode mode|
|Fitted||Scancode mode is possible|
|Open||Scancode mode is not possible|
The default operating mode for the Mule is ASCII mode. Characters received at the RS232 port are assumed to be ASCII and the appropriate keystrokes are emulated. Virtually all the printable ASCII characters can be emulated as either a simple keystroke or a shifted keystroke. The number keys emulated are those along the top of the keyboard. The numeric pad numbers are not used as the Mule cannot know the state of the keyboard Num Lock.
The only ASCII control codes to be emulated by simple keystrokes are: CR, BS, TAB and ESC. All other ASCII codes up to and including code 255 are emulated by an ALT key sequence. For example the character represented by ASCII code 123 is emulated by the key sequence ALT down, Pad 0, Pad 1, Pad 2, Pad 3, ALT up. Provided link 3 is made, the special ASCII control code SI is used by the Mule to access Scancode mode. This is described later.
Note that the Mule emulates scancodes not characters. The scancodes are mapped to particular characters within the computer. Some countries (not the USA) require a keyboard driver. If you find some of the characters consistently converted incorrectly you may not have an appropriate keyboard driver loaded or you may be using a version of "The Mule" intended for a different country where some characters are mapped to different keyboard positions. This problem may be overcome by using scancode mode for those characters.
Many keys like the function and cursor keys have no ASCII counterparts and cannot be directly emulated from ASCII mode. Many application programs require operation of these keys and the Mule includes a special means of emulating them. Using scancode mode every single key on the keyboard is accessible. Every possible simultaneous combination of keys and every possible sequence of simple or combinational keystrokes may be emulated. For example you may wish to emulate the combinational keystroke Shift-Alt-F1. This would be impossible in ASCII mode but with Scancode mode it is simple. Scancode mode with its unique flexibility is unique to the Altek Mule.
To understand and use Scancode mode you need to know how the keyboard encodes keystrokes. When any key is depressed a code number is sent to the computer. This code is called a 'scancode'. Each key has a unique scancode. The scancode bears no relation to the character appearing on the keycap. It is simply a reference to the physical position of the key on the keyboard. When the key is released a different scancode is sent to the computer. By processing these scancodes the computer can work out which key or combination of keys has been pressed. Scancodes may consist of one or more bytes.
Scancode mode is entered by sending the ASCII control code SI to the Mule (providing link 3 is in place). The Mule remains in scancode mode until it receives the ASCII control character SO. Alternatively scancode mode will be 'Auto-exited' if a character alien to scancode mode is received. (e.g. any ASCII character other than: ABCDEFabcdef0123456789 and SO). In this case scancode mode is cancelled and the alien character will be sent as a normal keystroke.
If you wished to send the SI code as a proper keystroke rather than entering scancode mode this may be done by transmitting the SI character twice. Each scancode byte is sent as a pair of ASCII hexadecimal characters. Capital or lower case characters are treated as being identical. A single hexadecimal character followed by an exit or auto-exit from scancode mode is discarded. If you wish to prevent entry to scancode mode Link 3 should be opened. This may be the best approach if you wish to send a binary file and it is not convenient to duplicate all the SI codes.
|Scancode mode example: To emulate Shift Alt F1|
|1: Enter scancode mode||&H0F|
|2: Shift key down||12|
|3: Alt key down||11|
|4: F1 key down||05|
|5: F1 key up||F005|
|6: Alt key up||F011|
|7: Shift key up||F012|
|8: Exit scancode mode||&H0E|
To enter scancode mode it is necessary to send the Mule an ASCII control character known as the SHIFT IN character (sometimes simply called the SI character). The SI character is not a normal printable ASCII. It is a special character used to control hardware devices like the Mule.
To exit from scancode mode send either the ASCII control character SHIFT OUT (Sometimes simply called the SO character). You can also exit the scancode mode by sending any character alien to scancode mode. For example it is often simpler to send a ascii NEW LINE at the end of the scancode string.
All remaining scancode data is sent as printable ASCII characters. The characters used for scancode mode are the numbers 0-9 and the letters A-F, The letters can be sent as either upper or lower case- it makes no difference. Any character alien to scancode mode (in other words a character the Mule cannot interpret as a Scancode character) causes the Mule to exit scancode mode.
Computer languages use different syntax in order to send strings. I have provided three examples using BASIC, C and PERL. These are not intended to be complete examples or even the best way to do it. They are meant as an example to illustrate exactly what sort of characters need be sent in scancode mode. In all cases I have assumed a data stream is already opened to the Mule and I have used the codes needed for the Shift Alt F1 example above.
To send the codes for ALT SHIFT F1 the following could used...
The above two lines have an identical result.
Note that the SHIFT OUT character may be omitted if the trailing character is alien to Scancode mode, for example a Carriage Return code. In these two simplified examples the trailing semicolon is omitted causing BASIC to auto append a Carriage Return.
To send the codes for ALT SHIFT F1 the following 3 lines could be used...
or more simply these 2 lines...
This works because the Mule sees the \n character as alien to scancode mode.
Alternatively the whole can be sent is a single lien by using the substitution features of the printf() function. The first %c is replaced by the character having octal value 17(octal 17 = hex 0F = decimal 15), The second by the character having octal value 16 (octal 16 = hex 0E = decimal 14)
If you prefer hex to octal some versions of C may allow direct use of hex values like this.
To send the codes using PERL the following expressions could be used. (Note that in PERL the dot is used as the concatenation operator)
or more simply by using the NEW LINE character to quit scancode mode...
Q Which is best KeyWedge Mode or USB Mode.
A Both Modes function in a similar way. Both send data to the computer just as if it were typed at the keyboard. You may have to use USB on a Laptop which has no external keyboard socket. You may have to use KeyWedge on an old DOS machine with no USB port. You may have to use KeyWedge on a UNIX machine which has no USB driver. USB is sometimes quicker and easier because you do not have to disconnect the existing keyboard. There is no simple answer - use whichever is best for you.
Q Most ASCII characters are OK but a few are consistently wrong.
A The Mule is designed to operate with a standard USA layout keyboard. Other countries sometimes have different ASCII values assigned to the keys (The same scancode is used but the computer interprets it differently) If you wish to use The Mule in a different country you may have to use scancode mode for the 'wrong' characters. Alternatively you could disable your own country keyboard driver. Your computer will then default to the USA key layout.
Q While using the Mule the computer sometimes beeps. The data often has characters missing and some characters are incorrect.
A If the RS232 buffer in the Mule overflows an 'overrun' scancode is inserted into the keyboard data stream. This will sound the computer beeper to warn of the error. This is almost always caused by an incorrect RS232 handshake. If your sending device cannot respond to a proper handshake then you will need to insert a delay into the RS232 data after about every 50 bytes allowing the Mule to clear its buffer before sending is restarted.
Q How do I send the £ (UK currency) symbol?
A In ASCII mode there is no straight forward solution. You could try ASCII code 156 or 163. If you need to send it in Scancode Mode this is the sequence 1226F026F012.
Q I am attempting to send a binary computer file to an application but after being transferred the data contains blocks of garbage.
A If your data contains the ASCII SI character you will be entering
scancode mode erroneously. It is best to send binary files with Link 3 removed.
links to other related web sites:
|Top Home||© Altek Instruments Ltd, 2008|