COMPUTER AIDED DESIGN FOR BRICK AND BLOCK CONSTRUCTIONS AND CONTROL SOFTWARE TO CONTROL A MACHINE TO CONSTRUCT A BUILDING
20190251210 ยท 2019-08-15
Assignee
Inventors
Cpc classification
B25J9/1694
PERFORMING OPERATIONS; TRANSPORTING
B25J9/1679
PERFORMING OPERATIONS; TRANSPORTING
B28D7/005
PERFORMING OPERATIONS; TRANSPORTING
G06F16/00
PHYSICS
B25J9/1612
PERFORMING OPERATIONS; TRANSPORTING
G05B19/416
PHYSICS
B25J9/1664
PERFORMING OPERATIONS; TRANSPORTING
G05B19/41815
PHYSICS
E04F21/023
FIXED CONSTRUCTIONS
B28D1/003
PERFORMING OPERATIONS; TRANSPORTING
G05B2219/39172
PHYSICS
Y02B10/30
GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
B25J9/1674
PERFORMING OPERATIONS; TRANSPORTING
B25J9/162
PERFORMING OPERATIONS; TRANSPORTING
B25J9/1684
PERFORMING OPERATIONS; TRANSPORTING
B25J9/1638
PERFORMING OPERATIONS; TRANSPORTING
G06F30/13
PHYSICS
E04B1/02
FIXED CONSTRUCTIONS
H04W4/70
ELECTRICITY
E04G21/22
FIXED CONSTRUCTIONS
E04B2/04
FIXED CONSTRUCTIONS
B25J9/1633
PERFORMING OPERATIONS; TRANSPORTING
B28D1/186
PERFORMING OPERATIONS; TRANSPORTING
B25J9/161
PERFORMING OPERATIONS; TRANSPORTING
G06F2111/20
PHYSICS
B25J5/00
PERFORMING OPERATIONS; TRANSPORTING
B25J13/089
PERFORMING OPERATIONS; TRANSPORTING
G01S17/66
PHYSICS
B28D7/04
PERFORMING OPERATIONS; TRANSPORTING
G06F16/1734
PHYSICS
Y02P90/02
GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
G05B2219/40257
PHYSICS
G05B19/4097
PHYSICS
B60P1/48
PERFORMING OPERATIONS; TRANSPORTING
International classification
G05B19/416
PHYSICS
Abstract
Computer aided design software for designing a building or other structure of brick construction, where in addition to the usual three dimensional modelling and rendering typical of CAD software, tabular data describing the spatial location and orientation of each brick is provided, including information regarding which bricks are cut to length so as to be shortened, and where they are located along each course, and which bricks are machined, drilled or routed for services or other special fittings. Data pertaining to this is compiled in a database for access by control software to control a brick laying machine to build a building or other structure from bricks. The database may receive via interface with a scanner data being a measure of the elevation of the footings and/or concrete pad that has been constructed according to the building plan and for each brick of the first course, to determine how much material must be machined off the bottom of each brick so that when the first course is laid, the tops of the bricks of the first course are at the same level. This machining data is stored for each brick with the tabular data produced by computer aided design software, so that the control software can control the brick laying machine to machine and cut each brick as per the stored data, and convey each brick to the stored position on the footing, pad or previously laid course of bricks, with application of adhesive prior to positioning of the brick.
Claims
1. Computer aided design software for designing a brick construction, said computer aided design software having a user interface allowing a user to input building plan data, said computer aided design software generating from said building plan data, data representative of a scale top-plan view of walls with predetermined known wall length dimensions, said computer aided design software generating a virtual extrusion of length commensurate with the wall height; said computer aided design software determining brick by brick placement data for said walls, including the identification of the position and orientation in three dimensions of each brick relative to a point of origin, including determining brick stepping and brick nesting at wall intersections, and having regard to a predetermined minimum cut brick lengthdetermination of cut length data for individual bricks to be cut to length in order to meet the required dimensions of wall length; said computer aided design software compiling a brick placement database including brick type, position and orientation in three dimensions of each brick relative to said point of origin, and cut length data for each brick identified as to be cut to length.
2. Computer aided design software as claimed in claim 1 having a first table containing one or more user selectable settings allowing stock brick type and size parameters to be stored and selected for walls.
3. Computer aided design software as claimed in claim 1 or 2 wherein said building plan data is representative of a scale top-plan view of external walls and internal walls.
4. Computer aided design software as claimed in any one of the preceding claims wherein said computer aided design software generates footing data and/or concrete pad data including the dimensions, position and orientation of the footings and/or concrete pad relative to a point of origin, relative height off-set between the bottom of the external walls and optionally the bottom of the internal walls and between different sections of internal walls and optionally determines the required volume of concrete to form the pad.
5. Computer aided design software as claimed in any one of the preceding claims wherein said computer aided design software allows user input of and storing positioning data for voids and/or apertures in said extrusion, said voids and/or apertures being of dimensions commensurate with the height and width of doors and windows to be fitted in the completed building.
6. Computer aided design software as claimed in any one of the preceding claims wherein said computer aided design software allows user input of and storing services positioning data for at least one of plumbing, electrical and ICT (Information and Communication Technology) and sound and vision cabling and connection points in said external walls and in said internal walls; said computer aided design software generating positioning data for channels in said walls to carry services and recesses in said walls for said connection points, said computer aided design software generating machining data for the location of recesses and cavities to be machined in individual bricks according to the positioning data of said channels and recesses; and storing said machining data in said brick placement database.
7. Computer aided design software as claimed in any one of the preceding claims adapted to determine the order that each brick is to be laid, and creates in said brick placement database, an index number allocated to each brick, to identify the brick laying order.
8. Computer aided design software as claimed in any one of the preceding claims wherein the reference position on each brick is the centroid of all dimensions of each brick, trimmed or whole, but for simplicity not taking into account any routed cut-outs or recesses.
9. Computer aided design software as claimed in any one of claims 4 to 8 wherein the relative height off-set between the bottom of the external walls and the bottom of the internal walls may be reflected in different z values for the first course of bricks of the external course and the internal course.
10. Computer aided design software as claimed in any one of the preceding claims wherein different spacings between adjacent bricks and thicknesses of adhesive or mortar between adjacent bricks are accounted for and adjacent brick spacing A and brick base spacing B are stored in the brick placement database.
11. Computer aided design software as claimed in any one of the preceding claims wherein for cut bricks the design software exports the coordinates of the cut to said database.
12. Computer aided design software as claimed in any one of claims 6 to 11 wherein for routed bricks the design software exports the coordinates of the rout to said database.
13. Computer aided design software as claimed in any one of the preceding claims wherein the design software brick placement database includes at least one trim data field to store a trim value or a trim value array for each brick.
14. Computer aided design software as claimed in any one of claims 6 to 13 having a first library in which data pertaining to one or more building plans in the form of said data sets are stored.
15. Computer aided design software as claimed in claim 14 having a second library in which data pertaining to one or more pre-defined rooms are stored.
16. Computer aided design software as claimed in claim 15 having a third library in which data pertaining to a plurality of doors and windows are stored, corresponding to data for stock items used in determining said positional data based on selected doors or windows.
17. Computer aided design software as claimed in any one of claims 6 to 16 wherein said computer aided design software treats walls of a structure to be built as segments extending between intersections of brickwork, where each segment has a course segment extending between intersections of brickwork and window and door opening edges; where any said course segment has a length s, where:
s=n.(b+A)+r+A+p.e+p.A+q.f+q.A?A where A is the A value or gap), b is the stock brick length, e and f are the end overlap at a brick wall intersection, p may be 1 (indicating e is equal to the width of a brick at the intersecting wall, or zero (abutting), q may be 1 (indicating f is equal to the width of a brick at the intersecting wall, or zero (abutting), r is the remainder which may be zero or greater than or equal to 0.2 b, preferably 0.25 b, and if this is true, a single brick is cut to length r to complete the course segment; and if r is less than 0.2 b, preferably 0.25 b,
s=(n?1).(b+A)+2r+2A+p.e+p.A+p.f+q.A?A where r is the length that two bricks are cut to, to locate within and complete a course segment having n?1 bricks.
18. Computer aided design software as claimed in claim 17 wherein a next course of said bricks are arranged in order to achieve preferred stepping, where a said course segment includes two bricks of length r, the immediately overlying course segment includes a single brick of length r balanced on the join between the two bricks of length r, with two bricks cut to length of c=(b+r)/2, located on either side thereof, with bricks of stock brick length b continuing away from at least one of said two bricks cut to length of c, and the course segment length can be described by the following:
s=(n?2).(b+A)+r+A+2(c+A)+p.e+p.A+p.f+q.A?A
19. Control software to control a brick laying machine to build a building or other structure of brick construction, said control software accessing a brick placement database compiled by computer aided design software as claimed in any one of the preceding claims, said control software controlling said machine to cut and optionally to machine each said brick in accordance with data stored in said brick placement database, and controlling said machine to convey each said brick one by one, and apply adhesive and locate each said brick according to data stored in said brick placement database.
20. Control software to control a brick laying machine to build a building or other structure of brick construction, said control software accessing a brick placement database including brick type, position and orientation in three dimensions of each brick relative to a point of origin, cut length data for each brick identified as to be cut to length, and machining data for each brick including a trim value or a trim value array for each brick being trim data derived from data received from a scanner located at a surveying position to measure the relative surface height of a surface extent where bricks are to be laid; said control software correcting for the difference in height of the surface extent for each brick, from the lowest point and the highest point for each course of bricks and determining from said trim data the amount to be machined from a horizontal face of each brick so that the top of each course of bricks is level when laid; said control software controlling said machine to cut and machine each said brick in accordance with data stored in said brick placement database, said control software controlling said machine to convey each said brick one by one, and apply adhesive and locate each said brick according to data stored in said brick placement database.
21. Control software to control a brick laying machine to build a building or other structure of brick construction, said control software accessing a brick placement database including brick type, position and orientation in three dimensions of each brick relative to a point of origin, cut length data for each brick identified as to be cut to length, and machining data for each brick; said control software including a scanner interface to receive data from a scanner located at a surveying position to measure the relative surface height of a surface extent where bricks are to be laid, storing the height of the surface for at least one location for each brick at which each brick is to be located according to said brick placement database; said control software correcting for the difference in positioning of said surveying position and said point of origin and determining the difference in height of the surface for said at least one location for each brick, from the lowest point and the highest point for each course of bricks and storing the difference in said brick placement database as trim data in the form of a trim value or trim value array for each said brick corresponding with the amount to be machined from a horizontal face of each brick so that the top of each course of bricks is level when laid; said control software controlling said machine to cut and machine each said brick in accordance with data stored in said brick placement database, said control software controlling said machine to convey each said brick one by one, and apply adhesive and locate each said brick according to data stored in said brick placement database.
22. Control software as claimed in any one of claims 19 to 21 wherein said control software determines the order that each brick is to be laid, and creates an index number allocated to each brick, to identify the brick laying order, and enters the index number into the brick placement database.
23. Control software as claimed in any one of claims 19 to 22 wherein said control software includes a library of handling identifiers which each identify a unique handling device within said brick laying machine, and said control software produces a handling table identifying individual bricks and associating individual bricks with a particular handling device at a particular time, and updating said handling table as individual brick progress from handling device to handling device with the elapsing of time.
24. Control software as claimed in any one of claims 19 to 23 wherein said control software calculates corrected x y z position and orientation data relative to said point of origin for each brick recorded in said brick placement database, based on the difference between the location of the point of origin and the surveying position, and records the corrected x y z position and orientation data relative to said surveying position, for use in controlling said brick laying machine.
25. Control software as claimed in any one of claims 19 to 24 wherein said trim data is measured and stored as a trim value array for multiple locations for each said brick, so that said machine may machine said brick to compensate for localised footing or pad height excesses.
26. A method of building a structure, comprising steps of determining the size of brick to be utilised; creating a scale top-plan view of walls with predetermined known wall length dimensions; determining brick by brick placement data for said walls, including identification of the position and orientation in three dimensions of each brick identification of the position in three dimensions and orientation of individual bricks to be cut to length in order to meet the required dimensions of wall length, and determining the order that each brick is to be laid, and storing this data in a brick placement database; measuring the relative surface height of a surface extent where bricks are to be laid, recording the height of footings for at least one location at which each brick is to be located according to said brick placement data, determining the difference in height of the footings for at least said one location for each brick, from the lowest point to the highest point for at least the first course of bricks and storing the difference from the lowest point as trim data in the form of a trim value or trim value array for said at least one location for each said each brick corresponding with the amount to be machined from a horizontal face of each brick so that the top of at least the first course is levelled when laid, the trim data being stored with said brick placement data; cutting each said brick in accordance with said brick placement data, conveying each said brick one by one, and applying adhesive and locating each said brick according to said brick placement data.
27. A method of building a building or other structure, comprising steps of determining the size of brick to be utilised for external walls and the size of brick to be utilised for internal walls; creating a scale top-plan view of external walls and internal walls with predetermined known wall length dimensions, determining footing and/or concrete pad data including the dimensions of the footings and/or concrete pad, relative height off-set between the bottom of the external walls and the bottom of the internal walls and between different sections of internal walls and optionally determining the required volume of concrete to form the pad; planning the configuration of the walls from the footings and/or pad up to the tops of the walls including positional determination of voids of dimensions commensurate with the height and width of doors and windows to be fitted, and positioning data for channels and recesses (chasing) for services of plumbing, electrical and ICT and sound and vision cabling and connection points in said external walls and in said internal walls; determining brick by brick placement data for said external walls and said internal walls, including identification of the position and orientation in three dimensions of each brick relative to the footings and/or concrete pad, identification of the position in three dimensions of individual bricks to be cut to length in order to meet the required dimensions of wall length, void size and aperture size, and generating machining data for the position of recesses and cavities to be machined in individual bricks according to the positioning data of said channels and recesses, and determining the order that each brick is to be laid, and storing this data in a brick placement database; measuring the relative surface height of a surface extent where bricks are to be laid , recording the height of the footings and/or a concrete pad for at least one location at which each brick is to be located according to brick placement data as described above, determining the difference in height of the pad for at least said one location for each brick, from the lowest point to the highest point for at least the first course of bricks and storing the difference from the lowest point as trim data in the form of a trim value or trim value array for said at least one location for each said each brick corresponding with the amount to be machined from a horizontal face of each brick so that the top of at least the first course is level when laid, the trim data being stored with said brick placement data; cutting and machining each said brick in accordance with said brick placement data, conveying each said brick one by one, and applying adhesive and locating each said brick according to said brick placement data.
28. The method as claimed in claim 26 or 27 wherein the building or structure may be built course by course until completed to the required height.
29. The method as claimed in claim 20 wherein the first course of each course of bricks is machined to reduce their height as necessary, according to the data from measuring the relative surface height of footings and/or a concrete pad so the tops of the first course are level.
30. The method of any one of claims 19 to 21 wherein said trim data is measured and stored as a trim value array for multiple locations for each said brick, so that each said brick is machined to compensate for localised footing or pad height excesses.
31. The method of any one of claims 19 to 21 wherein position and orientation data for each brick includes x and y horizontal dimensions relative to a reference point, with reference to a position on each brick, z vertical dimension, and 0 angle relative to magnetic north or other direction.
Description
BRIEF DESCRIPTION OF DRAWINGS
[0075] Preferred embodiments of the invention will now be described with reference to the drawings, in which:
[0076]
[0077]
[0078]
[0079]
[0080]
[0081]
[0082]
[0083]
[0084]
[0085]
[0086]
[0087]
[0088]
[0089]
[0090]
[0091]
[0092]
[0093]
[0094]
[0095]
[0096]
[0097]
[0098]
[0099]
DESCRIPTION OF EMBODIMENTS
[0100] The computer aided design software according to the embodiment can be implemented as a fully featured CAD program, or as a plug-in for an existing CAD program, such as Solidworks. The control software to control a brick laying machine to build a building which is designed in the computer aided design software imports a brick placement database produced in the computer aided design software, and then the brick laying machine implements the construction of the building according to the data contained in the brick placement database. During the construction phase, the brick placement database may have fields (cloumns) added to it, in order to associate new data with each brick.
[0101] The computer aided design software allows the user, once size of brick to be utilised for external walls and the size of brick to be utilised for internal walls has been determined, to create a scale top-plan view of external walls and internal walls with known wall length dimensions as determined by the user in accordance with the requirements of the person commissioning the build. The user determines the footing and/or concrete pad data including the dimensions of the footings and/or concrete pad, and relative height off-set between the bottom of the external walls and the bottom of the internal walls and between different sections of internal walls.
[0102] The computer aided design software can, through inputting of concrete thickness required to meet load bearing capacity of the built structure, determine the required volume of concrete to form the pad.
[0103] The computer aided design software provides for the user to plan the configuration of the walls from the footings and/or pad up to the tops of the walls including positional determination of voids of dimensions commensurate with the height and width of doors and windows to be fitted, and positioning data for channels and recesses (chasing) for services of plumbing, electrical and ICT and sound and vision cabling and connection points in said external walls and in said internal walls.
[0104] The computer aided design software then determines brick by brick placement data for the external walls and the internal walls, and identifies the position and orientation in three dimensions of each brick relative to the footings and/or concrete pad, and identifies the position in three dimensions of individual bricks to be cut to length in order to meet the required dimensions of wall length, void size and aperture size.
[0105] The computer aided design software generates machining data for the position of recesses and cavities to be machined in individual bricks according to the positioning data of said channels and recesses.
[0106] The computer aided design software then determines the order that each brick is to be laid, based on a rule that requires any brick extending across an intersection or to the apex of a corner to be laid first. A blockdependency data field can be provided, associated with each brick in order to identify a set of bricks that must be laid before the brick specified. This is to avoid laying arm collisions with previously laid bricks.
[0107] A brick placement database is compiled, containing data identifying the position and orientation in three dimensions of each brick relative to a datum point which relates to a point on the footings and/or concrete pad, and where bricks are trimmed to length, the trimmed length, and the order in which the bricks are to be laid. All position and orientation data is referenced to a central point in each brick, whether trimmed to length or whole. The gap to the next brick is also stored as an A value in the brick placement database. Machining data for services, or any special arrangements of interconnecting walls is also stored in the brick placement database, against each brick. Blockdependency data is included for each brick, where necessary.
[0108] For each side of each brick requiring routing or cutting, a record is placed in the brick placement database. Each record provides a link to the brick it is associated with, cross-referencing to additional tables that contain the actual routing and cutting information in a form that can be read by the routing tool or saw, as the case may be.
[0109] Additional fields in the brick placement database are also provided for, against each brick, which can be populated at the design stage when the footings and/or slab have been poured and scanned for surface height variation, or can be populated during the construction phase, by input to the control software for controlling the brick laying machine. These additional fields include trim data containing a trim value array for each brick, which is the amount of material that must be machined from the bottom of each brick, so that when the bricks are all laid, the tops of the course will be level.
[0110] A laser scanning device is arranged to measure the relative surface height of a surface extent where bricks are to be laid, recording the height of the footings and/or a concrete pad, or the height of an existing course of bricks or other surface, at the location where each brick is to be located according to brick placement database as described above, to determine the difference in height of the surface across the location for each brick, from the lowest point to the highest point for the first course of bricks and stores the difference from the lowest point as trim data in the form of a trim value array for each brick. This data corresponds with the amount to be machined from a horizontal face of each brick so that the top of each course is level when laid, the trim data being stored with said brick placement data.
[0111] Special considerations regarding the execution of a building plan in the computer aided design software, including location of trimmed bricks and nesting of bricks will now be discussed.
[0112] As will be apparent from the discussion that follows, each course of each wall of a building or structure has a start point and a finish point. The course distance between start point and end point for each course is known, determined from the scale top-plan view produced in the computer aided design software. These points comprise two of the end of a course of bricks, the stepped end of a course of bricks plus adhesive thickness, the edge of a window and the edge of a door. A stepped end of a course of bricks is stepped inwards along the length of the course by the wall thickness of an intersecting brick of an intersecting course, usually forming part of a wall running at 90 degrees to the course. The minimum brick length is determined by the length of the gripper of the brick laying machine, which in the present embodiment is 120 mm. It would be impractical for the brick laying machine to handle bricks of shorter length than its gripper as this would invariably lead to the gripper clashing with bricks that had already been placed.
[0113] A course is made up of a number of stock bricks of known length, including where necessary, one or more bricks that are trimmed in length, referred to as a remainder which can be no shorter than 120 mm. Where two or three trimmed bricks are utilised and the lengths of the trimmed bricks is determined to ensure that brick stepping conforms with accepted practices. In the embodiment, the external bricks are 258 mm high, 500 mm long and 240 mm deep. The internal bricks are 258 mm high, 500 mm long and 115 mm deep.
[0114] The first course is made up of a number of stock bricks of length 500 mm divided into the length of the wall. The remainder is determined from a distance greater than 125 and less than 500.
[0115] These bricks are illustrated in the
[0116] The computer aided design software allows the CAD operator to sketch the plan of the building, in this example, a house. Referring to
[0117] External openings for doors and windows are closed. Where the entire structure is built on a concrete pad, the external perimeter will represent the concrete pad dimensions. For a level concrete pad the elevation of the pad is given a z value of 0. The lowermost elevation of the wall should be set to the same z value. Alternatively for a stepped down damp course building construction, the external wall may be set down. The parallel lines of the wall in
[0118] The next step is to draw the internal walls 63 as a single line which traces the centrelines of the bricks whilst maintaining 125 mm grid system to position the walls at 125 mm increments. Referring to
[0119] Referring to
[0120] The sketch segments may be drawn in any direction, but the software collects the sketch segments and swaps the start and finish point (if required as it may be pointing in the opposite direction) on the sketch segment to maintain the chain pattern from start to finish on each sketch segment in an anti-clockwise direction, with sketch segment 57 having its 3D x y z finish point back at origin 63.
[0121] Wall assemblies are added to the project and are attached to the start point of the sketch segment, then the brick component from the library containing the brick data is inserted into the brick wall assembly. Brick data includes the stock external wall brick depth (thickness), length and height, the external vertical brick gap, the external wall horizontal brick gap, the stock internal wall brick depth (thickness), length and height, the internal vertical brick gap, and the internal wall horizontal brick gap.
[0122] All walls are created from a pattern of the first and second courses to the cap.
[0123] Referring to
[0124] For external walls, from corner to corner, or from door to corner or visa-versa, the wall length is equally divisible by 125.
[0125] The first (bottom) course starts flush on the end of the first corner and patterns as full bricks to the remainder gap minus the end of the perpendicular bricks depth, this being Right End Adjustment. The remainder is stepped using cut bricks of 125 mm intervals. ie 125, 250, 375.
[0126] Doors are treated similarly as a corner nest where the perpendicular brick in the Right End Adjustment is cut to a 250 brick on either side of the door for each course respectively.
[0127] The bricks 67, 73, 75 and 71 are placed on the exterior 59 line being the outer edge of the external brick and lines up with the sketch segments.
[0128] Referring to
[0129] Any course of bricks running between an intersection of bricks, a corner, or an edge for a window or a door, can be considered to be a course segment. Each course segment is populated in the design software with a number of full length bricks 73 extending from end adjustment 69 to end adjustment 79 (if any), with at least one full length brick 67, 71 abutting each end adjustment 69, 79 respectively, leaving a remainder gap 75. Where the remainder gap 75 is less than the minimum allowable remainder of 120 mm (or 125 mm under the 125 mm grid system), the calculated remainder gap 75 added to the length of a stock brick added to the A value for each, all divided by two, determines the length of two bricks 77 to fill the remainder gap 75, as is illustrated in
[0130] Where the remainder is the same as or greater than the allowable remainder, the trimmed brick length to fill the remainder is the determined remainder size. All data pertaining to this is stored in the brick placement database.
[0131] Referring to
[0132] The second course starts with the Left End Adjustment, being the perpendicular bricks depth, then patterns as full bricks until a remainder gap minus a full brick on the end sitting flush with the external face of the wall occurs. The remainder must be greater than or equal to 125 mm and can consist of 2?375 mm, 2?125 mm, 1?125 mm cut bricks and consideration of the first courses remainder for stepping as described above ensures a vertical gap overlap occurs to ensure that there are no continuous vertical gaps occurring between courses.
[0133] The final brick on the second course is a full brick and sits flush with the external face of the returning wall.
[0134] The third course placed on top of the second course 81 is a repeat of the first course 66, and the fourth course placed on top of the third course is a repeat of the second course 81.
[0135] The order of laying bricks in each of the first and second courses (and in consequence the courses that follow) may be swapped so that efficiencies can be gained from nesting arrangements at door and window headers with lintels.
[0136] Referring to
[0137] Referring to
[0138] Another design consideration for the design software is the order of the laying of the bricks, which is another parameter included in the brick placement database. As any course segment is laid, the first brick to be laid is one that extends across a brick junction or to the apex of a brick junction corner. This is so that the gripper of the brick laying machine has access to lay the bricks. If a brick abutting such a brick was to be laid first, the gripper of the brick laying machine would not have access to be able to lay the brick that extends across a brick junction or to the apex of a brick junction corner.
[0139] Internal wall creation is similar to external wall creation, except that the brick is placed centrally to the sketch segments and not on a perimeter sketch segments. The stepping of the bricks is also different in that the end conditions (nesting of the bricks from 1 wall to another) have many possibilities. A rule of thumb has been applied based on the direction of the walls to which the left and right end conditions are applied. This rule of thumb is applied to allow for corners to nest in any situation.
[0140] In a wall heading in the direction from North to South or South to North as shown in
[0141] Referring to
[0142] The adjusted length of the stepping adjustment bricks 77, the centre xyz coordinates for each brick in each course of bricks, and the orientation of each brick, relative to the origin 63 together with the left end adjustment 69 and right end adjustment 79 are stored in a brick placement database, which defines the parameters for the bricks to be laid. Since the bricks have a tongue at one end and a groove at the opposite end, and they are laid in a straight line with tongue projecting into groove, the orientation of each brick runs at any value from 0 degrees to 359 degrees, to retain the tongue-groove co-operation. In addition, the 3D x y z start point and 3D x y z finish point for each sketch segment is stored, and the course number for each brick is stored, for example 0 for the first course, 1 for the second course, and so on. The order of laying the bricks, typically from the origin 63, is also stored. The first brick to be laid will have adhesive applied to its underside, and the bricks that follow will have adhesive applied to both their underside and the end (or in the case of a corner, a part of the side that abuts the previously laid brick), and the location of applied adhesive is stored in the brick placement database.
[0143] Each bricks 3D location point, length, cut, routing, chasing and rotation data is exported from the design software in the brick placement database, to the control software of the brick laying machine. The three dimensional coordinates of each brick are the length x, the depth or width y and the height z. These values are imported from the brick data contained in a first table containing stock brick sizes, or where the brick is trimmed, are calculated from a virtual bounding box for the brick, generated by the design software. The orientation of the brick is measured against the design software project front plane running in the South to North direction and is degrees from 0 to 359
[0144] Where a brick is to be shortened it can be cut to leave the tongue end to be used, or the groove end. This will determine the handling of the brick for the cutting operation. The end to be used is predetermined and its data is stored in the brick placement database. The off cut length is calculated by the design software and the off cut is recorded as available stock for use elsewhere in the plan, and control software is programmed to retrieve an offcut brick portion from recorded available stock, with data pertaining to this being recorded in the brick placement database.
[0145]
[0146] Referring to the section shown on
[0147] Referring to the section shown on
[0148] The control software for controlling the brick laying machine is incorporated into control electronics in a control cabinet 282, to control the operation of a brick laying machine 202.
[0149] Referring to
[0150] Referring also to
[0151] The telescoping boom comprises telescopic boom elements 212, 214 and telescopic stick elements 215, 217, 218, 219, 220. Each element 212, 214, 215, 217, 218, 219, 220 of the folding telescoping boom has a shuttle located inside on a longitudinally extending track in the element, to transport a brick along the longitudinal extent of the element. The bricks are moved through the inside of the folding telescoping boom by the linearly moving shuttles. The shuttles are equipped with grippers that pass the brick from shuttle to shuttle. The shuttles in the telescoping elements are located alternately along the top of one element and along the bottom of the next element, when viewed with the boom unfurled, as shown in
[0152] The shuttles in the elements 214 and 215 run along the top of these elements and a pivoting gripper is provided about axis 216, so that a brick can transfer from the gripper on the shuttle in element 214 to the gripper on the axis 216 which can rotate to align to the gripper on the shuttle in element 215.
[0153] A pivoting gripper is also provided on the axis 213 about which boom element 212 mounts to the tower 210, so that a brick can transfer from the gripper on the shuttle on the tower 210, to the pivoting gripper on the axis 213 and then to the gripper on the shuttle running along the bottom of element 212.
[0154] The carousel 248 also has a pivoting gripper 274 into which a brick is placed by the transfer robot, before the carousel 248 rotates and the pivoting gripper 274 thereon pivots to present the brick to the grippers on the shuttle on the tower 210.
[0155] The end of the boom is fitted with a brick laying and adhesive applying head 232. The brick laying and adhesive applying head 232 mounts by pins (not shown) to element 220 of the stick, about an axis 233 which is disposed horizontally. The poise of the brick laying and adhesive applying head 232 about the axis 233 is adjusted by double acting hydraulic ram 235, and is set in use so that the tracker component 330 is disposed uppermost on the brick laying and adhesive applying head 232. A gripper is mounted about the pivot axis 233 and received a brick from the shuttle at the end of stick element 220, flips it and presents it to the brick laying and adhesive applying head 232, which applies adhesive to the brick and presents it to a robot 236 with a gripper 244 that lays the brick. Vision and laser scanning and tracking systems 334, 335, 333 are provided to allow the measurement of as-built slabs 123, bricks, the monitoring and adjustment of the process and the monitoring of safety zones. The first, or any course of bricks can have the bricks pre-machined by the router module 247 so that the top of the course is level once laid, as is discussed above.
[0156] The transfer robot, the saw 246, and the router 247 each have a gripper that can hold a brick at any point in time, as do the grippers on the carousel 248, the tower 210, the pivot axis 213, the shuttle in the boom element 212, the shuttle in the boom element 214, the gripper mounted to the pivot axis 216, the shuttle in the stick element 215, the shuttle in the stick element 217, the shuttle in the stick element 218, the shuttle in the stick element 219, the shuttle in the stick element 220, the gripper mounted about the pivot axis 233, and the brick laying robot 236. For a more detailed description of the brick laying machine, reference is made to the patent specification titled Brick/Block Laying Machine Incorporated in a Vehicle which is the subject of international patent application PCT/AU2017/050731, the contents of which are incorporated herein by cross-reference.
[0157] Operation of the brick laying machine will now be discussed. The brick placement database is accessed by control software contained in the control cabinet 282. If a scan of the slab to determine its horizontal variance has not already been carried out, this is now performed, and a trim value array for each brick is determined and loaded as trim data in the brick placement database.
[0158] A brick is taken from a dehacked row of bricks, by the transfer robot, and allocated an identification number as the first brick of the construction according to the brick placement database. The brick is then treated according to the instructions embodied in the brick placement database. As the first brick, it is unlikely that it will require machining or cutting, and if so it will be moved by the transfer robot to the carousel. If the brick requires machining due to the slab scan analysis determining that the slab has a lower elevation at other positions where bricks are to be laid, the brick is moved to the router 247 where it is transferred by a gripper therein and has material machined from the bottom thereof in accordance with the trim value array trim data stored against the brick in the brick placement database. Otherwise the transfer robot would transfer the brick to the carousel 247. After the machining operation the transfer robot transfers the brick from the router 247 to the carousel 248. After this, the transfer robot is free to return to the row of dehacked bricks, to select the next brick in the sequence as determined by the brick placement database
[0159] The carousel 248 rotates so that its gripper 274 aligns with the transfer robot, and the carousel gripper 274 grips the brick followed by the transfer robot gripper releasing the brick. The carousel 248 rotates to the position of the shuttle and track on the tower 210 (note that this slews with the tower rotating with the boom about the horizontal axis 209). The tower shuttle lowers to the grippers 274, and the brick is transferred to the grippers on the tower shuttle. The tower shuttle can then climb the tower 210 to reach the pivot axis. At this stage the carousel is ready to rotate back to receive the next brick from the transfer robot.
[0160] This process continues, with the transfer robot moving the bricks via the saw 246 and/or router 247, for the cutting and machining each said brick in accordance with said brick placement data allocated against each identified brick in the brick placement database.
[0161] The control software controls the brick laying machine elements to convey each said brick one by one, and apply adhesive and locate each said brick in position on the build, according to said brick placement data for each brick contained in the brick placement database.
[0162] In addition to this the control software builds a handling table identifying for each brick, its identification number which can equate to an identification number in the brick placement database, and for each step between different grippers in the sequence of grippers contained in the brick laying machine, identifies the time and the gripper ID.
[0163] All of these transfers between the programmable brick handling apparatus are logged in the handling table, so that the handling table provides a record of which brick is where and when.
[0164] Consequently, if for any reason the brick laying machine must be paused for any reason, such as shutting down at the end of a working day, it may be restarted, and the correct brick will be laid in the correct position after the restart has occurred.
[0165] Further, if for any reason a brick is damaged during a machining (cutting or routing) operation, it may be discarded at the machining tool, and the handling table can be updated by reallocating brick identification numbers to the bricks preceding the damaged brick in the supply chain.
[0166] Where damage to an individual brick is not determined until it reaches a position closer to the brick laying gripper, where any said brick already in transit along said handling devices includes no machining data in said brick placement database, said handling table can be updated by reallocating brick identification numbers to the bricks preceding the damaged brick in the supply chain.
[0167] However, where any said brick already in transit along said handling devices includes machining data in said brick placement database, due to the individual bricks being laid in order, it becomes necessary for the control software to run the brick laying machine in reverse, restacking the bricks and storing their restacked position until there are no bricks having associated said machining data in transit along said handling devices, whereupon a replacement brick can be picked from said pallet and processed according to said brick placement database. Thereafter, any restacked bricks are picked up in order, and operation then continues as pre-programmed.
[0168] Referring to
[0169] Both the design software and the control software access a database which is illustrated in
[0170] The build data and machine state section of the database stores the current state of the house; including location/state of each block, state of each clamp of the machine, state of the de-hacking bays and slab details. The build data is generated by the computer aided design software, and contains all of the information required by the control software to run the brick laying machine to build a structure. For each house or structure, hereafter referred to as a house for brevity, a record is added to the house table. This is the identifying data for the particular house being built and includes street address, slab origin in real world GPS coordinates, slab heading and project/client information.
TABLE-US-00001 TABLE 1 HOUSE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) Location VARCHAR(1000) The address/lot of a house/ structure location GpsN REAL The North GPS location of the house slab origin GpsE REAL The East GPS location of the house slab origin Direction REAL The slab direction, 0-360? ProjNumber VARCHAR(1000) The company project number for the house being built Customer VARCHAR(1000) The customer that the house is being built for BldCmplt BOOL Indicates if the house has completed BldInProg BOOL Indicates if the house has begun
[0171] A house is made up of multiple types of block. Each type is stored in the blocktype table. This contains the block details such as name, manufacturer, ordering details and physical characteristics.
TABLE-US-00002 TABLE 2 BLOCKTYPE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) Maker VARCHAR(1000) The company that makes the block Description VARCHAR(1000) The block type and description OrderCode VARCHAR(1000) The order code for the block type Surface VARCHAR(1000) The color and type of block, eg red smooth clay Long REAL The length of the block Wide REAL The width of the block High REAL The height of the block
[0172] A house is made up of many blocks, the details of each block are located in the block table. Each block record references the house that it belongs to as well as its type. As well as the location and rotation of the block on the slab, the block record contains the cut length required and if the spigot is to be removed.
TABLE-US-00003 TABLE 3 BLOCK TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) houseID INT (Relation) The house that the block belongs to, many block records can reference the same house blocktypeID INT (Relation) The blocktype representing this block, many block records can reference the same blocktype BlockOrder INT The ideal order in the house that the block should be placed PosX REAL The X position of the block location in the house in slab coordinates PosY REAL The Y position of the block location in the house in slab coordinates PosZ REAL The Z position of the block location in the house in slab coordinates Direction REAL The direction of the block in the house in slab coordinates SawLength REAL The length the block must be cut to RemSpigot BOOL Specifies if the spigot needs to be removed
[0173] Although blocks have a BlockOrder specifying ideal lay order, this is not mandatory. Blocks can be laid in a different order, for example, for fault handling. There are however some situations where a block (a) must be laid before another block (b), for example, to prevent the laying arm clamp from colliding with already placed blocks. The blockdependency table allows these situations to be specified.
TABLE-US-00004 TABLE 4 BLOCKDEPENDENCY TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) blockID INT (Relation) Block (b) that this dependency record specifies, many blockdependency records can reference the same block dependentblockID INT (Relation) Block (a) that this dependency record specifies, many blockdependency records can reference the same block
[0174] For each side of each block requiring routing, a record is placed in the side table. Each record has a link to the block it is associated with. The actual routing information is contained in additional tables.
TABLE-US-00005 TABLE 5 SIDE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) blockID INT (Relation) The block that this side belongs to, many side records can reference the same block SideID CHAR Specifies if the side is the front, back, top, underside, left or right side of the block.
[0175] The bore table references the side table, and uses a record for each hole to be drilled into the face of the block. Each hole has a specified position, width and depth. The location is specified relative to the face origin.
TABLE-US-00006 TABLE 6 BORE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) sideID INT (Relation) The side that this bore will be performed on, many bore records can reference the same side HoleXPos REAL The bore X position relative to the origin of the block side HoleYPos REAL The bore Y position relative to the origin of the block side HoleRadius REAL The size of the bore to be drilled HoleDeep REAL The depth of the bore to be drilled
[0176] The channel table contains details for each channel that has to be put on a block face. It references the face it is to be machined on as well as the channel depth and width. The channel does not have to be a single straight line but can have corners. The channel path is defined by the channelpoint table. Each point references a chase record and are in local face coordinates. Each chase has 2 or more points making up a path for the channel.
TABLE-US-00007 TABLE 7 CHANNEL TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) sideID INT (Relation) The side that this channel will be performed on, many channel records can reference the same side Wide REAL The width of the channel Deep REAL The depth of the channel
TABLE-US-00008 TABLE 8 CHANNELPOINT TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) channelID INT (Relation) The channel that this channelpoint is part of, the channel is made of several channelpoints ChaseXPos REAL The point X position relative to the origin of the block side ChaseYPos REAL The point Y position relative to the origin of the block side
[0177] Parts of the data set are used to generate block routing files for the router on the brick laying machine. A routing file is generated for each block that requires routing and uses the data in the block, side, bore, channel and channelpoint tables. This file is copied to the machine along with the rest of the build data.
[0178] Each block type will have associated pallets that the machine needs defined so it can de-hack it. This data is stored in the tables palletdefinition and palletlayer. The palletdefinition table will simply contain the block type, while the palletlayer table will have one record each for the layers in the pallet. Each layer will specify the number of rows and columns, as well as if the rows run left/right or front/back. Front/back is defined as being parallel with the forklift forks.
TABLE-US-00009 TABLE 9 PALLETDEFINITION TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) blocktypeID INT (Relation) The blocktype that makes up this pallet, each blocktype can have many palletdefinitions
TABLE-US-00010 TABLE 10 PALLETLAYER TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) palletdefinitionID INT The palletdefinition that this palletlayer belongs to, each palletdefinition can have multiple palletlayers LayerNo INT The order that the layers are in NoRows INT The lumber of rows in this layer NoColumns INT The number of columns in this layer Dir INT The direction of the layer, 4 directions are possible as the side with the spigot is significant
[0179] Along with the data required to build a structure, the machine state data section of the database contains the information required for the machine to continue building, either at the beginning of a new day, or following an unscheduled shut-down of the H109 controller. When the brick laying machine is restarted after a fault, the data is read back into the controller so that the brick laying machine can continue with minimal operator assistance.
[0180] For each structure that the brick laying machine has in its database, it records if the house has started or completed in the house table.
[0181] A surveypoint table is used to record points built into the slab that can be used to re-align the laser tracker with the slab after the first course of blocks have been laid. Each surveypoint record references the house table that it is associated with.
TABLE-US-00011 TABLE 11 SURVEYPOINTS TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) houseID INT (Relation) The house that this surveypoints belongs to, many surveypoints records can reference the same house PosX REAL The X position of the point in slab coordinates PosY REAL The Y position of the point in slab coordinates PosZ REAL The Z position of the point in slab coordinates
[0182] For each of the two de-hacker bays 249 and 250, a record is kept in the loadingstate table. The table records the pallet type, current layer and row that is to be de-hacked and the orientation of the pallet in the bay. The table also records if a row of blocks is currently being held in the de-hacker clamp. The primary ID is used to identify the left and right de-hacker data.
TABLE-US-00012 TABLE 12 LOADINGSTATE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) palletdefinitionID INT The pallet type that is loaded in the de hacker bay, this corresponds to the palletdefinition IDX field but there is no database relationship ThisLayer INT The current/next layer to be de-hacked ThisRow INT The current/next row to be de-hacked Direction INT The pallet direction in the bay ClampPosition BOOL Specifies if the de-hacker has hold of a row of blocks
[0183] For each block that has been loaded into the brick laying machine, either from the de-hacker platforms or saw offcut, an entry is made in the blockstate table. This record references the dehackoperation or sawoperation that produced the block. This is separate from the block table used for house data as a physical block may be damaged, and a second blockstate record generated for the second instance of the block in the house. Also, an offcut from the saw requires a blockstate entry, even if it hasn't yet been assigned to the house. The records specify the blocks current location on the H109, record if the cutting, routing and spigot removal have been completed, the current length of the block and the length of block removed from each end. This data is required in addition to the clamp data (described in the next paragraph) as it can track the difference between a block being damaged and discarded, vs being laid on the house. When a block is QC laser scanned, the actual block dimensions will be stored in the table.
[0184] Also associated with the blockstate table are the head flipper and laying arm logs, as these are only stored once per block. These record the start time and operation time of each operation.
TABLE-US-00013 TABLE 13 BLOCKSTATE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) blockID INT (Relation) The block that that this blockstate is refereeing to, many blockstate records can reference the same block in the case of block breakage dehackeroperationID INT (Relation) The dehackoperation that produced this blockstate, each dehackoperation can have many dehackstate records sawoperationID INT (Relation) The sawoperation that produced this blockstate, each sawoperation can have only one dehackstate record LocID INT The current location on the machine that the block is in CutComp REAL Specifies if the block has been cut to length RouteComp REAL Specifies if the block has been routed SpigotComp REAL Specifies if the spigot has been removed FrontLengthRem REAL Specifies the length of block removed from the front (front and back refer to the two block ends) BackLengthRem REAL Specifies the length of block removed from the back (front and back refer to the two block ends) CurrentLength REAL Specifies the current length of the block Long REAL The QC scanned actual length of the block Wide REAL The QC scanned actual width of the block High REAL The QC scanned actual height of the block FlipLogTime TIMESTAMP The start time of the flipper operation FlipOperationTime TIME The time taken for the flipper to complete brick delivery ArmLogTime TIMESTAMP The start time of the arm operation ArmOperationTime TIME The time taken for the arm to complete brick delivery
[0185] To complement the blockstate table, there is a locationstate table to record the state of all clamps on the machine. This table records if the clamp has a block and what its ID is. This is required in addition to the block state data as during block transfers, two clamps can be holding the same block. This data is used to prevent the machine moving two clamps apart when they both have hold of a block as it could cause damage to the machine.
TABLE-US-00014 TABLE 14 LOCATION TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) clampID INT The ID of the physical clamp on the machine clampPosition BOOL Specifies if the clamp has hold of a block BlockID INT The block type that is loaded in the de hacker bay, this corresponds to the block IDX field but there is no database relationship
[0186] To perform equipment logging, each item of equipment of has its own data structure type in a PLC. Separate buffers for each equipment struct type are used for logs across the brick laying machine. If the tail does not get appended successfully, an alarm will be raised.
[0187] Each time a piece of machine equipment moves or handles a block, the details are recorded. Typically this includes the block ID, what the equipment was doing, performance parameters and any applied corrections from the Vision system.
[0188] The conveyoroperation table records the pallet type that was loaded and operational data. The operational data consists of operation time, the mean torque, the torque standard deviation, the lag error mean and the lag error standard deviation. The operational data will aid the detection of equipment performance changes over time. Conveyor operation records are not attached to a particular house, as the blocks from a single pallet could be used to build adjacent houses without machine pack up in between.
TABLE-US-00015 TABLE 15 LOCATION TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) palletdefinitionID INT (Relation) Links to the palletdefinition that defines the pallet type loaded by the conveyoroperation record, each palletdefinition can have many conveyoroperation records LogTime TIMESTAMP The time that the operation began OperationTime TIME The time it took to perform the operation DehackerID INT The de-hacker (eg left or right) that performed the operation MeanTorque REAL The mean (average) torque of the axis during the operation TorqueDeviation REAL The statistical standard deviation of the axis torque during the operation MeanLagError REAL The mean (average) lag error of the axis during the operation LagErrorDeviation REAL The statistical standard deviation of the axis lag error during the operation
[0189] For each row removed from a pallet, a dehack operation is recorded in the dehackoperation table. This includes the results returned from the vision system. That is, the X and Y location as well as the rotation of three detected rows. The three rows are the two edge rows and the centre most row. The centre row is required as the geometry of the bays requires some pallets to be dehacked from the centre rows out. Along with the vision data, the PLC records the pallet layer and what row (of the three returned) was actually picked up. Operational logs are not stored as the de-hackers are 3d motion controlled CNC equipment, and the data cannot easily be reduced to a set of statistical values. Analysis of these drives must be performed on the axis logging data described later. The operation logs will not include the clamp operation as this is handled by the clamp exchange tables described below.
TABLE-US-00016 TABLE 16 DEHACKOPERATION TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) conveyoroperatioID INT (Relation) The conveyoroperation that that produced the pallet that this dehackoperation is being performed on, each conveyoroperation can have many dehackoperation records LogTime TIMESTAMP The time that the operation began OperationTime TIME The time it took to perform the operation LayerNo INT The layer being dehacked RowNo INT The row (of those returned from the vision system) that was dehacked PosX1 REAL Row 1 X position PosY1 REAL Row 1 Y position PosR1 REAL Row 1 rotation PosX2 REAL Row 2 X position PosY2 REAL Row 2 Y position PosR2 REAL Row 2 rotation PosX3 REAL Row 3 X position PosY3 REAL Row 3 Y position PosR3 REAL Row 3 rotation RowsDetected INT How many rows were detected by the vision system
[0190] For each cut the saw makes, a saw operation is recorded in the sawoperation table. The operation logs will not include the clamp operation as this is handled by the clamp exchange tables described below. The operational logs will hold the table axis operation time, the mean torque, the torque standard deviation and the lag error standard deviation. It will also record the saw torque standard deviation and the velocity error standard deviation.
TABLE-US-00017 TABLE 17 LOCATION TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) blockstateID INT (Relation) Links to the blockstate that that the sawoperation was performed on, each blockstate can have only one sawoperation record LogTime TIMESTAMP The time that the operation began OperationTime TIME The time it took to perform the operation MeanTorque REAL The mean (average) torque of the saw during the operation
[0191] For each block that the router cuts, a router operation is recorded in the routeroperation table. Operational logs are not stored as the router is a 3d motion controlled CNC equipment, and the data cannot easily be reduced to a set of statistical values. Analysis of these drives must be performed on the axis logging data described later. The logs will not include the clamp operation as this is handled by the clamp exchange tables described below.
TABLE-US-00018 TABLE 18 LOCATION TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) blockstateID INT (Relation) Links to the blockstate that that the routeroperation was performed on, each blockstate can have only one routeroperation record LogTime TIMESTAMP The time that the operation began OperationTime TIME The time it took to perform the operation
[0192] Each time the transfer robot moves a block from one location to another, a transfer operation log is made in the transferoperation table. This the source and destination clamp locations. The transfer can perform multiple types of block transfer and these require different logs. If the block requires an accurate pick up, the logs include the results returned from the vision system. That is, the X and Y location as well as the rotation of the block. If the transfer is to the carousel, the transfer will include a laser scan. The laser scan logs if the scan resulted in an accurate block match to the expected block. Operational logs are not stored as the transfer is a 3d motion controlled CNC equipment, and the data cannot easily be reduced to a set of statistical values. Analysis of these drives must be performed on the axis logging data described later. The logs will not include the clamp operation as this is handled by the clamp exchange tables described below.
TABLE-US-00019 TABLE 19 TRANSFEROPERATION TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) blockstateID INT (Relation) Links to the blockstate that that the transferoperation was performed on, each blockstate can have many transferoperation records LogTime TIMESTAMP The time that the operation began OperationTime TIME The time it took to perform the operation SourceLoc INT The location ID where the transfer picked up the block DestinationLoc INT The location ID where the transfer dropped off the block PosX REAL Vision system correction X component PosY REAL Vision system correction Y component PosR REAL Vision system correction rotation component BlockMatch BOOL If the transfer included a laser scan QC, this field will indicate if the scan matched the model in memory ClampGrabOp INT Refers to the clamp grab operation record, there is no actual database relationship ClampReleaseOp INT Refers to the clamp grab operation record, there is no actual database relationship
[0193] Every time a block is grabbed or released by a clamp (or platform), a clamp operation is logged in the clampoperation and clampexchange tables. These are always in pairs (giving and receiving clamp/platform) and are linked by a clampexchange table. This includes the type of operation (open/close), the clamp side (left/right for individually operated clamp sides) and the operation logs for the clamp. The operational data will aid the detection of equipment performance changes over time. The operational data consists of operation time, the mean torque and the torque standard deviation. Depending on if the clamp is a position or clamp operation, the additional data of velocity error standard deviation or lag error standard deviation is also logged.
TABLE-US-00020 TABLE 20 CLAMPOPERATION TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) blockstateID INT (Relation) Links to the blockstate that that the clampoperation was performed on, each blockstate can have only one clampoperation record LogTime TIMESTAMP The time that the operation began OperationTime TIME The time it took to perform the operation IDClamp INT The clamp that this record has been logged for OperationType BOOL Is the operation opening or closing SideClamp BOOL Specifies the left or right clamp for two piece clamps MeanTorque REAL The mean (average) torque of the axis during the operation TorqueDeviation REAL The statistical standard deviation of the axis torque during the operation VeloErrorDeviation REAL The statistical standard deviation of the axis velocity error during the operation
TABLE-US-00021 TABLE 21 CLAMPEXCHANGE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) clampoperationdestinationID INT The clampoperation that is (Relation) receiving the block, each clampoperation can link to multiple clampexchange records (give and receive) clampoperationsourceID INT The clampoperation that is (Relation) giving the block, each clampoperation can link to multiple clampexchange records (give and receive)
[0194] The vision system logging uses the database frequently. Upon start-up, the vision system will grab the details of every type of block from the database. This information is comprised of properties of the block relevant to the vision system, such as the ideal dimensions of the block, the presence of a spigot and the stacking pattern of the pallet for that block type.
[0195] This information is used frequently through all vision modules once taken from the database, but the system does not query it again, and hence the generic information flow is not documented here.
[0196] However, during operation, the database is queried for more specific information about the blocks. This information relates to the state of the block such as its current location, its measured size, its block type and its bore/channel details.
[0197] Upon completion of each vision analysis, the results are logged into the database. This information is kept for later review if required for any reason, and is detailed enough to trace any single block to all images it appears in.
[0198] The information stored is separated by module, as described in the following sections.
[0199] The dehacker module has a lot more information to log when compared to the other modules, with respect to the database. Every dehacker process has an associated dehackhalcon table with it. As with other modules, one of these records is created for every request the PLC makes.
TABLE-US-00022 TABLE 22 DEHACKHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) dehackoperationID INT Links to the dehackoperation that (RELATION) the dehackhalcon analysis was performed for, each dehackoperation can have many clehackhalcon records ErrorID INT If the analysis could not be completed, the error code returned to the PLC
[0200] Unlike other modules, the dehacker contains three tables of results, the dehackrowshalcon, dehackrowhalcon and the dehackblockhalcon. For every attempted analysis, a dehackrowshalcon record is created, along with a list of block rows, each represented by a single dehackrowhalcon entry. This entry contains the calculated effective centre of the row in 6DOF. For every block row, there exists many blocks, each block is represented by an entry in the dehackblockhalcon table, each containing the 6DOF of the block as well as the type of block. Therefore, every attempt for the dehacker vision module contains one dehackrowshalcon, comprised of many dehackrowhalcon which in turn each have many dehackblockhalcon. The three rows that are selected for PLC return, are indicated in the dehackrowhalcon records.
TABLE-US-00023 TABLE 23 DEHACKROWSHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) dehackhalconID INT Links to the dehackhalcon (RELATION) record that the dehackrowshalcon record belongs to, each dehackhalcon record can have many dehackrowshalcon records LogTime TIMESTAMP The time that the operation began
TABLE-US-00024 TABLE 24 DEHACKROWHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) dehackrowshalconID INT (RELATION) Links to the dehackrowshalcon record that the dehackrowhalcon record belongs to, each dehackrowshalcon record can have many dehackrowhalcon records ResultRow INT IF this row is a result returned to the PLC, give it the PLC return number (1-3) else this will be 0 PosX REAL The X coordinate of the row center PosY REAL The Y coordinate of the row center PosZ REAL The Z coordinate of the row center PosA REAL The A rotation of the row PosB REAL The B rotation of the row PosC REAL The C rotation of the row
TABLE-US-00025 TABLE 25 DEHACKBLOCKHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) dehackrowhalconID INT (RELATION) Links to the dehackrowhalcon record that the dehackblockhalcon record belongs to, each dehackrowhalcon record can have many dehackblockhalcon records BlockTypeID INT The block type for the block being analysed, this corresponds to the block IDX field but there is no database relationship PosX REAL The X coordinate of the block centre PosY REAL The Y coordinate of the block centre PosZ REAL The Z coordinate of the block centre PosA REAL The A rotation of the block PosB REAL The B rotation of the block PosC REAL The C rotation of the block
[0201] Every transfer operation is linked to a single table in the database named transferhalcon. This table represents the link between a PLC operation and the vision system analyses. One of these tables is created for every time the PLC commences a transfer operation to move a block from one location in the base to another location. Each of these transfers will contain one or more transferblockhalcon tables.
[0202] The transferblockhalcon table is the table which contains the actual results of each analysis. The information stored in this table both represent the detected location of the block as well as having the required information to reproduce the analysis if required. Hence, the table contains the results of the analysis as well as the state of the block and the location it is stored in. The results of the analysis being the blocks' X, Y and R locations. The state of the block describes the block at the time of analysis, with regards to its left cut amount and a right cut amount. Finally, the location state comprises of an offset X, Y and R for the analysis location, calculated via offsets provided by the PLC and offsets defined during machine setup/calibration.
TABLE-US-00026 TABLE 26 TRANSFERHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) transferoperationID INT Links to the transferoperation (RELATION) record that the transferhalcon record belongs to, each transferoperation record can have many transferoperation records ErrorID INT If the analysis could not be completed, the error code returned to the PLC
TABLE-US-00027 TABLE 27 TRANSFEBLOCKRHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) transferhalconID INT (RELATION) Links to the transferhalcon record that the transferblockhalcon record belongs to, each transferhalcon record can have many transferblockhalcon records LogTime TIMESTAMP The time that the operation began CutLeft REAL The amount of block missing on the left end CutRight REAL The amount of block missing on the right end OffsetX REAL A bay can hold multiple blocks, the represents the X coordinate offset for the block that should be analysed OffsetY REAL A bay can hold multiple blocks, the represents the Y coordinate offset for the block that should be analysed OffsetR REAL A bay can hold multiple blocks, the represents the Rotation offset for the block that should be analysed PosX REAL The actual X coordinate of the block PosY REAL The actual Y coordinate of the block PosZ REAL The actual Rotation of the block
[0203] Every QC laser scanner operation is linked to a single table in the database named laserscanhalcon. This table represents the link between a PLC operation and the vision system analyses. One of these tables is created every time the PLC passes the laser scanner with a block for the carousel, and is populated with one or more result tables. The QC results are very simple. The PLC only receives a pass or fail, with an identifier if failed. As before, there may be a number of analyses for each laserscanhalcon entry, one for each attempt.
TABLE-US-00028 TABLE 28 LASERSCANHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) transferoperationID INT Links to the transferoperation (RELATION) record that the laserscanhalcon record belongs to, each transferoperation record can have many laserscanhalcon records ErrorID INT If the analysis could not be completed, the error code returned to the PLC
TABLE-US-00029 TABLE 29 LASERSCANBLOCKHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) laserscanhalconID INT Links to the laserscanhalcon (RELATION) record that the laserscanblockhalcon record belongs to, each laserscanhalcon record can have many laserscanblockhalcon records LogTime TIMESTAMP The time that the operation began BlockMatch BOOL Does the scanned block match the 3d model of the block within a pre- determined tolerance Long REAL The scanned length of the brick Wide REAL The scanned width of the brick High REAL The scanned height of the brick
[0204] For every lay head vision operation, there exists a single table named headhalcon. This table represents the link between PLC operation and the vision system analyses. One of these tables is created for every request the PLC requests for the lay head module and is populated with one or more result tables.
[0205] For every headhalcon table there exists at least one table named headblockhalcon. This table contains the actual results of a single vision analysis, which are the 6DOF poses of the blocks. In the case of an intermittent fault, there will be more than one of these headblockhalcon table, one for each attempt.
TABLE-US-00030 TABLE 30 HEADHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) blockstateID INT (RELATION) Links to the blockstate record that the headhalcon record belongs to, each blockstate record can have many headhalcon records ErrorID INT If the analysis could not be completed, the error code returned to the PLC
TABLE-US-00031 TABLE 31 HEADBLOCKHALCON TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) headhalconID INT (RELATION) Links to the headhalcon record that the headblockhalcon record belongs to, each headhalcon record can have many headblockhalcon records LogTime TIMESTAMP The time that the operation began PosX REAL The X component position correction of the actual block location PosY REAL The Y component position correction of the actual block location PosZ REAL The Z component position correction of the actual block location PosA REAL The A component position correction of the actual block location PosB REAL The B component position correction of the actual block location PosC REAL The C component position correction of the actual block location
[0206] For every single instance of any vision result table, the vision system also stores several images used and created during the analysis in a standardised location. These images include the raw image from the image device, as well as various other forms of data generated during analysis. The filenames of the files describe the situation when the request was made.
[0207] For example, the filename Logs/B1/TM/T8-1-F1P refers to:
[0208] House 1, Transfer Master, Transfer location 8, PLC operation ID 1, Faulted attempt 1, Processed.
[0209] For the dehacker, the raw image and a processed image are stored for every dehackhalcon entry. The processed image being the image after being rectified into global co-ordinates and has the locations of each block and row marked.
[0210] Dehacker entries are stored with the identifier D#, where # is the ID of the dehacker. The file prefixes match the identifier.
[0211] The transfer stores the raw image from the relevant camera and the processed image after being mapped into the world co-ordinate system, with the detected block outlined.
[0212] These entries are stored with the identifier TM, with the individual entries prefixed T#, where # is the location ID.
[0213] For every laserscanhalcon entry, the raw image from the laser scanner is stored, as well as the point cloud represented in the image, the point cloud of missing points, and the point cloud of extra points. For later reference, the match location of the block in the point cloud is also stored, despite not being relevant to operation.
[0214] QC entries are stored using the identifier QC. With files being prefixed also with QC and suffixed with the content type, where M refers to missing and E refers to extra. Example: QC-2, QC-4-F2M or QC-6-F1E. In theory, there should not be a M or E file for a perfect block.
[0215] For the layhead, all raw images from the camera array as well as the calculated point cloud from the images are stored for every headhalcon entry.
[0216] Layhead entries are stored using the identifier LH, with the numerous images prefixed Lb 1 to L6.
[0217] All axis and instruments have normal logging of operational data. As a drive is operating it will check the following parameters: [0218] Lag between setpoint and actual position of drive (PositionLag) [0219] Velocity of drive [0220] Acceleration of drive [0221] Torque of drive [0222] Distance travelled by drive
If any of these change by a significant amount (amount is configurable) an event will be triggered to create a log in the database. Regardless of the trigger for logging, the following variables will be stored:
TABLE-US-00032 TABLE 32 DRIVE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) DriveID INT unique ID of the drive LogTime TIMESTAMP The time that the log was generated TotalDistance BIGINT Total distance travelled by drive at this point in time ExecutePosition BOOL Drive is being commanded to move to the set point PositionSP REAL Drive position set point from the controller Position REAL Drive position at time of logging PositionLag REAL Drive position lag (difference between setpoint and actual position) at time of logging Velocity REAL Drive velocity at time of logging Acceleration REAL Drive acceleration at time of logging Torque REAL Drive torque at time of logging
[0223] This data will be stored within a custom-made drive-log structure. This will then be appended as a tail to a buffer of axis log structures. The buffer will be used for all axis logs across the machine. If the tail does not get appended successfully, an alarm will be raised.
[0224] A drive that is defined as a DriveReference will store the above variables, as well as the position, velocity and acceleration relative to the parent that it is referencing. The data will be stored within a custom-made DriveReference-log structure. The buffer will be used for all DriveReference logs across the machine. If the tail does not get appended successfully, an alarm will be raised.
TABLE-US-00033 TABLE 33 DRIVEREFERENCE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) DriveID INT unique ID of the drive LogTime TIMESTAMP The time that the log was generated TotalDistance BIGINT Total distance travelled by drive at this point in time ExecutePosition BOOL Drive is being commanded to move to the set point PositionSP REAL Drive position set point from the controller Position REAL Drive position at time of logging PositionLag REAL Drive position lag (difference between setpoint and actual position) at time of logging Velocity REAL Drive velocity at time of logging Acceleration REAL Drive acceleration at time of logging Torque REAL Drive torque at time of logging ExecutePositionRef REAL Drive is being commanded to move to the referenced position SP PositionRefSP REAL Drive referenced position SP from the controller PositionRef REAL Drive referenced position at time of logging VelocityRef REAL Drive referenced velocity at time of logging AccelerationRef REAL Drive referenced acceleration at time of logging
[0225] A drive that is defined as DriveClamp will store the same variables as a DriveReference, as well as total distance the clamp apparatus itself has travelled. It also records the clamp operation state (what the clamp is doing). The data will be stored within a custom-made DriveClamp-log structure. The buffer will be used for all DriveClamp logs across the machine. If the tail does not get appended successfully, an alarm will be raised.
TABLE-US-00034 TABLE 34 DRIVEREFERENCE TABLE DESCRIPTION Field Type Description IDX INT (Primary Key) DriveID INT unique ID of the drive LogTime TIMESTAMP The time that the log was generated TotalDistance BIGINT Total distance travelled by drive at this point in time ExecutePosition BOOL Drive is being commanded to move to the set point PositionSP REAL Drive position set point from the controller Position REAL Drive position at time of logging PositionLag REAL Drive position lag (difference between setpoint and actual position) at time of logging Velocity REAL Drive velocity at time of logging Acceleration REAL Drive acceleration at time of logging Torque REAL Drive torque at time of logging ExecutePositionRef REAL Drive is being commanded to move to the referenced position SP PositionRefSP REAL Drive referenced position SP from the controller PositionRef REAL Drive referenced position at time of logging VelocityRef REAL Drive referenced velocity at time of logging AccelerationRef REAL Drive referenced acceleration at time of logging ClampTotalDistance BIGINT Total distance travelled by the clamp at this point in time OperationState INT (ENUM) What is the clamp doing: 0no command 1opening 2open 3closing 4closed
[0226] The design and control software of the invention provides a complete solution from design through to completed build, of any structure that may be built from bricks or blocks using a brick laying machine.