dyBOT: CAD/CAM to robot software description

    Q & A    S u m m a r y :

   1. What does this program do?
   2. I have a robot manipulating parts. Do I need dyBOT?
   3. If my robot already calculates Cartesian movement, why should I need dyBOT?
   4. Just great, but between you and me, what are the drawbacks?
   5. My robots are always building the same part. ... Why should I care about designing time?
   6. Who can use dyBOT?
   7. What will I find in the manual?
   8. What will I NOT find in the manual?
   9. How can I start doing something productive QUICKLY?
10. What CAD systems does dyBOT support?
11. What output does it generate?
12. Can I use dyBOT to edit joint movement?
13. If dyBOT always writes joint movement, how can you say it does Cartesian movement?
14. Can I create my own robots from scratch?
15. Could I build a robot with dyBOT and a PC-based linear 6 axes motion controller?
16. Can I write applications inside it?

This Q&A may use some robot specific language. If you are not familiar with such terms as Joint Movement, Tool Coordinates, etc. see this Glossary extracted from dyBOT's manual.

1. What does this program do?

    This program imports and edits trajectories that are intended to be followed by a robot. These trajectories are either cutting paths, welding paths or milling paths. They can be imported from a CAD system or designed in dyBOT, either from scratch or copying an imported part.
    dyBOT includes trajectory management functions such as optimization, or more advanced: teach-in, reorbiting, tool aligning, toolholder definition based on the attainable robot solution. It's CAD-style edition functions (erase, copy, move, scale, rotate) were conceived as an answer to basic requirements such as: placing inside a housing, scaling, making multiple parts, etc. dyBOT should be viewed as a complement of your main CAD system, not as a replacement for it.
    Besides trajectory edition and creation functions, dyBOT processes the trajectory, finds optimal robot solutions for all its points, solves the movement involved between points, and generates a file that is "ready to play" written in your robot's file format. It includes all the necessary I/O commands for: water-jet cutting, arc-welding, speed-driven laser cutting or whatever equipment is mounted on the robot.

To the top
2. I have a robot manipulating parts. Do I need dyBOT?

No. dyBOT is not intended to be used in manipulation environments. It basically handles Cartesian movement for applications such as cutting and welding.

To the top
3. If my robot already calculates Cartesian movement, why should I need dyBOT?

    This is certainly THE question.
    The advantage of computer-based systems is far from obvious to those who don't use them, as it could have been years ago if we had to compare CAD-drawing with hand-drawing. This comparison seems badly chosen because, a robot IS a high tech product and IS itself computer-based. But we still insist, read the following and you will see this is not an exaggeration, many situations are really analogous:
    a) On the robot, no matter what tool compensation functions are implemented, if you change an important parameter (for instance, tool length, not to mention the robot itself), in practice, you have to redo everything from scratch. And this happens every time you change it! (This is why you simply never change things that you would have changed if you had a more flexible tool.) With dyBOT redefining such things is a trivial and automatic task.
    b) The robot is hopeless to solve motion on alignments and other situations such as joint limits. This is NOT due to any malfunction and does NOT depend on the robot manufacturer. The robot only works with its current point (not just a possible solution, but the physical position of all the joints of your machine) plus the point where it is told to go. A problem whose solution requires having done things an other way some steps before, is simply impossible to be solved by a robot. These problems can be solved (even trivially) by a computer, since the computer always works with the whole problem.
    In the computer everything may be changed until everything is solved.
    Besides, the computer has much more information than the robot: What is and what is not important? Can roll be changed to improve access? Are some possible solutions preferred (or banned) by the user? What clauses have to be checked to know if something is colliding? etc.
    c) Even in the questionable case someone claims: "It is faster to teach-in directly on the robot than on a computer", this can only be due to very different practice levels on both systems. With some practice (please, download and check this by yourself) teaching movement on the computer is not only much faster, but it is also much safer and much less expensive.
    Other reasons to use dyBOT (and here we see again that our initial talk about a quantum leap from pre computer era to computer era has sense) are:
    d) Work organization. You could certainly store your old robot programs and organize them as a "working base". But, an ordinary, robot dependent, teach-in program is just an uncomprehensive list of coordinates that can only be replayed as they are. In contrast, dyBOT projects can be: Viewed graphically, easily modified, partially copied and pasted as part of new projects, etc. (In short, they are CAD files.)
    e) Robot independence. If you have different robot models, you are no longer restricted to build every part with the robot in which it was taught-in. You can change your robots with a minimum effort to follow your production demands.
    f) And (neither last nor least) QUALITY. You parts are built according to your customers specifications directly in CAD/CAM format. I.e. precisely, not just "under the watchful eye of the expert", as it is the case in "physical" teach-in.

To the top
4. Just great, but between you and me, what are the drawbacks?

    Only two drawbacks apply to some robots:
        a) You can easily outrun most robots memory capacities. This remembers the times when milling machines had 32 K main RAM because they were not running computer-generated programs. Nowadays, the average robot may have 512 K. This seems much for manual teach-in, but it certainly is limiting the complexity of what can be done when linked to a computer.
        b) Some robots get slow because they make pleistocenic assumptions about what the minimum time for a movement is. If your robot causes a syntax error for a movement under 0.1 sec, (even if this can be corrected by the software), it is limiting either cutting speed or precision.
    Robots will have to evolve to suit the needs of being computer-driven. They do not need to do calculations that can be done (even better) by computers, but they must have : Fast communications, big memory sizes and fast speed.

