HEI_Pas.dll: Troubleshooting VB.NET Integration Errors

A VB.NET project that can run the Ethernet SDK executables but cannot load HEI_Pas.dll has two distinct compatibility checks: Windows must locate both interface libraries, and the project must use declarations compatible with the SDK's calling convention and data widths. For the Koyo DL260 integration described here, resolve library loading before diagnosing PLC communications.

Understand the HEI_Pas.dll dependency chain

HEI_Pas.dll is the interface between a Visual Basic application, which uses Pascal-style calls in the supplied examples, and the Visual C library containing the HEI APIs. It is not a standalone communications library: HEI_Pas.dll must be in the same directory as HEI32_3.dll.

Separate a loader failure from a communications failure

If the compiler or application reports that it cannot find hei_pas, first treat the problem as library discovery or inter-library dependency resolution. Do not attribute it to the DL260, network cable, register address, or CCM protocol until both DLLs load.

If the application loads the libraries and reaches PASCAL_HEICCMRequest, the loader problem is resolved. A later timeout is a communications result instead. In the supplied VB6 EtherCCM example, disconnecting the cable produced Error 8006 (Timeout Error), displayed through the return code Rc and its explanatory text.

Install and reference the libraries

1. Obtain the Ethernet SDK and the available VB.NET 2003 source conversion from the manufacturer. Running an SDK executable alone does not prove that a separate VB.NET project has valid declarations or can resolve its native dependencies.
2. Locate HEI_Pas.dll and HEI32_3.dll in the SDK package. Keep the two files in the same directory.
3. Place that directory where Windows can find the native libraries. The evidence confirms that installations of DirectSOFT32, DirectSOFT4, DirectSOFT5, DS-Data, LookoutDirect, or DLPlus placed HEI32_3.dll in Windows/System32; placing HEI_Pas.dll there resolved the reported lookup problem. If those products are absent, use the paired DLLs supplied together in the Ethernet SDK.
4. Build and run the smallest supplied or converted example before adding application logic. Confirm that execution reaches an HEI API call rather than failing during library loading.

Audit the bWrite declaration before exchanging data

The Visual C SDK defines BOOL as an int. In the documented VB6 correction, the corresponding bWrite argument had to be a 32-bit Long, not a Boolean. The affected call had this form:

result = PASCAL_HEICCMRequest(aDevices(tDevice), bWrite, DataType, OctalRegisterNumber, Datalen, Bytes(0))

Do not copy the VB6 type name mechanically into VB.NET. Instead, inspect the VB.NET 2003 conversion and verify that the declaration passes bWrite with the same 32-bit width expected by the native int. A declaration that merely looks semantically Boolean can still have the wrong native representation.

Verify communications and error handling

1. Run one request with the PLC and network available. Record the return value and confirm that the expected PLC data is transferred.
2. Disconnect the network cable and repeat the request. The supplied VB6 example returned Error 8006 (Timeout Error); verify that the VB.NET conversion reports a controlled error instead of terminating with an overflow or critical error.
3. If the application crashes while the reference example returns a code, compare native declarations, argument widths, assignments, and arithmetic involving strongly typed variables. The evidence associates several VB6 failures with type manipulation rather than with an unreported SDK communications condition.

Successful verification requires all three outcomes: both DLLs load, the request exchanges the intended data, and loss of connectivity produces a handled return condition rather than an application crash.

FAQ