Frequently Asked Questions (Häufig gestellte Fragen)

Frequently Asked Questions

Q: Does the HartDLL 7.0 run on Windows 7 (64 Bit)?
A: It will work if the application program is a 32 bit executable. It will not run with 64 bit components. Please read our January newsletter for more information about the new product HartTools 7.1.

Q: How can I run my former development environment under Windows 7 (64 Bit)?
A: If you have the professional version of Windows 7 you should run a virtual machine which is emulating a Windows XP PC in a Windows 7 environment. It is available from Microsoft: http://www.microsoft.com/windows/virtual-pc.

Q: Is there a special version available as an update from HartDLL 6.0 to HartDLL 7.0?
A: No, HartDLL 7.0 is a new product. However, there will be updates to the version 7.0 in future. The price of such an update depends on the difference to the previous version. There is only one exception for orders arriving before March 31st (see QuotationHartDLL for further details).

Q: Is there any low cost Hart driver available?
A: Yes, please refer to our products and look for Tiny Hart Tools.

Q: Can you send me a quotation?
A: Yes, but it is not necessary. For all our products you can download a quotation from our site (Products).

Q: How many copies of the DLL may I deliver with my application?
A: The number of run time copies is unlimited.

Q: How is the DLL registered at the computer of the user getting my application? Du I have to provide registry entries?
A: No, your application have to call the DLL when it is loaded. The application has to pass the license code to the DLL.

Q: Does the DLL require any other sources, components or DLLs?
A: No, all you need is this single DLL.

Q: Where do I have to install the HartDLL if the application is delivered to the user?
A: There are two ways. You may copy it to the Windows system directory or into the directory where your application is started.

Q: What is usAddTimeOut?
A: In the Hart protocol specification a time out for the master slave communication is defined. When the master has sent the last byte of a request it starts a timer and waits for the response of the slave. If certain amount of time expires before any byte from the slave is received, the master assumes that the slave is not responding. This TimeOut is specified with approximately 280 ms. However, this is defining the interaction on the Hart Communication wire. In real systems the situation may become different. If you are using an usb modem, the usb driver in the PC may add an additional delay. This means that even if the device is conform to the HART specification the driver may not receive the response of the slave in the 280 ms.

In the Hart protocol specification a time out for master slave communication is defined. When the master has sent the last byte of a request it starts a timer and waits for the response of the slave. If certain amount of time expires before any byte from the slave is received, the master assumes that the slave is not responding. This TimeOut is specified with approximately 280 ms. However, this is defining the interaction on the Hart Communication wire. In real systems the situation may become different. If you are using an usb modem, the usb driver in the PC may add an additional delay. This means that even if the device is conform to the HART specification the driver may not receive the response of the slave within the 280 ms.

Let's take an example. Assume that the usb modem is sending with no delay and adds 50 ms when receiving. If the slave would answer 275 ms after the master have sent the request the driver in the PC will receive the response after 325 ms because 50 ms were added by the usb driver. In this case the driver in the PC would raise an error because the response of the slave did not arrive in the time which was required.

To manage problems like this, usAddTimeOut was introduced in the HartDLL to extend the original time out by a certain amount of ms. When you are choosing 100 ms usAddTimeOut you are extending the Hart specification of 280 ms to 380 ms and the driver is working well with this modem.

Q: Can I solve modem problems by using the setting of usAddGapTime?
A: That a device is certified for Hart does not play a role under certain circumstances. The combination of the Hart driver and the USB connection may not be conform to the Hart timing specifications even if the driver is certified. Hart is a very time critical protocol especially if taking the two master mode into account. Thus a timing with a granularity of ms is required for these cases. To achieve this was even difficult with real com ports. These com ports at present are almost totally replaced by modems connected through USB. This implies different timing behaviors for the Hart driver, which is only connected to a 'virtual' com port. Behind this com port a usb driver is implemented which is provided by the manufacturer of the modem. It could be the case that the usb driver is delaying the transport of octets. Some of the usb drivers can be configured others not. And even if the usb driver is configurable in most cases the user does not know this.

Therefore we introduced some extra settings in our Hart driver two years ago to solve timing problems generated by various usb driver implementations.

Last year we delivered a Hart driver for Windows CE to a customer. The driver was targeted to be used with a Hart modem connected through Blue Tooth. We had trouble to set it into proper operation. Finally it turned out that the Blue Tooth communication driver in the iPod was delaying the protocol by about 20 ms. The manufacturer of the modem had to change the driver implementation.

If a device is not correctly working in certain environments it may be caused by a gap time out in the protocol. In those cases we recommend to configure the driver with an additional gap time out.

BHDrv_GetConfiguration(hDrv, &strConfiguration);

strConfiguration.usAddGapTime = 10;

BHDrv_SetConfiguration(hDrv, &strConfiguration);

Q: Did you have some sample code on how to access your HartDLL from C# using P/Invoke? I can not find the code on your website, and thought I found it there previously.
A: If you download the Trial Version of the new HartDLL 7.0 and install it you will have access to the code of an example named 'GetCyclicData'. If you need some information quickly you should have a look into the manual. The example description is placed on pages 9 and 10 in the user's manual. BTW, I recommend that you are not using Invoke but to use BeginInvoke. Invoke is based of the Windows function Sendmessage(), which is returning after the message was processed. This may delay the calling thread in an unacceptable way. BeginInvoke is based on PostMessage() thus not generating any delay to the invoking thread.

FAQ

Optische Taeuschung

If you cannot find your question listed in this page please send us an email or just call. We are available for you at any time.