Wx100 Technical Reference

A complete Wx100 PLC system comprises two parts:

• The Wx100 PLC main controller
• The WxTermXX – the wiring terminals and expanded I/O on some models.

The two parts are connected via a 20-pin ribbon cable connector which brings the I/Os from the Wx100 PLC to the wiring terminals to connect to physical devices such as sensors and loads.

With its built-in HMI that comprises a 128 x 64 pixel OLED display and a 16-key keypad, the Wx100 PLC would most commonly be installed on the front door of a control panel or on the exterior of a control box where user can interact with it directly.

Wx100 may also be deployed as the brain of a subsystem inside a bigger equipment, E.g. to control the cooling system of a MRI machine. In such applications, the Wx100 may be installed inside the control panel or on a DIN rail if the OEM prefers not to let its user to have direct access to the keypad and display on the Wx100.

Note: When installed inside the control panel, the built-in HMI on a Wx PLC can still be an extremely effective maintenance and monitoring tool if properly designed, as it can constantly display critical performance data, charting the data trend etc and provide alert messages. OEM can easily create a menu system to allow the maintenance technician to access a wide range of data or control the operation of the subsystem with only a few key presses.

The innovative Wx100 enclosure is designed to be highly flexible which allows it to be readily installed in one of the above scenario.

TRi will be supplying several models of Wx Terminal boards with different combinations of digital and analog I/Os to fit most common applications. The main purpose of the terminal board is to provide simple wiring terminals for user to connect the Wx100 PLC to the industrial devices. For the most basic terminal board with no more than 8 inputs and 6 outputs, only mainly passive components are used on terminal along with some red and green LED indicators to indicate the ON/OFF state of the I/Os.

OEMs may like to take note that this unique wiring design of the Wx100 PLC opens the possibility for OEMs to very easily custom-design and build their own terminal boards that best fit their applications. This may be done to fit the available footprint for the control components, or to save cost.

For example, some applications may require all digital outputs to be electromechanical relays. Some applications may need to drive some AC loads using solid state relays and some may want to install pressure sensor and signal conditioners directly on board the terminal boards. Building a customized terminal board lets you eliminate the needs to wire from the PLC’s terminals to yet another board that contains custom circuitry, thus saving considerable labour cost and component costs.

We recommend that first time Wx100 user purchase one of the following standard terminal boards that TRi supplies to quickly deploy the Wx100 for real world applications:

a) Low cost, PCB based Wx-TERM8 with 8 DI/6 AI and 6 DO, no AO
Please refer to the Wx-TERM8 documentation: https://docs.triplc.com/wx-term8-um/

b) Standard Wx-TERM16 with 16 DI/6AI, 14 DO and 4 AO  (full part number: Wx-Term1614AO4-Std).
Documentation: https://docs.triplc.com/wx-term16-um/

In the rest of this chapter will focus our discussion mainly on how Wx100 + Wx-TERM8 combination as a quick start guide for user applications.

Note: 

• In the next few sections we will describe in greater details how the power supply, the digital inputs and digital outputs should be wired to the Wx-TERM8 board.
• The specifications and programming methods for the analog I/Os are detailed in Chapter 5 of this manual. Chapter 6 shows how the special inputs and outputs such as quadrature encoder, stepper motor driver etc. are mapped to the Wx100 digital I/Os.

a) PLC and I/O Using Same Power Supply

A regulated, low ripple industrial grade DC power supply between 12 to 24V should be used to power a Wx100 PLC application.

Wx100 PLC itself consumes less than 50mA (0.05A) at 24VDC when all its I/Os are turned OFF. For most applications Wx100PLC can share the same 12 to 24VDC power supply as the load. The output driver is capable of sinking 2A continuously per output. Hence the power supply current output capacity is mainly determined by the maximum total amount of output current need to power the digital output loads.

You should connect a separate pair of wires (AWG24 or larger) from the power supply to the Wx100 PLC as shown in section 1.3.1. Beside powering the Wx100 PLC, this pair of connecting wires is also tasked to carry the return current that the PLC output sinks from the load back to the power supply.

The power to the I/O should be connected to the bottom left screw terminals marked as “POWER IN” on the Wx-TERM8 as shown in Section 1.3.3. The power supply input is in-turn routed by the Wx-TERM8 PCB to the INPUT and OUTPUT terminal sections for easy connection to I/O devices.

Note:

Internally, the Wx-TERM8 also routes its power supply (via a reverse blocking diode) to the Wx100 via pin19 and 20 on the ribbon cable. This means Wx100 PLC will receive power even if you don’t connect the power supply cable to its own power supply screw terminals. However, we do not recommend you depend solely on this connection to power the Wx100 unless your output loads consume only very small amount of current. This is because If you don’t connect separate wires to the Wx100 power connector, then the total output current that the Wx100 output drivers sink from the 6 output loads can only return to the power supply via the ribbon cable, which has limited current carrying capacity and could lead to overheating if it has to constantly carry large amount of return current.

b) Using Separate Power Supplies for the PLC and the Load

If the output loads require higher current (such as driving large DC motors) or the loads draw very high in-rush current when turned on and could dip the power supply to below 9V, then it is recommended that a separate power supply be used for the output load. Note that if you choose to use two separate power supplies, their 0V terminals should be tied together to provide a common ground reference for the two power supplies.

It is recommended that the PLC and Load power supply should be either of the same output voltage or the load voltage should be at a higher voltage that PLC power. If the load voltage is lower than the PLC, the output LED may light up even when the output driver is not energized. This is because the current could flow out of the Wx100 output terminal into the (lower voltage) load power supply, essentially applying a reverse voltage to the load (though it is current-limited by a 10K pull up resistor) and therefore light up the LED. This can be confusing to users even though it would not damage the output driver. Should this happen, you will need to add a series diode to the output terminal to block the output LED currents from flowing through the load and into to the load power.

To simplify field wiring, the power input that Wx-TERM8 receives via its “POWER IN” connectors are routed by the Wx-TERM8 PCB to the input terminal section. The V+ and 0V terminals beside the IN terminals are electrically connected directly to the “POWER IN” terminals

The most outstanding feature of the new Wx100 PLC is the integrated HMI that comprises a 16-key tactile keypad and a 128 x 64 pixels graphical OLED display. This provides users essentially with a zero cost HMI to interact with the PLC.

The built-in HMI is fully integrated into the new i-TRiLOGI version 7.4 software and with full simulation support on the i-TRiLOGI software itself. Many new keywords have been added to TBASIC to let you easily display a text string anywhere on the OLED display with up to 7 font sizes, or draw or fill basic shapes such as line, rectangle, triangle, circle. There is also a built-in MENU_DEFINE and MENU_SHOW commands that lets you very easily create multiple onscreen menus to help user to navigate the menu structure to control the equipment or view performance data, as shown in some sample screen shots below:

Extended ASCII Characters

TBASIC can display beyond the 32 to 127 basic ASCII characters to include extended ASCII character set. By default TBASIC displays extended ASCII based on Windows-1252 (code page 1252) character set, which includes many European characters. In addition, TBASIC also supports the Hitachi HD44780A00 character set that includes a full set of Japanese Kana characters, by specifying text size 11 and display at 6 x 8 pixels only. See example below:

Extended ASCII – CP1252

Extended ASCII – HD44780A00

Custom Bitmap Icon

In addition, even though Wx100 does not directly support the thousands of characters available in all the world’s languages, it is still possible to create custom bitmap characters using the “DRAW_BITMAP” command, which allows TBASIC program to create and display custom bitmap graphics block of up to 32 x 32 pixels in size and support multiple magnification factor (1 to 4). This allows some limited display of messages in other languages or icons. Some examples are shown below:

Programming the HMI

Some programming examples for the LCD display are presented in Chapter 13.

Customizing The HMI Keypad Legends

Although the 16 keys in the integrated keypad are already labelled as shown in Figure 1.7, they are not fixed to serve only as a numeric key, a menu key or backspace key, etc. The new TBASIC function “KEYPRESS(n)” actually receives a keycode from a keypress action and can use it for whatever purpose the program decides.

This means that the 16 keys can be assigned to any purpose. For example, if your application doesn’t need the user to enter numeric value frequently, TBASIC can display an on screen numeric or alphanumeric keypad if need be, thus still allowing you to occasionally enter data using only a few keys. The unused numeric keys can then be assigned as “Start” “Stop” “Jog” or whatever that you need for your application.

OEM with moderate to large volume can work with TRi to design a customized keypad that is specific to the equipment they build and inscribed with their own brand and logo instead of using the standard keypad legend. For example, it is conceivable to customize a keypad as follow:

The OEM will then be able to order the Wx100 PLC with their own branded, customized keypad to be used with their equipment.

a) Program Memory

The Wx100 has 24K words (16-bit) of program memory stored in the CPU Flash memory area. Each ladder logic element (contacts or coils) takes up 1 word of memory. A TBASIC statement or function takes up half a word to four or five words, depending on the number of parameters the statement or function has.

The program memory can be erased and reprogrammed more than ten thousand times, which is a limit that you are unlikely to ever reach.

b)  Non Volatile EEPROM Memory

Wx100 provides 14000 (16-bit) words of EEPROM memory that PLC program can use to store 8, 16 or 32 bit integer data or 32-bit floating point data. The EEPROM memory can be erased and write more than 1 million times.

c) Volatile Data Memory

All the TBASIC variables used in the Wx PLC: A to Z, A# to Z#, FP[1] to FP[1000], DM[1] to DM[4000] and string A$ to Z$, EMINT[1] to EMINT[16] and EMLINT[1] to EMLINT[16] are in the category of “volatile data memory” – meaning when you turn off power to the PLC the memory content will be lost and they will be reset to zero when the PLC is powered up again.

Unlike the Fx or FMD PLC, Wx PLC does not feature FRAM memory. This means that all TBASIC variables cannot be made non-volatile. However, you can still store the volatile memory data content inside EEPROM memory using the SAVE_EEP, SAVE_EEP# or SAVE_EEP$ before power shutdown and reload them back into volatile memory upon power up.

If you need volatile data to be automatically backup to EEPROM memory before power failure, then you need to do two things:

1. Build a voltage drop detector circuit and attach it to an interrupt input to detect imminent loss of power. The interrupt service routine must backup the crucial data before power drops below an acceptable level.
2. Use a large capacitor or a backup battery on the power circuit to the Wx100 PLC to allow voltage to decay gradually so that there is sufficient time for the CPU to save the data to EEPROM before power is completely lost.

There is a 4-position “piano” style DIP switch accessible from the upper side body of the Wx100 PLC. It may be covered by a silicone rubber dust cover. To access the DIP switch, simply remove the dust cover to expose the DIP switch and use a pen tip or a small screw driver to turn ON/OFF the switches.

Note:     Wx PLC firmware now allows user program to read the positions of the DIP switches using the  n = STATUS(23) function. DIP switch #1 ON/OFF status is represented by bit 0 in the returned data in n. DIP switch #2 by bit 1 and DIP switch #3 by bit 2. Since DIP switch #4 pauses the PLC, no command will run and thus its logic state will not be returned by the STATUS(23) function.

Usefulness of SW1-4

We have taken every effort to ensure that the host communication is always available even when the user-program ends up in a dead-loop. This allows the user to re-transfer a new program to the PLC and overwrite the bad program. However, you may still encounter a situation whereby after transferring a new program to the PLC, you keep encountering communication errors and you are unable to erase the bad program.  This is especially common if you have been experimenting with the communication commands such as SETBAUD, SETPROTOCOL, PRINT or OUTCOMM. These commands may modify the communication baud rate, format, or protocol or set the PLC to send data out of a COMM port that conflicts with i-TRiLOGI. In such cases, you can turn ON DIP Switch SW1-4 and perform a power-on reset for the PLC. The PLC will not execute the bad program that causes communication problems and you can then transfer a new program into the PLC to clear up the problem.

Note that when the PLC has been power-reset with DIP Switch #4 set to ON, the serial port will boot up with default baud rate and communication format of 38,400, 8,n,1.

The Wx100 PLC has a built-in Real-Time clock (RTC) but does not have battery backup. The RTC will be reset to a factory date when first powered on. If the PLC is connected to the Wi-Fi network then it can automatically update its RTC after power on by making a TCP connection to an Internet time server to obtain Internet time (See Chapter 2.4.3 – Sync RTC to NTP Server). If the PLC is connected to the WiFi, but does not have access to the Internet , it can also obtain the time from a PC on the same LAN that provides the NTP time service, or a PC that runs the TLServer (part of the i-TRiLOGI suite) software.

Alternatively, if there is a PLC connected to the same LAN and has a battery-backed RTC (e.g. Fx2424), the Wx100 can connect to the Fx2424 to obtain its RTC data and update its own RTC.

Depending on demand, in future TRi may also supply a battery-back RTC module that the Wx100 can access to update its own RTC if the application does not enable the PLC to connect to the Wi-Fi network.

A Wx100 PLC can work standalone with or without connection to the WiFi network. For example you can program the PLC either over the air via the WiFi network , or via the built-in RS485 port on the Wx100 with the help of a USB-RS485 serial port adapter connected to a PC.

However, even if the end application does not require network connection, you may still want to connect to it via WiFi network during program development since program transfer over the WiFi network is very much faster than over the slower RS485 serial connection.

You must setup two parameters before the Wx100 PLC can connect to your Wi-Fi network:  i) SSID of your network and ii) The WiFi security key (WPA or WPA2). You can setup these two parameters using one of the following methods:

a) Setup the Wx100 PLC as a WiFi Access Point, then connect a PC or smartphone to it and use a web browser to access a webpage.

b) Use the onscreen keypad on the Wx100 OLED screen to enter the parameters.

c) Connect a PC to the Wx100 via RS485 serial port and run a configuration software.

Please note that both the SSID and the Passkey are CASE-SENSITIVE you must enter in exactly the same number of characters, without any leading or trailing white spaces.

 
We shall describe these 3 methods in the next few sections

If you are the end user of a machine or equipment  you do not need to proceed further beyond connecting your PLC to your WiFi network. The PLC is fully operational once it is connected to the WiFi network and will run the last operational program transferred to the PLC.  The next few sections describe all other PLC network settings that would be set mainly by the PLC programmers or the OEM equipment makers if the default factory settings is not suitable for their applications.

You will need the iTRiLOGI Version 7.4 or later in order to configure the Wx100 PLC’s network settings. We have briefly touched on this topic in Section 2.1(c) when we describe how you can configure the PLC’s WiFi SSID and security key via the RS485 port.  In this section we will describe all the other network related settings such as IP address, gateway, web server and Modbus TCP servers, etc.

First, run the iTRiLOGI version 7.4 or later software. Click the “Controller” menu and select “Ethernet & WiFi Configuration”. When the configuration screen appears, click the “Retrieve Parameters From PLC” button, then login to the PLC using the  IP address shown on its OLED screen to retrieve a copy of all the previous settings saved into the PLC, as follow:

After you have retrieved the existing parameters from the PLC, you will see that various fields in the configuration software screen are filled up. Note that the Wx PLC has two built-in “Server” programs that listen on a few different ports on the PLC for incoming TCP/IP request packets:

1) The FServer supports the TRi proprietary programs such as the i-TRiLOGI software and TRi-ExcelLink program, and also provide a web server for web page request from a browser software and implement simple web page applications. The FServer listens on the default port 9080.

2) A MODBUS/TCP server that listens on port #502 and supports the industry standard MODBUS/TCP protocols.

Note:

• These two servers share the same WiFi connection and therefore the same IP address and gateway addresses described in the following sections.
• The Wx100 PLC host both the FServer and Modbus/TCP Server, each can serve multiple simultaneous connections from external clients. This means that it is possible to connect multiple TRiLOGI, ExcelLink and Modbus/TCP clients to the PLC, all at the same time! The maximum number of available simultaneous connections will depends on the memory available in Wx100 and usually is less than 10 in total.

Once the Wx100 PLC is connected to the WiFi and has an IP address, you can use i-TRiLOGI software version 7.4 or later to transfer your PLC program to the PLC and perform online monitoring.

All the commands to interact with the PLC are grouped under the “Controller” menu as shown below:

When you run any commands (e.g. On-Line Monitoring) under this menu before the iTRiLOGI software is connected to the PLC, you will be presented with the login screen as follow:

 

Note:

1. If you have defined and enabled the “Use Username/Password” option in the Ethernet & WiFi Configuration screen, then you must enter the defined username and password in the respective field on the login panel before you click the “Connect” or “Detect ID” button.
2. If you are unable to connect to the PLC, then check that both the PLC and the PC running your i-TRiLOGI software are connected to the same network and are on the same subnet. Generally for a subnet mask of 255.255.255.0, if the PC’s IP address is 192.168.1.xxx then the PLC should have an IP address of 192.168.1.yyy and it may not work if the PLC has IP address such as 192.168.0.yyy or 192.168.2.yyy, since this means that the two devices are on different subnets. Likewise, if your PC’s IP address is “192.168.0.xxx”, and if you are defining static IP address for the PLC then please change your PLC’s IP address to “192.168.0.yyy”  Also ensure that the PLC’s IP address is not already assigned to another device on the same network, otherwise a conflict would occur and communication is not possible.

