Sabotaging a program for training purposes.

[Nova5]

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.

[cardosocea]

Lack of alarms is probably one that gets me daily. I am trying to change it, but... my god have people messed this up royally in the past.

[KingPresident]

1 Remove all the JSR's from your main.

2 Reset the HMI terminal IP,

3 Copy with a length of 5 from an array with 4 elements,

[Nova5]

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.

[TheWaterboy]

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.

[Nova5]

I like those.. thanks guys for the ideas. I'll have to work over a second program with them. got enough in the first with what I did.

[Sapper307]

direct HMI feedback to incorrect tags. IE HMI display is for temperature x, point displayed value to register for level y

[jaden]

In my PLC classes, I have students develop small programs. They introduce plenty of mistakes to troubleshoot.

[Nova5]

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.

[Nova5]

Originally Posted by cardosocea

Lack of alarms is probably one that gets me daily. I am trying to change it, but... my god have people messed this up royally in the past.

heh some of our programs have around 700 alarms I'm told. I've seen close to 300 in most.

[travispedley]

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.

[califflash]

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.

[cardosocea]

Originally Posted by califflash

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.

[spaderkung]

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”.