Messages

Hello Rafael,

I should have worked through my eMails in the other direction ;)

Best,
Johannes

Hello Rafael,

I'm sorry for the late reply, I just came back from my holiday!
To read the XML files you need a custom Java library that we provide to members.
I'll send it to you once I'm back in the office.

Best,
Johannes

Just to be on the safe side, are you 100% sure that the XYZABC values match between simulation and the robot? I.e. you are not using a template tool, but a Custom Tool with (more or less) exactly the same XYZABC values as you calibrated at the robot?

Best,
Johannes

Hello,

It took me a bit to unlock your post, as I'm currently out of the office - sorry for that!
You've got three planes for the CIRC movement - can you quickly test if you get the same XYZABC values in the SRC file for both LIN and CIRC movements? And if so, check if the robot moves differently (except the interpolation being linear/circular, of course)?

Please let me know how it works out!
Best,
Johannes

Hello,

First the disclaimer that I'm not really a milling expert. But basically a larger tool will rotate "faster" on the outside, so you may be able to get similar finishes by adjusting the rotation speed of the tool. Also the number of teeth makes quite a difference when milling foam, where you generally want to prevent it from becoming so hot that the foam melts, i.e. by using less teeth.

Best,
Johannes

Hello,

The rotary table component is only available in the member version. Are you a member through your institution? In that case I can unlock the account for you.
Basically you plug your robot into the rotary table component, and then the output of the rotary table into the Core component.
To program external axis values, you can right-click movement components and select the option to show the additional inputs.

Let me know if that helps, if you still have problems I can throw together an example once I'm back at the office.

Best,
Johannes

Hello Pete,

I've very quickly thrown something together which seems to work - the transformation is due to KUKA|prc's tool axis.
You can get the XYZABC values from the panel at the end - and double-check that I didn't make a mistake. At least with a base, any errors should be immediately visible in the simulation!

Best,
Johannes

Hello Yuan,

If the robot is doing something different than it is supposed to do (from the simulation) or if it is only showing an axis limit when you start the file, then most likely you are not using the same tools and bases in reality & simulation. See the sticky post: http://forum.robotsinarchitecture.org/index.php/topic,115.0.html
If the robot has got a problem with the file, then you will get an error message, telling you which line is causing issues. This would be very helpful!
In any case, you do not need a *.dat file for KUKA|prc, it's all inside the *.src file.

If you can provide some more information on the error message / problematic lines of code, I'm confident that we can get it to work!
Best,
Johannes

Hello,

Yes, the Analysis component would be the way to go as it gives you all the values, and now also the index of the currently displayed position.
I can give you some pointers if you run into a specific issues.

Best,
Johannes

Well, fixed IPs unless both your PC and the robot get the IP from a router/DHCP.
And yes, everything regarding networking that goes beyond "plug-it-in" and "enter key" is indeed quickly getting rather arcane...!
Best,
Johannes

Hello,

The idea is that not everyone who is in the same phyiscal network as you should be able to access your shared files. In order to do so, you need to be in the same IP-range (e.g. go into the TCP/IP settings of your PC and assign it a static IP that is close to the one of your robot, e.g. if the robot is 172.31.1.147, then set the IP of your PC to 172.31.1.150 - do not change any network settings on the robot side, that probably won't end well), the same workgroup (I believe the default is just WORKGROUP), and in most cases the other side has to authenticate itself somehow. In my experience with both Windows 95/XP (KRC2) and XP/7 (KRC4) creating a new user is the easiest way to get the login-data.
When you share a folder, make sure that your newly created user gets full read/write rights.
On your PC, go into the Windows explorer and enter the IP of the robot in the address-field on top, e.g. as \\172.31.1.147 which would be the default IP.
Then it should prompt you for credentials, and you enter your username and password. Finally the files will show up.

If you require support on that, you don't need a robot engineer, but just someone with Windows networking knowledge!

Best,
Johannes

Hello,

Did you test it with Notepad++, is the *.src file refreshing?
If not, please send me your GH file, just so I can take a look at it.
You can maybe try starting Rhino with administrator privileges (via right-clicking the shortcut) to rule some more issues out.

I don't believe that it's an issue with your Windows, so re-installing everything probably won't change anything.

Best,
Johannes

Hello,

If there is no movement in-between, you won't see the effect of the toolchange. This is why it's going straight from the first to the last!

Best,
Johannes

Hello,

In general I would advise against changing anything regarding T1. It's probably fine if you are the only user, but if anyone works with the robot, they have got certain expectation of T1-velocities.
For this reason I've never changed it before, but the manual shows some variables like $RED_T1 which is apparently the reduction factor in percent (integer).

Best,
Johannes

Hello,

I've tested all the inputs and it always refreshed, so it seems to be working. I checked it by opening the file in Notepad++. It will provide you with a message if the file is refreshed while you had it open. Maybe just the Windows "date changed" is causing issues?
I might have some more ideas, please keep me updated.

One last thing: You should use ReduceMesh to reduce the complexity of the tool, it slows Grasshopper down quite a lot.
Best,
Johannes