Rhapsody TechBlog

BLOG about IBM Rhapsody. Contains technical information as well as more private travel stories.

Page 8 of 16

Reverse Engineering for Dummies

How to import external sources to an Rhapsody Model

Sometimes it is necessary  to use data-types and/or functions defined in header files given by an other developer. In this case the best way is to import these header files as external files to the working model. For external files no code is generated.

In the following article two models are mentioned. A working model with whom the application is developed and an import model to perform Reverse Engineering.

1 – Initial import

To import external sources to a Rhapsody model Reverse Engineering can be used. In the following steps the import process is described.

    1. Open Rhapsody (depending on the language of the given source files choose Rhapsodoy in C or Rhapsody in C++)
    2. Create a new project (the import model).
    3. Open Tools > Reverse Engineering
    4. Choose Logical Modelling

      image2018-9-10_15-46-7

    5. Browse to file which have to be imported and select them.
      image2018-9-10_15-49-12
    6. Click Next and set External elements and Single top level package.
      image2018-9-10_15-52-38
    7. Import files with Next  and Finish. After that you should get something like in the next figure

      image2018-9-10_16-1-0
      At the package icon the small yellow arrow shows that no code is generated for the content of this package.

    8. (Optional) If the sources are in C and should be used in an C++ model (the working model) the language of the unit has to be changed to C++. With a right click of the package open the context menu and choose Unit > Edit Unit… and open the following window.
      image2018-9-10_16-6-26
      Switch the language to C++ and click OK.
    9. Close the import model and open the working model in which the sources should be used.
    10. Choose  File > Add to model… and browse to the created package.
      image2018-9-10_16-14-15
      As options choose As Unit and Copy Into Model.
    11. Now the data-types and functions can be referenced in the working model. In the following picture some samples of usage are shown.

      Select return type

      or argument type

      image2018-9-10_16-23-9

      or with the shortcut Ctrl + Space in the implementation.

image2018-9-10_16-24-40


Attention

When executed again, other GUID are assigned to the data types and functions. As a result, they are no longer recognised in the working model and must be reassigned.
If changes occur to the imported sources, they must be manually added to the imported package.
To prevent accidental overwriting, it is recommended to delete the import model used for reverse engineering after importing the package into the working model  


2 – Add additional header files

If new header files has to be imported to the externalSources package proceed as follows:

  1. Open Rhapsody (depending on the language of the given source files choose Rhapsodoy in C or Rhapsody in C++)
  2. Create a new project (the import model).
  3. Open Tools > Reverse Engineering
  4. Choose Logical Modelling

    image2018-9-10_15-46-7
  5. Browse to file which have to be imported and select them.

    image2018-9-12_9-59-0
  6. Click Next and set External elements and Single top level package. Choose another package name (externalSources_new) than in the working model.

    image2018-9-12_10-2-12


  7.  Import files with Next  and Finish. After that you should get something like in the next figure.
    image2018-9-12_10-3-44At the package icon the small yellow arrow shows that no code is generated for the content of this package.
  8. (Optional) If the sources are in C and should be used in an C++ model (the working model) the language of the unit has to be changed to C++. With a right click of the package open the context menu and choose Unit > Edit Unit… and open the following window.
    image2018-9-12_10-5-34
    Switch the language to C++ and click OK.

     

  9. Close the import model and open the working model in which the sources should be used
  10. Choose  File > Add to model… and browse to the created package.
  11. Now the new file can be moved to the externalSources package. It is easier to handle only one external package.
    image2018-9-12_10-8-4
  12. After that you should get something like in the next figure.
    image2018-9-12_10-9-56
  13. Now the new file can be moved to the externalSources package. It is easier to handle only one external package.
  14. Following video shows step 9 to 13:
    [wpvideo aFGPYz13]

     

That was it! Thanks to Dennis Koelbel for creating this article and video!

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

(Un-)Installing and Configuring Rhapsody

Uninstall Rhapsody

Uninstalling is easy, when you know what to do…

[wpvideo 6icZXjQk]

Installing Rhapsody

This video tells you what options you have to install Rhapsody. It gives a proposal for the best way to do it.

[wpvideo icJnAjFR]

Configuring Rhapsody

