I tried cutting and pasting some older unused programs into a folder today (New UR user). I found that once I did that it was giving me an tool error with me hitting cancel. However the files moved into the folder and I started getting an error. Suppressing the error in my program seemed to have solved the problem until I restarted the robot. Once it restarted I found that my programs would no longer work. I am now getting the error shown in this picture.
Does anyone know how I can fix this? My production line is down now.
As a URCap developer myself, I can Tell you that there is deffinatly a bug within the URCap it self.
I would suggest you contact TripleA Robotics, and ask for an updated version of your URCap, or guidance about how to work around the bug.
Do Provide the stack trace like you did here to TripleA too
Kind Regards
Side Note: What the error is telling you is basically that it is dependent on a value that has not been defined yet, which value we unfortunately cannot see. So you could try to simply reenter all the data in every input field, in the urcap nodes and in its installation too.
We noticed there’s been a bug since some version of the AAA tool changer if you are using Imperial instead of Metric. They aren’t handling that bit of localization properly and it throws the null pointer. Overall I wasn’t super impressed with AAA’s approach to tool changing, so I just wrote my own tool changing CAP.
And then it’s one line of code in the program to get/put the tool. I hated the way AAA inserts like a hundred lines of code you aren’t supposed to edit every time you want to interact with the changer. And the way you have to go about loading tools between subprograms is beyond clunky. Their physical product is fine, but the software is… just not good.
I actually had a talk with the inventor and owner of TripleA once, years ago, about exactly this.
Turns out, the software work the way it does because of a unique requirement.
That is he wanted his tool change system to work without the URCap permanently installed. In an effort to ensure that his system works no matter what else is installed on the Robot.
By creating all the script lines nessesary individually, you can the copy paste it outside of the URCap program node, uninstall the URCap, delete the undefined program nodes from the urcap and everything will still run.
I personally also would prefer the URCap to work in a different manner. But this at least should give some context to why the URCap works as it does.
Eh. Always love to hear the method to the madness but I’m really gonna stick to my guns here and say I think he just designed himself out of a viable product.
His hardware ALREADY can be used without a CAP installed AT ALL. Just write a program that does the changing and call it as a subroutine. His CAP actually makes this HARDER to accomplish because of the issues stemming from Copy/Paste, various nullpointers, and making things happen in the generateScript method, which is pretty obscure for the average user.
The point of the URCap is to SIMPLIFY certain processes. If your tool changer can run without your CAP then just…don’t make a CAP Definitely don’t make it HARDER. Before I wrote the CAP we use today, we just didn’t use the AAA CAP. It’s easier to just write your own get/put programs and call them as subs. Sounds like he took a niche use case and designed his entire software around that. The 10% rule I guess.
Yeah , I am not really trying to defend the choice he made.
But with the requirement of a URCap that should manly exist as a tool to help setting up everything in an easy manner, which output must be capable of running with the URCap unistalled.
I can definitely see how the URCap ended up the way it is today.
I also think I somewhat understands his thought process as he is selling a toolchanger system, it will, most likely, be installed along side other URCaps in 90% of the cases.
So I get why he would want it to have an option that is guarantied to never interfere with other URCaps, as his tool is an add-on, and not the main functionality.
But when that has been said, I do agree that the URCap created within these strict requirement resulted in a user-friendliness that isn’t the best and confusing at times.
And that the amount of cases where his URCap would interfere with another, would properly be extremely low if design with that in mind.
And just like you said this has resulted in some software that is less then ideal for most of his customers, but perfect only for a tiny fraction of them.