Wx100 with firmware version F94.2 or later now natively support MQTT 3.1.1. If your Wx100 PLC firmware is before F94.2 please contact support@triplc.com to obtain upgrade instruction to upgrade your firmware. You also need to upgrade your i-TRiLOGI software to version 7.5 build 12 or later in order to make use of all the new MQTT and JSON commands it supports.

Note: F94.x firmware version is not available to Nano-10, FMD or Fx PLCs

The Wx100 supports both the FServer and the industry standard MODBUS/TCP server simultaneously. This means that all F-series PLCs are ready to interface directly with many third party industrial control devices that support the MODBUS/TCP protocol. These include the SCADA software, HMI hardware, OPC Server, HVAC controllers and many other industrial control devices.

In addition, the Wx100 can be used both as a MODBUS/TCP SERVER as well as a MODBUS/TCP CLIENT simultaneously. This means that the Wx100 can readily read data from any device that has a MODBUS/TCP server, such as: flow meters, AC/DC drives, HVAC elements, RTUs, network sensors etc. It is also possible to perform peer-to-peer networking with other MODBUS/TCP controllers (e.g. another F-series PLC) over a LAN or over the Internet!

The Wx100 PLC implements a list of “Network Services” commands (NS), which can be used to instruct the Wx100’s operating system to perform a number of network related functions client connection via the WiFi network. These commands allow the PLC to connect remotely to another PLC in another building or another part of the world via the Internet! This allows peer-to-peer networking, or so-called “M2M” (machine to machine communication) to take place between the PLCs.

The PLC’s TBASIC program uses the PRINT #4 command to execute the NS commands . The PLC can also receive the return response string or from the O/S using the INPUT$(4) command.  You may be aware that channel #n in the PRINT #n and INPUT$(n) refers to serial comm port number. For Fx and Wx100 PLC, when n=4 it is to send and receive strings via the Ethernet or the WiFi network and not a physical serial port. We refer serial port #4 as “virtual COMM port”.

Only PRINT #4 and INPUT$(4) are implemented on virtual COMM port #4. The Wx100 currently DOES NOT support the INCOMM (4) and OUTCOMM 4 commands. Note that any non -zero ASCII data can be sent using the PRINT #4 command

The following subsections describe the various Network Service commands available.

The FServer provides an extremely useful feature called “Web Service”. You can actually use your web browser to access the Wx100 internal data by specifying the following URL:
<IP Address: portno of FServer>/HOSTLINK/<Point-to-point hostlink command without “*”>
E.g. Please enter the following URL into your web browser URL address space:

      192.168.1.5:9080/HOSTLINK/IR

You will see the following data appear on your browser screen:

      IR01

“IR” is one of the many “host link commands” that allows a host computer to read or write to the PLC’s internal data space using ASCII strings. This particular command “IR” is for reading the PLC’s ID and in this case the PLC returns “01” by default. For more details on the list of host link commands, please refer to Chapter 15 of this manual.

Normally the host link commands are sent to the PLC via the serial port (as per all other PLC models produced by TRi). The Fserver, however, permits these host link commands to be sent using the HTTP protocol, which enables the Wx100 to be easily accessible by enterprise software using what is known as “Web Query” methods. The enterprise software only needs to know the format of the host link command required to read the target data and then they can use their web query capability to query the PLC and extract the required data from the response string.

One example, which you can try immediately, is to use the Microsoft Excel 2000 (or later version) spreadsheet program. First, open a blank spreadsheet, then click on the “Data” menu and select “Get External Data” -> New Web Query, as shown below:

Next, please enter the text as shown in the following diagram and then click OK. This will command the Excel spreadsheet to send the web query string “RI00” to the Wx100 PLC that is connected to the network with IP address = 192.168.1.5 and port 9080. The query string “RI00” is for reading the status of 8-bit input channel #0 (which covers the logic states of input bit 1 to 8).

If the FServer is accessible by the PC from the network router, it will send the response data, which will be displayed on the selected spreadsheet cell where the New Web Query was defined earlier.

The response data shown on the cell could be RI00. The response data includes the command header “RI” as defined in the HostLink Command protocol described in Chapter 15. The data 00 indicates that none of the inputs 1 to 8 are currently turned ON.

The Wx100 PLC web server space can host up to 512K bytes of data files which can be HTML, JPG, JS (JavaScript) files etc. Thanks to its support of the “web services” commands, a programmer can create its own sophisticated control webpages using only standard HTML and JavaScript .

TRi has created an example control webpage which can be downloaded from:

    http://www.tri-plc.com/download/webapp/webapp02.zip

When you have successfully unzipped all the files from the Webapp02.zip into your hard disk, you will need to transfer the files to the PLC’s web server using a FTP client program. The following sections describe how to use the free FileZilla FTP program to transfer these files and section 2.10 will describe how to customize the control web pages.

NOTE:

The “M.JS” JavaScript file used with the new preloaded 0.HTM file is no longer provided in the new web app download because it is loaded remotely. In the past, M.JS had been stored inside the PLC and was available directly for editing. However, now the user modifications in the HTML file are more expanded and in order to save space for additional files as well as protect against accidental modification of the M.JS file, it is now stored outside PLC memory.

If you are an experienced web programmer, or you plan to outsource web programming services to customize your PLCs web interface, then you may obtain a copy of this file for more advanced editing by writing to support@triplc.com and providing your purchase references (purchaser’s name, company name, invoice # etc).

Of course, you may also like to build your own HTML and JavaScript/Jquery control structure, which is entirely feasible for any experience web programmer.

The second generation of Web control application is now available free for any TRi PLC user to download and install into their PLC. In the previous section (2.9 Installing a Control Web Page Into the F-series PLC) you were shown how to transfer html files to the FServer.
Click on the following link to download this new web application.

     http://www.tri-plc.com/download/webapp/webapp02.zip

The “Webapp02.zip” file you downloaded above (or in Section 2.9) for Fx PLCs contains the following:

• Four sample control web pages (0-C001-02.HTM, 0-C002-02.HTM, 0-C002-02-NoLCD.HTM, and 0-C003-02.HTM)
• A readme file (Readme.txt)
• A download link (UserGuide.htm) for the quickstart modification guide
• PLC program files for TRiLOGI 6 and 7 (webAppTest.PC6 and webAppTest.PC7) that can be loaded in the PLC

The user guide describing how you can modify the control webpage can be downloaded directly from:

     http://www.triplc.com/documents/WebApp_UserGuide.pdf

The physical I/O and internal relays can be programmed in ladder logic in a few simple steps.

3.2.1 For Physical I/O

1. Edit the label names
2. Place the input contact(s) into the ladder logic circuit
3. Place the output coil at the end of the ladder logic circuit

3.2.2 For Internal Relays (Non-Latching)

1. Edit the label names
2. Place the relay contact(s) into the ladder logic circuit
3. Place the relay coil at the end of the ladder logic circuit

3.2.3 For Internal Relays (Latching)

1. Edit the label names
2. Place the activating input/relay contact into the ladder logic circuit
3. Place the latching relay in parallel with the activating contact
4. Place the relay coil at the end of the ladder logic circuit

3.2.4 Programming Examples:

a) Example 1 – Editing Label Names

The Digital I/O can be named by selecting “I/O Table” from the “Edit” menu and choosing the particular digital I/O that you want to name. In Figure 3.1, physical input #1 is being named “Input1”.

b) Example 2 – Creating a Simple Ladder Logic Circuit

You can place components in the circuit by clicking in the green area to the right of the red arrow, as shown below. This will bring up the component tool bar in the gray area above the green circuit area.

Once the component toolbar is shown, you can place your input/relay contact by selecting the #1 component from the toolbar and then selecting the digital input from the I/O Table. The contact will then be automatically placed in the ladder logic circuit. The same can be done for the output coil by selecting the #7 component from the toolbar and then selecting an output that has been entered into the I/O Table. After selecting one input and one output, the ladder logic circuit should like something like the figure below:

c) Example 3 – Creating a Latching Relay Circuit

The first part of the circuit follows the same procedure as the previous example, except that the #7 coil should be a Relay coil. So it should look similar to the circuit in Figure 3.3. The next part requires a parallel contact to be added to the Input1 contact. This is done by selecting the Input1 contact (or whichever contact was used) and then adding the “#3” parallel contact as shown in the following figure:

In order to program digital I/O or anything in a custom function, a custom function must be created in the I/O Table and added in a ladder logic circuit. Custom functions act the same way as coils in ladder logic, in that that they need a contact to activate them. Once they are activated, the code inside them will execute.

To create a custom function circuit, follow these 3 steps:

1. Edit the name of the custom function in the I/O Table
2. Place the activating contact in the ladder logic circuit
3. Place the custom function at the end of the circuit

Placing the custom function in the circuit is done the same way as other ladder logic contacts and coils, by selecting the —[Fn] symbol and then choose the Differential custom function {dCusF} from the pop-up window. Gives the custom function a name when prompted (up to 16 characters max) – e.g. fTest1

The completed circuit should look something like below:

An empty custom function looks like this:

TBASIC code is entered into the custom function, which allows the possibility of total control of all of the PLCs functions and hardware.

There are 7 TBASIC functions available to control all of the digital I/O, which are:

1. SETIO labelname
2. CLRIO labelname
3. TOGGLEIO labelname
4. TESTIO (labelname)
5. SETBIT v,n
6. CLRBIT v, n
7. TESTBIT (v, n)

Each function has its own advantage depending on what needs to be done to a digital I/O. Each of these functions is explained in the programmer’s reference manual, which should be referred to for further information. Here are some examples of how to control digital I/O using these functions.

Example 1 – Turn on/off an Output

This can be done using both the SETBIT v,n / CLRBIT v,n command and the SETIO labelname / CLRIO labelname command.

1. Using SETBIT v,n / CLRBIT v,n

SETBIT OUTPUT[1], 0 'This will turn on the first output using the output[] register
CLRBIT OUTPUT[1], 7 'This will turn off the 8th output using the output[] register

2. Using SETIO labelname / CLRIO labelname

SETIO out1  'This will turn on the output out1
CLRIO out5  'This will turn off the output out5

In this case, out1 and out5 would need to be entered in the I/O Table as an output. Otherwise, there will be a compilation error.

Example 2 – Toggle an Output

TOGGLEIO light 'This will change the output, light, from off to on or on to off

The output, light, would need to be entered into the I/O Table as an output as well and could represent any desired output.

Example 3 – Test the Status of an Output

This can be done using both the TESTBIT (v, n) and TESTIO (labelname) command.
Using TESTBIT (v, n)

X = TESTBIT (INPUT[2], 1) 'status of input #10 (on = 1, off = 0) is stored in variable</me)
X = TESTIO (button) 'status of input label 'button' (defined in the I/O table) is stored in variable X

a) Timer Coils

A timer is a special kind of relay that, when its coil is energized, must wait for a fixed length of time before closing its contact. The waiting time is dependent on the “Set Value” (SV) of the timer. Once the delay time is up, the timer’s N.O. contacts will be closed for as long as its coil remains energized. When the coil is de-energized (i.e. turned OFF), all the timer’s N.O. contacts will be opened immediately. However, if the coil is de-energized before the delay time is up, the timer will be reset and its contact will never be closed. When the last aborted timer is re-energized, the delay timing will restart and use the SV of the timer rather than continue from the last aborted timing operation.

b) Counter Coils

A counter is also a special kind of relay that has a programmable Set Value (SV). When a counter coil is energized for the first time after a reset, it will load the value of SV-1 into its count register. From there on, every time the counter coil is energized from OFF to ON, the counter decrements its count register value by 1. Note that the coil must go through an OFF to ON cycle in order to decrement the counter. If the coil remains energized all the time, the counter will not decrement. Hence, a counter is suitable for counting the number of cycles an operation has gone through. When the count register hits zero, all of the counter’s N.O. contacts will be turned ON. These counter contacts will remain ON regardless of whether the counter’s coil is energized or not. To turn OFF these contacts, you have to reset the counter using a special counter reset function [RSctr].

c) Sequencers

A sequencer is a highly convenient feature for programming machines or processes that operate in fixed sequences. These machines operate in a fixed, clearly distinguishable step-by-step order, starting from an initial step, progressing to the final step, and then restarting from the initial step again. At any moment, there must be a “step counter” to keep track of the current step number. Every step of the sequence must be accessible and can be used to trigger some action, such as turning on a motor or solenoid valve, etc. As an example, a simple Pick-and-Place machine that can pick up a component from point ‘A’ to point ‘B’ may operate as follow:

The timers and counters can be programmed in ladder logic in a few simple steps.

For Timers

1. Edit the label names
2. Place the input contact(s) into the ladder logic circuit
3. Place the timer coil at the end of the ladder logic circuit
4. Place the timer contact in one or more ladder logic circuits

For Counters

1. Edit the label names
2. Place the input contact(s) into the ladder logic circuit
3. Place the counter coil at the end of the ladder logic circuit
4. Place the counter contact in one or more ladder logic circuits (optional)

Example 1 – Creating a Simple Timer Circuit in Ladder Logic

After creating a ladder circuit that contains one input and one timer output and another ladder circuit that contains one timer contact and one output, the ladder logic circuit should like something like Figure 4.2, below:

a) Timers and Counters Present Values

The present values (PV) of the 64 timers and 64 counters in the PLC can be accessed directly as system variables:

timerPV[1] to timerPV[64], for timers' present value
ctrPV[1] to ctrPV[64], for counters' present value

b) Inputs, Outputs, Relays, Timers and Counters Contacts

The bit addressable I/Os elements are organized into 16-bit integer variables TIMERBIT[n] and CTRBIT[n] so that they may be easily accessed from within a CusFn. These I/Os are arranged as shown in the following diagram:

c) Changing The Timer and Counter Set Values in a Custom Function

You can use the SetTimerSV and SetCtrSV functions to change the Set Value (SV) for a timer and counter respectively. An example of this is shown below:

SetTimerSV 1,500 'Define Timer #1 to have a Set Value of 500
SetCtrSV 10,1000 'Define Counter #10 to have a Set Value of 1000

d) Controlling a Timer or Counter in a Custom Function

You can activate a timer or a counter directly from within a custom function simply by assigning their present value counter to a desired value. E.g. To start a 50 seconds timer:

TIMERPV[2] = 500   ' Timer #2 will time out 50.0 seconds later.

E.g. To decrement a counter or a sequencer:

CTRPV[10] = CTRPV[10] - 1 ' Counter #10 is decremented by 1.

Introduction

TRiLOGI Version 7 supports eight sequencers of 32 steps each. Each sequencer uses one of the first eight counters (Counter #1 to Counter #8) as its step counter. Any one or all of the first eight counters can be used as sequencers “Seq1” to “Seq8”.

To use a sequencer, first define the sequencer name in the Counter table by pressing the <F2> key and scroll to the Counter Table. Any counter to be used as sequencer can only assume label names “Seq1” to “Seq8” corresponding to the counter numbers. For e.g. if Sequencer #5 is to be used, Counter #5 must be defined as “Seq5”. Next, enter the last step number for the program sequence in the “Value” column of the table.

A circuit that uses the special function “Advance Sequencer” [AVSeq] will need to be constructed. The first time the execution condition for the [AVseq] function goes from OFF to ON, the designated sequencer will go from inactive to step 1. Subsequent changes of the sequencer’s execution condition from OFF to ON will advance (increment) the sequencer by one step. This operation is actually identical to the [UPctr] instruction.

The upper limit of the step counter is determined by the “Set Value” (SV) defined in the Counter table. When the SV is reached, the next advancement of sequencer will cause it to overflow to step 0. At this time, the sequencer’s contact will turn ON until the next increment of the sequencer. This contact can be used to indicate that a program has completed one cycle and is ready for a new cycle.

Accessing individual steps of the sequencer is extremely simple when programming with TRiLOGI. Simply create a “contact” (NC or NO) in ladder edit mode. When the I/O window pops up for you to pick a label, scroll to the “Special Bits” table as follow:

The “Special Bits” table is located after the “Counters” table and before the “Inputs” table. Click on the “SeqN:x” item to insert a sequencer bit. You will be prompted to select a sequencer from a pop-up menu. Choose the desired sequencer (1 to 8) and another dialog box will open up for you to enter the specific step number for this sequencer.

Each step of the sequencer can be programmed as a contact on the ladder diagram as “SeqN:X” where N = Sequencers # 1 to 8 and X = Steps # 0 – 31. E.g.

Seq2:4 = Step #4 of Sequencer 2.
Seq5:25 = Step #25 of Sequencer 5.

Although a sequencer may go beyond Step 31, if you define a larger SV for it, only the first 32 steps can be used as contacts to the ladder logic. Hence it is necessary to limit the maximum step number to not more than 31.

Quite a few of the ladder logic special functions are related to the use of the sequencer. These are described below:

a)  Advance Sequencer – [AVseq]