And when installed, you have to know how to start the correct version. This video helps!

[wpvideo Bk3M0Y63]

So… that’s it for today

Have fun with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

(Un-)Installing and Configuring Rhapsody

Uninstall Rhapsody

Uninstalling is easy, when you know what to do…

[wpvideo 6icZXjQk]

Installing Rhapsody

This video tells you what options you have to install Rhapsody. It gives a proposal for the best way to do it.

[wpvideo icJnAjFR]

Configuring Rhapsody

And when installed, you have to know how to start the correct version. This video helps!

[wpvideo Bk3M0Y63]

So… that’s it for today

Have fun with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Da Boston Broker

Introduction

This week I’m in Boston at a customer that is starting a new project. I’m helping setting it up, setting up the model and the rest of the development environment.

In the beginning of our Rhapsody days, we were always happy to tell people we were the experts in “Systems with limited resources”. Now. in fact, we still are, just because we have a lot of experience in that area. I don’t think many people know how to handle the specific requirements of modeling in small 8- or 16bit systems with kilobytes of memory and microseconds to respond.

But slowly we have been growing with our customers and we also do larger systems. This week I helped setting up a “larger” system. This a “normal” PC with Linux on it, accompanied by a couple of other boards that do small tasks (and have smaller controllers!)

The use of Linux as operating system immediately introduced one big question: how are we going to implement a framework?
Linux has processes and threads. ( See BLOG entry ) Are we using a distributed framework? Or the normal framework with Threads?
Both have advantages and disadvantages. Distributed Framework is more difficult to implement but just threads will influence the way you can use your system and will not give you all the advantages of memory protection.

We decided to use both ways with a “simple” framework and use IPC to communicate. So we would actually use multiple applications that communicate with the use of the OS.
The trouble with IPC is always that you need some base information to start the communication. You can use a “zeroconf” system like Apple’s bonjour where every client starts and assumes it is the “Master” until it finds another client that already is the master. Or you create a Master that is known by all clients.

We have chosen the last variant. A Master-broker is in the system, waiting and listening on a fixed IPC Channel. Clients report to that Channel with their name and the Master sets up the communication. The client then opens up for its local clients to publish/subscribe that it will communicate with the Master-broker that registers all clients in the complete network. C++ makes a lot of this easier.

It was real fun to set this up. Most work was spend on setting up the development environment and describing how to use it. We use GIT and Sharepoint to do that.
The compiler/IDE is Eclipse in Ubuntu Linux, we deploy code to a shared directory with Windows. IPC on Linux is done with named pipes.

We spend some tie setting up the Rhapsody model so that the package structure was logical and ready for use by multiple people. The model will contain a lot of components that must be built separately. Luckily you can tell Rhapsody to “build all” (which will generate and deploy all in our case) Eclipse can also build a complete project with multiple executables. We also built some test tools to test the Broker setup.

This is what many people underestimate when starting to use MBSE. The UML Tool will not do that for you. It is a a UML Tool, UML is a language, not a process nor a development environment. It is very important to spend time setting that up and documenting it. Use a central documentation tool like Confluence, Sharepoint or MediaWiki, your success depends on it!

So… just work in Boston? Nope… in my 3rd Boston visit I finally had the time to visit “Cheers”, the bar of one of my favorite TV series.
I’ll end this one with a quote from Norm:

“Can I pour you a beer, Mr. Peterson?”
“A little early isn’t it, Woody?”
“For a beer?” “No, for stupid questions.”

“Cheers!” and Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

Da Boston Broker

Introduction

This week I’m in Boston at a customer that is starting a new project. I’m helping setting it up, setting up the model and the rest of the development environment.

In the beginning of our Rhapsody days, we were always happy to tell people we were the experts in “Systems with limited resources”. Now. in fact, we still are, just because we have a lot of experience in that area. I don’t think many people know how to handle the specific requirements of modeling in small 8- or 16bit systems with kilobytes of memory and microseconds to respond.

But slowly we have been growing with our customers and we also do larger systems. This week I helped setting up a “larger” system. This a “normal” PC with Linux on it, accompanied by a couple of other boards that do small tasks (and have smaller controllers!)

