10 Field network communications

An emBASIC node will usually act as a server for client applications residing on the master PC or in the higher level network (Ethernet) of the master PC. ELZET80 traditionally (since 1987) has used BITBUS for fieldbus communications between the host and the field controllers. As BITBUS has been invented to support distributed control, the basic structure of BITBUS lends itself well as a communication guideline. BITBUS is a pure master-slave network where the master sends messages and the slaves answers - no action can be initiated from the slaves. While this might look like a constraint, it proves to be a gift for the developer, keeping his task simple and communication transparent, this way enhancing safety.

As we see the emBASIC powered controller mostly being a slave, the typical task for an emBASIC program is to wait for a message from the master, keep some answers ready or obtain them very fast and reply to the master. The construct to handle messages in emBASIC is an "ON MESSAGE" procedure. It waits to be awoken by the arrival of a message and executes some statements leading to a REPLY. As this is a universal approach to messaging, emBASIC uses ON MESSAGE not only for BITBUS but for communication with other task in the same system (system messages), and even for message based communication over RS232 lines. Waiting for an event is associated with a SEQUENCE in emBASIC, thus the ON MESSAGE procedure has to be written inside a SEQUENCE.

10.1 The ON MESSAGE handler

This type of handler is used for processing network messages and communications with system tasks. A message handler definition defines a user-defined handler object. A handler definition is an executable statement. Its execution binds the handler in the current sequence's namespace to a message variable previously defined:

ON MESSAGE message_variable DO
   statements
ENDDO

A message definition is basically a structure definition with some of the member variables like the command byte predefined ($CMD).

10.2.1 Define a BITBUS message type

For technical reasons, emBASIC's view of fieldbus network communication is in the first instance that of BITBUS - although it will be continually adapted to other fieldbusses and Ethernet. Hence we start defining a message to be used with BITBUS. Beside the node or station address, a BITBUS message contains a command byte. emBASIC uses this command byte to differentiate message types. A message from the master that asks for the current system state would get for instance command number 40h while a message to specify a new recipe for a batch process would be assigned command number 41h. Commands 0..3Fh are reserved for system use, 40h and up are available to the user.

To start BITBUS message processing, the programmer must define a message type and declare the associated variables, then create the appropriate ON MESSAGE message handler inside the desired sequence.

To define the message type use the following syntax:

TYPE type_name AS BITBUS MESSAGE
$CMD = number
[attribute AS type]
[ . . . ]
ENDTYPE

Above, $CMD is the special field mapped to the BITBUS command for this message. The master application has to fill this value into the command/response field of a BITBUS message bound for this On Message handler. Once defined, this field cannot be changed. Example:

TYPE client_message_t AS BITBUS MESSAGE
$CMD = 0x40
attribute AS LONG
name AS CHAR[30]
ENDTYPE

Note that BITBUS does not support string values, you should use a byte array instead.

A message variable can be accessed like an ordinary structure element - by an attribute reference. Here, an attribute reference is a message variable name followed by a period and a name:

myMotorMsg.element
myReplyMsg.val

The message object is then asked to produce the attribute whose name is the identifier. If this attribute is available, the type and value of the object produced is determined by the object.
For convenient access to the message variable handled by native code within its handler it is allowed to omit the message object name or to use “this” instead of its name:

this.element = 0
val = 1

Note, however, that public and local variable declarations may mask attributes. In those cases you might use the “this” form or fully qualified attribute access. Also note that access to special attributes of the message like CMD and BUS are performed using one of the following system constant notations:

saveCmd = myMotorMsg.$cmd
saveCmd = this.$cmd
saveCmd = $cmd

10.2.2 Declare a message variable

Next, you have to declare a message variable to use somewhere in your code. This is done with the standard declaration syntax. For example, using the type defined above, declare the variable like:

DECL myMessage AS client_message_t

From this point on, you can use the variable myMessage as a conventional structure outside of the message handler. You can even use it systemwide if you decide to declare the message variable public. Example:

DECL PUBLIC myPublicMessage AS client_message_t

