I don't think this is possible. Sorry
Posts by vmec
-
-
Maybe that movement line is throwing a minor alarm but your PLC/whatever is resetting it so fast you can't see it. I have seen this only in YRCs, not in older controllers (faster CPU). Clear the log and check it afterwards, maybe there's something there.
Check it in manual also. Go forward through it after it bugs out (INTERLOCK + FWD key).
-
Thanks massula. I'm going to try your file and report back. I did find a workaround though. It's not the most elegant solution but it works as long as the robot keeps powering off hibernating, remembering the active program.
I selected in T my main UP, wrote a routine there that checks if it was powered off and if so restarts the program from the beginning. Since the controller remembers the last active program I wrote them all in a way that they fall back to the master when I send a dedicated bit from the PLC. I have a homing subroutine at the top so I gracefully move the robot back to a safe position before executing anything else.
-
I have another question. In the VSS Operation Handbook Release 3.3 there's a chapter dedicated to setting up the CELL file (section 5.4), by means of a configuration window. It's pretty straight forward but this program doesn't work for me. Picture from the manual:
I follow the procedure or press all buttons in the window but nothing happens. Folge1 isn't added to the cell. It does detect my folge since actFolge shows 1; if I delete the folge it shows 0.
I really don't need to change between programs since this is only a main palletizing UP that branches out to smaller subprograms. Can I just bypass the cell routine? I read yesterday a thread I'm actually trying to find that discussed just this, by writing a call to your program in the SPS file. But this file looks nothing like what was shown.
Since there's no call to CELL in this SPS file I'm guessing one would need to select it first before going AUT EXT, but as I said I would rather jump all of this.
-
Changing users (modes) is under SYSTEM INFO->SECURITY.
Management mode password is all 9999s.
-
I have used a 1Gb Trascend industrial CF all this time, with a Hama converter (00055348). I format this card on win7 in fat32 and it has always worked with a NX100.
Even in a Fanuc RJ3 from early/mid 00s
-
Thanks. The oldest manual I found in that kuka portal is for a VSS 5.4, though it still shows the same setup as this one. It's what it's showing on the controller. I'm personally missing some generic signals but thread is solved.
For the record I managed to log in as expert (Key file not found). I found a working floppy drive and it worked on the controller right off the bat. There was no way to change the floppy drive letter from A: to D: (not even forcefully, using LetAssgn), but I could transfer data back and forth so I downloaded a generic CD ROM driver from here (goldstar) and the controller detected the CD drive after rebooting.
I burned the files in this thread on CD and they work on this controller. 👍
-
if this controller has a floppy disk, I presume it is a first gen VKRC2 (VKRC2 ED05, the second generation, has no CD drive or floppy. Just USB ports).
Yes, this is right. It's from 2003. I doubt I have to be in expert user mode for this but I also doubt I'm going to make this work without ever needing it. Win95 identified all the drives I plugged and found drivers for them, but they still don't show up in the explorer.
make sure you are using correct documentation for your system. see READ FIRST and get the manuals from Xpert.
if your system is VKRC then it does not run KSS, it runs VSS (special Volkswagen version of system software...) and there - some things are just different.
That's what I thought. I followed some threads here that were about this same controller but they all had dead links to manuals and other threads.
I'm currently browsing the kuka portal and seems promising. I don't remember the exact software version so I'm gonna see and report in a couple days. Thanks
-
Second hand (or third, or fourth..) robot, VKRC2 controller, CD drive not working, missing floppy drive.
I'm trying to configure the automatic external mode. I have been reading manuals for the past four hours but there's some system variables that do not exist in the configure automatic external menu.
These are the 'original' settings it had. Since the CD drive isn't working and there's no kuka cd either, I have only been able to set up devicenet so far by booting directly into Windows and editing the .ini files manually. I have taken a look at the two files that manage these system variables (config.dat and machine.dat if I remember well) but there's no trace of signals like DRIVES_ON, MOVE_ENABLE and so on.
I have no idea if it's because the controller is a VKRC2 or those pop up when you log in as expert. I have tried mounting three spare IDE drives I have laying around here and getting windows to install them, but nothing happens after it asks me to reboot. Still nothing under ARCHIVE. USB ports are disabled in this controller so I don't know what else to do to try to log in as expert.
-
Are you really writing in hex? I doubt it. What are you using to send that UDP message? I ask because 0x00020 is not 20 in decimal, it is not a 1:1 conversion.
-
Okay, it's there, thanks. Indeed, turning off the feature lets me use the output as a normal one.
Thank you both.
-
-
I ordered a DX200 with a FSU unit mounted. There's a rather complicated perimeter fence logic so the wires of the fences and barriers go directly to the FSU terminals. I need to activate a lamp but all the pins of the safety relays are occupied by the robot, so I looked up and found I could use a general output from the robot, per this manual.
So I enabled this output in the safety logic circuit, but it stops execution. Whenever the circuit triggers the pendant shows M-SAF GENERAL OUT FB DIAG. ERROR. Is this the default behavior? There's times where I need the lamp but the robot shouldn't stop working (muting, for example).
-
Adding to Reintz's, if you use RET in a program that wasn't called by another (for example, in the master job), the controller will throw a UNDEFINED RETURN JOB alarm or something like that.
-
So the procedure is:
• Disable in your office router DHCP, or enabled just a range of IPs so you can save a static IP for your robot
• Link in the router this IP to the robot's MAC address
• Set up in the router the 'port forwarding' rules, allowing incoming traffic for the robot's IP. If you are just using a web browser, the rule looks something like:
IP Address: xxx.xxx.xxx.xxx
Ports: TCP 55000 forwards to 80, 550001 forwards to 443. UDP 55000 to 80, 55001 to 443
You router has to be capable of forwarding ports to other ports.
Your whole office network only has one door to the outside, the public IP that your ISP gives you. Port forwarding sends all the traffic coming to this IP and a specific port to a local IP and a port, the ones you set in the rule. It's the port who tells the router 'this goes to computer 1 or 2'. If you forward all traffic of port 80 (websites) to your robot the rest of computers won't see any of internet.
That's why you have to use higher ports that nothing use, like 55000. Whatever sends to your router through this port will communicate directly to the robot.
• Reboot router
• Boot the robot in maintenance mode and assign it this IP in the ethernet configuration.
• Connect the robot to the router network.
• Type your public IP in your browser, and add :55000 or :550001
If this works in your office it already works everywhere, since typing your public IP makes your computer use internet. But as I said, if it's open to you it's open for everyone.
-
That's no different than doing it locally as far as the robot goes.
You just need to connect the robot to the network with an IP that does not change just for itself, and open in the router the TCP/UDP ports that the software uses for that IP. The way this works, when the router detects a petition from the outside for that particular IP and port, it lets the traffic through. If you do not set these rules the router doesn't let any traffic come by. It's actually the same procedure as 'opening the ports' for Counter Strike and World of Warcraft, you will find tons of guides if you search for those.
Mind you this literally opens your robot to the entire internet. Not just the robot but whatever device connected holding that IP, including a computer. This is probably why you heard the term VPN. In order to make it safe from the outside you either need to create a VPN or install a physical firewall connected to the router.
-
First of all you have to set up the general ethernet settings for the Ethernet/IP port, in maintenance mode. Make sure the IP is in the same subnet as your PLC, same gateway, all of that. Manual 178942-1CD
Afterwards you have to set the E/IP settings - data size, whether it's adapter or scanner - that's the manual I attached 178651-1CD. Everything is explained there, starting from page 20.
When you have set up all of that, you have to restart and go into maintenace mode again, and extract the E/IP .eds file. This is in the manual too. This is the file your PLC is going to ask for to establish the connection. You will have to import it into your project, but you will also need to create in your PLC some kind of struct of data to hold all the bytes you are going to read/write. You will need to asign the E/IP tags to this data.
From the PLC you can monitor the Ethernet/IP connection in real time; it is going to tell you exactly what's working and what's not. You can just go step by step and debug easily, whether your connection is OK or not and whether you have set up your tags correctly or not.
I recommend you to fill the form on this site and download anything you need. For this you only need these two manuals but all of them are inside.
motoman.com/en-us/service-training/product-documentation
-
I doubt you can't get it any better than a FOR or WHILE statement. They are not fixed, you can nest, you can use variables and, most importantly, you can write inside whatever you want.
-
Can you program it manually? From defined P variable to another defined P variable with a MOVL. Test whether it is the controller or the program.
You have many points for that straight line so maybe it's drawing a spline.
-
You were right. I tested an empty job with an IMOV and it does restart after an emergency stop. You can do it indefinitely and the robot will just keep moving. Big oversight.
I managed to keep the macro functionality with a MOVL anyway, although the macro wouldn't show in the instruction list if I used a LP argument (?). Had to use a P, but it all works safely now.