All the high grade simulators I've seen cost big bucks, and some will just generate a bunch a positions to satisfy a path.
If you want to play with robot geometry and dynamics you might want to look at Scilab and the RTSS toolbox. Both are free off the web.
You can do forward and inverse kinematics and simulation, transformations, quaternion/euler conversions, matrices etc. I've only been playing with it for about 3 months now, it does seem stable, well written and surprisingly powerful. They have a Puma 560 file built. I am a cheapskate.
I've been buying books that the kids use in university robotics courses, most are pricey and of poor quality, but they do help. Makes nice toilet reading.
There are little online courses that one can access too,
http://prt.fernuni-hagen.de/pro/richodl/richodl.html is one of many.
Regarding standard practice, here's my take.
I've always been the only robot guy rubbing shoulders with a gang of PLC coders, and never get to see what other bot people do. I've developed my own "standard" over time that I force onto these guys. They like it (or, they say they do, anyway) and it works, so something must be at least half right.
Be anal about keeping taught points to an absolute minimum, it keeps code more maintainable.
I tend to copy the Fanuc/Kuka UIO/Remote Extern setup and apply it to all robots that do not have their own builtin interface, SCARAs included.
Give the cell master ability to abort a program and stop bot motion at any time, and the ability to start the bot in any arm position without having to care about where TCP is. In short it's like a multi-function actuator as far as the cell master is concerned.
Avoid use of refpos or "home" positions with IO handshakes. They eat cycle time.
Avoid having anyone jog the robot, they can do all they need to from the HMI. Then customer does not need robot-trained people to run a cell.
I set collision guard sensitivities way up, by building a cad model of tool and calculating/extracting COG and mass properties from it, so that I can stop a 165kg R2000i running at 100% by grabbing hold of the tool on it's way past in joint move to load an injection molder. Also has great entertainment value.
Other odds and ends like a separate user frame for each piece of tooling, and all origins at robot 0 so that I can visualize it, and structuring code from a product flow viewpoint as opposed to a hardware/tooling viewpoint.
What I would like to try is having robot as cell master. Maybe one day...
OK, so now I've spilt my guts, be interesting to see what other folk do.
Author