Sabotaging a program for training purposes.

Nova5

Member
Join Date
May 2013
Location
Northern Snowball
Posts
566
Introducing bugs/errors to a program that can be seen on the HMI..

So far I've done a misnamed tag so the hmi can't find it.
a few Inputs tags reading the same physical input when they shouldn't.
multiple different tags writing the same OTE.
problems in our alarm text and triggers..

Thoughts on other problems you folks have run into that started from seeing a problem on the hmi that was program related? Generally you'll have these only during startup.
 
1 won't work as you won't have a HMI indication of a problem.
2. won't as the HMI training terminal and program will be on the same PC. HMI is inside a VM running on a host the host PC on the new employees laptop. DHCP assigned as there is no need for a HMI system in field. remote into one of the HMI terminals for use during startup. we do use the HMI VM at the office for checking against programs loaded to inshop PLCs. Seeing that the HMI is fully functional.
3. Good if the HMI limitation wern't there. Now... I might be able to copy 4 from a 5, leaving a empty at the end.. have to look into that one.
 
1. signed integer where they should be using unsigned - start seeing negative values after 32k limit
2. 1 based indexing where Zero based index is used - bits or values always off by one location (P2 starts when P3 is selected)
3. Timestamps that don't account for UTC or even DST
4. Animation that changes a datalink color to make it impossible to see when there is an error in the datalink address.
 
These aren't full on classes, its a training/explore the program for our new programmers. We have a programming standard, prebuilt programs and feature most of what we need. Parts are added and removed as needed based on customer wants.
 
Throw in some ONS's, and then have some code to unlatch the storage bit. I've seen junior guys do this. Have an OTL paired with multiple OTU's scattered about. Maybe have an OTE on the same bit just for fun. Speaking of alarms, maybe a routine that just has 50 MOV's, each with a different number to the same DINT. Tie it to a multistate indicator on the hmi and watch it glitch as is scans out of sync with the code.
 
Order of operation problems are always a hang up in the real world. Take some logic that has to execute in a certain order then move the rings around. You can’t expect someone to fix it without some comments and documentation though. I’ve seen many experiences controls engineers break working code during debug or feature additions due to this.

Data mapping mix ups are another common thing Ive seen that indicate real world troubleshooting ability.

Another good one that can easily stump people is to put add instruction that will overrun its destination tag’s data type. Bury the issue in a subroutine in a subroutine. This forces you to start setting traps to debug the program. This one is better in codesys or logix600. Logix5000 directs you straight to the rung where the overflow occurred.

You can also do an intermittent triggered output. Set up some digital inputs and outputs that are buffered say in a continuous/freewheeling task. Set the RPI of the IO to some very large or very small value. Evaluate a high speed input counter in a cyclic task. Then In another task setup an output with some of the buffered inputs and the DN bit from the HSC instruction as conditions. Then go through and mess with the task priorities and timing until the trigger output works only intermittently. I actually fixed this issue on someone’s program a few weeks ago. The system triggered an event based off a registration mark input and encoder offset.

Another issue that can focus on tasks is to set up three or four cyclic tasks. Adjust the task priorities and timing such that one of the tasks will never, or rarely, executes.
 
Order of operation problems are always a hang up in the real world. Take some logic that has to execute in a certain order then move the rings around.

This reminded me of another. Use the same variable for a string of calculations and that variable is used to display a numeric display in the screen.

This will cause the screen to mostly show the correct value but every now and then display the wrong value as the tag was read mid calculation.
 
It’s generally not considered good teaching practice to show errors, so I would think twice, maybe tweak it to a refactoring of an otherwise working program. In other fields we have the saying “Children do as you do, not as you say”.
 

Similar Topics

Hi, I am new to ladder logic. I have completed a code in the Xinje PLC XC3-32RT-E for one of the machines I am developing. Currently the program...
Replies
10
Views
113
Hi everyone i have a customer, who wants to show an alarm on the machine, if the I/O forces are enabled and set, on at ControlLogix L81E with...
Replies
3
Views
138
I can't seem to get the Panel View Plus 7 standard edition to downgrade to V_11, when I check the AB downloads and compatibility websites for this...
Replies
1
Views
93
Hello all, I have an ABB PLC (PM573) and it has without MC card. I need to take backup from PLC to PC (in automation builder v2.7 ). My...
Replies
8
Views
172
Anyone have access to Melsec Medoc plus 2.31a that can either open a file (.pcd zipped in link below) and send a PDF/screenshot of the ladder, or...
Replies
10
Views
306
Back
Top Bottom