The graphic display of the robot within the PolyScope software is the "visual simulation".
Are you looking for more industrial simulation environment software where you can 3D model the environment, the robot, objects that it's picking up, etc?
The graphic display of the robot within the PolyScope software is the "visual simulation".
Are you looking for more industrial simulation environment software where you can 3D model the environment, the robot, objects that it's picking up, etc?
If the robot is connected to a network, it does not matter if you are controlling the bot via a hard wired or wireless device.
You will need to look up the Dashboard Interface, which can be used to send basic commands (play, stop, pause, etc) and script commands (any bit of code that the robot can execute, like movements etc). It's completely possible in Python as well as pretty much any other language, as the protocol is just a plain vanilla text TCP socket.
1 - check the Installation > Safety tab and uncheck the Unrestricted Wrist 3 option
2 - not sure if you can do it in the UI but you can insert a Script Code node and use sleep(myVar) where myVar is the wait period in seconds
3 - never tried using that connector, dunno!
Correct, after the BCO run, the robot is transitioning along previously programmed paths.
Since the initial position to your XHOME waypoint is variable, the BCO safety feature makes sure someone is monitoring the robot as it blazes a new path.
Check your documentation for explanations on BCO run
Every time this comes up it makes me wish I had free time to connect an old robot up to some open source solution and make a guide... give all these old ones a new life with fancy comms.
Open the DLL in Reflector or dotPeek and you can see a reassembled version of the source, look around for some explicit ArgumentOutOfRange throws.
I believe Reflector will also allow you to step into that method and debug it.
If you do get serial communication working, please do post the solution. I abandoned the approach after realizing that KRC1 simply does not do serial communication well. You can do everything 100% right, with the most beautifully structured serial protocol the world has ever seen, and the controller will randomly produce some kind of weird error that you don't even have the tools/commands to get around and recover from in the KRL program. It's disappointing and frustrating when you realize you can't get around things that are beyond your control. Maybe I didn't go slow enough, dunno.
IMO the best approach would be to take the things that it does do well (basically reading registers on really old industrial protocols, i.e. DeviceNet), and make the most of it. I so wish it were easier just to rip out the Kuka controller altogether and control the servo drive positions directly; to me that would make this generation of robots really fun for these types of projects. Oh well... good luck.
OK, so, having already been down this road you're about to drive on... let me offer you a not-so-objective opinion...
KRC1 is a complete pain to interface with a PC. There's a good chance you will wish you never attempted this, and wish you had spent the extra $$ on a much newer KRC4 robot. My application required control of the robot in real time by simply sending it joint angles or XYZABC positions over RS232 and let it chase it, and send me back the current position. On the PC side I'll know when the robot reaches the position by comparing target/actual. Simple enough, right? No. Not at all, a thousand times no.
The code on the robot controller isn't impossible to write (using SREAD and SWRITE). I connected a RS232 cable to a computer on top of the robot controller, then wrote a bridge that translates the serial port to TCP. Voila, KRC1 over ethernet! Not so fast, I created subprograms to read and parse the data coming across the wire. Sometimes the controller will complain about them having errors. Then you open and close them in a magical sequence and suddenly it's happy. Until you reboot it.
No problem, rewrite the program for the 43rd time to not use subprograms. Sometimes it reads data at a predictable speed. Sometimes it does not. Don't forget to include some kind of recognizable delimiter in your communication, because sometimes it only reads some of the data, and your joint position array is off by one, and suddenly you have a giant robot that pile drives itself into the floor. At this point, once that is all sorted out, when all the stars seem to be lining up, you get your program running, it receives coordinates correctly and chases them, then all of a sudden it stops reading data from the serial port and you get some weird random buffer errors that can only be cleared by restarting the program. Sometimes your "serial port handle" will get stuck open so your code will need to deal with that scenario on startup.
Now that you have a glimpse into a week of my life that I can't get back, here are the 2 strategies I can recommend:
1) Generate your KUKA programs on the PC and transfer them to the robot. You can set up file sharing in Windows 95 and connect the robot up to your network. One word here - KRC1 does not allow you to copy programs directly into its active /programs folder. You must copy it somewhere else on the C:, make sure the teach pendant is in expert mode, and copy/paste the programs into the right spot on the teach pendant, because KRC1 needs to feel special about it and compile the program as it pastes in. If you are doing some milling type work then make sure each of these files does not exceed 100k or so in size.
2) Use a PLC + DeviceNet or some other supported card in your KRC1 to transfer your position data/command via registers. KRC1 likes registers.
3) Just buy a KRC4 robot with the right control comm package and save your sanity.
Look at this client code for starters:
http://stackoverflow.com/questions/3064…-winsock-tcp-ip
You can also use telnet on your Windows machine to manually send/test commands:
telnet 1.2.3.4 29999
What language are you programming in?
It's port 29999... Some commands:
load <program.urp>
play
stop
pause
quit
shutdown
running
robotmode
get loaded program
popup <popup text>
close popup
Look up "dashboard server" in the UR3 software manual.
You can connect to the dashboard TCP port and send the following commands: (these are from memory so confirm in manual)
load /programs/my_program.urp
play
Kind of at a loss here -
KR200/KRC1. I had a program moving 100mm on the Y axis (a relative LIN movement). After recalibrating the frame (using the 3-point measurement), that 100mm is now more like 97mm.
What can cause the robot to lose the correct spatial measurement? The new frame is not much different than the null/default frame, just compensating for a surface that's not quite perfectly level.
Generally at slow speeds if you exceed ~40 lbs of force at minimum safety settings in any direction, the robot will fault. I wouldn't.
Sent from my iPhone using Tapatalk
You can assign the variables in the subprogram via a "script code" node instead of a "assignment" node and Polyscope won't warn (because it doesn't know or care what you're doing in script code).
Sent from my iPhone using Tapatalk
Standard behavior for UR. And yes, it's painful watching the robot go through its "startup" further crashing your tooling. Only alternative that I'm aware of is to remove the joint cover and manually disengage the little silver solenoid brake to allow you to free-rotate the joint out of a bad spot.
Sent from my iPhone using Tapatalk
Do you mean transferring a script file from your PC to the robot/simulator file system, or bringing the script file into your robot program once it's there?
Sent from my iPhone using Tapatalk
Yeah, we have those X11 pins jumpered but either have an I/O misconfiguration or something wrong with one of the jumps, do you know what the controller is looking at for the operator gate circuit?
Sent from my iPhone using Tapatalk