The use of Linux as operating system immediately introduced one big question: how are we going to implement a framework?
Linux has processes and threads. ( See BLOG entry ) Are we using a distributed framework? Or the normal framework with Threads?
Both have advantages and disadvantages. Distributed Framework is more difficult to implement but just threads will influence the way you can use your system and will not give you all the advantages of memory protection.

We decided to use both ways with a “simple” framework and use IPC to communicate. So we would actually use multiple applications that communicate with the use of the OS.
The trouble with IPC is always that you need some base information to start the communication. You can use a “zeroconf” system like Apple’s bonjour where every client starts and assumes it is the “Master” until it finds another client that already is the master. Or you create a Master that is known by all clients.

We have chosen the last variant. A Master-broker is in the system, waiting and listening on a fixed IPC Channel. Clients report to that Channel with their name and the Master sets up the communication. The client then opens up for its local clients to publish/subscribe that it will communicate with the Master-broker that registers all clients in the complete network. C++ makes a lot of this easier.

It was real fun to set this up. Most work was spend on setting up the development environment and describing how to use it. We use GIT and Sharepoint to do that.
The compiler/IDE is Eclipse in Ubuntu Linux, we deploy code to a shared directory with Windows. IPC on Linux is done with named pipes.

We spend some tie setting up the Rhapsody model so that the package structure was logical and ready for use by multiple people. The model will contain a lot of components that must be built separately. Luckily you can tell Rhapsody to “build all” (which will generate and deploy all in our case) Eclipse can also build a complete project with multiple executables. We also built some test tools to test the Broker setup.

This is what many people underestimate when starting to use MBSE. The UML Tool will not do that for you. It is a a UML Tool, UML is a language, not a process nor a development environment. It is very important to spend time setting that up and documenting it. Use a central documentation tool like Confluence, Sharepoint or MediaWiki, your success depends on it!

So… just work in Boston? Nope… in my 3rd Boston visit I finally had the time to visit “Cheers”, the bar of one of my favorite TV series.
I’ll end this one with a quote from Norm:

“Can I pour you a beer, Mr. Peterson?”
“A little early isn’t it, Woody?”
“For a beer?” “No, for stupid questions.”

“Cheers!” and Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

Using Rhapsody in vacation time…

Vacation!

Hi! And sorry for the low BLOG frequency. It’s vacation time. Not that I am on vacation, that would actually mean I have more time to write… No, I am busy at the moment, other are on vacation which leads to more work and I have a lot to do  privately: I’m building a new house.
That is… I have other people build me a house… As I always say: I have two right hands but unfortunately I am left-handed… (BTW: Today August 13 is international left-hander day!!)
So I do not build but that does not mean my work is done… there is a lot to do besides physically building.
So we did not planned a holiday because the house should have been finished around this time….
“Should have been”?? Yep. It’s not.

When software projects go rogue and take longer than planned, one of the things people (non-involved people…) say is: “These software projects… always late… they should learn how to plan just like the people who build houses.”
Well…. That is just sooo not true.. building projects also go rogue. Mine does but others do as well.
Builders plan but the same way software people plan. So plenty of space for mistakes and “unknown”
In my case the architect designed my house with a CAD tool. Not a very advanced one, I am still waiting on a 3D view…, but that is how he did it. The guy is an artist and he draws beautiful houses. We were very enthusiastic about it and we even got the permission to build it from our community (Yes that is needed in the Netherlands)

There were a lot of prerequisites that we had to comply with, it had to fit in a certain part of our (own!!!) ground and it had to have a straw roof (To make it look like the other farms in the neighbourhood)
I did not want that, I wanted Tesla Tiles that create power, but hey…
So the architect draw the straw roof. The drawings of the architect then have to be enhanced by a constructor that knows how you build a house. Then the builder starts organising sub contractors to deliver parts.
It turned out when he ordered the roof that the angle was not steep enough. So the roofer would do it but with our guarantee.
So back to the drawing board and half a year delay (New permit, new calculations…)
So don’t tell me building houses goes better than building software…

So I asked myself: Would modelling have helped here?
I think so. The fact that a straw roof needs an angle of more than 45º is basic knowledge that should have been a design rule in the CAD program.
Moreover, I have not seen anybody work with a tool like Doors or Polarion to fix the house requirements. It is more advanced than the last time I built a house (1986) but it is with Mail, WhatsApp and Word that the house is built.