Increment the sequencer’s step counter by one until it overflows. This function is identical to (and hence interchangeable with) the [UpCtr] function.

b)  Resetting Sequencer – [RSseq]

The sequencer can also be reset to become inactive by the [RSseq] function at any time. Note that a sequencer that is inactive is not the same as sequencer at Step 0, as the former does not activate the
SeqN:0 contact. To set the sequencer to step 0, use the [StepN] function described next.

c) Setting Sequencer to Step N – [StepN]

In certain applications it may be more convenient to be able to set the sequencer to a known step asynchronously. This function will set the selected sequencer to step #N, regardless of its current step number or logic state. The ability to jump steps is a very powerful feature of the sequencers.

d)  Reversing a Sequencer

Although not available as a unique special function, a sequencer may be stepped backward (by decrementing its step-counter) using the [DNctr] command on the counter that has been defined as a sequencer. This is useful for creating a reversible sequencer or for replacing a reversible “drum” controller.

e) Program Example

Assume that we wish to create a running light pattern which turns on the LED of Outputs 1 to 4 one at a time every second in the following order: LED1, LED2, LED3, LED4, LED4, LED3, LED2, LED1, all LED OFF and then restart the cycle again. This can be easily accomplished with the program shown in Figure 4.5.

The 1.0s clock pulse bit will advance (increment) Sequencer #2 by one step every second. Sequencer 2 should be defined with Set Value = 8. Each step of the sequencer is used as a normally open contact to turn on the desired LED for the step. A “Stop” input resets the sequencer asynchronously. When the sequencer counts to eight, it will become Step 0. Since none of the LEDs are turned ON by Step 0, all LEDs will be OFF.

You can change the current step of Sequencer easily from within a Custom Function by changing the present value of their equivalent counter. E.g. Sequencer #3 is the same as Counter #3, thus if you wish to assign Sequencer #3 to Step 10, you can achieve it as follows:

CTRPV[3] = 10

Wx100 PLC has built-in 6 channels of 12-bit, 0.5V to 5V analog inputs that is pin-shared with digital inputs 1-6.

When the PLC is first powered on input 1-6 defaults to digital inputs. Once you run a ADC(n) command the input #n becomes an analog input.  The ADC(n) function returns the 12-bit analog reading from channel n. The built-in analog input is unable to properly read analog input voltage < 0.5V. Hence the range is between about 412 and 4095.

a) Wiring ADC to Wx100 PLC via Wx-TERM8 or Wx-TERM16

With Wx-TERM8 and Wx-TERM16, you simply wire the 0-5V output from an analog sensor directly to any of the input 1-6 and 0V to the Wx-TERM8 0V input and run the ADC(n) command to obtain the analog data.

b) Wiring ADC to Wx100 PLC via Customized Terminal Board

Note that each digital/analog input on a WxTERM-8 and WxTERM-16 incorporates a 20K ohm 1% current limiting resistor in between the input terminal and the signal to the Wx100 ribbon cable connector. The Wx100 has scaled the analog inputs that include the 20K ohm resistors in its calculation.

Therefore, if you design your own terminal board and have designated an input to be analog input, then you need to add a 20K ohm 1% resistor in series with the analog signal.

c) Electrical Characteristics

Note that each ADC input channel has an input impedance of 164.2K ohm. Hence to avoid loading effect your sensor need supply at least (5/164200 = 0.03mA) at 5V.

d) Interfacing to 0-20mA and 0-10V Analog Signals

With addition of simple resistors you can easily convert 0-20mA or 0-10V signal to 0 to 5V which can then be measured by the Wx100 analog inputs. Please refer to the following diagrams:

Note: The parallel resistance of the (249+1.37=250.37 ohm) and the internal 164.2K impedance of the Wx-TERM8+Wx100 PLC yields 250 ohm, which is then used to convert 20mA current to 5V.

e) Interfacing to Two-Wire 0-20mA Analog Signals

Many 4-20mA analog sensors only have two wire connections and are designed to be powered by the 4-20mA output current that flows through it. These types of sensors can be interfaced easily to the 0-5V analog inputs of the PLC as shown in the following diagram:

The sensor output will be converted to a 1-5V analog voltage and can be read by the PLC using the ADC(n) statement, which will return readings of between 820 and 4092.

Up to 64 additional 12-bit, 0-5V analog inputs can be added to Wx100 PLC with adequate expansion I/O boards. Please refer to the Wx-EXP User Manuals for more details when the product is available.

The 6 analog input signals are read by the TBASIC command ADC(1) to ADC(6). The ADC(n) function will return a number between 0 and 4095(12-bit resolution), which corresponds to the measured voltage at any of the analog inputs n. The resolution of a 12-bit ADC is 1/4096 = 1/4096, this means that for the 0-5V ADC range, the resolution is 5/4096V = 1.22mV.

That means that if you apply a 2.500V to the PLC’s analog input #3, ADC(3) should return a value of 2.500/5.000 x 4096 = 2048.

Note that the CPU only accesses the analog input #n when the TBASIC function ADC(n) is called.  Since the analog input on Wx100 is pin-shared with the digital inputs, the pin will be configured as analog input the first time ADC(n) function is run on the channel n.  The shared input terminal will be reset to digital inputs only when the Wx100 is power cycled.

Also, in order to monitor the analog input, you have to execute the ADC function periodically. The frequency that the ADC function is called is known as the “sampling rate” and it depends on how fast the analog data changes. If the analog data changes slowly (such as room temperature) then there may be no need to sample the analog at high frequency.

A very simple example of sampling the analog inputs #1 to #4 every second and converting the data into voltage readings of  0.50 to 5.00V) is shown as follow:

Moving Average

The Wx100 PLC offers a built-in “Moving Average” computation routine for ADC channel 1-6. When moving average is enabled the PLC firmware would store the past analog readings for each channel in its own historical memory array, and each new instantaneous reading would overwrite the oldest reading. When you run the ADC(n) function, the PLC firmware would return the average of these past readings instead of the instantaneous new reading.

You can define a moving average of 1 to 9 points using the procedure described in Section 5.4.5

Defining a larger moving average can better help to even out fluctuations in ADC readings that can be caused by interference from digital noise. However, the larger the moving average, the slower the ADC(n) function can detect a sudden change in the amplitude of the analog signal due to the averaging effect.

For a system that needs to quickly detect a signal change, consider using either a smaller number of moving average points or call the ADC(n) function more frequently so that a sudden change can be detected earlier.

To further even out fluctuation in the analog readings, you can perform a number of reads and then take their average.

E.g.

    A = 0
    FOR I = 1 to 100
       A = A + ADC(1)
    NEXT 
    B = A/100  ' B contains a average of 100 readings taken from the ADC channel #1

Scaling of Analog Data

The analog inputs on the Wx100  return data in the range of 0 to 4092, which corresponds to the full range of the voltage input presented at the analog pin. However, very often a user needs a formula to translate this numeric data into units meaningful to the process (e.g. degree C or F, psi etc). To do so, you need to know at least two reference points of how the native unit maps to the PLC’s ADC reading.

Reference Point    ADC Reading
    x1                 a1 
    x2                 a2 

Hence, for any reading A = ADC(1), the corresponding X is derived from:

(X - x1)/(x2 - x1) = (A - a1)/(a2- a1) 
--> X = (x2 - x1)*(A - a1)/(a2 - a2) + x1

Note that since x1, x2, a1, and a2 are all constants the actual formula is much simpler then it appears above. E.g. Temperature measurement

Temp         ADC(n) 
------------------------
30.0          200 
100.0         3000 

So for any ADC readings A, the temperature is: X# = 70.0*(A – 200)/2800 + 30.0

a) Thermistor Temperature Sensors

A thermistor is a kind of resistor whose resistance decreases when its surrounding temperature increases. It is a very low cost and stable device that can be used to measure a wide range of ambient temperature from freezers to hot water boilers, which are commonly used in HVAC applications.

In order to convert the resistance changes into voltage readings to be read by the PLC’s analog input, you can use it to form an arm of a voltage divider circuit which would present a variable voltage to the analog input when the temperature changes. A type of thermistor that measures 10.0K ohm at 25 degree C (simply called 10K thermistor) is especially suitable for use with the Fx2424 PLC, as illustrated below:

For ADC #1 to #6, you can use an external 22.775 K Ohm resistor to form the voltage divider with the 10K thermistor. The 22.775K resistance, when parallel with the internal 164.2K resistor yields a 20K resistance, which can readily use the example program in the sample program without modification. However, you can also choose a slightly different resistor value and compute the parallel resistance, then enter the value into the Excel spreadsheet included with the example program.

Note that since the thermistor resistance value vs. temperature change is a non-linear function, you cannot simply use a formula to calculate the temperature from the voltage value. For better accuracy you need to use a look up table plus a linear interpolation technique to determine the temperature based on the ADC readings. The look up table and interpolation method can be implemented using TBASIC quite easily. For your convenience, we have provided a sample TBASIC program that you can download from the following web page:

http://www.tri-plc.com/appnotes/F-series/ThermistorSensorFPLC.zip

This example uses the R-T (Resistance-Temperature) graph of the Precon Type III thermistor to implement the temperature look up. We have provided an Excel file that computes the ADC reading vs ambient temperature for this thermistor type. The TBASIC program uses these ADC readings to determine the temperature.

The sample program is structured such that the lookup table values are stored in the EEPROM and you can readily adapt it to other types of thermistors with a different R-T graph. The program only implements lookup for a temperature range of –10oF to 100oF, but you can also easily change the temperature range of interest.

Note:

You may also use a 100K thermistor to connect directly to the PLC’s analog input and using its internal 164.2K impedance and the thermistor to form a voltage divider. We did not provide an example program for such a connection but you can write the program by following the example of 10K thermistor forming a voltage divider with a 20K resistor.

b) Using LM34 Semiconductor Sensor

The LM34 is a wonderful, low cost semiconductor temperature sensor with a range of –50 oF to 300 oF. It is extremely easy to use for measuring temperature above 0 oF. You simply connect one pin to the positive voltage (+5 to +30V) and the other pin to 0V, and the signal pin will output a voltage that is directly proportional to the ambient temperature in oF. The output voltage is 10mV per degree F.

So at room temperature of 72 degrees F, the device will output a voltage of 72 x 0.01 = 0.72V. If you connect this to the PLC’s analog input, you can obtain the temperature in degree F or degree C using the formula:

     F = ADC(1)*500/4096  'in degree F

OR

     C = (F – 32)*5/9     'in degree C

Although another part number LM35 can output temperature in 10mV per degree C, the output falls into even lower ADC range for ambient temperature measurement since the same 72 degree F is only 22 degree C, which means LM35 only outputs 22 x 0.01 = 0.22V. Hence for better accuracy and resolution we recommend using LM34 instead of LM35 and if need be then convert it to degree C using TBASIC.

Another advantage for using LM34 instead of LM35 is that you can measure down to 0.oF (-17 degree C) without using a negative voltage source as shown in the circuit on the right in Figure 5.7.

c) Using Thermocouple

Thermocouples are very rugged devices that are widely used in the industry because of their stability, accuracy, and wide functional temperature range. They are commonly used in measuring temperature in ovens that may go up to several hundred degrees C.

However, thermocouple output signals are in the range of tens of microvolts to mille-volts, which is too small to be measured by the Wx100’s analog input directly. You will need a “signal conditioner” that can amplify the thermocouple output to 0-5V, which can then be connected to the PLC’s analog input.

d) Using PT100 Temperature Sensor

PT100 is a positive temperature coefficient thermistor that is made from platinum. It has the advantage of being very stable and highly accurate. It is usually connected to a signal conditioner in a balanced bridge configuration and the signal conditioner will convert temperature changes to 0-5V output for the PLC.

The basic Wx100 + Wx-TERM8 does not support any analog output. However, there are 6 channels of PWM outputs on the digital outputs which in many cases could be used to simulate analog output for control purposes.

The Wx-TERM16, a more powerful terminal boards for Wx100 PLC, supports 4 channel of 12-bit analog outputs. 2 of these analog outputs are 0-20mA and 2 are 0-5V.  Please refer to Wx-TERM16 User’s Manual for more details.

Digital inputs #1 + 2, #3 + 4, and #5 + 6 form three channels of high speed counter inputs which can interfaced directly to a rotary encoder that produces “quadrature” outputs. A quadrature encoder produces two pulse trains at a 90o phase shift from each other as follows:

When the encoder shaft rotates in one direction, phase A leads phase B by 90 degrees. When the shaft rotates in the opposite direction, phase B will lead phase A by 90 degrees. The quadrature signals therefore provide an indication of the direction of rotation.

The Wx100 handles the quadrature signals as follows: if the pulse train arriving at input #3 leads the pulse train at input #4, the High Speed Counter (HSC) #1 increments on every pulse. If the pulse train arriving at input #3 lags the pulse trains at input #4, then the HSC #1 decrements. Note that if input #4 is OFF, then pulse trains arriving at input #3 are considered to lead the input #4 and HSC #1 will be incremented. Likewise if input #3 is OFF, then pulse trains arriving at input #4 will decrement HSC #1.

Inputs #5 and #6 form the inputs for High Speed Counter channel #2 and Inputs #7 and #8 forms the inputs for High Speed Counter channel #3. HSC#2 and HSC#3 operate in the same way as HSC#1 described above.

The fact that the Wx100 automatically takes care of the direction of rotation of the quadrature encoder greatly simplifies the programmer’s task of handling high-speed encoder feedback. The HSCDEF statement can be used to define a CusFn to be executed when the HSC reaches a certain pre-defined value. Within this CusFn you can define the actions to be taken and define the next CusFn to be executed when the HSC reaches another value. Please note that the HSDDEF statement will also activate the Pulse Measurement hardware as described in the Pulse Measurement section.
A programming example of the HSC can be found in your iTRiLOGI program folder:

C:\TRiLOGI\TL6\usr\samples\HighSpeedCtr.PC6

The default method in which the PLC handles quadrature signals as described above is somewhat simplistic. It does not take into consideration the “jiggling” effect that occurs when the encoder is positioned at the transition edge of a phase. Mechanical vibration could cause multiple counts if the rotor shaft “jiggles” at the transition edge of the phase, resulting in multiple triggering of the counter. This simplistic implementation, however, does have the advantage that the HSC can also be used for single phase high-speed counting.

For the Wx100, an enhanced quadrature decoding routine is provided which will lock out multiple counting by examining the co-relationship between the two phases. You can configure the Wx100 to use the enhanced quadrature counting by using the SETSYSTEM command, as follows:

   SETSYTEM 4, n

The value of n at bit 0, 1, and 2 respectively defines if the HSC channel 1, 2, and 3 is to run in “Simple” (when the bit is 0) or “Enhanced” (when the bit is 1) mode. As such:

If you have a choice, you should select an encoder that can produce 12V or 24V output pulses so that they can drive the inputs #3,4,5 ,6,7 or 8 directly. If you have a 5V type of encoder only, then you need to add a transistor driver to interface to the PLC’s inputs. The simplest way is to use an IC driver ULN2003A or ULN2803A connected as shown in the figure. Since ULN2003/ULN2803A  output is current-sinking type (NPN), you should connect V+ to the Pull-up input to turn the digital input into NPN type so that the driver chip output can sink current from the respective inputs.

1. To use the PM input to measure pulse width or frequency, execute the PMON statement ONCE to configure the relevant input to become a pulse measurement input. You usually put the PMON statement in the init custom function and execute it with a “1st.Scan” pulse.
2. Thereafter the pulse width (in microseconds) or the pulse frequency (in Hz) can be easily obtained from the PULSEWIDTH(n) or PULSEFREQUENCY(n) functions. You can also obtain the pulse period (inverse of frequency) using the PULSEPERIOD function.

      E.g.   A = PULSEWIDTH(1)
             B = PULSEPERIOD(1)
             C = PULSEFREQUNCY(1)
   

3.  All PM inputs by default return the measured pulse width and pulse period in unit of microsecond. However, for those who desire better resolution, you can define PM #1 to #4 to return the measured pulse width and pulse period in 0.1 microsecond resolution by executing the following command once only during initialization:

         SETSYSTEM 20, 1

