## 3 Development of a Dynamic Model of the Robotino with Bond Graphs
### Named Pipe Communications and Simulation  
The _named pipe_ is a two-way IPC mechanism, which enables the transfer of data between two or more applications on the same computer, or on computers connected in a local net. Any applications can serve both as server and a client, making two-way communications possible. However, only one application creates the named pipe: it is termed the _server_. Those that connect to the first application are called clients.  
In this scenario, there is one server, BondSim3 DVisual, and one client, BondSim implemented on the same computer. After a project is opened on the first one and the scene is created, we create the named pipe using the command Open Pipe. After the pipe is created, a message is sent inviting the client to connect to it.  
To connect to the server, we activate the BondSim applications and open the bond graph problem corresponding to the virtual project we created in the server. We manipulate the frames of both applications to make them both visible on the computer screen.  
The bond graph model contains an **IPC** component in the form of a ring (or pipe cross-section) (see the top of Figure 31). It has an input signal port that serves to connect the signal lines, which transfer data across the pipe to the server, and an output port that receives the signal data returned by the pipe. After all the IPC ports are connected, we build a mathematical model of the BondSim application. If the building of the model is successful, we can start the simulation. Before starting the simulation, we need to connect it to the server using the corresponding command under the _Build_ menu.  
There is one other parameter that needs to be defined at the start of simulation. This is the Frames per second (FPS) parameter. The visual screen in BondSim3 DVisual is updated by sending data over the pipe at discrete times. Every pack of data generates a picture displayed on the screen; this is called a frame (following film terminology). The question of how often we need to send data is answered by the fact that the human brain can process 10 to 12 FPS, which are received by our eyes as steady pictures; higher rates are recognized as motion. The time interval when the packs are sent over the tube is currently set to 30 ms, or about 33 FPS.  
Every pack of data that is sent by the client consists of a series of binary values of the joint drive's angular or prismatic displacement (see Figure 6b), ordered by counting joints in the XML model tree starting from the root and moving to the tree top (Figure 10). Thus, the first value corresponds to the first joint bellow the root, the second datapoint to the next joint, etc. After the pack is received by the server, it reads it and sends the first datapoint to the first joint drive, the second to the second joint drive, etc. Thus, the pack coding is very simple and easy to decode. After receiving data, the geometry of the mechanism is reevaluated and the screen updated. Repeating the package sending and updating the screen appears as the motion of mechanism over the screen.  
A similar observation can be made of the date packs sent from the server to the client. Because these data currently contain only the coordinates of the probe (in the Robotino model, a small red ball below its body), when received by the client, these have to be taken into account.