Back to Rhapsody

Vacation time is a good time to work on improving your Rhapsody models!
Sometimes customers ask me to do a review on a Rhapsody model. What do I do in a review?
It depends of course but for totally new models I do a couple of steps which I want to share with you:

  1. Check how old the model is. You cannot see it all but you can ask (..) and check if the model has CGCompatibilityPreX.Y Settings. They tell you the conversion already performed on the model (And the fact that the creators did not know what to do with it)
  2. Do a Check Model ( “Tools”, “Check Model”, “<name>” ) This should give you a lot of information about the model. Most common warnings are: “Default Names” and “Empty Description” but there are many more.
    The more warnings, the less precise the model is built
  3. Use Metrics to determine the number of elements in the model. Check for requirements, sequence diagrams and classes. There should be a fair number of requirements and a lot of sequence diagrams. unfortunately IBM stopped using the Metrics in 8.2. There is a more complicated system to still do it.
  4. Use the built-in document creator ( “Tools” “Report on model”, then select only “Include Overridden Properties” ) to look at the overridden properties. This should be limited to profiles.
  5. Do a general check.
    1. How do the names look? Consistent?
    2. How many packages compared to classes?
    3. Are there requirements used?
    4. Are there any Sequence Diagrams?
    5. Little number of properties is OK but not much
    6. What is the number of elements on diagrams. Yes that can be more than the “normal” 7+-2 but they should be understandable
    7. Are comments used?
    8. How is the diagram navigation?
    9. How many level of state-chart are there? One level or at most one sub-state-chart is OK. Everything else must be documented and proved necessary.
    10. Are model elements described in comment?

This is something that you can check yourself…. Do it sometimes.

Happy Modeling with Rhapsody

Greetings from Motown!

Walter van der Heiden (wvdheiden@willert.de)

V7 – Released

License to thrill

The number 7 is a famous number, not in the least by James Bond who was, of course, “007”. He had a “License to Kill”. Our V7 has a “License to Thrill”.
That is what we hope it will do to you! OK, It took a us while, admitted, but the first release of our V7 RXF for ‘C++’ is now on our Willert Download Portal.
We have worked hard for it, had many Beta Releases and lots of changes to make the best RXF yet. A big thanks to everybody who worked on it but a special “Thank You” to Johannes who has really done a lot for this release!

What is changed?

  • Completely made with Rhapsody. So the RXF is a model, with everything a model needs to be a good model, Requirements, traceability, Sequence Diagrams, explanations etc.
  • Smaller and faster. (YES! although modelled and generated, the code is smaller and faster!)
  • All adaptations integrated in one version. You select RTOS, compiler, CPU etc via tags.
  • New Deployer, this one remembers a lot more of your stuff. (Is not completely finished yet but I’ll give the new features)
    • Creates direct links to the Rhapsody code in your IDE so round-tripping just works!
    • Able to create you own template models that you can select, they are then copied
    • stores its settings in the project
  • Latest Target Debugger
    • faster, will not degrade performance when many events are processed
    • new design, improved stability and usage
    • break-point editor
    • editor for event injection
    • export to Rhapsody
  • Easier to configure Memory Management

For the time being only in ‘C++’, ‘C’ will take a while. But with a decent compiler we recommend ‘C++’ anyway. Bob Dylan already sang it a long time ago: “The times they are changing”. And that is what happens. From ‘C’ only in 32Bit on 8 and 16Bit Targets to ‘C++’ on 64Bit on 16- and 32Bit Targets.

That was it for now. It’s hot here… almost too hot to work. Luckily we are getting used to it.

Have fun with Rhapsody!

Migrate Rhapsody Developer to EUSIII

What is the difference?

Rhapsody Developer is the “full” version of Rhapsody, EUSIII (Embedded UML Studio III) is the Willert version. The only difference is that EUSIII does not have Animation, all other features are there. Also EUSIII has the Willert RXF as additional Framework.

No Animation? Is that bad?

Not really. Animation will only work with Windows on a PC as target environment (Or Linux or another really powerful platform) otherwise it is not possible/practical to use it. EUSIII has an alternative built-in solution called “Embedded UML target Debugger” that does the same but without using additional resources.