4. Once the above statement is executed, if PUSLEWIDTH(1) to  PULSEWIDTH(6) returns the value 1234 it means the measured pulse width is 123.4 microseconds.  A sample program can also be found on your i-TRiLOGI installation folder at:

         C:\TRiLOGI\TL6\usr\samples\PulseMeasurement.PC6

a) Measuring RPM Of A Motor

One useful application of the PM capability is to measure the speed of rotation (RPM) of a motor. A simple optical sensor, coupled with a rotating disk with slots fitted to the shaft of a motor (See Figure 8.1) can be fabricated economically. When the motor turns, the sensor will generate a series of pulses. The frequency of this pulse train directly measures the rotational speed of the motor (RPM = Frequency x 60) and can be used to provide precise speed control.

Note that the above setup can also double as a low cost position-feedback encoder when used with the high speed counter, since the number of pulses counted can be used to determine the displacement. With the Wx100 PLC, the pulses can be both counted and measured simultaneously on the same input.

b) Measuring Transducer with VCO Outputs

Some transducers incorporate a Voltage-Controlled-Oscillator (VCO) type of output that represents the measured quantities in terms of varying frequency of the output waveform. Such transducers may be used conveniently by the Wx100 using the pulse measurement capability. However, the frequency of such signals should be below the maximum input pulse rate.

c) Measuring Transducer with PWM Outputs

Some transducers may output the readings of their measurands (the quantity that is being measured) in the form of “pulse-width modulated” outputs. This means that the transducer would send rectangular pulses with varying duty cycles that are proportional to the measured quantities. You can then easily use the PULSEWIDTH and PULSEPERIOD functions to compute the duty cycle of the incoming PWM pulses and readily convert it to the actual units of the measurands. The Wx100 PLC is able to measure with reasonable accuracy the pulse width of incoming pulses with frequency up to 50KHz .

For applications that require frequency measurement and pulse counting of the same signal, you only need to feed the pulse input into any pair of the inputs #1 & 2, or inputs #3 & 4, or inputs #5 & 6 and define it as a High Speed Counter (see Chapter 7). This is because an input pin that has been defined as an HSC will automatically be enabled for pulse measurement.

In other words, if you need to use the HSC and the Pulse Measurement on the same channel, then you don’t need to execute both the HSCDEF and PMON, you only need to execute the HSCDEF. The HSCDEF function will automatically start the Pulse Measurement hardware so it is not necessary to use the PMON function. However, if you use only the PMON function, it would not enable the HSC function. However, if you execute the HSCDEF function and then execute the PMON function, the HSC will be disabled, even though it was previously enabled.

During normal PLC ladder program execution, the CPU scans the entire ladder program starting from the first element, progressively solving the logic equation at each circuit until it reaches the last element. After which it will update the physical Inputs and Outputs (I/O) at the end of the scan. Hence, the location of a logic element within the ladder diagram is important because of this sequential nature of the program execution.
When scanning the ladder program, the CPU uses some internal memory variables to represent the logic states of the inputs obtained during the last I/O refresh cycle. Likewise, any changes to the logic state of the outputs are temporarily stored in the output memory variable (not the actual output pin) and will only be updated to the physical output during the next I/O refresh.

You can see that the CPU will only notice any change to the input logic state when it has completed the current scan and starts to refresh its input variables. The input logic state must also persist for at least one scan time to be recognized by the CPU. In some situations this may not be desirable because any response to the event will take at least one scan time or more.

An interrupt input, on the other hand, may occur randomly and the CPU will have to suspend whatever it is doing as soon as it can and start “servicing” the interrupt. Hence, the CPU responds much faster to an interrupt input. In addition, interrupts are “edge-triggered”, meaning that the interrupt condition occurs when the input either changes from ON to OFF or from OFF to ON. Consequently, the input logic state need not persist for longer than the logic scan time for it to be recognized by the CPU.

The Wx100 PLC supports up to 8 interrupt inputs: Any one or all of digital inputs #1 to #8 can be defined as interrupt inputs using the INTRDEF statement. The Interrupt inputs may also be defined as either rising-edge triggered (input goes from OFF to ON) or falling-edge triggered (input goes from ON to OFF). When the defined edges occur, the defined CusFn will be immediately executed irrespective of the current state of execution of the ladder program. A simple interrupt test function is as follow:

Variable A will be incremented on every rising edge sensed on input #3 (mapped to interrupt input #1)

Note:

Since inputs 3 to 8 can also be used as other special inputs such as High Speed Counter (HSC) inputs and/or Pulse Measurement (PM) as described in Chapter 6, 7 and 8, if these inputs are also defined as interrupts using the INTRDEF statement, then the defined custom function will also be called whenever a defined interrupt edge has occurred.

The Periodic Timer Interrupt (PTI – not available on T100M+ PLC) lets you define a custom function that will be executed by the CPU precisely every x number of milliseconds (ms). The syntax for setting up a PTI is as follow:

     INTRDEF 18, cfnum, x   ' Interrupt 18 is reserved for PTI
           cfnum - custom function number to execute when PTI event takes place.
               x - The period in number of milliseconds between two PTI events.

     E.g. INTRDEF 18, 101, 15 ‘ call function #101 every 15 ms.

The Periodic Timer Interrupt runs independently of the ladder logic and its execution is therefore not affected by the total PLC program scan time.

When the PTI timer times up, the CPU will suspend the execution of the ladder logic or a (non-interrupt) TBASIC function and immediately calls up the custom function defined by the INTRDEF 18 statement. However, if the CPU is currently executing a user-interrupt service routine (e.g. an input interrupt or HSC interrupt), then the CPU will have to complete the current interrupt service routine before it will run the PTI interrupt function.

Notes:

1) Limit the use of PTI only for critical code that requires precise timing between two events. Program bugs that occur due to problems in the PTI interrupt routine may be quite hard to debug.

2) For normal periodic routines, such as checking for temperature or checking serial port for incoming bar code data every few seconds, it is better to use the system clock pulses e.g. “Clk:1.0s” to trigger a {dCusF}.

3) Always try to keep your interrupt service routine short and ensure that it will not end up in an endless loop. The TBASIC custom function execution time should be much shorter than the period of the PTI events. Otherwise, you may find that the CPU will be spending most of its time servicing the PTI interrupt routine, leaving very little time for scanning the ladder program, and that will have an adverse impact on the CPU performance.

It is essential to understand the difference between a stepper motor “Controller” and a stepper motor “Driver”. A stepper motor “Driver” comprises the power electronics circuitry that provides the voltage, current, and phase rotation to the stepper motor coils. A stepper controller on the other hand, only supply the “direction” and “pulse” signals to an external stepper motor driver to actually rotate the stepper motors.

The Wx100 PLC supports 3 channels of stepper controller only, or 1 channel of stepper motor driver + 1 channel or stepper controller. i.e A small stepper motor can be driven directly by the PLC, or the PLC can  supply up to 3 sets of control signals to an external stepper motor driver.

The PLC as a stepper driver takes up 4 out of its 6 high speed digital outputs and is limited by its 0.5A current drive limit. It is hence suitable mainly for driving small stepper motor where maximum coil current < 0.5A. To control higher power stepper motors, we recommend using external stepper motor drivers that also provide other important functions such as thermal management, over current protection etc.

The Wx100 can drive 1 small stepper motors directly, using digital outputs #1, 2, 3 & 4,  All these outputs are capable of driving stepper motors of up to 0.5A per phase. Note that any outputs that have been defined for use with a particular stepper channel would no longer be available as regular digital outputs in the ladder or TBASIC program. Please refer to Chapter 6 for a definition of the list of special digital I/Os.

a) Stepper Motor Wiring Types

The most commonly available stepper motors today are either 4-wire, 5-wire or 6 wires types and their windings are as shown in Figure 10.1

•  4-wire stepper motors require drivers that can reverse current flow from coil terminal 1 to 2 or from 2 to1, as well as from terminal 3 to 4 or from 4 to 3. These kinds of drivers are known as “bipolar drivers”.
• 5-wire stepper motors typically connect the common terminal (5) to the power (e.g. +24V DC) and 4 current sink drivers are connected to terminals 1 to 4 to sink the current to 0V. The sequence in which the four coils are activated controls the rotation of the stepper motor. These kinds of drivers are known as “unipolar” drivers.
• 6-wire stepper motors are the most flexible and may be connected either to bipolar drivers (leaving terminals 5 and 6 unconnected) or to unipolar drivers (connecting terminals 5 & 6 together to “+” terminal).

Since all the Wx100 digital outputs are NPN (current sink) type, only 5- or 6-wire type stepper motors can be used.

If you have a stepper motor with 6 wires (most common) but you do not have the wiring diagram, you may be able to figure out which wire is which terminal by using a multi-meter to measure the resistance between coils. E.g. the resistance between terminals 1 and 2 will be twice the resistance between terminals 1 and 5 or between 2 and 5, likewise for terminals 3,4 and 6. There will be no connectivity between terminal 1 and 3 and between terminal 2 and 4. It will however be more tricky to figure out the actual wiring of a 5-wire stepper motor since it is difficult to figure out which is the coil 1-2 and which is the coil 3-4, so some trial and error may be required to get the motor working.

b) Damping Circuits (Inductive Bypass)

Since the stepper motor windings are all inductors, it is important to connect damping diodes across each winding to absorb the inductive kicks produced when the windings are turned OFF. There are several ways to connect the damping circuit; the simplest way is to connect a diode from the PLC’s output to the stepper motor power supply V+, as shown below in Figure 10.2.

The above circuit works best when the stepper motor power is the same voltage as or is a slightly higher voltage than the PLC’s power supply. (Note: The maximum stepper motor’s power supply voltage must not exceed the PLC’s stepper output driver breakdown voltage of 40V)

If the stepper motor’s power supply were lower than the PLC’s power supply, then connecting the output shown in Figure 10.2 would result in the PLC’s output LED to light up, even when the output driver is off. This is because the PLC’s output LED is tied to the PLC’s power supply and a lower voltage at the load’s power supply would cause current to flow out of the PLC’s output terminal into the load’s power supply and therefore turning on the output LEDs. Although this should not affect the driver’s function it can be misleading to the user as to the PLC’s output state. Hence, we recommend connecting a diode in series with each of the PLC’s outputs to block such reverse current flow:

Since the built-in driver use up 4 of the 6 outputs available on Wx100 with Wx-TERM8, you may need to preserve the outputs for other purposes, or or if the built-in stepper driver is not suitable for your application (e.g. if you need micro-stepping or you need to drive a higher power stepper motor), then you can use an external stepper motor driver and use the PLC to send direction and output pulses to the stepper motor driver.

When configured as a Stepper-Motor Controller, the PLC would generate the required number of “pulses” and sets the direction signal according to the defined acceleration and maximum pulsing rate specified by “STEPSPEED” and “STEPMOVE” commands. The “pulse” and “direction” outputs are not meant to be connected directly to the stepper motor. Instead, you will need a stepper motor “driver”, which you can buy from the motor vendor. Depending on the power output, the number of phases of the stepper motor, and whether you need micro-stepping, the driver can vary in size and cost. Most stepper motor drivers have opto-isolated inputs which accept a direction signal and stepping-pulse signal from the “Stepper Motor Controller”. In this case the Wx100 is the “Stepper Motor Controller” which will supply the required pulse and direction-select signals to the driver. A Wx100 PLC can control up to 3 stepper motor drivers using all its 6 digital outputs.

Note that the digital outputs #1, #3, and #5 automatically become the direction-select signals for the Stepper controller channels #1, #2, and #3, respectively, when the stepper controllers are being used. The direction pin is turned ON when the motor moves in the negative direction and turned OFF when the stepper motor moves in the positive direction. The STEPMOVEABS command makes it extremely simple to position the motor at an absolute location, while the STEPMOVE command lets you implement incremental moves in either direction for each channel.

Interfacing to 5V Stepper Motor Driver Inputs

Some stepper motor drivers accept only 5V signals from the stepper motor controller. In such a case, you need to determine whether the driver’s inputs are opto-isolated. If they are, then you can simply connect a 2.2K current limiting resistor in series with the path from the PLC’s output to the driver’s inputs, as shown in Figure 10.4.

However, if the stepper motor driver input is only 5V CMOS level and non opto-isolated, then you need to convert the 12-24V outputs to 5V. This can be achieved using a low cost transistor such as a 2N4403. A better way is to use an opto-isolator with a logic level output, as shown in Figure 10.4. This provides a galvanic isolation between the PLC and the stepper motor driver.

a) Introduction

Any of the 3 stepper-motor channels can be configured as either a Controller (direction/pulse) or a Driver; and as a Driver, can drive in FULL STEP mode or HALF STEP mode. The stepper channels are controlled by the PLC program using the “STEPMOVE” and “STEPMOVEABS” commands. These commands have the same parameters as they did when they were used on M-Series PLCs. For example,

   STEPMOVE ch, count, r
   STEPMOVEABS ch, position, r

The ch parameter is the channel. This is how the PLC knows which stepper motor channel to turn on. Now this parameter is also used to set the stepper motor channel to controller mode, full-step driver mode, or half-step driver mode.

To set the stepper motor channel to controller mode, the ch parameter should be a “1”, “2”, or “3”.

To set the stepper motor channel to driver mode, the ch parameter needs to have a “1” prefixed to it for full-step mode and a “2” prefixed for half-step mode.

b)  Full-Step Driver Mode:

     STEPMOVE 11, 100, 1 ‘Stepper channel 1 will be driven 100 full steps
     STEPMOVE 12, 100, 1 ‘Stepper channel 2 will be driven 100 full steps
     STEPMOVE 13, 100, 1 ‘Stepper channel 3 will be driven 100 full steps

c)  Half-Step Driver Mode:

     STEPMOVE 21, 100, 1 ‘Stepper channel 1 will be driven 100 half steps
     STEPMOVE 22, 100, 1 ‘Stepper channel 2 will be driven 100 half steps
     STEPMOVE 23, 100, 1 ‘Stepper channel 3 will be driven 100 half steps

The same format should be used for STEPMOVEABS, except that the count parameter is changed to the position parameter (more details provided in the Programmers Reference manual and also in the program examples section of this chapter).

d)  Setting the Acceleration Properties

Whether the stepper motor channels are being used to control a stepper motor driver or to drive the motor directly, the STEPSPEED command must be executed first in order to define the acceleration settings. Once this command has been executed, the acceleration settings will not change until another STEPSPEED command is executed with different settings or if the PLC is powered down. If the PLC is powered down, the STEPSPEED command will need to be executed again before the stepper motor channels can be used. However, if a software reset executed (from online monitoring or within the program), the STEPSPEED command does not need to be re-executed.

     STEPSPEED ch, pps, acc

The ch parameter should be a value between 1 and 3. Speed, pps, is based on the no. of pulses per second (pps) output by the pulse generator. The pps parameter should be set to a value between 1 and 10000 (max rated pps for the Wx100). The acceleration, acc, determines the total number of steps taken to reach full speed from a standstill and the number of steps from full speed to a complete stop. The stepper motor controller calculates and performs the speed trajectory according to these parameters when the STEPMOVE or STEPMOVEABS commands are executed.
To set stepper motor channel #3 to a speed of 100 pps in 50 steps, the command would be as follows:

   STEPSPEED 3, 100, 50

This would be equivalent to an acceleration of 100 pulses/s2, which can be calculated using the following expression:

    A = V^2/2S = 100^2/2*50 = 100pps^2

he TBASIC SETPWM statement controls the frequency and duty-cycle settings of the PWM channel. The Wx100 PLC features six channels of PWM on its digital outputs #1 (PWM channel #1) to output #6 (PWM channel #6).

The PWM channels can generate pulses with frequency ranging from 10Hz  to 50KHz. At the lower frequency range, the output frequency can be extremely accurate (less than 0.01% error). Even at 10KHz the output frequency error is less than 1% for channel 1 & 2, and < 0.1% for channel 3 to 6. This makes it possible to use the PWM channels to generate square wave pulses of a certain frequency.

Usually it is better to select as high a frequency as possible because the resulting effect is smoother at higher frequencies. However, some systems may not respond properly if the PWM frequency is too high, in such cases a lower frequency should be selected.

Since all 6 PWM outputs are high voltage, high current outputs (24V, 0.5A) they can be used to directly control the speed of a small DC motor. They can also directly drive proportional (variable position) valves whose opening is dependent on the applied voltage. Note: When using the PWM output to drive a motor or solenoid valve, please take note of the need to add a bypass diode to absorb the inductive kick that will occur when the output current to the load is turned OFF, as mentioned in Section 1.7c

PWM Speed Control of a large DC Motor.

The advantage of using the PWM is that you can easily amplify the drive current to a larger load such as a larger permanent magnet DC motor by using a power transistor or power MOSFET to boost the current switching capability. If the load is of a different voltage and the load current is high, you should use an opto-isolator to isolate the PLC from the load, as shown the above diagram.

