[TestReport] multiple robots/controllers in static form

Information and discussion regarding the ACE PackXpert software

[TestReport] multiple robots/controllers in static form

Postby TravisA » Wed Apr 16, 2008 11:00 am

This describes a test performed in Livermore March 2008. The test involves 9 robots on 8 controllers, each robot is performing a process picking static Parts and placing at static Targets. The intent is to determine the capability of Adept Packaging Manager to allocate parts to multiple robots, and witness the processor loading to do so.
Test Setup:
In total 8 controllers and 9 robots were used. Various versions of V+ existed on these controllers, and a variety of robots were configured:

Ip Address-----type-----V+ Version-----Robot(s) C2--------Quattro s650 C3--------Python XYZT A4--------Cobra s350 A5--------Viper s650, Cobra s600 D---------Cobra s600 C6--------Cobra s600 C2--------Cobra s600 C6--------Cobra s350

The controllers were spread around the lab. In order to connect them all, two different Netgear 10/100 Fast Ethernet Switches were used. 6 of the controllers were connected to one switch, and from there to the wall. The PC and the other 2 controllers were connected to a different switch and to the wall. This means a lot of the data was travelling through the corporate network.

The PC is a standard Windows XP machine of moderate speed. The processor is an Intel Pentium 4 3.0Ghz CPU, and the machine has 1GB PC3200 RAM memory.

Each robot was set up with a process utilizing a static part and static target. The pick and place locations were taught typically about 50-100 mm apart.
All processes were run from a single Packaging Manager object. This object would be sending each part and target down to the individual controllers.

ACE was run from Visual Studio Express. To test the various execution methods, it was launched in “Debug” mode and “Release” mode without the debugger, and the CPU Usage tracked (below). In addition, I measured the usage while displaying the “3D Visualization” window and without it.

All robots would run successfully, and at relatively high speeds. A few issues to note:
In cases where I ran the robots at very high speed some delays could occasionally be seen. Example: Part and target locations very close together. No break at either location. Short approach/depart heights (10mm). High accelerations (250 on Cobra s600). On some of the depart motions (approx. 1 out of 3) there would be a very slight delay before it moved on to the next location. This is related to the PC sending each individual part information down to the robot.
The intent of this test was not to examine the maximum parts per minute with static part/target processes, so I did not spend a great deal of time examining this. That test will come later. It should be noted that belt-fed parts and pallets will have a higher maximum ppm due to the parts being queued up.

CPU Usage:
Running from Visual Studio in Debug mode, 3D Visualization on, then turned off
debug+3d.jpg (13.16 KiB) Viewed 9358 times
debug-3d.jpg (15.3 KiB) Viewed 9358 times

Running from Visual Studio in Release mode, 3D Visualization on, then turned off
release+3d.jpg (13.58 KiB) Viewed 9359 times
release-3d.jpg (15.29 KiB) Viewed 9359 times

From this we can reasonably say that managing part allocation alone is not a significant load on the CPU for the PC running the Packaging Manager Server and Client tasks. Additionally, the system is robust when dealing with network traffic and is not likely to be significantly impacted by general usage. A "flood" event has not been tested, where network traffic is massive.

Return to ACE PackXpert

Who is online

Users browsing this forum: No registered users and 1 guest