I've been thrown into these situations (kept looking up, expecting to see the bus) a few times. I don't bother to prepare anything, except to have some copies of the applications that they use.
I just walk into the room and ask the attendees what it is they want to take away from the training. Then I tailor what I'm going to say to meet their needs, rather than try to guess their needs and teach them what I think is important.
If they answer "troubleshooting", then I open up their program, show basic navigation, cross-reverencing, searching, etc., from physical output back through the logic (and how the various instructions solve), back to the physical inputs. "The code doesn't break; the real world does."
If they are looking to program from scratch, then I teach them best-practice techniques for data and logic structure, using one of their projects as an example of what-to-do/what-not-to-do. Always stress the importance of presentation (e.g., HMI) because if the operator doesn't understand what is going on, it isn't right even if it is. "Form follows function; function follows form".
Halfway through the time, I ask, "what are the biggest problems that you're seeing / hardest things you are asked to do?". Then I attempt to solve/demo that example. If there's more time, and they do have laptops, I flip that and have them show me how to do it, while I critique/advise/guide. Building "muscle memory" is really the only way they'll actually acquire skills.
This really only works for small class sizes (1-3 students). More than that, and you do need to have stuff prepared, specific tasks that they need to perform, with step-by-step instructions. The problem with those kind of training courses is that the students only really learn how to follow directions, not how to reason their way through the issues.
So my best advise to you is: call your client and ask them what they want to get out of your "introductory PLC course". Nail down the class size and duration (2 hours | 2 days | 2 weeks have very different expectations and outcomes.
Good luck!
I just walk into the room and ask the attendees what it is they want to take away from the training. Then I tailor what I'm going to say to meet their needs, rather than try to guess their needs and teach them what I think is important.
If they answer "troubleshooting", then I open up their program, show basic navigation, cross-reverencing, searching, etc., from physical output back through the logic (and how the various instructions solve), back to the physical inputs. "The code doesn't break; the real world does."
If they are looking to program from scratch, then I teach them best-practice techniques for data and logic structure, using one of their projects as an example of what-to-do/what-not-to-do. Always stress the importance of presentation (e.g., HMI) because if the operator doesn't understand what is going on, it isn't right even if it is. "Form follows function; function follows form".
Halfway through the time, I ask, "what are the biggest problems that you're seeing / hardest things you are asked to do?". Then I attempt to solve/demo that example. If there's more time, and they do have laptops, I flip that and have them show me how to do it, while I critique/advise/guide. Building "muscle memory" is really the only way they'll actually acquire skills.
This really only works for small class sizes (1-3 students). More than that, and you do need to have stuff prepared, specific tasks that they need to perform, with step-by-step instructions. The problem with those kind of training courses is that the students only really learn how to follow directions, not how to reason their way through the issues.
So my best advise to you is: call your client and ask them what they want to get out of your "introductory PLC course". Nail down the class size and duration (2 hours | 2 days | 2 weeks have very different expectations and outcomes.
Good luck!
