Posts by BluesMatt

I have never used WoV 3.1.8. However, I have spent a lot of time using 3.1.7 build 17. If you have access to that version, you might want to try it. I have found that different versions of WoV behave differently.

Perhaps I am preaching to the choir but I have spent hours fighting with WoV. If you are working with a new robot that is still under warranty, I would suggest contacting the KUKA hotline. In my experience, solving WoV problems have often times been a mysterious challenge and can be a major time sucker.

If you are on your own, all of the KOP's that are needed for your WoV project should be on the D drive of the controller. Keep in mind that the KOP version number used in your WoV project must match what is installed on the controller.

If you are programming using the in-line forms on the SmartPad, there is a drop down box called "orientation control" (under CPDAT#) that provides 3 choices; "standard", "wrist PTP", and "constant orientation". I typically select "wrist PTP" for all of the circular moves. In the past, I may have also used "constant orientation".

I believe you can also hard code the system variables in your program before making the move (I have done this in the past also.)

Now, I prefer to use the drop down menu because it gets me going faster.

Hope this helps.

What version of Workvisual are you using? What version of KSS is on the controller? Are you using other KOP's in the project?

Yes, if one of the robots stops for some reason (i.e. arc start failure), the others will continue to run their own programs. Only when a PROGSYNC command is reached, will all of the robots need to be at the correct locations. If the arc start failure robot is still not running, then the others will wind up waiting forever.

So this brings up an interesting point, only use a PROGSYNC command when you need to (to say, avoid robot to robot collisions).

So here's a question for you: Will there be an operator at all times supervising the robots (to take care of arc start failures for example) or will you be using stack lights to show the shop floor supervisor the status of the robots?

There are several ways to use Roboteam and weld. Last year, we completed a mig welding system using 2 robots and Roboteam. We employed the simplest way to use Roboteam; we used the PROGSYNC command. The way this works is that you program each robot separately at whatever speed they need to run. Since I understood you to say that the external positioner will NOT be moving while welding, each robot is therefore free to weld at whatever speed is needed for the joints each is welding.

When you come to a place in either robot's program where you want to verify where the other robot physically is in space before continuing, you use a PROGSYNC command. Basically, this command uses a uniquely named position that each robot knows about and must both be at before either robot can continue moving.

Using this approach, it is important to understand that the robots are NOT speed synchronized and they also do NOT know where the other is in space (that's up to the programmer to know). However, using the PROGSYNC command, you can verify where each robot is in the program it is running. If one robot gets to a particular PROGSYNC command before the other, then that robot will sit and wait (not move) until the other robot catches up.

In the end, we found that even using Roboteam in this fashion was probably overkill. We probably could have used a series of digital I/O signals between the 2 robots to establish "communication" and allow the programmer to know where each is in the programs that are running.

Hope this helps.

As an update, a KUKA applications engineer went to the customer to look at the slow SmartPad. He updated the KSS. After the update, I was told the SmartPad slowness went away.

Thanks Panic Mode.

I sounds like you have gone through this process several times. My question is: is all the trouble worth it or is it smarter to purchase the robot with the additional axis already setup and configured? Some people here believe it would be cheaper to do all of this ourselves. I'm not convinced; that's why I ask.

Has anyone integrated a non-KUKA MGU with a KUKA controller?

I really have no idea how to do this. I understand that the controller cabinet would need to be wired to accept the additional axis. The appropriate connecting cables would need to be made (or purchased). And then the kinematic system needs to be updated to include the added axis (using WoV I guess). And then somehow (maybe within WoV), the controller has to understand how many encoder counts to expect when the motor spins around once (also done within WoV). Is that it or is there more that needs to be done?

Try declaring a different INT using a different name. Does that work?

Here's a stupid question.....with such an old version of KSS, why are you using the newest WorkVisual? Is it possible to update the KSS?

Not that they need me to say so, but Panic mode and skyfire are correct. I ran into this problem several times on different robots before I finally remembered that I need to go into Safety Config and approve the change. When I have done this, the check sum errors have always gone away.

I always use the USB connections on the front of the controller with a USB drive. I use the USB port on the SmartPad for a wireless keyboard/mouse.

I make it a habit to change the name of the WoV project after making changes before re-deploying. This makes it very easy to see which project is running. By tapping the WoV symbol on the left side of the SmartPad, I can verify which version of the project is running.

All fixed. I was able to get the file via an email link. Thanks OrangeApps for the quick response!

Thanks for the replies.

When I open the attached link, I receive an "Gateway Anti-Virus Alert" (MalUAgent.MIP (Trojan)) message. I'm not sure if this means there is a virus attached to this link or if there is something in my machine that is triggering this alert or if it is a false alarm.

I did a full system scan and came up clean, but I've seen virus scanners miss things before. So I'm not sure.

I will try contacting you via email to get the file. thanks

Hello all.

I'm trying to download the latest version of OrangeEdit from their website (my current installation has expired) but for some reason, the file won't download. I've tried contacting them directly with no response.

As background, I am an admin on my laptop and I do have a working internet connection. Has anyone else had a similar issue?

Hey everyone.

We have a customer running Roboteam with 2 robots and KRC4 controllers. This setup shares one SmartPad between the 2 controllers. The customer states that the SmartPad response while programming welding commands (ArcTech) can slow way down almost to the point where the SmartPad is not usable after programming for a while. I don't have any other details and I have never seen this problem on their system.

With a controller reboot, the SmartPad response returns to normal but eventually returns to being slow.

Has anyone else experienced this? To me, this screams memory management issue with Windows/KSS but I'm not sure.

I am also understanding that all programs in the R1 folder are automatically loaded into memory whether the user wants to run them or not. Is this your understanding as well?

Has anyone else here worked with Roboteam? What was your experience like?

thanks

Changing code while in "select" mode confused me for quite a while. What I finally came to understand is that if you are typing in a change that requires 2 separate lines to finish (like LOOP/ENDLOOP) while you are in "select" mode, once you finish entering in the first line (LOOP), the program will recompile generating an error (because you haven't entered the 2nd line like ENDLOOP). So if your edits are confined to 1 line, I find that I can make them in "select" mode. If I need more than 1 line to finish the change, then I cancel the program, open it in "open" mode, make the edit, close the editor (which recompiles the code), and then re-open in "select" mode (if there were no errors), and run it again.

Could the Advance Run Pointer be causing the issue?

Can you edit the program into even smaller sub-programs? Load each smaller sub-program one at a time into the editor and see if it compiles without errors. Once all of the sub-programs compile without errors, try loading the entire program. If that doesn't work, what is the error message? If you can't load the entire program (with all of the error free sub-programs), comment out all of the subs and try loading again. If that works, remove the comment character for the first sub program and load again. If that works, keep removing the comment character in front of each sub-program call one at a time reloading each time until you run into an error. What's the error message?

There is a memory limit for programs but it hard to know what the limit is and how close you might be to it.

These programs sound very large. What are you doing with so much code?