Problems with "hei_pas"

[caestrada]

I already downloaded the Ethernet SDK.  I can run the EXE examples but when I
try to use the SourceCode VB Samples, the compiler cannot find the file "hei_pas" even
when I placed them in the same directory as the project...

Suggestions?  Should I move them to different directory?

Regards,

[caestrada]

I already solve the problem last night.  Those DLLs should be placed in Wndows/System32 for
better results.

It was amazing to discover there is bug on the design because and based upon how the
sample code is written (bWrite) one would assume it is a Boolean Type Variable but I
have found to have it the code working properly, that bWrite should be LONG under VB6.

I also found other "weird" situations but if anyone needs any sort of help, I gathered
some experience with SDK...

Regards,

[MikeS]

HEI_Pas.Dll is the interface library that lives between your Visual Basic application and the Visual C library that has all of our HEI APIs. It's job is simply to make the transition between VB applications - which utilize Pascal-type calling convention - and a Visual C DLL - which uses C-style calling convention.

Technicall speaking, HEI_Pas.DLL needs to be in the same directory as HEI32_3.Dll. Since HEI32_3.Dll is installed with all of our software products, if you've got DirectSOFT32, DirectSOFT4, DirectSOFT5, DS-Data, LookoutDirect or DLPlus installed, the installation script has placed a copy of that DLL in your Windows/System32 folder. And that's the first place Windows in going to look when it goes looking for DLLs.

The Ethernet SDK has both HEI_Pas.Dll and HEI32_3.Dll in the same folder just for folks who don't have any of our software products installed - one example is people using Entivity software products with our EBCs and EBC100s.

In our Visual C code, we define a BOOL as an 'int', which in Visual Basic should translate a Long (32 bits). I'll make that correction in our Ethernet SDK code and post an update soon. Thanks for bringing this to my attention.

You mentioned other "weird" situations when dealing with the SDK code, I'd love to hear about them, I want our SDK code to be as bulletproof as possible.

--thanks
--MikeS

[caestrada]

Mike,

It was not my intention to affect anybody saying or using weird word.  In spanish, weird means something not expected as it happened, unusual.

I already tested the SDK, which I found it good, simple to use.  When you connect to a DL05 or DL06 -my cases- and start executing

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

if for some reason the network cable or the power are removed, the VB app reports a critic error saying something like overflow.  I think it would be nice if this routine do not block or crash when it detects the device is not longer available.  If you have access to source code, I would add something that sends back a negative number in result, in order to detect the comms are not ok...

In other brands, some classify comms errors in negatives and obviously, one can use different numbers for problems with driver, wires or anything...

Comments?

[MikeS]

The system of error reporting built into our Ethernet SDK code does give you the level of control you're looking for. Once you establish a connection to the ECOM (or ECOM100), the error code possibilities get pretty small, the CCM protocol itself doesn't have a lot of error responses and the PASCAL_HEIxxx APIs eithere work or time out.... therer just aren't a lot of errors that can occur with the HEI calls.

that said, there's a much more detailed example of the error handling available to you in the EtherIO example program.

In the VB6 example program included with the Ethernet SDK (EtherCCM), I cannot reproduce the symptom you're describing by unpluggung the cable and attempting the PASCAL_HEICCMRequest(). I get a "Error 8006 (Timeout Error) ..." which is what I would expect to happen.

It's been my experience with VB6 that it is very temperamental when it comes to working with the strongly-typed variables. Most crashes that I experienced during the development of the example programs were caused by my attempts to manipulate the variables in math equations and in assignment operations.

Please keep me informed of any more issues you run into.

--MikeS

[caestrada]

MikeS,

Did you got that error on Rc variable or via a message box in VB6?

I agree with your about temperamental (even histeric) behavior of VB6...

Regards,

[MikeS]

In the example code, the error code (Rc) is displayed in the main TextBox along with the explanatory message.

--MikeS

[caestrada]

MikeS

Something is happening in my environment.  I copied exactly the same code from
your sample EtherCCM and the codes behaves quite different regarding the CCMRequest.

I solved the problem with OnError and works fine but probably is not the most
elegant solution.

In the sample EtherCCM, you are correct, the sdk returns a number...

Regards,