![]() |
Telelogic Rhapsody (steve huntington) | ![]() |
Topic Title: Distributed Power Supply Topic Summary: Created On: 21-Nov-2005 18:32 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|||
Subject: TCP/IP Sockets example
Model: Rhapsody in C++ 6.1 and Rhapsody in J 6.1 The attached model is provided as two projects, one RiC++ and one RiJ: PowerSupply_WithNetworking_Cpp.rpy - used to generate server executable and client executable PowerSupply_GyrosAndSensors_Java.rpy - used to generate client executable Note - You don't need the StaticEventIdentification.zip file. See 9 below. The attached model can be run as a standalone C++ application (one executable) or as a networked application (one C++ server and one or more C++ or Java client executables talking to the server executable). When networked, the GyrosAndSensorsComponent "client" executable uses TCP/IP to send velocity updates to the MIPLS_PowerSupplyComponent "server" (a different executable). The TCP/IP interface between the GyrosAndSensorsComponent and the MIPLS_PowerSupplyComponent demonstrates a very basic integration between two executables. Typically the networking parts are put into a different package, and often this Network package is actually in a different Rhapsody project and simply referenced by the Rhapsody project that needs the networking capability. To run the networked application: 1) Before opening the model, put the two attached .bmp files in your $OMROOT\PredefinedPictures directory. This is an optional step. 2) In the RiC++ or RiJ project, look at the deployment diagram in package Deployments to see the architecture. 3) In the RiC++ project, Build the Debug configuration of the FinControllerComponent. The resultant library is needed by the MIPLS_PowerSupplyComponent. 4) In the RiC++ project, the server component is the MIPLS_PowerSupplyComponent component, and the GyrosAndSensorsComponent is the client. Here's how to build and run them: - Set the GyrosAndSensorsComponent's Release configuration as the current configuration. Do a Generate and Build from the Rhapsody Code menu. - Set the MIPS_PowerSupplyComponent's Debug configuration as the current configuration. Do a Generate/Make/Run from the Rhapsody Code menu. - When you get the animation toolbar, press Go. Optionally view the RateProcessor instance statechart (in package Domains::Guidance). - In Windows Explorer, start the GyrosAndSensorsComponent running by double clicking on the <yourDirectory>\PowerSupply_WithNetworking_CppGyrosAndSensorsComponent\Release\GyrosAndSensorsComponent.exe. - Look at the two black output windows and the animated diagrams in Rhapsody. You should see the GyrosAndSensorsComponent sending 1Hz velocity updates to the MIPLS_PowerSupplyComponent component, which in turn stores the data and then updates the FinControllerComponent at a rate of 2Hz. - In Windows Explorer, start another GyrosAndSensorsComponent by double clicking on the same executable. Now two clients are sending velocity updates to the single server. 5) Here's how to build and run the Rhapsody in J client. - While the animation is still running in RiC++, start RiJ and select Yes when Rhapsody asks if you want to continue (animation will be disabled in RiJ for this session). - Set the GyrosAndSensorsComponent's Release configuration as the current configuration. Do a Generate/Make/Run from the Rhapsody Code menu. - You should now see another black output window showing the sending of velocity updates to the RiC++ generated server. 6) The RateProcessor class is an active-class, so it runs in its own thread, and doesn't fall behind in its processing. You can see velocity updates coming in from the GyrosAndSensorComponent, and velocity updates going out to the FinControllerComponent. 7) The implementation of the Networking package has been abstracted away from the application. It could be TCP/IP (as it is in this model), shared memory, or another protocol. 8) This is a basic solution, with all components running on Windows and the Windows Sockets API (WinSock). Another example might show how asynchronous events can be sent across processor boundaries, for example between a Windows executable and a VxWorks executable. 9) This model also comes with the StaticEventIdentification.zip file which includes its own Readme.txt. Enclosed in the zip is an approach for statically defining event identifiers to facilitate the sending of events between distributed applications. Although not done yet, the static event ID approach could be incorporated into the PowerSupply example.
|
|||
![]() |
|||
![]() |
|||
Just a coment on this otherwise brilliant model.
The situation: The GyrosAndSensorsComponent clent is started before the MIPLS_PowerSupplyComponent server, and the expected result occurs: The client reports an error. When the server is started the connection is established as expected, but then nothing hapens... No velocity messages are send! This behavior is due to, after my opinion, a beginners mistake in designing Rhapsody statecharts! The GuidanceUnit_Subsystem has a statechart with a single timeout transition with a guard and an action. The problem is that if the guard is evaluated to false, the timeout never fires again, since the timer only restarts when a state is entered! The solution: The timeout transition should lead to a condition conector with two outgoing transitions: One with the original guard and action, and one with a simple [else] guard. This way the timer restarts every time the [else] transition is taken. It is nice to see, that it is not only us "mortals" that tends to make these mistakes... ![]() ------------------------- Jesper Gissel Johnson Controls Denmark, Marine Controls |
|||
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.