Configuring Productivity Suite UDT-Style Tags for Pumps

Productivity Suite did not support User Defined Tags (UDTs) when this Pump/Fan structure was first requested. AutomationDirect listed the feature as a customer request on its improvement list for later releases. Your first job is to find out whether the release on your PC has user-defined structures. If it does not, you rebuild the Logix-style Pump or Fan data type as a set of indexed arrays. The target structure has analog members for Amps, Pressure and Temperature, plus Boolean control bits for Start, Stop, Run Status and Run Output.

Does your installed Productivity Suite release offer user-defined structures?

Check the software before you plan any tags. Open the Tag Database and look for an option to create a structure or data type that holds members of different types. Also read the release notes for your installed version, because the feature was planned for later releases than the one in use when it was first requested.

• A structure editor exists and allows mixed member types: define one Pump type with its seven members, create one instance per pump, and go to the build procedure below.
• Only single-type tags and arrays exist: the UDT has to be emulated. Continue to the next check.
• Only system-defined structures appear (instruction data blocks and similar): treat this the same as no UDT support. You can read those structures, but you cannot declare your own.

Where does a flat tag list break down along the pump signal chain?

Each pump signal passes through the same chain. A field device drives an analog input. The input module converts the signal to raw counts, scaling turns the counts into engineering units, and the result lands in a tag. Logic reads that tag and writes a control bit, and the bit drives an output that energizes the starter. A UDT keeps every link of that chain for one pump under one name. A flat tag list keeps them only by naming convention.

Most commissioning faults occur where that convention is weak. Tag three of pump 2 gets pointed at pump 3's terminal, and the logic executes correctly on the wrong data. The table below lists the symptom you will see on each signal when a mapping or index is wrong.

Which array layout reproduces a Pump data type without UDTs?

An array holds one data type only. A single array therefore cannot carry both floats and Booleans the way a UDT does. The standard substitute is parallel arrays: one array per member, all sized to the number of pumps, with the pump number as the common index. The names below are examples you choose, not built-in tags:

PumpAmps[n]      float   scaled motor current
PumpPress[n]     float   scaled discharge pressure
PumpTemp[n]      float   scaled temperature
PumpStart[n]     bool    start command
PumpStop[n]      bool    stop command
PumpRunFb[n]     bool    run status (aux contact)
PumpRunOut[n]    bool    run output to starter

You can compact this further if your release supports two-dimensional arrays. Use one float array indexed [pump, member] for the analogs and one Boolean array for the bits, with fixed member numbers such as 1 = Amps, 2 = Pressure and 3 = Temperature. The trade-off is readability: PumpAmps[2] is self-documenting, but PumpAna[2,1] needs a legend in the project documentation.

Before you write any indexed logic, open the array definition and read its base index (0 or 1). An off-by-one between the HMI, the logic and the I/O mapping produces the most common symptom in the table: the command acts on the neighbouring pump.

Is a wrong reading a wiring fault or an array-mapping fault?

Measure before you edit logic or scaling. Work through these checks in order:

1. Measure at the input terminal. Put a meter on the analog channel for the suspect pump. If the loop signal is wrong or absent at the terminal, the fault is in the field wiring or the transmitter. The tag structure is not involved, so stop here and fix the wiring.
2. Read the raw channel value in the I/O monitor. If the raw counts track the meter but the array element does not, the scaling or the channel-to-element assignment is wrong. Go to step 3.
3. Disturb one input and watch the whole array. Change one signal, for example by removing one transmitter's loop or injecting a known value. Then watch all elements of the member array in a data view. If a different element moves than the one you expected, the channel is mapped to the wrong index. If the correct element moves but reads the wrong value, correct the scaling span.
4. Toggle one command bit from the HMI. Watch which PumpStart[n] element changes and which physical output energizes. If the HMI writes element n but the logic reads element n±1, the base index is misaligned between the two.
5. Check the run feedback path separately. Energize the starter and confirm the auxiliary contact input sets the matching PumpRunFb[n]. A fail-to-start alarm on a running motor almost always comes from a feedback index error, not from the alarm timer.

How do you build and prove the pump array set?

1. Fix the pump count and any spare capacity. Arrays are sized at definition, so every parallel array must be resized together whenever a pump is added.
2. Create the member arrays with identical length and the same base index.
3. Map each analog channel to its scaled element and each discrete input or output to its bit element. Record the full pump-number-to-terminal cross-reference.
4. Write the control logic once against a pump index. Use a loop or a repeated rung block, depending on what your release supports. Keep the per-pump logic identical so a fault in one pump appears in all of them during testing.
5. Point HMI objects at array elements by the same index. If the HMI reaches the PLC through a communications map, confirm each element's mapped address rather than assuming the addresses are contiguous.
6. Run a point-to-point check on every pump. Inject a known analog value and confirm it appears only in element n on the matching HMI screen. Press Start and Stop for pump n and confirm that only starter n responds. Confirm that Run Status n follows the auxiliary contact.

The build is verified when every member of every pump passes the one-input-changes-one-element test, and when no command reaches a neighbouring starter.

What goes wrong when porting Logix UDT habits to Productivity arrays?

• Arrays with different lengths. Adding a pump to only some member arrays leaves logic reading past the end of the short arrays. Resize all of them in one edit.
• Mixed-type assumptions. Logix lets a single UDT instance hold REAL and BOOL members. Here, each member needs its own typed array, and code copied from Logix that indexes one structure must be split per member.
• Rename drift. A UDT renames all its members together. Parallel arrays keep their consistency only through naming discipline. Use one prefix per equipment class and export the tag list for review before download.
• Migration debt. If a later release adds user-defined structures, the parallel arrays will not convert on their own. Keep the pump-to-index cross-reference so you can remap to a native structure in one pass.

FAQ