3D MULTI-THREADED, PARAMETER LAYERED, PHYSICAL PROGRAMMING INTERFACE

Abstract

A physical programming interface with a multi-threaded command sequencing which distinguishes between functions and parameters, by separating them to different planes (horizontal and vertical), and associates the parameter quantitative size and it's functionality with their physical appearance and dimensions. The association also enables an automatic physical debugging system to prevent the user from compilation errors by one-to-one or one-to-many relationship, or using lights to inform on functional errors.

Claims

1. A physical programming interface with a multi-threaded command sequencing, distinguishing between functions and parameters, by separating functions into different planes (horizontal and vertical), and associating the parameter quantitative size and its functionality with their physical appearance and dimensions. comprising: different kinds of stackable or non-stackable interlock blocks: three kinds of blocks: play blocks, function blocks, and parameter blocks; and electrical components; and a receptor; and parameter plates; and Parameter Extension plates; and programmed elements; and an automatic error prevention system by one-to-one relationship; and wherein function blocks comprise: a unique function block (me button); a read function blocks; and save function blocks, and Wherein interlock blocks comprise spring-based connectors over a function block, transmitting data and current flow between connected function blocks and play blocks; and Wherein the value of parameter block is read by electrical components.

2. A system of claim 1 wherein function block has a special parameter receptor suitable to one or more parameter blocks having different geometry shapes, wherein receptor's upper surface fits the shape of parameter block bottom surface.

3. A system of claim 1 wherein parameter block has correlation between its physical dimension (height and width) and its logical value Influence is effected by stacking parameter blocks or by using higher or wider parameter blocks.

4. A system of claim 1 wherein mixed stackable parameter and function blocks may be used, with and/or without spring-based connectors.

5. A system of claim 1 wherein a code thread-branching may be preform with any function block and/or play block.

6. The system of claim 5 wherein the number of thread-brunching in each branching-point is set by the number of walls of each shape, subtracting 1.

7. A system of claim 1 wherein pointers to other function blocks may be performed by using parameters blocks as variables.

8. A system of claim 1 wherein run-time running indication is indicated by lightning up the function blocks when a programmed element is preforming during run-time operation.

9. A system of claim 1 wherein an error prevention indication lights up a function block when a wrong parameter block has been placed on a function block.

10. A system of claim 1 wherein an error prevention indication lights up when there is a logical error in function flow.

11. A system of claim 1 wherein a function block reads from multiple function blocks.

12. A system of claim 1 wherein a Me button is positioned on a function block allowing user to run a specific function block out of a series of connected function blocks without activating the entire program sequence.

13. A system of claim 1 wherein a Me button is positioned on a function block allowing the user to run a set of function blocks, such as open loop, close loop, and all other function blocks contained in between, without activating the rest of the function blocks which are not contained in between.

14. A system of claim 1 wherein a function block, reads from multiple function blocks

15. A system of claim 1 wherein a program made out of several function blocks and parameter blocks may be stored using save function block.

16. The system of claim 14 wherein memory for stored functions may be placed on read function blocks, on play block or on programmed element.

17. The system of claim 1 5 wherein stored programs may be read by read function blocks and further repeat the stored program.

18. The system of claim 16 wherein stored programs may be used for changing the values of parameter blocks.

19. The system of claim 1 wherein parameter plates are used to control a large number of parameter blocks.

20. The system of claim 1 wherein programmed elements may be controlled by stackable or non-stackable parameter blocks in plural or single manner.

21. The system of claim 1 wherein play blocks communicate with plural different programmed elements in parallel.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] FIG. 1is a perspective view of invention's component: Function Block (100), Parameter Block (200), Play Block (300), and the Programmed Elements (400).

[0024] FIG. 2Is front, top, and bottom view, showing the way Function Blocks and Play Blocks are interlocked on Base Plate (500).

[0025] FIG. 3is a schematic circuit diagram of one embodiment of the present invention, showing the connection of a plurality of Function Blocks (100(1)), (100(2)) and Play Block (300). The numbers in inverted commas indicate order of movements and Spring-Based (600) shows the connection for data and current flow.

[0026] FIG. 4 is a schematic circuit diagram showing the connection between a Function Block and Parameter Blocks. This figure also illustrates a physical correlation between different Parameter Blocks logical values to their physical dimension.

[0027] FIG. 5 is a schematic circuit diagram of another embodiment of the present invention, showing the connection of a plurality of blocks, standard size non-stackable parameters (200a); standard size stackable parameter (200b); 3 standard size stackable parameters (200c) and triple size stackable parameter (200d), all formulating a specific program to a Programmed Element using wired or wireless communication.

[0028] FIG. 6 is a top perspective view of an example for a Function Block with its various parameters.

[0029] FIG. 7 is a top perspective view of parameter block.

[0030] FIG. 8 is a schematic circuit diagram, showing program over a Physical Programming Interface using single multi-threading by a Function Block or by a Play Block.

