Here at Avanceon, we’ve been developing solutions for our customers for a long time. And in the process, we’ve run into – and solved – many “interesting” technical challenges. We’ll share some of the more generally applicable ones on this page: after all, if we already have a solution, why should you have to develop your own?
Allen-Bradley Ethernet Module Loading
While using a 1756-ENBT module in an application with MSG instructions to/from 20 PLCs, plus HMI traffic, some instructions failed and sometimes the HMI screens froze. The occurrence of these incidents varied between once every 2-3 weeks and several times a day.
By checking the CPU usage on the on-board ENBT processor (not the PLC processor), which is available via the ENBT module’s web page with a 15-second refresh, we determined there were brief (less than 15 second) periods in which the CPU usage would spike from a steady state of 40% to a full 100%. These spikes directly corresponded to the outages. However, raising the Processor Timeslice, slowing down the HMI refresh, slowing the message instructions, and replacing the ENBT all had no effect on the frequency or duration of the spikes.
We found that even though the ENBT was operating within its designed range, it was unable to keep up with traffic demands. Replacing the ENBT module with an EN2TR, which has double the bandwidth and supports 128 connections, has solved the problem. CPU usage is now a steady 10%, and no spikes have been observed.
Making RSLogix5000 behave
Attempting to import routines to a Logix5000 PLC results in a crash of Logix 5000.
From Windows, press CTRL-SHIFT while double clicking on the ACD file you wish to open. Keep the keys pressed until the program is fully opened. This will reset the Logix5000 Registry values back to their defaults and clear out any incorrect entries. You may also find that Logix 5000 opens faster.
SQL Syntax Help
It is sometimes difficult to remember the complex syntax of SQL statements.
Use the Template Explorer feature in SQL Server Management Studio.
To access the tool, go to the View menu and choose Template Explorer
Figure 1. Template Explorer Window
This opens up a window with categories for everything that can be created or modified in a SQL Server environment.
Make sure to expand the “Earlier versions” tree, as it includes most of the tool’s basic features.
Figure 2. Template Explorer with “Earlier Versions” Tree opened
Drag and drop what you want into your query window. Be aware, however, that the text contains placeholders. For example, see the Template Explorer generated “DECLARE (cursor_name, sysname, test_cursor) statement. To correct this, see below:
Figure 3. Copied text, uncorrected
To replace the placeholder text, press Ctrl+Shift+M, which will prompt you to replace the placeholder text with your entries. See Figure 4.
Figure 4. Replacing Template text
The net result will appear similar to Figure 5:
Figure 5. Placeholders removed with valid statements
Note: that the default entries from Figure 3 have been replaced with the values entered in Figure 4.
PID Tuning for ControlLogix Conversions
Is it necessary to retune all PID loops after a PLC conversion from PLC5 to ControlLogix?
Provided that the PLC5 loops are triggered from a timer DN bit with a preset equal to the Loop Update Time, the loops do not need to be re-tuned.
If the loops are called unconditionally, then the difference in scan time from the PLC5 to the ControlLogix will necessitate re-tuning of the loops. For example, if the CLX scan time is 4x faster than the PLC5, and the PID loop is not triggered from a timer, then the KI and KD must be adjusted (slowed) by a factor of four in order to provide the same response observed in the PLC5. KP remains unchanged.
In either case, there is one required change in order to make the loop operate correctly:
The Output (CV) range of the CLX loop defaults to a range of 0 – 100, which is not consistent with the PLC5 range of 0 – 4095. Therefore, the CV range must be changed to 0 – 4095 (see Figure 1).
Figure 1. PID Setup
This process was verified by testing with a PLC5 program converted to ControlLogix. The code was run in physical PLCs in order to eliminate timing issues introduced by Emulation software. Simulation code was added in order to provide PV response to the loop’s output modulation. The testers compared response of a flow control loop to a setpoint change from 300gpm to 400gpm.
As seen in figures 2 and 3, the response of the loop to a setpoint change from 300gpm to 400gpm is the same in both PLC5 and ControlLogix, with a rapidly decaying overshoot and a return to stability after approximately 2 minutes.
Figure 2. Tune Compare 1
Figure 3. Tune Compare 2
Provided that the PLC5 loop is programmed using the triggering timer and associated Loop Update time as shown in Figure 4, no re-tuning is needed. The only edits needed are as shown in the ‘required changes’ section above.
Figure 4. Loop Update Time
Beware Asynchronous Operation!
In the PLC code in Figure 1 below (ControlLogix converted from PLC5), the rung copies the alarm array (N750) into another array (MsgBoard), then zeroes out all or portions of the array based on process conditions. This can cause problems.
Figure 1. PLC code with rung copy of alarm array
The rung executes sequentially, so by the time the rung completes execution, the MsgBoard array has the correct contents. However, the Ethernet communication to the PLC is not synchronized to the PLC program scan, which means that periodically, the Ethernet client reads transient data because the rung hasn’t finished executing when the data is read.
This can happen more frequently than one would expect: in the case of the example in Figure 1, about once in every 15 minutes, which can cause considerable problems.
If multi-step operations need to be done on data being read by an external client, use buffer tags and move the result to the ‘actual’ tag when the calculations are complete. This ensures that the tags being read by the external system will never have incorrect intermediate values.
Forcing Unsupported Conversions in Studio 5000
There are situations in which the Rockwell Logix/Studio 5000 development tool does not allow you to make changes to modules in the project tree after they’ve been created (such as Ethernet modules and certain processors). A typical example is where you have had to create your code before design teams have finalized their choice for processor type: given the dependency of code on processor selection, sometimes you are “too far down a one-way road” to make a change and convert from, say, an L81E to an L71 processor.
Similarly, maybe you assumed the use of ENBT Ethernet modules, only to find out later that EN2T modules have been purchased. If you’ve created a large number of client connections like drives, I/O racks, and other devices under that ENBT in the project tree, you’ll be faced with deleting and re-adding them under the EN2T.
There is, however, a way in which you can make the process easier, though you will not find it in any instruction manual. What you must do is export the entire program to an L5K file, make the required changes manually in the text file, and then re-import the code to Studio5000 as a new program.
The specific steps will depend on what you need to do, but here is a process for changing code for an L81E processor to code for an L71:
1. Export the L881E program to an L5K file
2. Edit the L5K file with a text editor.
a. Under “CONTROLLER”, change “L81E” to “L71”
b. Under “MODULE Local” change “L81E” to “L71”
c. Under “MODULE Local” change ProductCode to 92
3. Save the L5K file, and then open it with Studio5000.
a. You may receive warnings from Studio5000, but you will be able to bypass them. Studio5000 will accept the change to L71.
Caution: As this is not a “standard” solution, please make sure you check your code carefully to make sure all necessary changes have taken place successfully.
If you need to make a different change, like in the Ethernet example, it is simplest to create a “dummy” module of the type you need, and then use that as a template when making changes in the L5K file.
Bulk Delete FactoryTalk View Tags
A useful feature of the FactoryTalk View SE and ME HMI applications is their ability to export the tag database to CSV files, edit them, and re-import them. This feature allows you to add new tags or make changes to items such as descriptions or PLC addresses. However, there is no built in way to delete or rename tags in bulk; if you try to change the name of a tag in the CSV, then import it, you’ll end up with two tags rather than one renamed tag.
You can work around this limitation by exporting the entire database to CSV, deleting or editing the appropriate tags, and then replacing the source tag database with a new, empty one created from scratch. Then import the CSV with your changes.
You can make bulk changes/additions by executing the following steps:
• Export the tags and alarms to a CSV file, and make the required changes
• Create a new, empty FTView project and close it immediately.
• Using Windows Explorer, go to the \Tag folder of the project you’re deleting or otherwise changing tags from and delete all the files in the folder
• Copy the \Tag folder contents from the new, empty project and rename them to match the filenames you deleted
• Import the CSV files from step 1 into your project