10.2.3 Create a message handler

The message handler is where the work is done in the users program. Its structure is similar to a procedure, it starts with ON MESSAGE and ends with DONE. Once the ON MESSAGE handler is active, it gets woken up when a message arrives from the fieldbus and executes its statements. Waiting for an event and then executing some statements is the way a SEQUENCE works in emBASIC, thus the ON MESSAGE procedure has to be written as part of a SEQUENCE. Example:

ON MESSAGE myMessage DO
statuscode = proc_state
REPLY
ENDDO

ON MESSAGE myMessage DO
CALL ProcessCommand(REF myMessage)
REPLY
ENDDO

The REPLY initiates the answer message. Please make sure to reply immediately, otherwise BITBUS communication with other tasks might get blocked.

10.2.4 Disabling message wait

By default, if there are no message handlers defined in a given sequence, message processing is disabled. If however ON MESSAGE handlers appear in a sequence, that sequence automatically transits to waiting state after the execution reaches the sequences end.

To change this behavior, use the DISABLE MESSAGEWAIT statement. This will produce a “command unknown” error for all subsequent requests for the command numbers assigned to On Message handlers used in this sequence. Please note that all messages intended to be processed in the sequence will be answered with “command unknown”.

10.2.6 Reply to network messages

For each message the master sends to a BITBUS slave there must be one reply from the slave. The reply is executed as one of the statements of the ON MESSAGE handler.

For a reply, you have two options:

• Change data in the received message structure and reply with the same message - or
• fill another message structure and reply with this different structure.

To return the same message to the requesting application after the attributes have been modified use REPLY without an argument:

REPLY

To return another message to the requesting application, first declare an appropriate message variable

DECL reply_message_type AS reply_message

then use the following syntax to reply with the specified structure:

REPLY reply_message

Usually, a BITBUS master sends the same message structure that it expects as an answer. If you return another structure, make sure the master is prepared for this.

10.2.5 Sending network messages

While the station is a slave, sending a message without request is not supported from BITBUS, a slave only replies to a master message.

If the emBASIC device is the master in a BITBUS network, it sends out REQUESTs to the attached slaves and waits for their reply with an ON MESSAGE procedure.

The REQUEST command takes the form:

REQUEST myMasterMessage FROM nodeNumber

With myMasterMessage being a message variable of a previously defined BITBUS message type and nodeNumber being the number (1..250) of the station this message is meant for.

10.2 BITBUS - the master side view

A RAC/GBS task is present on all properly configured BITBUS stations and executes basic functions like memory up- and download, i/O access, starting tasks etc.

emBASIC will make itself known at startup to the BITBUS RAC/GBS-task as function code EB.

From this, any application on the master can find out the task number assigned to emBASIC. All communication with emBASIC will go to this task number and emBASIC will distinguish 255 commands based on the command/response byte in the BITBUS message. While commands 0x0..0x3F are reserved for system communication (debugger, download,...) commands 0x40 to 0xF0 are for user communication.

10.3 ProfiBus-DP

The situation on ProfiBus-DP is similar to BITBUS in that it is Master-Slave, too. The ProfiBus chip on TSM-CPUH2 and on TSM-ARMCPU have a DP-RAM interface which is usually used to mirror the state of inputs and outputs (ProfiBus DP is a distributed-i/o concept, not distributed task like BITBUS).

Momentarily, ProfiBus is not implemented in emBASIC but would have to be handled by calling the mCAT system level ProfiBus library. If you need assistance with integrating ProfiBus into emBASIC, please call.

Momentarily, ProfiBus cannot be used for development or program download

10.4 CAN

With CAN the situation is different in that this is a no-master bus. Any station can send to the bus and an arbitration scheme repeats messages until they go through. Usually a station reacts to a number of addresses and sends messages to other addresses. Message length is 8 bytes. Even worse, there are competing higher level protocols like CAN-open and DeviceNet that behave different. For the reason of this complexity, CAN is not supported in the first versions of emBASIC. There is, however, access to the CAN controller on a register level. Please call for disclosure of register addresses etc.