To the top
5. My robots are always building (cutting) the same part. I change the design once a year or less frequently. Why should I care about designing time for the new part?

You are right. Not everybody needs a productive design tool.

To the top
6. Who can use dyBOT?

     There are three types of dyBOT users:
    a) Final users are those who use it to produce parts on a machine (robot + accessories) that was built by third parts.
    b) Equipment manufacturers build equipment and want to configure the program to work with it. Once tested, equipment definitions are saved as: housing definitions (.vHO), robot definitions (.vBT) or toolholder definitions (.vTH).
    c) Programmers who want to use:
        c1) the object oriented mathematical kernel:
              (BotObj -> BotSolution -> BotBlocks -> BotCollisions -> BotDynamics, etc.)
        c2) the graphical UI, menus, toolbars, etc.
        c3) the high standardization (input file filters and drivers for major robot manufacturers)
&
        c4) the industrial experience
    .. that are behind dyBOT to develop software that specializes on their application. This avoids "reinventing the wheel" and allows programmers to concentrate on the valuable part of their development or integration. dyBOT can be used as an OLE2 automation server that serves applications written in popular programming languages that create OLE2 clients: Microsoft-VisualBasic, Borland-Delphi or Microsoft-VisualC.

To the top
7. What will I find in the manual?

    If you are a final user who has some basic 3D-CAD knowledge the manual is all you need. It covers:
    a) Q&A (this)
    b) Glossary
    c) Fundamentals of: edition, teach-in and processing
    d) A tutorial example of a complete part
    e) The full reference of all the commands
    f) A customization guide
    You have to read everything from a) to c) (it is not much) and practice the tutorial example with the program. It is useless to read it, if you don't practice it. You can leave the full reference to be consulted later if you have some doubts.
    Equipment manufacturers can read from a) to c) to understand dyBOT's fundamentals and then read the customization guide.
    Programmers can read from a) to c) to get some knowledge of the product, but they require a fully different product with a fully different set of manuals called "OLE2 server version of dyBOT". At the time this was written (Feb. 2000) it is still under development, expected for Fall this year.

To the top
8. What will I NOT find in the manual?

    Two things:
    You will NOT find basic computer or CAD issues (What is a file? What is a mouse? What is a spline?)
    You will NOT find any robot model specific information.
    You may find such information in files with names like !read-f.txt for Fanuc, !read-f.txt (for Stäubli (Adept)) and so on, that are installed with your robot definitions.

To the top
9. How can I start doing something productive QUICKLY?

    Download dyBOT at this site.
    As mentioned above: Read this Q&A, the Glossary and the Fundamentals in full, then PRACTICE the tutorial part. When you have done so, process it using one of the predefined robots. Once you have succeeded, try it with your own parts.
    If you experience any problems doing this, try the troubleshooting guide (inside the help menu).

To the top
10. What CAD systems does dyBOT support?

    dyBOT imports four different file formats:
    ASCII: (Including simple APT) This is the only format that is NOT strictly speaking a standard file, although simple APT files can be imported with it. (See .ASC and .APT example files for details). It is a user configurable filter that imports files that can be edited in a text editor (therefore called ASCII files). These files contain 3 axes or 5 axes (configurable) information and may also contain feedrate. The actual syntax of the file is user defined. If you can program some script in your CAD system to generate such files, you will probably like this filter, since it allows you to have the full control of what is being imported.
    If you did not understand this explanation, you can forget ASCII files. Don't worry, the other filters ARE standard.
    DXF: This the standard Autocad file format of the same name. Most CAD systems support this. dyBOT supports the entities that can be used in trajectories i.e. POINT, LINE, ARC, CIRCLE and POLYLINE and it also supports the entity 3D-FACE (So you can see the parts, like in the simple.vPR example in junction with the trajectory). (The 3-D Porsche is a sample 3D Studio MAX surface.)
    Trajectories imported from a DXF file are always 3D (5 or 6 axes information will have to be defined inside dyBOT) Feedrate will only have two values: one for cutting (describing the entity itself) and one for moving (describing the gap from one entity to the next one) (see DXF options). The sense in which an entity is drawn and the order in which the entities are in the file is, in most CAD systems, meaningless. Therefore, the first thing to do with a trajectory imported from a DXF file may be optimization. The way the tool approaches the trajectory or retracts from it will probably need redefinition. (This is called reorbiting)
    IGES: This should be THE standard because it is the only manufacturer independent format. Unfortunately, because of its gigantic specification and the need to support many redundant entities, it is poorly supported (if at all) by low cost systems. As it happens with DXF, dyBOT supports the entities that can be used in trajectories i.e. CIRCULAR ARC, COPIOUS DATA, LINE, PARAMETRIC SPLINE, POINT and NURB curve.
    Some entities include the others, the NURB entity includes them all. Any curve is a particular case of a NURB, and some software (like Rhino) exports all IGES line, arc or curve entities as a NURB. (Do not mix up NURB and NURBS, a NURBS is not a curve, it is a surface. NURB means non-uniform rational b-spline, and NURBS means NURB-surface.)
    Except for one of the three possible forms of the copious data entity, which may have 5 axes info (point + tool direction), all the observations made for DXF files above are equally valid for IGES files.
    Again:
    Trajectories imported from an IGES file are always 3D (5 or 6 axes information will have to be defined inside dyBOT) Feedrate will only have two values: one for cutting (describing the entity itself) and one for moving (describing the gap from one entity to the next one) (see IGES options). The sense in which an entity is drawn and the order in which the entities are in the file is, in most CAD systems, meaningless. Therefore, the first thing to do with a trajectory imported from an IGES file may be optimization. The way the tool approaches the trajectory or retracts from it will probably need redefinition. (This is called reorbiting)
    ISO: Unlike DXF and IGES (which are general CAD formats intended to interchange drawings and parts) ISO was created to fully describe trajectories. It should therefore be the choice. Unfortunately, many users won't be able to create ISO files, since CAD programs very rarely write those files. ISO files are used by CNC controllers and are created by CAM (manufacturing) programs (more specifically by their postprocessors). You should not have any problem to configure CNC-specific issues, since the ISO filter is configurable and very flexible, supporting jumps, procedure calls, splines and more. (See the file demofiles\simple.iso for details.)
    Unlike the two preceding formats, ISO files can include: 5 axes information, feedrate, approaching and retracting movements and the trajectory is (or should be) optimized in file order.

