Downloading and Using the Wonderware InTouch Hmi User Manual
The Wonderware InTouch Hmi User Manual is a reference document you'll probably use when something isn't working the way you expected it to. It covers version 10.x and earlier versions like 9.11, which are still running in a lot of plants right now. The manual itself is just a PDF from Aveva (formerly Wonderware), and the official download is located on the Aveva support portal. I know some people prefer to buy the printed version or keep it bookmarked, but the digital copy is what matters most. The PDF is well over 400 pages and covers everything from basic object placement to the scripting language InTouch uses, which is similar to BASIC but has its own quirks. If you are trying to make a tag blink on a screen, the manual will tell you how. If you are trying to get InTouch to talk to a PLC over Ethernet/IP without dropping connections every thirty minutes, the manual will not help you much. That part comes from experience.
Wonderware Intouch Hmi User Manual: Where to Find It and What Is Inside
The official manual lives at https://www.aveva.com. You will need an account to download it, and sometimes that account verification takes a day or two. Make sure you grab the version that matches your install. A v10.1 manual has different screenshots and slightly different menu paths than a v9.5 manual. The core concepts are the same, but if you follow a v10 procedure on a v9 system, you will be clicking through dialogs that do not exist. Inside the manual, the chapters break down into roughly these sections:
- Getting Started — installation steps, system requirements, and how to launch the Wonderware InTouch Application Server
- Tags and the Data Dictionary — how InTouch tracks values, scan rates, and trending
- Windows and Objects — building the HMI screens
- Animations and Attributes — making things move, change color, or respond to user input
- Scripting — the InTouch script language for custom behaviors
- Data Exchange — how to connect to PLCs via OPC, DDE, or native drivers
- Trending and Archiving — recording values over time and replaying them
- Reports — printing production summaries and alerts
The scripting chapter alone is about 60 pages. Most of my team uses scripts maybe twice a week. The rest of the time they are just moving mouse pointers between windows or setting alarm priorities. Here is the thing nobody tells you: the manual is not written linearly. It assumes you already know what you are looking for. When I have a problem — say, my trending data stopped writing to the archive and I have no idea why — I do not read the manual from front to back. I use the index. Search for "archive" or "trending" or "write failed." That gets me to the relevant section in about fifteen seconds. One practical technique that actually works is to open the manual and your InTouch IDE side by side. Every menu path the manual describes is exactly where it says it will be. If the manual says the Trend Setup dialog is under View > Trend, it will be there. If it is not, you are probably running a different build or a modified installer. This happens more often than you would think.
Get the Full Details
Another thing: the manual does not cover everything. I remember one project where a customer needed to suppress an alarm on a specific window based on a PLC boolean. The manual has a section on alarms and a section on window interactions, but it does not explicitly connect the two. I spent about forty-five minutes reading cross-references before I figured out that the alarm suppression attribute on the window object itself was the answer. The workaround was straightforward — set the alarm disable attribute to 1 when that boolean went true, clear it when false. The manual did not walk me through that exact scenario. It assumed I would figure out how the pieces fit together.
Common Pitfalls the Manual Will Not Warn You About
Scan rates are not optional. Every tag has a scan rate, and the default is usually 1000 milliseconds. If you are building a high-speed process and your tags are sitting at the default, your screens will feel sluggish. I have seen operators complain about a laggy interface only to discover the tag dictionary was full of 2-second scan rates. Change the global scan rate or adjust individual tags to 100ms for critical values. This alone can make a screen feel noticeably faster. The script language does not support arrays. Not real arrays. You can fake them with named tags, but if you are coming from a programming background and expect to declare an array and loop through it, you will hit a wall. InTouch scripting is functional, not general-purpose. Use it for simple logic and offload anything complex to the PLC or a separate controller. OPC connectivity breaks silently. I once spent three hours troubleshooting a missing tag in an alarm window. The alarm was not firing. The tag value was not updating. I checked the PLC, the network, the OPC server, everything. The problem turned out to be that the InTouch data exchange was configured for an old DDE link instead of OPC. The system had been migrated from an older version and the data exchange had not been updated. The manual has a section on migrating data exchanges, but it is easy to skip that chapter if you are not actively doing a migration. The fix was deleting the stale DDE entry and recreating it as an OPC DA connection. Saved me two days of confusion.
Memory management matters more than you think. InTouch stores everything in RAM. A screen with hundreds of high-resolution bitmaps and multiple trend windows will consume significant memory. I have seen systems slow to a crawl with sixty plus windows open and multiple trends running simultaneously. The workaround is to close unused windows, reduce bitmap resolutions, and avoid having more than two active trend windows on the same screen. Performance drops are not always obvious in testing, but they show up immediately when multiple operators start using the system simultaneously.
A Realistic Walkthrough: Setting Up a Simple Alarm
Here is a practical example from the manual that actually works the way it says it will. Let us say you want to create a high-limit alarm on a tag called PV_TankLevel. First, define the tag in the data dictionary. Set the data type to floating point. Set the initial value to whatever makes sense for your process. Set the alarm status to enabled. Next, go to the alarm configuration dialog. Set the high alarm limit to your threshold value. Set the high alarm delay to zero if you want immediate response, or add a small delay if your process has normal fluctuations that should not trigger an alarm. I typically use a 2-second delay on level tags to avoid nuisance alarms during fill cycles.
Then, add an alarm window to your screen. Place it where the operator can see it without blocking the main process display. The manual suggests the lower right corner for most layouts. Drag and drop an alarm window object, then bind it to your alarm group. Test it. Manually override the tag value above the threshold in the tag editor. The alarm should fire within one scan cycle. If it does not, check that the alarm status on the tag is actually set to enabled and not just the alarm limits. This whole process takes about five to ten minutes in a fresh project. In an existing project with thirty years of accumulated modifications, it could take an hour because you have to find the right alarm group and make sure the naming conventions are consistent across the entire system. That is the difference between a tutorial and real work.
What the Manual Does Not Cover (And What You Should Know Instead)
The manual is a reference, not a training course. If you have never built an HMI before, it will feel overwhelming. The scripting section is particularly dense. I would recommend starting with a simple tutorial project — maybe ten screens with basic navigation and a handful of analog tags — before you dive into the manual for advanced topics. Once you have a working project, the manual becomes much more useful because you have context for everything you are reading. Another thing the manual does not adequately address is backup and recovery. InTouch projects can grow to several gigabytes with trends and archived data. Make sure you are backing up the project directory, the database files, and the configuration separately. The manual mentions backup briefly in the installation chapter, but it does not give you a recovery procedure for when your hard drive fails at 3 AM and you are the only person who knows how the system is organized. If you are managing multiple InTouch installations across different sites, the manual will not help you standardize your projects. I use a shared template library with pre-configured windows, symbol libraries, and alarm group definitions. This cuts project startup time from about four hours to roughly forty-five minutes per new site. The manual does not cover this because it is a practice decision, not a technical feature. But it is one of the most impactful things you can do if you are responsible for more than one system.
The Wonderware InTouch ecosystem is also being phased out in favor of Aveva System Platform. If you are starting a new project today and you have the budget for it, you should be evaluating System Platform instead. InTouch will continue to run and receive support for the foreseeable future, but new development is going toward the newer platform. The InTouch manual is still relevant for the millions of existing installations, but if you are designing something from scratch, the long-term trajectory points elsewhere. The Wonderware Intouch Hmi User Manual remains the primary reference for anyone working with this software. It is not perfect. It does not solve every problem. But it is better than nothing, and in a plant environment where the HMI is down and production is losing money by the minute, having the manual open and searchable is usually the fastest path to getting things running again.
