Different "homework" assignment

Hello everybody. I have been tasked to develop a tutorial for less experienced field engineers. These are guys that have had someone to lead them by the hand. The tutorial is designed to give them basic information about the program (with bugs). The field guy has to use his imagination to correct the bugs.
The first scenario has the QW0 count up using indirect addressing. They have to make it count down.
The second scenario includes a hidden "time-bomb" that shuts down the automatic process at random intervals.
My problem is that I have a S7-315 with 1 input word and 1 output word, and I have run out of ideas. I have ordered a touch panel, but until it comes in I still need to make progress.
I don't want any code just ideas.

How about coding an algorithm to find the square root of a real number (x) ? The algorithm involves making a guess at the square root as one side of a rectangle, making the other side of the rectangle = x/guess. The guess is updated making the rectangle more and more square until the sides of the square are very nearly equal, hence you have the square root.(You could use the in-built square root instruction to validate). This provides a good base for introducing STL, loops, arthmetic, floating point numbers, single stepping etc.

Or, how about a logging program that detects changes on the inputs and puts an entry in a datablock giving the input bit address, transition type and the time/day that it occurred. The data block will need a pointer to the next entry and of course it will eventually fill up and need to start overwriting the earlier entries.

That is a very good idea - for a class.

This is more for learning troubleshooting. Get to the site. This is broke - fix it. That's the reality of what we have to deal with. These guys have had someone tell them keystroke by keystroke what to do. Field service is all feet to the fire, and they need more realistic experience. But nothing too tough.

But, thank you very much for your input.
I will keep that in mind in case they have me change the scope.

Or how about a simple digital storage scope that waits for a trigger and then stores samples of real numbers in a data block until the data block is full. (You could copy the DB from the online folder to the offline folder, save the DB as source code, export it and then import it to Excel to show a graph of the data versus time !)

SimonGoldsworthy said:

Or, how about a logging program that detects changes on the inputs and puts an entry in a datablock giving the input bit address, transition type and the time/day that it occurred. The data block will need a pointer to the next entry and of course it will eventually fill up and need to start overwriting the earlier entries.

Click to expand...

Now this is something that I can work with.
Great idea - thank you

You could use area crossing indirect addressing with the address stored in a DB to flash one of the outputs and then ask them to change the output that flashes. (I have used this method of configuring which output to use in the past, so this is a real world question).

Not sure what kind of systems you deal with but most problems I've seen in the past deal with switches.

Switches that are mis-adjusted, loose, damaged...
Switches that get replace w/ the wrong type (N.O. vs N.C. or PNP vs. NPN.)

If the applications are sequence driven, I'd take a working sequence and flip a N.O. contact for a switch to a N.C.... Let them figure out why the sequence always stops at step X.

Once had a conveyor that would run a part into a "V" stop where a photo-eye would sense the part ready for load. Then the conveyor would stop. After a few months, the conveyor surface became slipery and the parts would bounce off the "V" stop... But the sensor was made for long enough to stop the conveyor and all the logic held up until the grippers came down and removed the part. But... since it had bounced off the stop, the part was not in position and it started to crash sometimes. The answer was to debounce the photo eye signal before stopping the conveyor and to interlock the down movement of the gripper with the de-bounced photo-eye signal.

Hope that was what you were looking for...
Good Luck

ndzied1 said:

Switches that are mis-adjusted, loose, damaged...
Switches that get replace w/ the wrong type (N.O. vs N.C. or PNP vs. NPN.)

If the applications are sequence driven, I'd take a working sequence and flip a N.O. contact for a switch to a N.C.... Let them figure out why the sequence always stops at step X.

Click to expand...

Thanks,
I hadn't even thought of hardware faults, my concentration was on code problems.