RXF?

Yep. The Real-time eXecution Framework. The Willert Framework that allows you to generate Rhapsody code on even the smallest of targets without real-time violations or large use of resources. Comes with a built-in single-threaded RTOS or adapters for other RTOSes. Also included is the UML target Debugger that can write Sequence Diagrams and Timing Diagrams even from a small target environment.

Re-install?

Nope. Not necessary. You can keep using your existing installation. Since EUSIII is based on the Architect for Software you have to start that version.

  • Starting Rhapsody via a desktop icon. (Or via the start menu) Then you can open the properties of the shortcut and go to the tab “Shortcut” (Names are different in other languages) There you can add “-architect” to the “target” field. If it already says “-dev_ed” you have to remove that. You can add the -lang=C or -lang=C++ to start the correct language by default.
  • Starting Rhapsody by double-klick a Rhapsody Model. Now you have to look for the Rhapsody.ini file. This should be in the directory next to where your “Share” directory is. In that file there are 2 commands:
    DefaultEdition=Architect
    DefaultLanguage=c++

    You should change them that they say “Architect” and the correct language.

Install RXF

Not only does EUSIII come with the RXF, you really need it. Without an RXF the code generation will not work. So you must install one. It is not important which one but of course you should install one that you want to use. Installation is easy, just start the setup, answer the questions, check if there are no errors (When an error is given during installation it will NOT workl!!!)
When you have purchased EUSIII (Or just an RXF) you have access to the Willert Download Portal where you can download your RXF adapters for the Language (C or C++) the Compiler (Keil, IAR, GreenHills, Visual Studio and many more) and the RTOS (CMSIS, FreeRTOS, OORTX, µCOS, Linux and many more) that you want to use.

License

You either have received a dongle (with a license file) or just a license file (Floating License) You just install that as usual with Rhapsody,

So that’s it. Happy Modeling with Embedded UML Studio III

Walter van der Heiden (wvdheiden@willert.de)

Yes we CAN! (part 1)

Introduction

What are we going to build? A CAN implementation. How? Well…. I’m nut sure myself. I will just start and write down my experiences along the way. For sure we will use our standard Board for that, the Keil LPC1768 board and we will, in parallel, implement on a PC using a USB-CAN connection. We will use Rhapsody in ‘C’ for that. C++ would be too easy…. (It’s not… but Johannes is already working on that and I don’t want to interfere with that. )

What are we exactly going to build? Years ago I did build two small apps, a master and a slave app that were exchanging info via CAN. On the Master Board you could operate the Potentiometer and the values were send to the slave board where an LED was regulated.

This is the first step we are going to build. I would like to build a different app, namely one that can log CAN messages to a PC. That would involve a PC program as well to interpret the CAN messages and display them. I’m not sure how to do that but I think we will get ideas when we start using CAN.

Preparations

First let us do some model preparation. For the first steps we need 4 Rhapsody models and, of course, the IDE projects as well.

The Rhapsody projects need to be prepared, a lot of things can be done by using profiles but unfortunately not everything. Global properties must be set in every model. (There are tricks around that, I will spend a future BLOG entry to that tricks, I promise! )

So we create the following projects:

  • lpc17xx
    The CAN driver for the Keil board, mostly already there in CMSIS packs.
  • PC_sim
    The CAN driver for the PC, not sure how (yet) but let’s prepare for it.
  • master
    Communicates via CAN to the slave tha twill receive commands and executes them.
  • slave
    Gets commands from the master and executes them.

The best way to work with these models is to load them all in Rhapsody. This can be done by creating a Project List with “File”, “Insert project”.

