Visible 3Bot Workspace & Control

‘X’ and ‘Y’ workspace

The Visible 3Bot 3-gantry machine is built on a frame using 500mm shafts for the X-axis and 800mm shafts for the Y-axis. These are the same frame dimensions as used by the single gantry Visible Robot machine.

The gantries of the Visible 3Bot travel within a usable X-Y plane of 350mm (13¾”) and 590mm (23¼”), although some minor variation is likely as built. This includes deductions for the unusable space taken up by the ‘X’ and ‘Y’ carriages. The total workable footprint, therefore is 2065cm2 (320 sq. in.).

The travel in ‘X’ is the same for all three gantries. Again, there will likely be some minor variation due to build.

Supposing we portioned off equal-sized “domains” for each of the three gantries: The ultimate travel limits of ‘Gantry0’ (G0) then, would be from Y0min=0 to Y0max=196mm (~7¾”). (Figured as 1/3 of the Y-axis travel of 590mm)—with Y0min=Ymin=0. While the domain of each gantry is 196mm, about half of that is unreachable by an end-effector (assumed to act on a point—as with a 3D-printing nozzle, or a drill). This would leave the actual workspace for each gantry in the ‘Y’ direction to be about 100mm (4”)—except that the gantries have stiffening “outriggers” that, to avoid collision, constrain their workspace further, limiting each to about 80mm (3.15”).

As the ‘X’ axis travel is 350mm, this gives a working X-Y footprint of 280cm2 (~43 sq.in.) for each gantry.

With each gantry controlled separately, three part-sets can be built concurrently.

Is this good enough, or can we do better?

Adding cooperation

If G0 is allowed to “reach” to its full extent, it would be able to travel the full ‘Y’ distance (590mm) less the ‘Y’ length of the gantry hips of ‘Gantry1’ (G1) and ‘Gantry2’ (G2), which are ~140mm (5½”) each. This amounts to 590mm-280mm = 310mm (~12”). This is the point at which its travel is limited by G1. G1 is, in turn, limited by G2, which is also at its limit against the Ymax endstop of the base frame. In this case, both neighbors must agree to withdraw to their limits of travel—G2 to the Ymax endstop, and G1 up against G2.

This is a gain of nearly 300% of workspace over the method of equal-sized apportioning—though, significantly, G1 and G2 are idle during the period when G0 is granted the extra space.

Similarly, G1 and G2 can also have a maximum of 310mm of ‘Y’ travel. Though, as above, not at the same time. (G1 will have a bit more room due to the outriggers of G0 and G2 being half hidden, but this is a complication to the arithmetic left alone for now).

Not only is the workspace of an individual gantry better than tripled, sharing the workspace now allows the gantries to work in concert with one another.

The price of this gain will be to find a method of sharing that avoids collisions between gantries and allows “intrusions” of neighboring gantries into the space that would be “owned” in the less-efficient partitioning of equal space for each gantry.

There is an additional hardware requirement as the individual robot controllers—as currently setup—don’t “talk-to” one another. This might be met by the controlling computer negotiating workspace requests, and issuing “pause,” “move,” “return,” and “continue” commands to both interrupting and interrupted gantries. (See Strawman suggestions below).

Strawman

Negotiating workspace

Let each gantry be given “dominion” over ~196.667mm1 (590/3) of ‘Y’. Let there be a “request/reply” protocol to allow or forbid a neighboring gantry to enter the “domain” of another.

The request may ask for a certain distance along the ‘Y’ axis, a specific amount of work-time, or until it sends a “task done” or “job done” message. The reply may allow the request entirely, or set limits. When the reply is “limited,” the gantry making the request can decide to accept the limits, withdraw the request, or propose an alternative.

On acceptance of either the request or a negotiated alternative, the owner of the space must send a positive message that it is out of the area and will not return until the agreed condition/s is/are met. For its part, the requester must wait until it receives the message that the area has been cleared. The agreement is then in force.

The domain sizes would depend on the ‘Y’ dimension of the as-built machine. Below, we suppose the machine—as-built—has a distance that can be traveled on the Y axis of 590mm.

