Best Practices - Program Execution Sequence

This article helps explain the execution sequence of each of the programming methods available in Powervision so that you can get a better idea of when your variables are updated and when application actions or events execute and operate on those variables. This is important to pay attention to if you need to guarantee a variable is updated with the desired value before any action is taken on it.

CCM - Central Control Module

There is not a hierarchy of applications when it comes to actions. The inter-process communication in our system is based on QNX message passing, and CCM is the application that processes all of the action calls. So when you have a list of actions on an event or state (in a state machine), CCM will go through each item in the list in the order that it appears in PowerVision, sending a QNX message to the specified application. 

 For example, the J1939 send extended free form action will send a message to the J1939 app to send the specified free form message. This QNX message will be received by the J1939 application and processed, resulting in a CAN message transmission. However, this message passing architecture is asynchronous - CCM is not blocked until the J1939 app has finished transmitting the CAN message, it is only blocked while transmitting the QNX message to the J1939 application.

Scripting & Activity Diagrams 

Scripting and activity diagrams are a little different in that CCM will process a script routine/function or activity diagram from start to finish. So if you're needing to do something like update all of the variable values before telling J1939 to send the CAN message that uses those variables, scripting or activity diagrams are a more reliable/synchronous way to orchestrate that work. 

Calculation Events

 Calculation events can be a little tricky, because what is actually happening is that you're telling CCM to fire the calculation event, which means it is sending an event to itself. That means the calculation will be processed in the next work loop. In the example event list, if item 1 is updating a variable that is used in the CAN message sent by item 2, it's possible the variable's value won't be updated prior to the CAN message being sent. This scenario would be a much better fit for scripting or activity diagrams.

Example User Event Action List

1.  CCM-Fire Event-Calculation event (to modify a system variable value)
2.  J1939-tx Ext Free Form-FFCAN.myCANmessage
3.  CCM-Fire Event-Calculation event (to modify a system variable value)
4. UIApp-Show View-Main Layer.MyCustom View
5.  CCM-Fire Event-SCRIPT_MyScript.

 Screen Ready System Event

At bootup the loader will display the boot logo image selected in the configuration tab until it completes loading the software out of FLASH into RAM memory. How long this takes depends on the size of the configuration and the display hardware.

Once memory transfer is complete the OS will do two things; first it sends a Screen.ScreenReady system event to notify the config that it is ready to begin processing screen data, secondly it loads the pages in the layer hierarchy with the Overlay layer sitting on top.

If you have any timing sensitive tasks that need to be fired only after the screen is ready for processing then it can be fired from this event. Keep in mind that system applications like the J1939 transmitter may not be ready to begin transmitting data at this point. One time user events that occur only at startup may need a delay timer to guarantee the application is ready to receive the data or command. Actions that are called too early may get missed.