[0031] FIG. 9 is a schematic circuit diagram showing program over a Physical Programming Interface using plurality of multi-threading by a Function Block.

[0032] FIG. 10 is a chronical flowchart showing a code transmitted to the robot, corresponding to FIG. 9 hereto.

[0033] FIG. 11 is a schematic circuit diagram of one embodiment of the present invention, showing a Function Block that returns a value, which is used by other Function Blocks.

[0034] FIG. 12 is a schematic circuit diagram showing the Electrical Connectivity (700) between Function Block to one or more Parameter Blocks.

[0035] FIG. 13 shows a Function Block which lights up to indicate that this is the specific Function Block currently activated in the Programmed Element.

[0036] FIG. 14 shows Error Prevention by using one-to-one relation between Receptor (800).

[0037] FIG. 15 shows Error Prevention when there is a logical error in the Function flow.

[0038] FIG. 16 is a schematic circuit diagram of one embodiment of the present invention, showing one Function Block, which reads data from two Function Blocks.

[0039] FIG. 17 is a schematic embodiment of the present invention showing the me button (900(a)). The Me button is positioned on a function block allowing user to run a specific function block out of a series of connected function blocks without activating the entire program sequence.

[0040] FIG. 18 is a schematic circuit diagram showing how a program made out of several Function Blocks (100(2)), (100(3)) may be stored for reuse in other instances using a save Function Block (100a) by pressing the me store button (900(b).

[0041] FIG. 19 is a schematic circuit diagram showing how the user may change parameters of a Stored Program dynamically.

[0042] FIG. 20 is a schematic circuit diagram showing a Stored Program communicating with a computer or a tablet wired or wireless.

[0043] FIG. 21 is a schematic circuit diagram showing how a Parameter Plate (1000) may be used to extend the number of Parameter Blocks, which can be used as inputs in the Stored Program.

[0044] FIG. 22 is a schematic circuit diagram showing how a Play Block (300) may control different Programmed Elements (400).

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0045] FIG. 1, shows a perspective view of invention's components: Play Block (300), Function Block (100) and Parameter Block (200) and the Programmed Elements (400). The Play Block and Function Block (100) are placed on an interlocked Base Plate (500) to ensure conductivity between every Function and Play Blocks, (FIG. 2).

[0046] A Spring-Based (600) connection for data and current flow is shown in FIG. 3. Each Play Block (300), and Function Blocks (100(1)) & (100(2)) are connected by one or more Spring-Based (600) which are electrical connectors allowing data and current flow, FIG. 3. Electrical plurality connections of Parameter Blocks (200) are shown in FIG. 4. In addition, Parameter Blocks (200) may be: standard size non-stackable block (200(a)), standard size stackable block (200(b)), multiple standard size non-stackable block (200(c)) and stackable blocks (200(d)), to enable the correlation between their physical dimensions (height and width) and its logical values.

[0047] In order to formulate a program using the current invention, user needs at least one Play Block (300) to communicate with the Programmed Element (400) and one Function Block (100) to determine a specific function. Parameter Blocks (200) may or may not be included according to the requirement of the function. Meaning that a program may include more functions and parameters in different combinations. For example, read from sensor Parameter Block (200) may be stacked over a 2 seconds Parameter Blocks (200) (FIG. 6). Another example is a diagram of an embodiment meant for generating a light blinking code for 20 times of the Programmed Element (400) (FIG. 5).

[0048] Play Block (300) is connected to Function Block (100(1)), which has two Parameter Blocks (200b(1)). Each of Parameter Blocks (200b) holds the information for 10 iterations, thus forming a repetition of 20 iterations in total (FIG. 5). Following Function Block (100(2)) activates the light for one second followed by light closing Function Block (100(3)). The last Function Block, which determines the end of the code, is close loop Function Block (100(4)).

[0049] Parameter Blocks (200) may be in different embodiments and different shapes in order to illustrate a correlation between their physical and logical values. For example, FIG. 6 shows a specific Function Block (100) (Move Motor) with various Parameter Blocks (200):

(1) Operate motor A (200b(1)), Motor B (200b(2)), and Motor C (200b(3)),
(2) Set motor polarity (200(a)), which determines the turning direction of Move Motor (100) (clockwise or counter clockwise)
(3) The duration of motor (200b(4)) and motor speed (200(d)).

[0050] Parameter Blocks (200), which are used, were previously introduced in FIG. 4.