The following profiles must be loaded:

  • Rpy_C_CMSIS_Keil5_ARM_MCB1700_TD_Profile (only Master, Slave & lpc17xx)
  • Rpy_C_Win_VS13_PC_TD_Profile (only Master, Slave & PC_sim
  • WST_Types, this implies some global properties to be set:

    General::Model::CommonTypes must be set to: WST_Types
    General::Model::DefaultType must be set to WST_Types::uint32_t
    *EDIT* – Not necessary anymore! Although the properties are “Model-level”, you can still set them in a profile. The Code Generation is done from the Component/Configuration and will therefore use the properties. Very cool. Not sure why the selection box of attributes and variables show the types but, hey, let’s not look a given horse in its mouth….

  • WSTProfile
  • WST_CG_Profile

It is convenient to include all profiles in a separate project in the beginning, you will have to change stuff often, it is better to have everything within reach.

Here is the profile that you can load to have C99 types AUTOMATICALLY! WST_Types

Set the following global properties to make working with Rhapsody easier:

  • Browser::Settings::ShowOrder to YES
    Lets you re-order elements i teh Rhapsody browser.

  • Browser::Settings::ShowPredefinedPackage to NO
    Removes the Predefined Types Packages from the browser

  • Browser::Settings::ShowSourceArtifacts to YES
    Displays source-artifacts. Since we also set the Roundtripscheme to “advanced” there should be no source-artifacts.

Workflow

The idea is that we put all hardware dependant stuff in the lpc17xx and in the pc_sim models, we include these into the master and slave models to make the last ones completely hardware independent. When all is ready we start preparing the models for the implementation.

Structure:

  • CAN
    • Model
      • LPC17XX
      • Master
      • Slave
      • PCsim
      • profiles
    • Code
      • LPC17XX
      • Master
        • LPC17XX
        • PCsim
      • Slave
        • LPC17XX
        • PCsim
      • PCsim

This is a good working structure, maybe we do some fine-tuning later on.

LPC17xx Model

This will include the implementation of the hardware drivers for the MCB1700 Board. It needs some packages to store the work we do. We do reverse engineering to achieve most of that.

The next is the project where we store the generated code.

Keil Projects

In Keil we can also create a Project Space/Workspace to handle multiple projects. First create the projects themselves, Keil will not let you create an empty workspace…

First we create the empty project for the LPC17XX, select the correct CPU (NXP lpc1768) If this does not show up, you first have to install the pack from NXP. After you have done that, select the packs we need, RTOS and CAN. Don’t Worry! We can always select other packs when we need them!  You do not have to click all ticks right away…

We can copy these projects to the Master and Slave directory once we are happy with them. Or we wait until we are done, that’s probably better.

 

PCsim Model

This is the model that contains the same as the lpc17xx model but then runnable on a PC as simulation. It is important to have something that can run on a PC to make testing much easier.

The next is the project where the generated source code is stored and compiled.

Visual Studio 2013 Project

A Microsoft Visual Studio Project. I still use 2013, that is also supported “out-of-the-box” by Rhapsody, we also have a 2015 Adapter.

 

Master Model

The model that contains the Master Model, the model that serves as a master in the CAN network.

Slave Model

The Rhapsody model that acts as slave. There are also projects for the source code for both ARM and PC.

 

CAN we?

I’m not going to write a lot about CAN itself. There are enough pages on the web that explain what it is, that it was invented by Bosch, how the priority works etc. Try Wikipedia and you will as smart as you need to be for this in minutes.

How can we model a CAN communication? Well that is not too difficult (I think) but we should ask ourselves: What do we really want to model?
I think we should use as much driver technology that is already there. On the Keil Boards that is easy: the CMSIS Packs give us a lot. We need to include it in our model somehow and then build intelligence above it.

 

Prepare the LPC17xx model

We will use Rhapsody Reverse Engineering to prepare it. Since we only use the outcome of this we can do reverse engineering without any other preparation (RE changes a lot to your model and your Component/Configuration, since we do not build anything here we just leave it)
We first prepare the LPC17xx Keil Project to have the sources there for RE.

  • Open your Keil project
  • Open the Pack Installer
  • First install all packs needed ( Left Window, Boards, MCB1700 )
  • Then install Examples (Select MCB1700 in left window, then right window will show you CAN Example (amongst others)
  • You can find the Sources (or actually the includes) to use for Reverse Engineering in:
    • <Keil Install Dir>\ARM\PACK\ARM\CMSIS\<latest version>\CMSIS\Driver\Include\
  • Open the LPC17xx Rhapsody Model (In Rhapsody in ‘C’ please, will not work the same in ‘C++’.
  • Rename the Component to “reverseEngineering” and the Configuration to “keilMCB1700”
  • Start “Tools”, “Reverse Engineering”
    • In the first screen select “model driven”, “logical modeling”
    • In the second screen enter the path for the include files, then select all files. (We only need CAN but why not create a complete model right away, costs nothing and might be convenient later on)
    • In the third screen, leave the top 2 fields (“ordinary model elements” and “replace existing packages” but change the 3rd to “single top leve; package”and name it “HAL”
    • The fourth screen is OK, press “Finish” to perform RE. The result wil look like the picture on the right.
      • Screen Shot 2018-07-16 at 14.21.32

Now we can use this model in the other models to have a CAN driver included.

Just do an “Add to Model” in both hte Master and the Slave Model and include the “HAL.sbs” file there (As a (REF) of course )

When you have don that you can select all HAL functions with the INtellivisor ( Use “select” )

In the next part we are going to implement a simple CAN send and receive function that just sends and receives generated messages.

from there on we are ging to implement things like:

  • publisher subscriber, so you can subscribe to a certain kind of  CAN Messages with a callback function and that will program the CAN Acceptance Filter (if there is one)
  • define messages for sending a value and receiving the value.

 


That’s it, the rest follows soon in part 2!

Happy modeling with Rhapsody if you CAN!

Walter van der Heiden ( wvdheiden@willert.de)

 

PS

I just used a picture of Obama because he used the “Yes we Can” slogan in the 2008 elections and I found that a nice wordplay. Please do not assume i meant anything political with it, I never want to discuss anything even remotely political in this BLOG,
I do not want anything else than just technical discussions here.
I use other platforms to express my personal opinions.

W.

Florida 5: Bahama’s

Introduction

Preparation is everything. That is valid for everything. For modeling but also for vacation…..
Both Robert and I have never been to the Bahama’s and it seemed like a great idea to visit it. The flight was pretty cheap so we decided to just go there on an early flight and leave again in the evening. (Yes, we are the “Been there, Bought the t-shirt type tourists…)
But we did not do any other preparation…. we just went to the airport early. That was not difficult, the time zone works in our advantage.
The flight was very nice and shorter than planned. But then the first “small” issue crossed our path.
We both assumed that the Bahama’s were part of the USA. They are not… as it turned out… It is a country. With customs and borders and so… On the airport we had to fill in a Visa application form. Luckily there was nothing to do upfront.
Now the good part was that nobody gave us a hard time, everybody was extremely friendly but at first we were worried. But we got in quite quickly.
Then we wanted to check on the web where we had to go just to find out that even my super-duper cell phone plan did not cover the Bahama’s… Being online was extremely expensive so we had to stay in the airport WiFi to figure out where to go.
The speed of the WiFi was, well, very low. So I just saw that Uber would not work and that Nassau was on the opposite part of the island from the airport.
So we decided to rent a car. Hertz (my normal rental company) was out of cars but I managed to rent a car.
It was a VW Polo, Automatic and Aircon but not in a good shape. There we were confronted with preparation again.. There was a big sticker on the windshield that said “Keep Left”. But confusingly he car had a left-hand side steering wheel…
Then I realized that the Bahama’s have been English. These guys leave their marks thorough… So the road signs were exactly as in the UK and people drove left.
Not very cool with a “normal” car but I managed.
We were also not able to tell what kind of units they were using. The first sign after the airport was “45” but it took a while to figure out that they used miles or kilometers. With the state of the cars there, kilometers would not have been unlogical. So miles and not metric like the speedometer of the car. It didn’t even had the small inner “mile” indicator.

Conclusion

The Bahamas are very much worth a visit, one day is enough unless you are the sunbath type. The day was very relaxing and in the evning an hour before flying back we returned the car. At the check-in the lady told us that we were just in time. It turned out that you had to check-in an hour before when flying to the US, we had 2 minutes left… This proved again that preparation is everything. For traveling but certainly also for things like modeling. Gather all information you can get and model your application based on that.

 

Walter’s Rules #10: “Assumption is the mother of all f***-ups.”

Happy modeling with Rhapsody

Walter van der Heiden ( wvdheiden@willert.de )

 

 

« Older posts Newer posts »

© 2025 Rhapsody TechBlog

Theme by Anders NorenUp ↑