Note:

1. The opto-isolator must be able to operate at a frequency matching that of the PWM frequency, otherwise the resulting output waveform will be distorted and effective speed control cannot be attained.
2. The simple PWM speed control scheme described above is the open-loop type and does not regulate the speed with respect to changing load torque. Closed-loop speed control is attainable if a tachometer (either digital or analog) is used which feeds back to the CPU the actual speed. Based on the error between the set point speed and the actual speed, the software can then adjust the PWM duty cycle accordingly to offset speed variation caused by the varying load torque. A PID function may also be invoked to provide sophisticated PID type of speed control.
3. The Fx2424’s PWM can be used to control the speed of small motors only (up to the maximum current limit that the PLCs output can safely drive). For larger motors, industrial-grade variable-speed drives should be used instead.

RC Servo is a class of DC servo motor commonly used in remote control (hence the term RC) for positioning a device at a desired location. It is often termed “proportional control” because the position where the motor will turn to is directly proportional to the pulse width of the control signal.  When chosen appropriately, RC Servo can provide an extremely inexpensive and versatile solution for positioning a device. For example, for controlling the percentage opening of a HVAC damper, or to rotate the angle of window blinds or to position a solar panel to track the sun light. There are many sizes of RC Servo available in the market, from those that weigh just a few grams to those for controlling an industrial scale unmanned vehicle (e.g. UAV or unmanned submarine).  A small, self-contained RC servo typically cost less than $20 retail price and is incredibly easy to control using the PWM output on the Wx100.

RC Servo typically only have 3 wires: Power “ + ” (typically 4.8 to 6V),  “ – “  and a “Control” input.

To position the RC Servo to a position within its range of travel (Some are 0 to 90 degree and there are those that can go from 0 to 180 degree), you send a positive pulse with pulse width between 1.00 ms to 2.00 ms to the “Control” input once every 20ms. The servo will position the actuator to one end when it receives a pulse of 1.00ms and the other end when it receive a pulse of 2.00ms. If you send it a pulse of 1.50ms it will position the actuator to the center.

In PWM term, 1.00ms pulse width every 20ms means a duty cycle of 1.00/20.00 = 5.00%.  2.00ms pulse width every 20ms means a duty cycle of 2.00/20.00 = 10.00% duty cycle. So to control the position of the actuator one only needs to send it a positive PWM signal with frequency = 1/0.02 = 50Hz and duty cycle between 5% and 10%.

The gear and servo feedback mechanism within the RC Servo produces a huge amount of torque relative to its weight for positioning the actuator to the position determined by the pulse width at the “control” input. Yet once it is in the correct position the servo draws only minimum current required to maintain its position. Hence being a closed-loop controller an RC Servo is actually a much more efficient and effective positional control device (for a limited range) than a stepper motor which relies on a constant current in its winding to provide the “holding torque” for positioning. The open loop nature of stepper motor means that it does not know if the device is actually being knocked out of its desired location whereas in the Servo any deviation from its desired location is instantly being corrected by the servo mechanism.

RC Servo Positioning Accuracy

Since the resolution on the Wx100 PLC’s PWM output is precise to 0.01% at 50Hz, this means that you can get a maximum of 500 discrete positions within the travel range of the RC Servo.  This should be sufficiently accurate for many applications such as HVAC damper control or control of proportional valves. The actual positioning accuracy and precision, however, will depend on the quality of the RC Servo.

Users of the FMD and Fx PLC may be familiar with the SETLCD command that allows the PLC to display text strings on  a 4 lines x 20 characters, optional LCD display that are supported by these PLCs.

Although the Wx100 PLC does not have a built-in LCD port to connect to the external LCD, it does support the SETLCD command in emulated mode. Wx100 will run the SETLCD command and store the result inside an internal “virtual LCD” memory buffer which is visible from the iTRiLOGI software as well as displayed on web browser via the webapp interface. This allows the programmer to use the virtual LCD to store some debugging information even without a real LCD.

However, to support previous and current users of FMD or Fx PLC users so that they can more easily port their original programs to the Wx100 with minimum effort,  the Wx100 by default will automatically  display the result of the SETLCD command on the OLED screen by emulating it as a 4 lines x 21 characters LCD display.

Notes:

    SETSYSTEM 30, n     ' n = 0: De-link OLED from SETLCD
                        ' n = 1: Link OLED to SETLCD

Wx100 simultaneously supports both the SETLCD command as well as newly added TBASIC commands such as DRAW_TEXT, DRAW_TEXTPOS,  DRAW_RECT, FILL_CIRCLE etc. We will discuss these new graphical commands in the next section.

a) SETLCD y, x, string

TBASIC command allows you to easily display any string of up to 20 characters on the y^th  line starting from the x^th  column.  E.g., to display the message “Wx100” on the 3^rd line starting from the 5th character position from the left end of the screen, you use the command:

   SETLCD 3, 5, “Wx100 Super PLC”

Normally, y  = 1,2,3, 4;  x = 1, 2, …. 20.  Integers must be converted to strings using the STR$() or HEX$() function before they can be displayed using SETLCD. You can use the concatenation operator “+” to combine a few components together in the command. E.g.

   SETLCD 1,1,“Rm Temp = ”+ STR$(ADC(1)/100,3)+” deg C”

The function STR$(ADC(1)/100,3) reads the content of ADC channel #1, divides it by 100 and converts the result into a 3-digit string. The final string being displayed will be :

   Rm Temp = 012 deg C.

b) Special Commands For LCD Display

If you use the SETLCD command with line #0, then the strings will be treated as special “instructions” to be sent to the LCD module to program it for various modes of operation.  For real external LCD this includes: blinking cursor, underline cursor or no cursor, as well as display shift mode. You have to refer to the LCD manufacturer’s data sheet for the detailed commands.

Since Wx100 does not support the actual LCD, only one special SETLCD command is supported as shown below:

     SETLCD 0, 1, CHR$(1)   ' clear LCD screen. Will also clear OLED screen if linked.

c)  Displaying Numeric Variable With Multiple Digits

The “SETLCD y, x, string” command only overwrites the exact number of characters in the string parameter to the LCD display, and thereafter the cursor is placed back to the location specified by the x and y parameters. Thus if there exists some old characters right after the last character it can cause confusion, especially if you are displaying a number. E.g. If you first display the following string at row 1 and column 1:

     Pressure = 12345

And if you subsequently display the string “Pressure = 983” at the same location without first clearing the line, then you will see the following string being displayed:

     Pressure = 98345

What happens is that the string “Pressure = 983” is correctly displayed but the two old characters “45” left over from previous display would appear to be part of the new data. This can cause confusion.

There are several ways you can eliminate such a display problem:

     SETLCD DM[100],1, "                    "

      SETLCD 1,1, "Money = $"+ STR$(D) + "      "

      SETLCD 1,1, “Temp = ”+ STR$(T,4)

d)  Displaying Floating Points

The STR$(x#) and STR$(x#,n) can convert a floating point number x# into a text string which can therefore be displayed immediately using the SETLCD command. Please refer to the help file for the STR$() command.

If you wish to control the number of digit being displayed then you could use the MID$ command to extract the number of significant digits and the exponents from the string returned by STR$(x#, n) function.
 

Wx100 has a 128 x 64 pixel graphical OLED display and hence is capable of displaying text at any coordinates (x, y) as shown in the following diagram:

Wx100 supports up to 7 text sizes as shown in the following table:

Commands for Drawing Text On The OLED

Please download the following example program to help demonstrates what will be discuss below

https://triplc.com/TRiLOGI/Examples/Wx_Specifics/DisplaytExtendedAscii_And_Custom_Bitmap.zip

a) Default Character Set

Using TBASIC, Wx100 can display all basic ASCII characters from ASCII code 32 to 127 (decimal) . In addition, it can display  extended ASCII based on Windows-1252 (code page 1252), aka ISO-8859-1 character set, which includes many European characters as shown below:

Extended ASCII – CP1252

The default character set are supported for all text sizes from 1 to 7.

b) Hitachi HD44780 LCD character set.

TBASIC also supports the Hitachi HD44780A00 character set which is very common among character LCD displays that are based on the Hitachi HD44780 controller chip or one of its licensed derivatives. (Note: this chip is used in the LCD216 and LCD420 that are used with our other lines of PLC such as the FMD88-10 and Fx-2424 PLCs).

The Hitachi HD44780 includes a full set of Japanese Kana characters. If you need to display these characters then you need to specify the text size = 11 before calling the DRAW_TEXT , DRAW_TEXTPOS or SETLCD commands. Only a single size (6 x 8 pixels) is supported.

Extended ASCII – HD44780A00

c) Customized Bitmap Graphics

It is possible to display characters that are unsupported by the Windows-1252 or Hitachi HD44780 character by creating them as custom bitmap graphic.

For example, you can display Chinese Characters or special symbol created as custom bitmap graphic to display the following:

For more details, please refer to Section 13.7 – Draw Custom Bitmap

a) Reading last Key Pressed

When a user pressed a key on the Wx100 built-in keypad, the event is captured and the key code of the last key pressed can be retrieved by the following TBASIC function:

A = KEYPRESSED(1)

The following are the key codes returned by KEYPRESSED(1) for each key:

Keys	Key codes
to	0 to 9
	10
	11
	12
	13
	14
	15

Notes:

1. When no key is pressed, KEYPRESSED(1) function returns a -1.
2. KEYPRESSED(1) will return the key code of the last key pressed even if the key has already been released by the time the program runs the KEYPRESSED(1) function.
3. To simplify programming for number entry purpose,  the KEYPRESSED(1) function  will return the keycode ONLY ONCE when it is first called. i.e. Even if you hold down the same key continuously, subsequent call of the KEYPRESSED(1) function will always return a -1. If you release the key and then press it again then the KEYPRESSED(1) function will again return the actual keycode only once when it is called.
4. This is to prevent a custom function from repeatedly executing a program sequence even if you just meant for it to execute once. For example if you press the ‘1’ key when entering a number, you do not want the custom function to record it as a continuous streams of 1 being entered. The PLC program runs much faster than human can release the key in time so having KEYPRESSED(1) returns the keycode only just once each time the key is pressed will ensure that only a single digit is entered.

b) Reading Continuous Key Pressed

If you need to read the same key code as long as the key is being pressed and held down, then you can use the following function instead:

A = KEYPRESSED(0)

You may need to use this capability for example if you want to be able to press on a key and have a number scroll up or down rapidly and stop when the key is released.

c) Using Keypad In Ladder Logic

You can easily translate the actual key pressed into open or close contacts of some internal relay bit so that the keypad can be used in place of physical push buttons normally wired to the inputs of a PLC.  The following function call automatically transfer the keycode 0 to 15 into the corresponding bit position in the 16-bit variable RELAY[2] :

  RELAY[2] = KEYPRESSED(2)  ' transfer the 16 keys into internal relay 17 to 32

The above statement essentially turn the KEYPAD into 16 digital inputs and their logic ‘0’ and ‘1’ are transferred to internal relay #17 to #32. The resulting relay bit can then be readily used by the ladder logic part of the program.

One effective way to use this capability is to use a clock pulse to drive a differentiated custom function that periodically runs the above single line statement so that the internal relay #17 to #32 is regularly updated which can then be used to trigger different parts of the ladder logic.

d) Customized Keypad Consideration

You probably already figure it by now – that although the built-in keypad appears to be arranged and labeled conveniently for entering numbers into the PLC,  the key legends on the keypad are not hard-coded for a specific purpose only. Since the key pressed actions are returned as numeric codes.  the PLC program can easily use any key for any purpose. Hence if you do not need to enter numbers into your equipment then the key pads can be re-purposed as push button inputs to trigger different parts of the program. This can have tremendous cost savings for OEMs as physical push buttons are quite expensive and also result in high labour cost to wire them. For mid to large OEM customers it is possible to order the PLC with customized legends so that these keys can be used for other purposes than as numeric keypad entry. For example, it is totally conceivable that you could custom-order a Wx100 with the following keypad legends:

TBASIC makes it extremely simple for the programmer  to create a menu system where the user can select a function that he/she wants the PLC to run by picking it from a menu. You start first by defining the menu structure using the “MENU_DEFINE” command. Then the program simply runs the MENU_SHOW command and the Wx100 firmware will automatically highlights the selected item.

Commands for Displaying MENU On The OLED

Example: The best way to quickly experiment with the Wx100 menu system is to download the WxDEMO.PC7 program and then open it using the iTRiLOGI 7.4 software. It  You can test the menu system using the iTRiLOGI simulator to simulate the function and click on the up down arrow keys or click  the 1 to 8 button on the virtual HMI (see figure below)  to jump to the desired menu item and then click on the green “Enter”  key to select the menu. There are a great numbers of demos that you can experiment with that showcase the capability of the HMI.

Feel free to modify the program and immediately simulate it to see the result of the changes you have made. When you are satisfied with your simulated program, transfer it into Wx100 PLC and test using the real push button and display on the OLED screen.

The following graphical drawing commands are supported:

Besides displaying ASCII text and vector graphics via DRAW_XXX command, TBASIC is also able to display custom-designed bit map graphic block of up to 32 x 32 pixels. The procedure begins by designing the graphic using a special graphic editor software, then export the generated bit pattern as data points to be assigned to the PLC’s DM[n] variables. Finally, run the new TBASIC DRAW_BITMAP command to display the bitmap graphics on the OLED display. We will explain the procedure below.

 DRAW_BITMAP x, y, dmIndex, magnification
- x and y are the coordinates to display the bitmap character
- dmIndex is the starting index of the DM that stores the bitmap. It can start anywhere from 
     1 to (4000 - number of bytes needed to represent the bitmap).
- magnification factor.  E.g. if = 2 means that the character is displayed at double the size. 
      So a 6 x 8 character will be displayed as 12 x 16.

Using the DM is convenient as it allows you to load the characters either from EEPROM or from a data file or even from an online source and then deploy it as and when needed.

Now what do you store in the DM? If the bitmap is less than 8 pixel tall, then a single byte is used to represent a column of dots where a ‘1’ means that the dot is ON and ‘0 means that the dot is OFF

For example, the following graphics can be represented as an array of bytes (hex): &HFF, &H91, &HA1, &H91, &H89, &H85, &H81, &HFF

If the bitmap is larger than 8 but less than 16 pixel tall, then 2 bytes are used to represent each column. A 32 pixel tall bitmap requires 4 bytes to represent the column and as many 4-byte words as is needed to represent the number of columns.

E.g. A 12 x 12 pixel bitmaps as following :

can be represented by &HFF, &H0F, &HC1, &H08, &H81, &H09, &H01, &H0B, &H01, &H0B, &H81, &H09, &HC1, &H08, &H61, &H08, &H31, &H08, &H19, &H08, &H09, &H08, &HFF, &H0F

Note: it is written in Little Endian format. So the leftmost column can be thought of as &H0FFF but is represented by the first two byte: &HFF, &H0F.

Likewise, second column should be &H08C1 but is represented by the 3rd and 4th byte: &HC1, &H08
.. and so on.

It will be a real pain to try to do this by hand but fortunately there is a free program call MicroElektronika GLCD Font creator which you can download from:

https://www.mikroe.com/glcd-font-creator

The program is meant for you to create bitmpa font for ASCII characters or Unicode characters. You can import some system font for simple graphics (e.g. WingDing) or create from scratch.