[0051] Parameter Blocks (200) may come as stackable (200(b)), non-stackable (200(a)) and in different combinations thereof as shown in FIG. 7, where stackable Parameter Block (200(a)) is placed on another stackable Parameter Block (200(a)) and a non-stackable Parameter Block (200(b)) is placed on a stackable Parameter Block (200(a), thus allowing combination of Parameters Blocks (200) from different families (Values obtained from sensors, constant, or others).

[0052] The invention also enables code branching in each one of Play Blocks (300) and Function Blocks (100) of the code. As Play Blocks (300) and Function Blocks (100) contain electronic conductors on all sides, as shown on FIG. 8, where three code branching may occur in any of them.

[0053] The invention is not limited to squared shapes only, and Function Block (100) may create a rectangle with N walls of Function Block (100), the branching code enables (N1) branches from every branching point in the code. Furthermore, there is no limitation for code branching as shown in FIG. 9. A flow chart of the code is shown in FIG. 10, demonstrating the hierarchy of the code in one direction (up to down).

[0054] The invention may also demonstrate the concept of pointers, in which one Function Block (100) points to another Function Block (100), without the need to be directly connected to it; this concept simulates using pointers in programming. FIG. 11 demonstrates how a Move Motor Function Block (100(1)) may use a result calculated by Calculator Function Block (100(2)). A logical operation of add is conducted between two Parameter Blocks (200b(1)) & (200(d)) using operator Parameter Block (200b(2)). The result is represented by Parameter Block (200(a)), which also appears on move motor Function Block (100(1)), thus allowing the use of the calculated result for other Function Blocks (100).

[0055] Each of Parameter Blocks (200), which are placed, (in a stackable or non-stackable manner), on Function Block (100) have a specific value, which is transmitted to Function Block (100) using Electrical Components (700) (FIG. 14.

[0056] The invention also enables a runtime debugging by lighting up Function Block (100) whenever Programmed Element (400) performs a specific corresponding Function Block (100), (FIG. 13).

[0057] The invention also enables Error Prevention mechanisms in two ways: (1) the physical size of Parameter Block (100), which has to be similar to Receptor (800) of Function Block (100). In case of placing an unsuitable shape of Parameter Block (200) on Function Block (100), an Error Prevention light turns on (FIG. 14). Similar Error Prevention takes place when creating a circular hierarchy (FIG. 15). In this case, the thread, which Function Block (100(2)) is part of, is not well defined, as it may be considered as part of two threads: (1) as part of the thread going out from the right wall of Play Block (300) through Function Block (100(1)), or (2) as part of a thread going out from the bottom wall of Play Block (300) through Function Block (100(3)).

[0058] Such hierarchical failure described hereto lights up an Error Prevention notification on Function Block (100(2)). Nevertheless, the invention may connect two threads into one Function Block (100) using Read from Function of Function Block (100).

[0059] FIG. 16 shows yet another embodiment as an example for Read from Function, where Function Block (100) reads from many Function Blocks. Where two threads are combined into a single thread (FIG. 16), Threads Combining Point (100(1)), moves forward to Make Sound Function Block (100(2)) only after the two threads have finished.

[0060] A program may be stored and re-used using a Function Block (100a) with saving capabilities, by pressing the me store button (900(b)) (FIG. 18). Function Block (100a) has a Parameter Block (200e(1)) with a unique address and physical shape for identification. The Stored Program is reused by attaching a read Function Block (100b) that knows how to read the specific function using the same unique Parameter Block (200e(2) which is now physically placed on the Function Block 100b, (FIG. 18).

[0061] FIG. 19 shows yet another embodiment where in several cases when programmer wants to dynamically change and control the parameters of the stored function using Parameter Blocks (200b(1)), (200b(2). For this matter a Function Block (100a) with several Parameter Blocks (200g(1)), (200h(1) is used.

[0062] Each Parameter Block (200g(1)), (200h(2) is a unique pointer to another Parameter Block (200(g(2)), (200(h(2)), which then may be reused by placing Parameter Blocks (200(b(1)), (200c) on read Function Block (100b). The Parameter Blocks (200g(1)), (200h(1), (200g(2)), (200h(2)) may be reused more than once in a plurality of appearances. The saved program may be stored either on Play Block (300) or in save Function Block (100a) by pressing the me store button (900(b)).

[0063] Similarly, a program may be stored or read by communicating with a Programmed Element (400) wireless or wired, (FIG. 20). i.e., reading Function Block (100b) to a computer or saving to a computer, by using save Function Block (100a).

[0064] FIG. 21 shows yet another embodiment where in case there is a need to use a large number of Parameter blocks (200)(f), for example in Function Block 100, i.e. larger than the number of available Receptors (800) in Function Block (100) a Parameter Plate (1000) may be used. Parameter Plate (1000) is placed on top of a supporter Block (1000) which contains also Electrical Components (700). The electrical connection and communication is conducted through a Parameter plate (1000) which is electrically wired to the Function Block (100) and includes a place for several Parameter Blocks (200).

[0065] FIG. 22 shows yet another embodiment disclosing how a Play Block (300) may control different Programmed Elements (400) using stackable Parameter Block (200(a)) or non-stackable Parameter Block (200(b)). I.e. changing Parameter Block (200) enables communication with one or more robots, or different types of robots or other Programmed Elements 400.