To the top
11. What output does it generate?

dyBOT writes "ready to use" files that can be played on the robot. The robot specification (.vBT file) includes the "output file grammar" which is a user-configurable full description of how these files are structured.

To the top
12. Can I use dyBOT to edit joint movement?

Yes. Download the software and you will see some examples. Load the simple.vPR example, press <F10> Continuous move forward, and see what happens. Note that the trajectories are curves in space even if they are defined by their endpoints only. Those points have joint information and fully define the intermediate curve.
dyBOT does not write such trajectories itself, except when it inserts orientation maneuvers, but if you want to increase maneuver speed, you can change a rapid movement by a joint maneuver using: Reach the point with joint movement. As mentioned in this command's reference, in most cases, you will have to re-route the joint movement manually using teach-in. Joint movement is always performed at maximum angular speed and it may drift from the theoretical (displayed) trajectory due to inertia.

To the top
13. I have been studying your output files closely and dyBOT always writes joint movement. How can you say it does Cartesian movement?

    You could say the same thing about the robot itself. This is precisely what dyBOT does. It builds joint information in space (fragmented in joint interpolation). If the movement is precise enough, it is sent "as it is", if the movement is out of tolerance, it is fragmented (using Cartesian fragmentation) and forced to go through those newly calculated points. This is what the robot itself does when it tries to produce Cartesian movement, and is the only way to force a machine that rotates arms around angular joints to move the endpoint in a line.
    This tolerance is found in Processing options (Final linear tolerance) and is one of the basic issues to understand. Even in the case the robot could "perhaps" do the calculations, there are at least the reasons mentioned above under "If my robot already calculates Cartesian movement, why should I need dyBOT?" to prefer doing this with a computer.
    Talking about robots (no matter if calculations are done by a computer or by the robot itself), when we mean the trajectory is a line, what we really mean is: The trajectory will never separate from a line more than a controlled value. (Called here: Final linear tolerance) It usually has values from 0.25 mm to 0.01 mm and is obviously related with speed. More precision <=> Less speed.

To the top
14. Can I create my own robots from scratch?

Yes. You will find information to do so under Customization (see the manual).

To the top
15. Could I build a robot with dyBOT and a PC-based linear 6 axes motion controller?

    It is certainly not an easy task to do, but the answer is yes, as long as the motion controller can interpolate the 6 axes at a time without any limitation.
    It is certainly more complicated (mechanically) to build a robot that a standard TTT milling machine, since mechanical errors are multiplied times the arm lengths and added to the error of the previous joints.
    Also, many security related issues (dead man switches, brakes, etc.) have more legal requirements for robots than for milling machines, since robots are more dangerous than milling machines.
    Even if we are not encouraging you to build your own robot, there is a good reason some one should do it: Robot controllers based on custom computers, since custom computers are not sold as much as PCs, can be limited by obsolete processors, memory spaces or communications.
    Often, the complexity of the work that can be built on a ($100.000+) robotized cell is limited by: a 1.44 Mbyte diskette (if not a 720 K), a 9600 baud serial communication, 1 Mbyte (or less) RAM space, etc. Something you wouldn't find on the cheapest ($1000-) PC.
    Basing robot control on PCs, even if it is certainly not an easy task to do, is probably the best solution in the long term.

To the top
16. Can I write applications inside it?

Yes, but this requires an OLE2 server version. This version is not ready now and is expected for Fall this year (2000).

To the top