When creating from scratch you define the number of width and height for your bitmap and assign it a code number (you can use the 32 to 32 which is actually a space character but won’t matter. Then just use left click to draw pixels and right click to erase pixels inside the bitmap.

Once you are done with creating the bitmap, click on the icon on the left (the one next to 32) to SAVE the character

After you have saved the character, generate the bitmap data by clicking on “Export for GLCD” to generate the Basic, Pascal or C codes for the character bitmap.

If you click on the “mikroC” tab you see the following array. Discard the very first byte (0x0C as shown below) as we don’t use it.

const unsigned short Untitled12x12[] = {
0x0C, 0xFF, 0x0F, 0xC1, 0x08, 0x81, 0x09, 0x01, 0x0B, 0x01, 0x0B, 0x81, 0x09, 0xC1, 0x08, 0x61, 0x08, 0x31, 0x08, 0x19, 0x08, 0x09, 0x08, 0xFF, 0x0F // Code for char
};

The data after the first byte will be what we want to fill in the DM array starting from DM[dmIndex + 4] onwards until the last byte in the array is reached.

You need to fill in DM[dmIndex] to DM[dmIndex+3] the following:

   DM[dmIndex] = 0   ' reserved, always 0  
   DM[dmIndex+1] =   bitmap width in number of pixels
   DM[dmIndex+2] = bitmap Height in number of pixels
   DM[dmIndex + 3] = ' reserved, always 0

For example, in the 12 x 12 bitmaps example above, if we starts with dmIndex = 1

   DM[1] = 0
   DM[2] = 12
   DM[3] = 12
   DM[4] = 0
   DM[5] = &HFF
   DM[6] = &H0F
   DM[7[ = &HC1
   DM[8] = &H08
   ....
   DM[27] = &HFF
   DM[28] = &H0F

Now if you run

DRAW_BITMAP 0, 30, 1, 1 

it will draw the bitmap checkbox graphic at coordinate x = 0, y = 30 with x1 magnification.

Note: Please download the following example program that shows the creation and display of custom bitmap graphics:

https://triplc.com/TRiLOGI/Examples/Wx_Specifics/DisplaytExtendedAscii_And_Custom_Bitmap.zip

The Wx100 RS485 is highly configurable. It can be set to a wide range of baud rates. You can also program it to communicate in either 7 or 8 data bits, 1 or 2 stop bits, odd, even or no parity. The baud rate and communication formats of the serial ports are set by the following command:

     SETBAUD  ch, baud_no

ch represents the COMM port number (1, 2, or 3 only). The baud_no parameter takes a value from 0 – 255 (&H0 to &HFF), which allows for additional configuration of the communication format. The upper 4 bits of baud_no specify the communication format (number of data bits, number of stop bits, and parity) and the lower 4 bits represent the baud rate. Hence the baud_no for 8 data bit, 1 stop bit, and no parity is the same as the old models, providing compatibility across the PLC families.

Once the new baud rate has been set, it will not be changed until execution of another SETBAUD statement. The baud rate is not affected by a software RESET but the settings will be lost when the power is turned OFF. The available baud rates and their corresponding baud rate numbers for COMM1, 2, and 3 are shown below:

Where xxxx represents the baud rate of the comm port, as follow:

A table of all the available baud rates and COMM formats is shown in the following page. The communication format written as “7,2,e”, which means 7 data bits, 2 stop bits and even parity. Likewise, “8,1,n” means 8 data bits, 1 stop bit and no parity. You can use the table to select the baud number for a certain baud rate and COMM format.

Important:

Please note that if your program changes the baud rate or communication format to something that is different from that set in the iTRiLOGI serial port setting, then i-TRiLOGI will no longer be able to communicate with the PLC via this COMM port. You will have to either configure the iTRiLOGI’s serial port setting using its “Serial Communication Setup” routine to match the PLC, or you can cycle the power to the PLC to reset the COMM port to the default format (38,400, 8,n,1).

If you had used “1st.Scan” contact to activate the SETBAUD command than you will need to cycle the power to the PLC with DIP switch #4 set to ON to halt the execution of the SETBAUD command. When the PLC is reset this way, its COMM1 port will power up at the default format of 38,400, 8,n,1 only so you will need to configure iTRiLOGI’s serial port also to 38,400bps, 8, 1, n to communicate with it.

The Wx100 has been designed to understand and speak many different types of communication protocols, some of which are extremely widely used de facto industry standards, as follows:

a) NATIVE HOST LINK COMMAND
b) MODBUS ASCII (Trademark of Modbus.org)
c) MODBUS RTU* (Trademark of Modbus.org)
d) OMRON C20H protocols. (Trademark of Omron Corp of Japan)

The command and response formats of the “NATIVE” protocols are described in detail in Chapter 15 and 16. The other protocols and their address mapping to the Wx100 are described in Section 14.5. By default Wx100 works in “automatic protocol” mode. There is no DIPswitch to set and no special configuration software to run to configure the port for a specific communication protocol. The following describes how the automatic protocol recognition scheme works:

1. When the PLC is powered ON, its RS485 serial port is set to the “AUTO” mode, which means that it is open-minded and listen to all serial data coming through the COMM ports. The CPU tries to determine if the serial data conforms to a certain protocol and if so, the COMM mode is
determined automatically.

2. Once the protocol is recognized, the CPU sets that COMM port to a specific COMM mode, which enables it to process and respond only to commands that conform to that protocol. Error detection data such as the “FCS”, “LRC” or CRC are computed accordingly which method is used
to verify the integrity of the received commands. If errors are detected in the command, the CPU responds in accordance with the action specified in the respective protocols.

3. When the COMM port enters a specific COMM mode, it will regard commands of other protocol as errors and will not accept them. Hence, for example, if COMM #1 has received a valid MODBUS RTU command (which puts it in an “RTU” mode), it will no longer respond to i-TRiLOGI’s attempts to communicate with it using the “NATIVE” mode. You will receive a communication error if you try to use i-TRiLOGI to access a PLC COMM port that has just been communicating in other protocol modes.

4. To improve the flexibility of switching from one COMM mode to another, The Wx100 incorporates a COMM mode self-reset timer such that a specific COMM mode will time out automatically and enters into “AUTO” mode after 10 seconds if no more commands are received from that COMM port. When a user wants to switch from one COMM mode to another, he/she often will be changing the serial connector from one device to another. During this time there is no data received by the COMM port, which presents an opportunity for it to reset its COMM mode. However, the surest way to reset the specific COMM mode is to cycle the power to the PLC so that its COMM port will be reset to “AUTO” mode and ready to communicate with any supported protocols.

5. If you wish to use the COMM port for serial data input only, you can use the SETPROTOCOL command to set the COMM port to NO PROTOCOL. This can prevent the PLC from erroneously treating some serial data as the header of an incoming communication protocol and respond to it automatically.

The SETPROTOCOL command can also be used to set the PLC to a specific protocol. This may be desirable if the COMM port has a specific role and you do not want it to enter other modes by mistake.

Please refer to the TBASIC Programmer’s Reference manual for a detailed description of the SETPROTOCOL command.

Note:

If you fix a COMM port to a non-native, non-auto mode, TRiLOGI will not be able to communicate with the PLC anymore. You may have to power-cycle the PLC to reset the COMM mode. If you use the “1st.Scan” contact to activate the SETPROTOCOL command, then you will need to cycle
the power to the PLC with DIP switch #4 set to ON to halt the execution of the SETPROTOCOL command. (Also remember that when the PLC is reset this way, its COMM1 will power up at default format of 38,400, 8,n,1 only so you will need to configure iTRiLOGI’s serial port to 38,400bps to communicate with it.)

Besides responding automatically to specific communication protocols described in section 14.5, The WX100 RS485 serial ports is fully accessible by the user program using the TBASIC commands: INPUT$, INCOMM, PRINT # and OUTCOMM. It is necessary to understand how these commandsinteract with the operating system, as follow:

When a COMM port receives serial data, the operating system of the Wx100 automatically stores them into a 256 bytes circular buffer so that user programs can retrieve them later. The serial data are buffered even if they are incoming commands of one of the supported protocols described in section 14.3. In addition, processing of a recognized protocol command does not remove the characters from the serial buffer queue so these data are still visible to the user’s program.

The RS485 COMM port has its own separate 256-byte serial-in buffer. As long as the user-program retrieves the data before the 256-byte buffer is filled up, no data will be lost. If more than 256 bytes have been stored, the buffer wraps around and the oldest data is overwritten first and so on.

The following describes how INCOMM and INPUT$, PRINT # and OUTCOMM functions interact with the serial buffer:

a) INCOMM (n)
Every execution of the INCOMM(n) function removes one character from the circular buffer. When no more data is available in the buffer this function returns a -1. The data removed by INCOMM will no longer be available for the INPUT$ command.

b) INPUT$(n)
When the INPUT$(n) function is executed, the CPU checks the COMM #n buffer to see if there is a byte with the value 13 (the ASCII CR character) which acts as a terminator for the string. If a string is present, all the characters that make up the string will be removed from the COMM buffer. If a completed string is not present, then the COMM buffer will not be affected, and INPUT$(n) returns a null string. This ensures that before a complete string is received, the serial characters will not be lost because of the unsuccessful execution of the INPUT$(n) function.

c) INPUT$(n) in Blocking Mode

INPUT$(n) is designed to be non-blocking and to return immediately – i.e. either it returns a complete string or it returns an empty string. This means that INPUT$(n) will not suspend the CPU and wait for a valid string from the COMM port. However, in real world communication very often you will need to send a command to a device and it takes a while for the device to be able to send back a response string.

The most efficient way of handling such serial communication exchange with other devices is to send a command string using the PRINT #n and then start a timer and let the PLC program continue to scan the ladder program. When timer times out, the timer contact is used to activate a custom function and use INPUT$(n) to read the return message from the device. This is most efficient use of the CPU time since the program will not have to waste time to wait for response string from the device and that’s the reason for INPUT$(n) to default to non-blocking mode.

Another way to deal with this is to use the NETCMD$ function (terminated with “~”). NETCMD$ sends a command string and will return immediately when it receives a response string or if more than 0.15s has passed. If the device is slow to response the CPU basically sits in a loop to wait for the response for up to a maximum of 0.15s. NETCMD$ function also re-tries the communication several times if it does not receive a response in the first try.

A third way of handling serial exchange with other devices is to use the INPUT$(n) command in blocking mode. Starting from CPU firmware r72 and above, if you run the command

     SETSYSTEM 19, t

This will configure the INPUT$(n) command to block the CPU for up to maximum of (t x 10) milliseconds to wait for a valid string from 3rd party device. Although this command also wastes CPU cycles to wait for a response and hence it is not as efficient compared to using the timer-activated
method mentioned above, it nonetheless is very simple to implement and can be used for non time-critical applications.

You only need to execute SETSYSTEM 19, t once and INPUT$(n) will block for the same t x 10 millisecond every time it is executed until SETSYSTEM 19,t is run again. To return the INPUT$(n) to non-blocking mode, run SETSYSTEM 19, 0.

d) PRINT #n

The PRINT statement transfers its entire argument to a 256 byte serial-out buffer, which is separate from the serial-in buffer. The PRINT statement, therefore, does not affect the content of the serial buffer for incoming characters. The operating system handles the actual transfer of each byte of data out of the serial-out buffer in a timely manner.

Note that the PLC automatically enables the RS485 transmit driver when it sends serial characters out of its COMM 2 and 3 ports. When the stop bit of the last character in the serial-out buffer has been sent out, the operating system immediately disables the RS485 driver and enables the receiver.  This greatly eases the use of the RS485 port since there is no need for a user to bother with the often-critical timing of controlling the RS485 driver/receiver direction.

e) OUTCOMM

This command sends only a single byte out of the serial COMM port without going through the serial out buffer. For RS485 port, it enables the RS485 transmitter before sending the character and disables it immediately after the stop bit has been sent out.

a) RS485 Network Interface Hardware

The built-in RS-485 interface allows the Wx100 PLC to be networked together using very low cost twisted-pair cables.  Since the PLCs are fitted with a 1/8-power RS485 driver such as the 65HVD1785, up to 256 devices can be connected together. The twisted-pair cable goes from node to node in a daisy chain fashion. When communicating at the default baud rate of 38400 bps, the twisted pair cable should be terminated by a 120-ohm resistor if the cable length is longer than 300m (1000 ft). Terminating resistor is not needed for short distance communication.

As there will be times when no transmitters are active (which leaves the wires in “floating” state), it is good practice to ensure that the RS-485 receivers will indicate to the CPUs that there is no data to receive. In order to do this, we should hold the twisted pair in the logic ‘1’ state by applying a differential bias to the lines using a pair of 560R to 1K biasing resistors connected to a +9V (at least +5V) and 0V supply as shown in Figure 15.3.1. Otherwise, random noise on the pair could be falsely interpreted as data.

The two biasing resistors are necessary to ensure robust data communication in actual applications. Some RS485 converters may already have biasing built-in so the biasing resistors may not be needed. However, if the master is a Wx100 PLC then you should use the biasing resistor to fix the logic states to a known state. Although in a lab environment the PLCs may be able to communicate without the biasing resistors, their use is strongly recommended for industrial applications.

Care should be taken to ensure that the power supplies for all the controllers are properly isolated from the main so that no large ground potential differences exist between any controllers on the network.

b)  Single Master RS485 Networking Fundamentals

RS485 is a half-duplex network, i.e., the same two wires are used for both transmission of the command and reception of the response. Of course, at any one time, only one transmitter may be active. The Wx100 implements a master/slave network protocol. The network requires a master controller, which is typically a PC equipped with an RS485 interface. In the case of a PC, you can purchase a USB to  RS-485 adapter card or an RS232C-to-RS485 converter and connect it to the RS232C serial port.  A Wx100 can also be programmed to act as the master, it can communicate with other PLCs by executing the “NETCMD$” function or the “READMODBUS” or the “WRITEMODBUS” commands (the latter two are for communicating using MODBUS protocols only)

Only the master can issue commands to the slave PLCs. To transmit a command, the master controller must first enable its RS-485 transmitter and then send a multi-point command to the network of controllers. After the last stop bit has been sent, the master controller must relinquish the RS485 bus by disabling its RS485 transmitter and enabling its receiver. At this point the master will wait for a response from the slave controller that is being addressed. Since the command contains the ID of the target controller, only the controller with the correct ID would respond to the command by sending back a response string. For the network to function properly, it is obvious that no two nodes can have the same ID.

There are two ways to change the PLC ID:

c) Multi-Master RS485 Networking

Since the Wx100 is capable of sending out network commands, the obvious question is whether multiple masters are allowed on the RS485 network? It is possible to have multiple masters on a single RS485 network provided the issues of collision and arbitration are taken care of.

Some RS485 protocols have arbitration or token passing features built-in, which automatically allow multiple masters over a single RS485 network.  The 3 serial communication protocols that Wx100 currently supports, namely Hostlink protocol, Modbus ASCII and Modbus RTU do not have built-in arbitration and are hence are not suitable for multi-master type communication. Although  there are ways and means to introduce such arbitration method into the standard protocol, you probably should instead consider communicating using TCP/IP via the WiFi  if you need to have multiple PLCs talking to each other at arbitrary time.

TCP/IP communication is inherently multi-master, so any PLC can talk to any other PLC by establishing a virtual connection and then talk as if it has exclusive direct connection to the other PLCs. The Wx100 PLC can use either the Hostlink and Modbus TCP protocol to talk to another PLC, allowing true machine-to-machine communication easily and at a speed that is MUCH faster than serial RS485 communication. The TCP/IP communication capability therefore makes multi-master RS485 communication somewhat redundant today.

d) Trouble-Shooting An RS485 Network

Single faulty device

If a single device on the RS485 network becomes inaccessible, problems can be isolated to this particular device.  Check for loose or broken wiring or wrong DIP switch settings. Also double check the device ID using the host-link command “IR*” sent via the serial link when only a single PLC is connected to the PC.  If all attempts fail, either replace the PLC and try again.

Multiple faulty devices

If all the PLCs are inaccessible by the host computer, it may possibly be due to a faulty U-RS485 converter at the PC. If this is the case, disconnect the USB-RS485 converter from the network and check it using a single PLC. Replace the converter if it is confirmed to be faulty. Next check the wire from the converter to the beginning of the network. A broken wire here can lead to the failure of the entire network.

Since an RS485 network links many PLCs together electrically and in a daisy chain fashion, problems occurring along the RS485 network sometimes affect the operation of the entire network. For example, a broken wire at the terminal of one node may mean that all the PLCs connected after this node become inaccessible by the master. If the RS485 interface of one of the PLCs has short-circuited because of component failure, then the entire network goes down with it too. This is because no other node is able to assert proper signals on the two wires that are also common to the shorted device.

Hence, when trouble-shooting a faulty RS485 network, it may be necessary to isolate all the PLCs from the network. Thereafter, reconnect one PLC at a time to the network, starting from the node nearest to the host computer. Use the TRiLOGI program to check communication with each PLC until the faulty unit has been identified.

The following describes some possible uses of the RS485 ports.

a) Programming And Network Configuration

Besides programming via Wi-Fi, a Wx100 can also be programmed via its RS485 port on a one-to-one or multi-drop manner.  Since most PCs do not have built-in RS485 port, you will need to purchase an optional USB-RS485 adapter (e.g. the U-485 adapter that TRi supplies) in order to program the PLC via its RS485 port.

The i-TRiLOGI programming software now directly supports programming of the PLC via serial port. (In older version of iTRiLOGI software you will need to run the TLServer software to be used as a TCP-to-serial port gateway). This is especially useful should you encounter problems connecting the PLC to a WiFi network (e.g. you accidentally messed up the wireless key settings), or if you are unable to connect your PC’s WiFi to the PLC even when it boots up in AP mode, then serial connection may be the last resort for you to connect to the PLC for quick programming or configure the network parameters.

b) Acting As a Modbus TCP WiFi to Modbus RTU Gateway

