Error with external tool frames?
I defined an external tool and move with a gripper to it, switch to that tool and like to jog around that tool with the center of orientation of the tcp of course. This does not work, the tcp used is that of the gripper. And when I teach a target with this external tool selected, I don't get a configuration for it (the configurations dialogue is completely empty), which makes this target useless. Instead in FlexPendant I get an error msg like tool changed (something like #20127 or 20128 afaik), but I didn't changed anything. It works when I switch to the gripper as the active tool, but then I don't have the correct orientation of course.
This seems to me that the calculation chain from the gripper over robot base over station world to the external tool frame is broken somewhere. The above only is with external tools (to be precise: tools, that aren't hold by the robot). So here are my questions:
1. Is this an error or am I too dumb?
2. Is there any other way to get an orientation around an external tool tcp (as far as I tested: No)
3. When will there be a version of RS (and RobotWare as I imagine) where this will work correctly? (which means how fast can I get my hands on)
I'm with 5.016.1560.158.
All the best,
LohengrinLohengrin38720,7029513889
Lohengrin
Comments
-
Hi Lohengrin,
The problem with jogging around an external tool is a known problem that will be corrected in the next RS version. The next RS version is planned to be released in quarter one this year. A workaround in the meantime is to use the VirtualFlexpendant for jogging.
Your problem with no configuration can I not reproduce, and we don't have any reported problems with that.
Best regards,
Anders Spaak
ABB Robotics0 -
Hi Anders,
teach a new point with an active external tool where you can't jog around and you'll get no configuration for that point at least in RS. The config dialogue box is simply empty. When you change the tool to an attached one, then you'll get a config.
I will try to jog and teach with an external tool with the FlexPendant and tell you how it works later.
Right now I have another problem with VC who f**ked all of my newly created signals because of a parser error. I hadn't backed up yet, but restarted first. No good choice, so let's start again from scratch. :-(
Again not too amused,
Lohengrin
P.S. RS is still very young and I would like to have faster updates in shorter time frames until it is stable enuff and production safe. Then a new update every 3 months is ok, but not right now. I'm walking on very thin ice here, because a customer chose to take IRC 5 despite everybody warned him because it might not ready for prime time yet. I don't talk about beta, but we'll see how it'll work in practice when the robots are delivered. With this kind of problems that cost so much time already in offline programming I'm not too convinced. Only my personal opinion.
BTW: Getting signals into the controller is a real pain. Always opening the dialog box and hacking in the data. What about importing a textfile with all data in RS-Online, of course in XML? Then I wouldn't have to hack in again all the stuff I have lost now, and that was 3 hours work. With XML we could do all signal stuff in a database and then export it and import it into the controller.Lohengrin38724,8618518518All the best,
Lohengrin0 -
Dear Lohengrin,
Thanks for your feedback! It's valuable to us all.
In the next version you will be able to jog in external TCP coordinates in a more correct way than today. I can't reproduce the problems you have with configuration on targets teached with an external TCP. Could you send us a station where you have these problems?
Regarding the problems with IOs I was wondering under what circumstances the error appeared.
- Where/How did you create your signals (RSO, TeachPendant or by loading an IO.cfg file)?
- In which product did the error appear?
- What caused the error? Exactly what were you doing at that time?We have noted your request for more frequent updates and we are discussing it internally, but we have no plans for this in the near future.
You can edit your signals in a separate configuration file (.cfg) that you later can load into the controller. Create a backup of your controller and locate IO.cfg file to get a feel for the syntax.
Kind Regards
FredrikFredrik Syr?n
Program Manager
ABB Automation Technologies0 -
Hej Fredrik,
-I could send you a station file, but it's 85 MB big. In this station I have no problem reproducing the error with the missing configs as I described above. If you don`t need more than the station file then gimme ftp and I'll up it.
-The problems with the IOs happened again and I also found a workaround, which I will describe exactly now:
In RSO I created a bunch of signals. Then I created some System Inputs and System Outputs with some of these signals. I did a (warm) restart (in RSO) of the controller and everything was fine. Then I created even more signals, and stepped over some signals which names I misspelled, and changed them. After a new restart the controller halted because of a system error, because the signals I changed were linked to some of the system signals, and of course they didn't work anymore and caused the system error. From RS I got into FlexPendant (I got no connection with RSO anymore) to change this now wrong system signals, but when doing this with one system signal, the controller forces me to do an immediate restart, what I did. It restarted again with a system error, because there have been more than one changed signals and corresponding system signals. This second time I didn't got into FP anymore, nor into RSO.
The workaround was that I removed the system from the station, connected to the controller again with a cold start, which of course erased all of my signals.
I had this again the last days, but now I do a backup before doing restarts after signal changes or additions. After the cold start the restore of this backup works flawless and I can change the signals that caused the system error.
So it seems that the signal parser doesn't look at maybe linked system signals when changing signal names.
-I know that I can import that IO.cfg (here it is EIO.CFG in SYSPAR), but only from a backup that I did first. So there is no direct import option in RSO or anywhere else, which I miss. And the format of the cfg is not really conformant to something I can get out of e.g. a database, where I preferrably like to maintain my signals for different projects. So here I think an open format to explicitly import into the controller like XML would be fine. I didn't tried to remove blank lines in the EIO.CFG while directly editing signals there or other reformatting to make it better editable, because I simply don't have the time to test stuff like that right now.
It works with backup, editing and restoring, but this is a way which is not obvious and might not be automated. An explicit import option for config files, be it only for signals, would be obvious.
Thanks for all your help and responsiveness, I try to do my best to tell you what problems I face here and how to reproduce them, but right now this particular project I do here does not give me too much time for it right now. I am of course also interested in getting better versions of your all-in-all great and from all robot manufacturers most advanced controller-, offline- and simulation software, but our customers are interested in results, and not programmers problems nor -dreams. And right now it's of no use for me when you know this problems, but I have to stick for months with the current versions and have to develop workarounds for every problem in this case of tough time pressure. So please understand my frustration sometimes and don't understand me wrong - RS+ is a really cool piece of software.
Hej da,
LohengrinLohengrin38728,7685185185All the best,
Lohengrin0 -
Hallo Lohengrin,
I was wondering if you perhaps could make the station somewhat lighter (by deleting "unnecessary" parts) and then zip and mail it to me?
I will investigate and try to reproduce the IO problem.
You know that you can load a separate .cfg file into the controller (without having to do a restore)!?
I fully understand your position, no question about that, and you can rest assured that we will do what we can to improve your situation. Thank you for your patience and also for the positive feedback.
Kind Regards
FredrikFredrik Syr?n
Program Manager
ABB Automation Technologies0 -
Hi Fredrik,
I deleted all the unneeded stuff in the file, so compressed it is around 150k. Do you also need the system?
I read now how I can import cfg-files into the controller. This is still not what I expect, but gets into the direction, so thanks for the hint.
All the best,
Lohengrin
All the best,
Lohengrin0 -
Hi Lohengrin,
It would be great if you could include the system as well.
Kind Regards
FredrikFredrik Syr?n
Program Manager
ABB Automation Technologies0 -
Hi Fredrik,
I prepared an email with the data you need, so pls give me a valid email address of yours (look also in pm).
All the best,
LohengrinAll the best,
Lohengrin0
Categories
- All Categories
- 5.5K RobotStudio
- 396 UpFeed
- 18 Tutorials
- 13 RobotApps
- 297 PowerPacs
- 405 RobotStudio S4
- 1.8K Developer Tools
- 249 ScreenMaker
- 2.7K Robot Controller
- 310 IRC5
- 59 OmniCore
- 7 RCS (Realistic Controller Simulation)
- 786 RAPID Programming
- AppStudio
- 3 RobotStudio AR Viewer
- 18 Wizard Easy Programming
- 105 Collaborative Robots
- 5 Job listings