[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:
Controllers:
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)
172.21.3.51----CX-----17.0 C2--------Quattro s650
172.21.3.75----CX-----17.0 C3--------Python XYZT
172.21.3.77----CX-----17.0 A4--------Cobra s350
172.21.3.79----CX-----17.0 A5--------Viper s650, Cobra s600
172.21.3.81----CX-----16.4 D---------Cobra s600
172.21.3.84----CX-----16.4 C6--------Cobra s600
172.21.3.85----CS-----16.3 C2--------Cobra s600
172.21.3.106---CX-----16.4 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.

PC:
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.

Software:
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.

Results:
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
debug+3d.jpg (13.16 KiB) Viewed 8512 times
debug-3d.jpg
debug-3d.jpg (15.3 KiB) Viewed 8512 times

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


Conclusions:
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.
TravisA
 

Return to ACE PackXpert

Who is online

Users browsing this forum: No registered users and 1 guest