Wx100 PLC has a built-in Modbus TCP to Modbus RTU Gateway capability!  What it means is that you can connect a Wx100 to a network of Modbus RTU slave devices that have only RS485 port and enable them to be accessible by a Modbus TCP master over WiFi. The Modbus TCP master could be a SCADA master or another intelligent device that speaks Modbus TCP but may have no direct physical connection to the Modbus RTU slave via RS485. Since a Wx100 can be connected to a WiFi network it provides a convenient means for the Modbus TCP master to accessible these slave devices over the air.

To enable the Modbus TCP to RTU features in the Wx100, run the following command once during initialization:

    SETSYSTEM 12, 1    ' relay Modbus TCP messages through COMM1 on the PLC

Then set the PLC ID to be different from all the slave Modbus RTU devices connected to its RS485 port. That’s all!

Once enabled, any Modbus TCP packet that is addressed to an ID which does not belong to the PLC itself will be relayed out of the RS485 serial port to be received by slave Modbus RTU devices. A response packet received from the RS485 port will in turn be sent back to the Modbus TCP master via the WiFi port and thus completing the command/response packet.

Note: The Modbus TCP to RTU gateway operates in the background without needing any direct intervention by the PLC program at all. Best of all, the PLC can continue to execute its control program even when the Modbus TCP-to-RTU gateway function is ongoing in the background. So you essentially get a free gateway while still using the full power of the PLC to control your equipment.

c) Interfacing non-Mobdus Devices to Modbus Host or to the Internet

Since the Wx100 supports MODBUS protocols, it can operate as a master PLC and serve as a gateway to interface non MODBUS-enabled PLCs (such as the E10+ PLCs, or the I-7000 analog modules) to third party SCADA masters or MMI hardware that speaks MODBUS TCP or MODBUS RTU. The Wx100 also makes it easy for these devices to be controlled or monitored over the Internet. The master Wx100 will use its RS485 port to pull data from these devices into its data-memory. The data memory in the Wx100 is in turn accessible by a SCADA program using the Modbus serial or Modbus/TCP protocol.  Through the Wx100, these other connected devices are also accessible from the Internet.

d) Accessing 3^rd Party RS485-based Devices

There are more and more industrial devices such as electric power meters, analog I/O modules (e.g. the I-70xx modules by ICPDAS), variable frequency drives, etc that allows data communication via their RS485 port. The Wx100 PLC has many built-in commands for reading/writing to these serial ports, including built-in commands for communicating with devices that use the MODBUS ASCII or RTU protocols.

e) Distributed Control

Another important use of the RS485 port will be to connect a Wx100 to other TRi PLCs. One Wx100 will act as the master and all other PLCs will act as slaves. Each PLC must be given a unique ID. The master will send commands to all the slaves using the “NETCMD” or READMODBUS, WRITEMODBUS, READMB2, WRITEMB2 statements and coordinate information flow between the PLCs. In this way, a big system can be built by employing multiple units of Wx100, FMD, Fx or Nano-10 PLCs connected in a network. This results in more elegant implementation of complex control systems and simplifies maintenance jobs.

The Wx100 PLC supports a subset of the OMRON™ C20H and MODBUS™ (Both ASCII and RTU modes are supported) compatible communication protocols so that it can be easily linked to third-party control software/hardware products such as SCADA software, LCD touch panels etc. The PLC automatically recognizes the type of command format and will generate a proper response. These are accomplished without any user intervention and without any need to configure the PLC.

Both MODBUS and Omron protocols use the same device ID address (00 to FF) as used by the native “Hostlink Command” protocol described in Chapter 15. Since the addresses of I/O and internal variables in the Fx2424 are organized very differently from the OMRON or Modicon PLCs, we need to map these addresses to the corresponding memory areas in the Modbus address space so that they can be easily accessed by their corresponding protocols.

All I/Os, timers, counters, internal relays, data memory DM[1] to DM[4000], and floating point data FP[1] to FP[1000] are mapped to the Modbus Holding Registers space. The Inputs, Outputs, Relays, Timers and Counters bits are mapped to the MODBUS Bit address space as shown in Table 14.1. Note that input and output bits are always mapped according to Table 14.1 whether it is MODBUS function 01, 02 or 05.

However, 32 bit variables and string variables are not mapped since they are fundamentally quite different in their implementation among different PLCs. Internal variables that are not mapped can be still be accessed by copying the contents of these variables to unused data memory DM[n] (this can be easily accomplished within a CusFn) so that they can be accessed by these third party protocols.

a) MODBUS ASCII Protocol Support

The Wx100 supports MODBUS ASCII protocols with the following command and response format:

The following Function Codes are supported:

The exact command/response format of the MODBUS protocol can be found at http://www.modbus.org. However, if your only purpose is to interface the PLC to other MODBUS hosts such as an LCD touch panel or SCADA software then there is no need to know the underlying protocol command format. All you need to know is which PLC’s system Variable is mapped to which MODBUS register.

Please refer to Section 2.5 and Table 2.5.1 for the memory mapping of Wx100 I/Os and internal data to MODBUS Register.

Bit Address Mapping

All the Wx100 I/O bits are mapped identically to both the Modicon “0x” and 1x space. The Modicon bit register offset is shown in the last column of Table 2.5.1. Although Modicon names the “0x” address space as “Coil” (which means output bits) and the “1x” address space as “Input Status” (which means input bits only), the Wx100 treats both spaces the same. Some Modbus drivers only allow a “read” from 0x space and a “write” to 1x space but you still use the same offset shown below on Table 2.5.1

Example:

1. To read from the PLC Input 5 via Modbus, you select the Modicon bit address 0-0005.
2. To read from  the PLC’s output #2, you may have to specify Modicon register address 0-0258 and to write to PLC output #2, you may have to specify Modicon register address 1-0258.  However, if your Modbus TCP client allows reading and writing to either 0-xxxx and 1-xxxx space, then you can use either 0-258 or 1-258 and the action will be identical.

 Word Address Mapping

As shown in Table 2.5.1, to access the PLC’s DM[1], you use MODBUS address space 4-1001 (The address naming  scheme by Modicon. For binary addressing use 1000 (dec, or &H03E8) and so on. To access the Real Time Clock Hour data (TIME[1]), use 4-0513. The I/O channels can also be read or written as 16-bit words by using the addresses from 4-0001 to 4-0320.

Some MODBUS drivers (such as National Instruments “Lookout” software) even allow you to manipulate individual bits within a 16-bit word. So it is also possible to map individual I/O bits to the “4x” address space. E.g. Input bit #1 can be mapped to 4-0001.1 and output bit #2 is mapped to 4-0257.2, etc. This is how it is shown in Table 2.5.1. However, if you do not need to manipulate the individual bit, then you simply use the address 4-0001 to access the system variable INPUT[1] and address 4-0257 to access the system variable OUTPUT[1]. Note that INPUT[1] and OUTPUT[1] are TBASIC system variables and they each contain 16 bits that reflect the on/off status of the actual physical input and output bits #1 to #16.

b) MODBUS RTU Protocol Support

The Wx100 also support the MODBUS RTU protocol. The difference between the ASCII and RTU protocols is that the latter transmits binary data directly instead of converting one byte of binary data into two ASCII characters. A message frame is determined by the silent interval of 3.5 character times between characters received at the COMM port. Other than that, the function codes and memory mappings are identical to the MODBUS TCP and Modbus ASCII protocol.

The following Function Codes are supported:

c) OMRON Host Link Command Support

Some OMRON host link commands are described in Section 16.40. For other commands please refer to the Omron C20H/C40H PLC Operation manual published by OMRON Corporation. If your purpose is only to use the PLC’s OMRON mode with SCADA or HMI, then there is no need to learn the actual command/response format.

d) Wx100 As a Modbus Master – Getting Data From Power or Flow Meters

The Wx100 support for the MODBUS protocol goes beyond being a MODBUS slave only. You can use the TBASIC READMOBUS and WRITEMODBUS commands, as well as READMB2 and WRITEMB2 to send out MODBUS ASCII or RTU commands to access any other Wx, Fx, FMD or Nano-10 PLCs or any third party MODBUS slave devices. The READMODBUS or READMB2 commands use MODBUS Function 03 (this can be changed to function 04 using SETSYSTEM 6,4 command) to read from the slave, and WRITEMODBUS or WRITEMB2 use MODBUS Function 16 to write to the slave.

Note that when using the READMODBUS or WRITEMODBUS commands, the 40001 address stated in Table 2.5.1 should be interpreted as address 0000, and 40002 as address 0001, and 41001 as address 1000, etc. This is in accordance with the specifications stated in MODBUS protocol. MODICON defined zero offset addresses for the MODBUS protocol, yet in their holding register definition these are supposed to start from address 40001 – hence the unusual correspondence. But to maintain compatibility with the MODBUS specifications, we have to adhere to their definitions.

Sending Modbus ASCII or a Modbus RTU Commands

The Wx100 PLC can act either as a MODBUS ASCII or MODBUS RTU master.

You use the same READMODBUS and WRITEMOBUS commands to send and receive MODBUS ASCII or MODBUS RTU commands. The only difference being the comm port number you use with these commands.  The RS485 port on Wx100 is assigned COMM port #1. If you run the MODBUS command via COMM port #1 then it will send out MODBUS ASCII command by default.

To send MODBUS RTU command,  what you need to do is add 10 (decimal) to the COMM port number to signal to the processor that you wish to use MODBUS RTU instead of MODBUS ASCII to talk to the slaves.

In other words, you should specify port #11 to use RTU commands on COMM1 port..

E.g. the statement DM[10] = READMODBUS (11, 8, 16) will access, via COMM1, the slave with ID = 08 and read the content of register #16. This register corresponds to MODICON address 40017 and is the OUTPUT[1] of the slave PLC. The ability to speak MODBUS RTU greatly extends the type of peripherals that can be used with a Wx100 PLC. You can now make use of many off-the-shelf, third party RTU devices to extend the PLC
capability.

When the Wx100 receives a native host-link command via its RS485 port, it will automatically send a response string corresponding to the command. This operation is totally transparent to the user and does not need to be handled by the user’s program.

All Wx100 support both the point-to-point (one-to-one) and multi-point (one-to-many) communication protocols. Each protocol has a different command structure as described below.

In a point-to-point communication system, the host computer’s RS232C serial port is connected to the PLC’s COMM1. At any one time, only one controller may be connected to the host computer. The hostlink commands do not need to specify any controller ID code and are therefore of a simpler format, as show below:

Command/Response Frame Format (Point to Point)

Each command frame starts with a two-byte ASCII character header, followed by a number of ASCII data and ends with a terminator which is comprised of a ‘*’ character and a carriage return (ASCII value =13 decimal). The header denotes the purpose of the command. For example, RI for Read Input, WO for Write Output, etc. The data is usually the hexadecimal representation of numeric data. Each byte of binary data is represented by two ASCII characters (00 to FF).

To begin a communication session, the host computer must first send one byte of ASCII character: Ctrl-E (=05Hex) via its serial port to the controller. This informs the controller that the host computer wishes to send a (point-to-point) host-link command to it. Thereafter, the host computer must wait to receive an echo of the Ctrl-E character from the controller. Reception of the echoed Ctrl-E character indicates that the controller is ready to respond to the command from the host computer. At this moment, the host computer must immediately send the command frame to the controller and then wait to receive the response frame from the controller. The entire communication session is depicted in Figure 15.1.

After the controller has received the command, it will send a response frame back to the host computer and this completes the communication session. If the controller accepts the command, the response frame will start with the same header as the command, followed by the information that has been requested by the command and the terminator.

As you can probably see, proper handshaking using the Ctrl-E character between the host and the PLC is important to communicate successfully using the Point-to-point protocol. Although the “Multi-point” format discussed in the next section seems more complex, the communication
exchange using multi-point protocol is actually simpler than point-to-point since it involves only a single exchange of command/response string. We therefore recommend using the multi-point format if you are writing your own communication program.

Note: TBASIC has a built-in command “NETCMD$” that lets a Wx100 PLC access another slave PLC using the multipoint Host-link protocol format very easily.

If an unknown command is received or if the command is illegal (such as access to an unavailable output or relay channel), the following error response will be received:

Error Response Format (Point-to-point)

The host computer program should always check the returned response for possibilities of errors in the command and take necessary actions.

In this system, one host computer may be connected to either a single PLC (via either RS232 or RS485) or multiple PLCs on an RS485 network.

a) Command/Response Frame Format (Multi-point)

Each command frame starts with the character “@” and two-byte hexadecimal representation of the controller’s ID (00 to FF), and ends with a two-byte “Frame Check Sequence” (FCS) and the terminator. FCS is provided for detecting communication errors in the serial bit-stream. If desired, the command frame may omit calculating the FCS simply by putting the characters “00” in place of the FCS.

Note: we call “00” the “wildcard” FCS, which is available when the PLC is in “auto protocol” mode. This is to facilitate easy testing of the multi-point protocol. However, the wildcard FCS can be disabled if the PLC has executed the SETPROTOCOL n, 5 to put its COMM port n into pure native mode. In that case you will have to supply the actual FCS to your command string.

b) Calculation of FCS

The FCS is 8-bit data represented by two ASCII characters (00 to FF). It is a result of performing an Exclusive OR on each character in the frame sequentially, starting from @ in the device number to the last character in the data. An example is as follows :

Value 48₁₆ is then converted to ASCII characters ‘4’ (0011 0100) and ‘8’ (0011 1000) and placed in the FCS field.

FCS calculation program example

The following C function will compute and return the FCS for the “string” passed to it.

     unsigned char compute_FCS(unsigned char *string){
     unsigned char result;
     result = *string++; /*first byte of string*/
     while (*string)
         result ^= *string++; /* XOR operation */
         return (result);
     }

A Visual Basic routine for FCS computation is included in the source code of a sample communication program you can download from:

http://www.tri-plc.com/applications/VBsample.htm#VB6sample

c)  Communication Process

Unlike the point-to-point communication protocol, the host computer must NOT send the CTRL-E character before sending the command frame. After the host computer has sent out the multi-point host-link command frame, only the controller with the correct device ID will respond. Hence it is essential to ensure that every controller on the RS485 network assumes a different ID (If a master PLC is used, then the master PLC should also have a different ID from all the slaves). Otherwise, contention may occur (i.e., two controllers simultaneously sending data on the receiver bus, resulting in garbage data being received by the host). On the other hand, if none of the controller IDs match that specified in the command frame, then the host computer will receive no response at all.

If the PLC is operating in “auto-protocol”  mode (default),  it will automatically recognize the type of command protocols  (point-to-point or multi-point) sent by the host computer and it will respond accordingly. If a multi-point command is accepted by the controller, the response frame will start with a character ‘@’, followed by its device ID and the same header as the command. This will be followed by the data requested by the command, a response frame FCS and the terminator.

d) Framing Errors

When the controller receives a multi-point host-link command frame, it computes the FCS of the command and compares it with the FCS field received in the command frame. If the two do not match, then a “framing error” has occurred. The controller will send the following Framing Error Response to the host:

e) Command Errors

If an unknown command is received or if the command is illegal (such as an attempt to access an unavailable channel), the following error response will be received:

d) SHOULD YOU USE POINT-TO-POINT OR MULTI-POINT PROTOCOL?

Although at first the point-to-point protocol appears simpler in format (having no ID and no FCS computation), the communication procedure is actually more complex since it involves the need to synchronize the two communicating devices by exchanging the Control-E character. The lack of error checking also makes the protocol less reliable especially in noisy environment.

Hence, if you were to write your own communication program to talk to the PLCs, we certainly strongly recommend using only the multi-point protocol exclusively due to its simplicity and built-in error checking capability.  The “IR*” point-to-point protocol may still need to be used to retrieve the ID of a PLC with unknown ID (and you can only run this with a single PLC attached to the PC).

We have earlier described in Chapter 2.9 that a Wx100 PLC has 512K bytes of file space that can be used for storing control web pages that a web browser can load to perform control operation.

In addition, the PLC can also open or create a data file for reading, writing or appending. This allows the PLC to log operational- or maintenance-related data into data file for non-volatile storage. Once a data file has been updated, there are two ways to retrieve the stored data files from the PLC:

1. Download the file from the PLC’s built-in web server: The file created by the PLC can be downloaded from the PLC’s built-in web server using any web browser. This allows the user to access the data file at any time of the day.
2. Automatic FTP upload from the PLC to an external web-server: You can program the Wx100 PLC to make a FTP client connection to any web server on the local network or on the Internet/Cloud and upload the data file it has created to the web-server using any filename.

Imagine what the Wx100 can do with this file uploading capability! The ability to log data locally and automatically upload the data to a web server transforms the PLC into a potent data-logger!  The PLC can be programmed to capture daily, weekly or monthly data and then periodically upload the data file to an Internet web server with a unique, time-stamped filename (E.g. “temperaturelog2012-01-01.csv”).  This allows the PLC to log data completely unattended.

