One of the nicer features of VPL is its ability to compile your application as a service. Unfortunately, there is no way to go the other way and turn a service into a VPL application. After you compile a VPL application as a service, you can select it from the list of services in the left-hand menu. This can be useful when you need to group together commonly used blocks into a function that you can reuse in other applications.
To compile the application as a service, click Compile As A Service from the Build menu. This creates a Visual C# project, which you can open in Visual Studio to view the code associated with your VPL application. This can be very useful for programmers who are new to MSRS or programming in general. It provides an opportunity to understand how blocks in VPL relate to the code required to build a service.
Note
When you compile the application as a service, by default, it places the code files for your service on your desktop.
For example, if we compile the BoeBotBumperTest as a service, it creates a Visual Studio project that contains the following two class files:
DiagramService.cs. This is the implementation class, and it is where the code that runs your application is located. It is where the message handlers responsible for generating notifications to subscribers are located.
DiagramTypes.cs. This is where the type definitions, such as the ones that handle state, are located. It is also where the PortSet is located. The PortSet is used to define what types of Decentralized Software Services Protocol (DSSP) operations are allowed.
If you open the project in Visual Studio and then expand the References folder in Solution Explorer (see Figure 3-16), you see references to the Robotics.Common.Proxy and TextToSpeech.Y2006.M05.Proxy assemblies. These are the proxy files that handle calls to the two services included in the BoeBotBumperTest application. The Robotics.Common.Proxy assembly contains classes for all the generic services (refer to Table 3-2) available with MSRS. As you may recall, the BoeBotBumperTest application included a block for the GenericContactSensors service.
Figure 3-16. The References for the BoeBotBumperTest service include the Robotics.Common.Proxy and TextToSpeech.Y2006.M05.Proxy assemblies.
Even if you are not interested in using VPL as a design tool, you may want to consider using it as a learning tool. It can save you a lot of time by generating the code to interface with built-in services. For example, the BoeBotBumperTest service includes several class files related to handling what happens when one of the contact sensors is triggered.
Examining the code generated for the BoeBotBumperTest service can be useful for readers who want to learn more about the fundamentals of Concurrency and Coordination Runtime (CCR) and how to work with the GenericContactSensors service. For example, the message handler for the GenericContactSensors subscription uses the Task interface (ccr.ITask). This allows the code within the handler to execute in the context of the CCR dispatcher. The dispatcher manages threads for the operating system and ensures that tasks are load balanced properly.
IEnumerator<ccr.ITask>
GenericContactSensorsUpdateHandler(contactsensor.Update message)
{
OnGenericContactSensorsUpdateHandler handler = new
OnGenericContactSensorsUpdateHandler(this, Environment.TaskQueue);
return handler.RunHandler(message);
}You can then look at the code within the constructor for the OnGenericContactSensorsUpdateHandler class. The following code is what this constructor looks like:
public OnGenericContactSensorsUpdateHandler(DiagramService service,
ccr.DispatcherQueue queue) : base(service, queue)
{
// Register joins with base class to manage active count for
// incomplete joins.
base.RegisterJoin(_joinAlphaPorts);
// Activate Join handlers
Activate(ccr.Arbiter.MultiplePortReceive(true, _joinAlphaPorts,
_joinAlphaHandler));
}Notice that the update handler is assigned to the DispatcherQueue. This means that the task executes within a First In, First Out (FIFO) queue of tasks. In this case, using CCR task scheduling to handle incoming messages is advisable because multiple sensors (whiskers and IR detectors) could be returning results at the same time that commands need to be sent to the Boe-Bot. All of this is happening very quickly, and it is the responsibility of the CCR dispatcher to properly manage all of these tasks.