Device Task Uploading

Currently offline programming capabilities are applicable to Robot Tasks only. In practice, though rarely, robot controllers are not only used to control robots, but also non-robotic programmable devices. If a robot rail is not integrated with the robot, but it is a separate programmable, move-by-joints device, operated by the different robot controller as the rest of the robot axes.

To account for special cases like the previous, Device Tasks should also be authorized for both upload and download.

This introduces roundloading of Device Tasks to V5 OLP. Device Tasks will be uploaded and downloaded in the same way Robot Tasks are, since they are not fundamentally different from the Robot Tasks (after all, robots are nothing else then devices with inverse kinematics ability). From user's perspective, the only change is that in V5 OLP the user can now select Robot Task or Device Task to be uploaded or downloaded, and that Device Tasks are restricted (not by OLP, but by their infrastructure) to having two activity types only: "DelayActivity" and "MoveHomeActivity".
 
 

Robot languages in general may be used to program not only robots (devices with inverse kinematics), but forward kinematics devices as well. In general terms, based on usage of controller capabilities, programmable devices utilize just a sub-set of controller instructions. Following that concept, offline programming paradigm is equally applicable to devices as it is to robots.

Along those lines, device tasks can only have two authorized children activities: robot motion and delay activity, which are both supported by robot tasks. Therefore, from the OLP perspective, downloading or uploading a process from or to robot task or device task, makes no difference. Thus, the decision has been made to handle roundload of device tasks through the same commands used for upload and download of robot tasks.

From the user's perspective this enhancement will be transparent, since there is no change in GUI, or the way Upload and Download commands work. The only two important things to remember are that Device Tasks are restricted to containing only two different activity types: "DelayActivity" and "MoveHomeActivity", and wherever Robot Tasks were selectable during execution of Upload and Download commands, now Device Tasks will be valid selections as well.

Changes made to XML schema for device tasks:

Tasks, assuming that the number of activities in both cases is the same, in reality, in most cases, number of activities in Device Tasks will be lower then in case of Robot Tasks, hence the OLP performance will be better.

Trying to upload any activities that have their types different then "DelayActivity" and "MoveHomeActivity" will not result in creation of corresponding activities in PPR tree.