Training Technicians in Fanuc IO

    For the next two weeks I'm cycling through my EMT's (Electrical Maintenance Technicians) and taking them to a local community college for a one day hands on training to help them gain familiarity with Fanuc Robots. They have all had formal operations/handling training from Kawasaki ( we have more Kawasaki Robots then Fanuc) so some concepts transfer over well. I performed my first training day yesterday and I felt it went fairly smoothly. I got the bare bones basics across (terminology, basic components of TP and Controller, TP layout, Joint/World/Tool Jogging, IO Types/IO Uses/IO configurations) done in the first four hours then spent the last 4 hours making a simple program and then continuously modifying it to give them more experience. All in all my tech felt like they learned some useful information and I felt like I cover the content competently. The only section I feel I need to tweak is the content pertaining to IO types, IO Uses, and IO configuration. So I guess that is my question for you all, when training how do you all cover that info without losing yours pupils attention or confusing them? The equipment we were using to train on was a certified Fanuc Education Training cell which uses local IO all configured to Rack 48 ( I think?), this was the first time I had ever actually worked with that particular style of configuration so I believe this was part of my problem, I understood it well enough to work with it but not teach it. Generally I'm used to a ethernet configuration although we do have two Fanuc Robots with Model B type IO. I brought along data sheets I had made showing the interconnected DI's/DO's and their correlating PLC tags/bits. And when I tried to explain program calls (PNS/RSR/Other) and I felt like I really lost him then). For information's sake we use RSR and Other type program calls. I attached a image of the training cell and a transcript of the program my tech created by the end of the day (we couldn't make a backup because the cell used CF cards only which I had none with me). I'm just throwing this out there to see if anyone with experience providing technical training can help guide a another relatively new "Trainer".

    Quote from ericwiz7923

    The only section I feel I need to tweak is the content pertaining to IO types, IO Uses, and IO configuration. So I guess that is my question for you all, when training how do you all cover that info without losing yours pupils attention or confusing them?

    Everyone has different existing levels of experience, knowledge etc and fundamentally they are already in 'technical environment', so should already have some idea of how equipment is operating fundamentally and so you should not be spending too much time re-inventing the wheel.

    So the premise is for them to tell you when they are confused or lost.

    As for attention, a quick slap is usually good enough.....nah seriously, this whole subject is an art in my opinion as opposed to a rule.

    Just like a comedian and their audiences.


    You could be harsh and ignore it when you see someone confused or lost, or try and 'bring them back', but this may mean the others in the group become bored and can often undermine the person that's struggling.

    - So the key is to try and find and then maintain a balance for your audience.

    - Some people can just sit in front of a manual all day.

    - Some people prefer the hands on approach.

    - Some people just like a step by step guide to follow, trouble with that, you also need the 'what if you accidently do something else'.

    - Some like to mix it up a little.

    - People just don't get enough one on one time with a robot outside of breakdowns, so making it more hands on is a key part of this balance in my opinion.


    I have many techniques, that are more psychological than practical, but over the years - Terminology has been a very large part of.

    I always say to people, try not to find the right words, just say it as you see it, then you'll appreciate the terminology they use.

    As a trainer, if you can adjust your terminology to theirs (and make some similarities/comparisons), then they will understand easier and when this happens, they usually begin adopting the terminology and begin understanding easier.

    If you can demonstrate it whilst you are talking about it, this also helps the deliverance and can help the recipient understand easier.


    The best method I use is to create training modules with prepared supporting documents as references (not the manuals).

    - A small introduction of the topic, functionality and areas it is integrated or applied and open up a discussion of the topic.

    - A demonstration, which you reinforce with further information and Q and A sessions based on what they saw.

    - Depending on numbers involved, either individual consolidation or group consolidation exercises.

    - Individual consolidations are best as this gives people the opportunity to bolt things together in 'their own time'.

    - A final consolidation (time dependent) is to bolt ALL the sections together (not a pass or fail).


    During these consolidation periods, this gives you the opportunity to spend some time (one to one) with some of the stragglers.


    Regarding the specific IO situation:

    - Have a peripheral so that they can install, configure, commission and test it from scratch using an IO box with switches and leds or a fieldbus IO device.

    - Then program the robot to integrate it into a working solution.

    - Then introduce them to how it is being integrated in the 'working system' by providing a code walkthrough.

    - Including the areas that they have already just used, so they can see the comparison.


    Hope this helps.......


    I'm actually visiting a client tomorrow where we are going through the setup of an Ethernet/IP Balluff module using a backup of their current robot system in Roboguide to integrate and test it, ahead of time before integrating it into the working system as an upgrade.

    They have never done this and it is part of system upgrade they are looking at rolling out amongst several of their existing systems.

    So I'm going down to assist and draw up a working document for them to proceed with it and for their other Fanuc Systems too.

    So it'll be like a training document afterwards including when things aren't configured correctly, so they can effectively carry out the upgrades themselves.


    P.S

    Have a look on Google for 'Domain of Learning' - Cognitive, Affective, Psychomotor.........A very interesting read indeed if you take training seriously.

    kwakisaki another great answer sir.

    I've attached two of my IO sheets I've created that I am using for training. The one called ISW-01A is probably more user friendly to understand. The difficulties to understand IWS-02B probably come from the fact that originally the cell was configured for another application so there is a bunch "leftovers" in the program and the IO configuration. The biggest problems seem to be coming from the UOP signals and program calling. Ill be running my head at the wall today to continue to tweak the lesson today. My second training went well yesterday. This was with my most experienced technician though and he agreed that there was still some being lost in translation.

    Quote from alive15

    I downloaded your word doc, and noticed no comments on any lines? That may help in understanding each line.

    A very good point. Thank you.

    The impression I am 'reading' is I don't feel as though your audience are asking too many questions or giving you any real feedback to establish a personal benchmark and giving you cause to think it maybe confusing, or your missing something out or are they actually are stating that it's confusing?

    Quote from ericwiz7923

    The biggest problems seem to be coming from the UOP signals and program calling

    Reading your posts, I am not too sure where this lies, except for the above........

    So what are these problems, what are they specifically saying.......but I assume it's what they're not saying that is also a concern perhaps too?


    Just to put another suggestion your way and maybe you could use this concept to address the UOP and program calling aspect.


    Reviewing the document 1WS-01A (no criticism intended), this is open to loads of questions and also reading the footnote just down to terminology alone.

    So below, I will ask you the kind of questions I would expect to be asked if I was hosting this just based on the IO_ScreenGrabs spreadsheet.

    As a suggestion, you could incorporate the answers you would give into your footnote, just to elaborate a little, this may help as a concept to introduce.

    Please appreciate, I am in no way criticising your work, merely trying to convey an unbiased view by being 'the trainee'.


    So if you presented this to me (and consider I am the trainee for a moment), this is what I would be considering asking you but may not actually ask:


    1. Robot:I and Robot:O is the Ethernet module mapped to the Control Organizer at IP 192.168.81.121, this is the robot Host Comm address.

    - Ok, so this is the device that communicates with the robot then?

    - Can you show me where this Ethernet Module is please?

    - Will you be showing us how to troubleshoot or set this up in the event of failure or are you just going to be explaining what this all means?

    - Can you show us the connections between the PLC and the Robot - Where are they?


    2. It says the lengths of the Robot Input and Robot Outputs are 64 Word Integer Arrays.

    - What I'm thinking is that in this case the actual number of signals used for Inputs or Outputs are 64x16bits = 1024 signals, would this be correct?

    - Wow, I'd hate to have to physically wire these up and the connection you showed us earlier - all of these signals along a couple of cables.....Cool!


    3. The values of Robot.OutputWord is copied and applied to Robot:O ( example-Robot.OutputWord[0].2 is ON then Robot:O.Data[0].2 is ON and DI 3 will be ON).

    - What does the [0] mean, I'm not quite sure about this?

    - I don't quite get this, your talking about Robot Outputs here in the PLC and now you've mentioned DI3, which I've never heard of, what is this?

    - Ok so DI3 is Digital Input 3 on the robot.......ie a signal coming into the robot from the PLC - Correct?

    - I'm a little confused as aren't the robot outputs coming from the robot to the PLC and robot inputs signals coming from the PLC to the robot?

    - So I can't quite understand in your example your talking about Robot Output bit 2 and then saying digital input 3 is on, shouldn't that be DO3 is on?


    Again as a suggestion, applying a similar concept to the inputs and outputs spreadsheet, I could generate many questions like the above.

    Especially the UO and UI as from spreadsheet it is clear they are some sort of signal.

    For example, again as a trainee, I would be asking things like:

    - What is a UI and UO?

    - What does RSR mean?

    - I see RSR_PNS1, what is this?

    - Can I see these on the robot teach pendant?


    If you could elaborate on these just a little further, maybe grab the info from the Fanuc Manual as reference and show them on the teach pendant the monitoring area whilst the system is running so they can see these signals in action, it could well just 'bridge the gap between OEM and Integration'.


    Hope this helps......

    Very glad to hear it's improving for you, and as you get more and more sessions under your belt, you will adjust your deliverance and documents as a way of self reviewing and therefore improving as you go along and the more positive comments will then come, which should then answer your questions of:

    - Did I miss anything out.

    - Was it confusing.

Advertising from our partners