Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic Rhapsody (steve huntington)
Decrease font size
Increase font size
Topic Title: Distributed Power Supply
Topic Summary:
Created On: 21-Nov-2005 18:32
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 21-Nov-2005 18:32
User is offline View Users Profile Print this message


Edmund Mayer

Posts: 179
Joined: 30-Apr-2005

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.


Report this to a Moderator Report this to a Moderator
 17-Jan-2006 14:17
User is offline View Users Profile Print this message


Jesper Gissel

Posts: 88
Joined: 20-Jul-2005

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
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic Rhapsody forum.
There are currently 1 users logged in.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.