The data uploaded by the PLC to the external web server can therefore be viewed or downloaded into a PC using any web browser, anywhere in the world. This allows you to carry out analysis of past logged data file for performance or diagnostic analysis at any time without having to physically access the PLC to retrieve the logged data.

1. Although it is possible to directly access the PLC’s internal web server to download the data file it has created, this does require active action by the user and to ensure that the data are retrieved before the file is full and deleted by the PLC to create space to log new data.
2. By programming the PLC to upload the data periodically the PLC can delete the file after it has successfully uploaded the data file to free up space to accept new data. In other words the PLC will never run out of data space to log data since it can store the logged files on any server including the Cloud!
3. To directly access the file stored on the PLC from outside of the LAN, you will need to setup the router or firewall to “forward” the PLC’s server port (e.g. 9080) to the PLC. If you have multiple PLCs logging data, then each PLC will need to have a different port number in order to properly forward the data. This not only complicates the setup, but also is often frown upon by System Administrator and may not even be permitted by the corporate network security policy.
4. The PLC is designed to upload data to any web server via FTP passive mode by providing the login username and password. Using FTP passive mode allows the PLC to open a network connection to an external web-server to upload a file and then close the connection immediately. It does not require opening a port on your router to permit external access to the PLC from the Internet. Hence there is no complicated router setup involved as there is no port forwarding required.  It also eliminates the security risk from someone trying to take control of the PLC from outside of your LAN and is generally much more acceptable to the System Administrator.

If you have multiple PLCs in use, you can program each PLC to upload data to a different directory or append a different file name prefix, or to a different server, and once programmed all PLCs will happily log data unattended indefinitely!

Wx100 does not support directory structure. All files are therefore always stored in the root directory.  File name on a Wx100 can be a combination of alphanumeric characters excluding white space and not more than 31 characters in length. You can store multiple files with different names as long as the total space used up by the file is less than 512K bytes.

Wx100 FTP uploading capability is quite flexible and you can program the PLC to upload the file to a FTP server using a completely different name from the actual name of the file to be uploaded.

Note:

The PLC can open a new file for writing new data (essentially deleting the old file content), or open an existing file and append data to the end of the file. It can also open a file and read data from the file as ASCII strings. It can achieve this by using the PRINT #8 and INPUT$(8) functions, which will be described in details in the following sections. We have created a sample program: “ExtendedFileSystem.PC6” (click here: http://www.tri-plc.com/trilogi/ExtendedFileSystem.zip to download) that demonstrates all these capabilities.

a)  Open A File For Writing New Data

Syntax:  PRINT #8 “<WRITE  filename>”  

If successfully executed, the “<WRITE>” command will open the file and set the file pointer to the beginning of the file. Thereafter the PLC can start writing ASCII data to the file using the PRINT #8  <string data> command.  [Note: the PRINT #8 command automatically appends a carriage return to the end of the string data unless the string data is terminated with a semi-colon (‘;’) ].

When the PLC has completed writing data, it must close the file by executing the command:   PRINT #8 “</>”.

E.g.

   PRINT #8  “<WRITE Z005.TXT>”
   PRINT #8  “The current Greenwich Mean Time is”
   PRINT #8  STR$(TIME[1]);”:”;STR$(TIME[2]);”:”;”00”
   PRINT #8  “</>”
    

The CPU should use the STATUS(2) command to check whether the <WRITE> has been successfully executed before begin writing data to it. STATUS(2) command returns a 1 if “<WRITE>” operation is successful and returns a ‘0’ if the operation failed. The CPU can only write or access to a single file at a time so any opened file must be closed by the PRINT #8 “</>” command before another file can be opened for writing.

b)  Open A File For Appending Data To The End Of The File

Syntax:  PRINT #8 “<APPEND filename>” 

If successfully executed, the “<APPEND>” command will open the file and set the file pointer to the end of the file. Thereafter any string data following a PRINT #8 command will be appended to the end of the file. When the PLC has completed appending data, it must close the file by executing the command:  PRINT #8 “</>”.

As per the “<WRITE>” command, the CPU should also use the STATUS(2) command to check whether the <APPEND> command has been successfully executed before begin writing data to it.

Example

    PRINT #8  "">"
    S = STATUS(2)       ‘ Status(2) returns 1 if successful.
    IF S <> 1 RETURN: ENDIF
    FOR I = 1 to 100
       PRINT #8  STR$(I,4)+":This is the Appended first line"
       PRINT #8  STR$(I,4)+":This is the Appended second line"
       SETLCD 1,1, "Append  #"+STR$(I,4)
    NEXT
    PRINT #8  "</>"     ‘ close the file

c)  Open A File For Appending Data To The End Of The File

Syntax:  PRINT #8 “<DELETE filename>”  

There is no need to close a deleted file.

d)  Open A File For Reading Data

Syntax:  PRINT #8 “<READ  filename>”  

If the file has been successfully opened for reading after execution of the PRINT #8 “<READ>” command, the PLC can start to retrieve ASCII data from the file line-by-line using the INPUT$(8) command. A line is either a string that is terminated with a Carriage Return character (ASCII 13), or is a 70-character long string (which is the maximum length of any string variables A$ to Z$) without carriage return. In either case the return string does not contain the CR character itself.

The PLC can check if a file has been successfully opened for reading using the STATUS(2) function AFTER executing the PRINT #8 “<READ>” command. STATUS(2) will only return a 1 if a file has been successfully opened.

The PLC can determine if the End-of-File  (EOF) has been reached using the STATUS(2) function after every INPUT$(8) command has been executed. STATUS(2) returns a 255 if the EOF has been reached. The PLC should then close the file by executing the “PRINT #8 “</>” command.

     A$ = ""
     S = STATUS(2)
     IF S <> 0 
        SETLCD 1,1, "Failed to Open File"
        GOTO @100
     ENDIF
     C = 0
     PRINT #8 A$
     SETLCD 1,1, A$
     WHILE 1
        A$ = INPUT$(8)
        S = STATUS(2)
        IF S = 255 EXIT : ENDIF   ' S = 255 means EOF
        SETLCD 2,1,A$
        DELAY 50       ' So that reader can read from the screen.
        C = C+1
     ENDWHILE

     SETLCD 1,1, "Read ” +STR$(C) + " lines "
     @100
     PRINT #8 "</>"   ' close the opened file

One important capability of the new Wx100 PLC is the ability to upload file created by the PLC to an external server on a local area network or on the Internet via the FTP protocol. If you have access to a FTP username and password on your company’s server (or if the SysAdmin is authorized to set up an account for you) you can certainly use your own account for testing. If not, you can download the free Filezilla FTP Server and set it up for testing. The “ExtendedFileSystem.PC6” has a FTP upload demo and it was configured to work with a FileZilla FTP server.

Using Filezilla has the advantage that you can see the login sequence performed by the PLC when it attempts to connect to the FTP Server so that it is easier to troubleshoot connection problem.  (For professional grade troubleshooting, one handy program to have is the “Wireshark” program which is a TCP/IP packet sniffer that allows you to look at the actual TCP/IP packets sent between your PC and the PLC). However, it is important to setup the Filezilla server program properly to minimize connection trouble.

a) Download and Setup FTP Server

1. First download the FileZilla server installer from the following website:

     http://filezilla-project.org/download.php?type=server

2. Run the “FileZilla Server Interface” program which is meant for managing the FTP Server settings.

3. If the FileZilla Server is running on the same PC that you are running the FileZilla Server Interface program then you can use the localhost IP address which is 127.0.0.1 – the Port can be anything since this is a client port that the Interface program is using to interact with the FTP Server (don’t be confused with the FTP Server listening port which is by default = 21).
4. If this is the first time you run the program after setting up Filezilla FTP Server there will be no Administration password so you can leave it blank. Click OK to connect.

5. Click “Edit->Settings” and then “General Settings -> Welcome message” – leave only one line of welcome message so that the PLC has less work to do. Then click OK to accept the change.
6. At the “General” page of the setup screen, click “Add” button at the “Users” pane to add a username “PLC”. Since no group has been defined simply leave the default as “<none>” in the second text box as shown in the following diagram.
7. At the “General” page of the Users setup screen, click “Add” button at the “Users” pane to add a username “PLC”. Since no group has been defined simply leave the default as “<none>” in the second text box as shown in the following figure.

8. Next click “Shared folders” page and you must setup a folder that is to be used to receive uploaded file. Click “Add” at the “Directories” pane to add the folder.

9. You can choose any folder on your PC to be used for the FTP upload and you just have to remember the location so that you can look for the uploaded file later in the test. However, make sure that you check all the check boxes for “Read”, “Write”, “Append” etc as shown in the following figure:

10. Click “OK” to complete the setup. The FTP server should now be ready and wait for incoming connection from any FTP client including the PLC.
     

You can now test the FTP Server using the FileZilla client as mentioned in Chapter 2.9 in this Manual.

But a better way to test is to use the “Telnet” program on your PC (if you are running Windows Vista or Windows 7 you may need to enable the Telnet program since it is disabled by default – do a quick Google search on how to enable the Telnet client software on your PC).

Also you may want to find out the IP address of your PC that is running the FileZilla Server.  If you have TLServer running on your PC your IP address is reported on the TLServer’s front panel. You can also get the IP address from the Windows “Network Connection Status” .  Our test PC has an IP address = 192.168.1.168 which will be used in the following tests as well as used in the PLC program to connect to the FTP Server.

1. First open a command prompt window and then type “telnet 192.168.1.168 21” – this will open a telnet connection to the FTP server on our test PC with IP address 192.168.1.168 and listening at port 21.  Please replace the IP address with the actual IP address of your The following screen shot captures the test sequence.  Note that the same command/response sequence with the server is also shown on the  FileZilla Server Interface program front panel:

2. Once you get the “230 Logged On” message you know that the FTP setup is done correctly. Note that the welcome message from the FTP Server shows only one line “220 FileZilla Server Version x.xx” which is what we have set it up to be. You can now disconnect from the FTP server by typing “Quit” at the command prompt.
3. There is one more things you need to do before you proceed to test the FTP upload features of the PLC to avoid connection problem – that is to temporarily TURN OFF the Windows Firewall and any software firewall setup by anti-virus software during your test. You can always re-enable your software firewall(s) after the test if you wish. PC operating system are designed to run client program normally instead of acting as a server so Windows Firewall by default is to block all incoming connections to the FTP Server. Thus it can give you a lot of headache when you are trying to connect to the FTP server operating behind the Windows Firewall.

Notes:

• The main purpose of Windows Firewall is to protect your PC when you are connected to say a public wi-fi network. But if your PC is connected to the Internet via a router at work or at home, the router hardware itself would act as a firewall to isolate your PCs and a software Firewall is actually redundant. (If a hacker tried to connect to a port to your public Internet IP address what he reached would be the port on the router and he would not be able to reach your PC, unless you have specifically set up to forward all TCP/IP messages sent to that port to a specific PC).
• If you really want to use the Filezilla FTP Server as a permanent server on a PC to receive files, and still want to have the Windows Firewall enabled, you can refer to the next section in this chapter which describes how to do it.

Most Windows PC today are shipped with Windows Firewall enabled, which will prevent inbound connection to the Filezilla server program from any external device. Hence in order for Filezilla server to work successfully you have to setup the Windows Firewall to allow inbound connections. For quick test you can temporarily disable the Windows Firewall if you do not wish to go through the process of setting up the inbound rules. If you want to setup Filezilla to work permanently to accept inbound FTP connection then you and follow the step by step instructions below:

You can also refer to the following Microsoft document describing issues and solutions related to FTP server behind the Windows Firewall.

http://technet.microsoft.com/en-us/library/dd421710(WS.10).aspx

Microsoft focuses mainly on the FTP server in their IIS server (for obvious reasons) instead of Filezilla. If you are setting Filezilla as a permanent FTP server behind a software firewall you can try to make the following configuration setup:

1) You must specifically setup a range of port number for Passive mode use. These are the port number that Filezilla will assign to the PLC to make a data channel connection when it attempts to transfer a file using passive mode. The following is an example where two port numbers are assigned so that two PLCs may connect to the Filezilla simultaneously. You can add a larger port range if more PLCs may connect to the FTP Server simultaneously.

2) The next step is to allow FTP connections through the Windows Firewall. Open up Windows Defender Firewall and click on the “Advanced Settings” link. Then click on “Inbound Rules” and click “New Rule”. Click on “Program” and browse to the Filezilla FTP server executable.

Click Next and make sure that “Allow Connection” option is selected and click next again and give a name to your new rule. Finally, click “Finish” button when you are done setting up the program exception rule.

3) Next we will add the FTP ports to allow inbound connection. Click on “New Rule”, select “Port” and select “TCP”, then either select “All local ports” (the easiest way, but less secure) or “Specific local ports” and then enter the port number 21 (FTP server port) and the port range 41000-41001 that we want to allow Filezilla Server to accept inbound connection, as shown below:

Click “Next” and make sure that “Allow Connection” option is selected and click next again and give a name to your new rule. Finally, click “Finish” button when you are done setting up the port exception rule.

a) Overview of The FTP Protocol

The FTP protocol requires two socket-connections between the devices performing the file transfer. One connection is the “command” channel where FTP commands such as STOR or DELE and the responses are sent as plain ASCII text strings between the FTP client and the FTP server. The second connection is the “data” channel where only the file content or the file directory data are being transferred.

There are two transfer modes: “Active” mode and “Passive” mode. Active mode requires that the server establish a data connection back to the client. Passive mode on the other hand, requires that the client also be the one to establish the data connection. i.e. For passive mode, both the command and the data connections are performed by the client (the PLC in this case).

The PLC has been designed to use only passive mode to transfer file to the FTP server. Passive mode is preferred because that is the only way to transfer file if the FTP Server is located on the Internet. The alternative active mode transfer requires the server to make a data connection back to the PLC that is sitting behind a router firewall, and that can be problematic unless the router is specifically configured to forward the data port to the PLC.

b) PLC FTP Upload Procedure

In order to upload file to the FTP Server, the PLC would use the PRINT #4 “<TCPConnect xxx.xxx.xxx.xxx:21>” command tag to connect to the FTP server port 21 to establish the “command” connection to the FTP Server. The PLC uses its PRINT #4 to send and INPUT$(4) to receive ASCII text strings from the FTP server via the command channel. The PLC would then send the command “PASV” to inform the FTP server that it wants to transfer a file in passive mode.

At this point you can use the PRINT #4 command to send any valid FTP command to the server, including changing directory (CWD command – make sure the directory exist), deleting a file (DELE command – beware of what you are deleting!) etc.

When the PLC is ready to start a file transfer to the FTP server, the server will in turn provide the PLC with the port number that it has opened for the PLC to connect to establish a data connection. Upon receiving this port number the PLC will make a second TCP connection to the given port and then the actual file transfer will begin.

A new, network service command tag named “FTPUPLD” handles the negotiation between the FTP Server and the PLC as well as handling of the data transfer from the PLC to the FTP server. The following is the syntax:

     PRINT #4 "<FTPUPLD Zxxx.yyy  [destination file name]>"

Where: Zxxx.yyy is the file name of the extended file that the PLC has access to. The [destination file name] can be any legal name acceptable to the server so you can attach a date or time stamp to the file name for easy identifications.

When the above command is run, the PLC will send the actual “STOR” command in the background to the FTP server and then obtain the port number from the server and it will then make a data connection to it, and file transfer can then begin.

c) Monitoring The FTP Upload Progress

Once the file transfer begins the PLC firmware will handle the rest of the file transfer until either the file has been completely transferred or the transfer is aborted due to a network or server trouble. You can monitor the progress of the file transfer using either the STATUS(4) or STATUS(20) functions.

STATUS(4) = 0  : FTP client was idle or last FTP failed
            1  : FTP data transfer just started
            2  : 1st FTP segment transferred, now transferring the rest
            3  : FTP data transfer completed. 

STATUS(20) > 0 : Number of bytes uploaded to FTP Server. Transfer is in progress.
           < 0 : Total number of bytes uploaded. Transfer completed.

For example, If 2,345 bytes has been uploaded to the server and the transfer has ended, STATUS(20) will return the number = –2345.

Since file transfer can take substantial amount of time to complete, it is not wise to run a loop to wait for the file transfer to complete since this will block the PLC from processing any other part of the program. The demo “ExtendedFileSystem.PC6” shows you how to setup a monitoring function to periodically monitor the progress of the file transfer and report the transfer status on the LCD display.

Please refer to the comments in the custom function “fnConnFTP” and “fnMonFTP” of the “ExtendedFileSystem.PC6” program for more detailed descriptions of each command involved in the FTP file transfer.