The “sovereign” domain—the area in which it asserts ownership—of ‘Gantry0’ (G0) according to this arrangement is Ymin to Ymin+196mm. (1/3 of the ‘Y’ travel).

The domain of ‘Gantry1’ (G1) is Ymin+197mm to Ymin+393mm.

The domain of ‘Gantry2’ (G2) is Ymin+394mm to Ymax (590mm).

With permission from G1, G0 can extend its maximum ‘Y’ travel to Ymin+320mm—an increase of about 120mm (4¾”) over its sovereign domain. This requires G1 to move to its boundary with G2 (Y2min). Likewise, with permission from G1, G2 can extend a similar amount.

1 Actually, due to the “outriggers” of the actual gantry_hip parts measuring 140mm in the ‘Y’ direction, against 100mm for the gantry_hip section between the ‘Y’ endstops, there is a 40mm “boundary dispute” region, where neighboring gantries must give up 20mm of travel to avoid the possibility of collision. The 196mm allotment now becomes 176mm. Rather than deal with this little complication, to keep things simpler, I’ll just sweep it under the rug for now and deal with it later in the actual design.

G1 benefits from the fact that both G0 and G2 can withdraw all the way to the endstops and “hide” their outriggers beyond the endstop positions. This gives G1 some additional workspace.

When both neighbors agree to withdraw, the workspace available to the requester increases, yet again.

Implementation

In that the current offerings of robot controllers—RCs (e.g., RAMPS/Printrboard/Megatronics) cannot pass messages directly to one another, the messaging becomes a key task for a Workstation Controller (WC). A piece of software written specifically for this type of work is ROS—the Robot Operating System. ROS is a peer-to-peer, publish/subscribe, message-passing system with huge sets of libraries available free for download. It is open-source and has a large community.

As interface, all RC boards are expected to have USB ports. These provide access for updating the firmware and controlling the robot via host software. As there are three RCs, a port is needed for each on the WC. Fortunately, the inexpensive Raspberry Pi 2/3 has the three needed USB ports. It also runs GNU/Linux (Ubuntu), which is the base operating system for ROS. A desirable future addition to RC hardware would be Ethernet connectivity.

A potential problem with RasPi as WC is that it might be under-powered. ROS suggests a PC for minimum performance. Also, maybe need to add a USB HDD or SSD for the storage of libraries and the tools database.


Z-axis travel

A 3-gantry machine was built with three different sized gantries. Gantry heights are determined by the lengths of shafts used to separate the ‘X’ and ‘Y’ axes. The tradeoff between the three is between the amounts of ‘Z’ travel and stiffness—as might be expected.

There are two available carriages for the ‘Z’ axis. The Original and the Alternative. The Original has more parts, is mechanically more complex (and is less stiff). The Alternative allows more Z-axis travel, but needs a drill-press and a jig to ensure proper axial alignment.

As built, with the Alternate X-Z carriage and a Finix Extruder and E3D hotend attached, G0, using 300mm (11¾”) gantry shafts, has a Z-axis travel of 110mm (4¼”), taking into account bottomed leveling dials and an 8mm (5/16”) glass build platen. The attached extruder and hotend are 105mm (~4 1/8”) tall.

With the Original X-Z carriage on G0, fixing the taller Finix 3Struder Leveling Platform with three E3D hotends (combined, 130mm tall), the ‘Z’ working height is 70mm (2¾“). (This platform consumes the most Z-axis height of the offered end-effector platforms and thereby delivers worst-case in terms of Z-axis travel).

Gantry1, using 350mm (13¾”) gantry shafts, has a Z-axis travel of 140mm (5½”) with the Finix Extruder and Original X-Z carriage and 115mm (4½“) with the Finix 3Struder mounted. Using the Alternate X-Z carriage, the Z-axis travel is 175mm (6¾”) and 150mm (5.9”), respectively. While giving a substantially larger working volume than the other gantries, it is the least stiff of the three.

Gantry2, using 250mm (9¾”) gantry shafts) Z-axis travel is 55mm (2.15”) with the Original X-Z carriage and Finix Extruder, and just 30mm (1.2”) with the 3Struder. Using the Alternate X-Z carriage bumps these numbers up to 80mm (3.15”) and 55mm (2.15″), respectively.

Share