PiC Dynamic Link Library with Visual Basic

This article refers to G&L PiC application note AN000022 and describes the PiC dynamic link library with Visual Basic.

The G&L Dynamic Link Library (DLL) is a driver library that allows an application written to run under Microsoft Windows 3.1 to communicate data to and from the PiC900 family of processors.  The DLL requires the COMM900 ASFB for the PiC.

The main ladder application in the PiC will include a transceiver function block which is part of the COMM900 ASFB package.  The transceiver function block manipulates the physical I/O device (e.g. the serial or ARCNET port), reads and writes the memory addresses requested by the DLL, and implements the actual communication protocol used to talk to the external device running the DLL.  A different transceiver function block exists for the serial and ARCNET medias.

The COMM900 ASFB manual does a good job of providing an overview of how a Personal Computer communicates to the PiC.  The PC acts as the master and must initiate all message transfers.  This means that that the PC program determines what memory addresses to read or write and when to do it.  The PiC cannot send a message to the PC unsolicited.

The COMM900 ASFB manual outlines the functions used in the PC to send a message to the PiC.  The DLL implements the same functions.  The application programming interface (API) for these functions are identical to the versions described in the COMM900 ASFB manual.  No additional manual is required to program with the DLL product.

Most Visual Basic programming languages are different from other languages since they do not support an integer data type of 1 byte or 8 bits.  This becomes a problem when you want to read or write any of the 8 bit data types in the PiC (i.e. BOOL, BYTE, USINT or SINT).  To solve this compatibility problem, a new parameter called ‘flags’ was added in the version 2.0 release of the COMM900 ASFB product and to the version 1.0 release of the DLL product.  The flags parameter currently has only two possible values:  16#00 and 16#01.

If the value of 16#00 is passed as the flags parameter value, this tells the function that talks to the PiC that the calling program does support 8 bit data types and that no special data handling is required to exchange PiC data types that are 8 bits in size.

If the value of 16#01 is passed as the flags parameter value, this tells the function that talks to the PiC that the calling program does NOT support 8 bit data types and that special data handling is required to exchange PiC data types that are 8 bits in size.

The illustrations shown below try to show why the flags value of 16#01 is needed and what it actually does.

 -------------------------------                                                          ------------------

| xxxxxxxx | XXXXXXXX |    ----- WRITE COMMAND --->      | XXXXXXXX |

 -------------------------------                                                          ------------------

 

2 byte Integer in Visual Basic                                                  1 byte Integer in PiC

 

----------------------------------                                                       ------------------

| 00000000 | XXXXXXXX |    <---- READ COMMAND -----     | XXXXXXXX |

 ---------------------------------                                                       ------------------

 

2 byte Integer in Visual Basic                                                  1 byte Integer in PiC

Notice that when a 2 byte Integer is exchanged with the PiC that the most significant byte (MSB) of the variable in the Visual Basic is ignored.  For example, when data is written from the Visual Basic program to a PiC, the least significant byte (MSB) is masked off and only LSB byte is copied into the message to be sent to the PiC.  When data is read from the PiC to the Visual Basic program, one byte is taken from the message received from the PiC and placed into the LSB of the Visual Basic variable and the MSB is programmed with zeros.  If the flags parameter is set to a 16#01 and the data being transferred is not a single byte data type, the parameter will have no affect.

If you want to use the custom data support of COMM900 to transfer data with a Visual Basic application, there are a few rules that must be followed since all custom data are treated handled as bytes internally to the DLL.

1. A custom data type cannot include both single byte and multi-byte data types within the same data type declaration.
2. If you are using a custom data type that includes only multi-byte data types, set the flags parameter to a 16#00 so the DLL does not treat your data as 8 bit data.  Remember, however, that the data quantity is still expressed in the number of bytes to transfer.
3. If you are using a custom data type that includes only single byte data types, set the flags parameter to a 16#01 so the DLL handles the 8 bit data types correctly.