Some users have reported problems when registering the hmitalk.ocx file under Windows Vista. We have found that the solution to this is running the registration tool as Administrator.

For example, if you use VB5 or VB6 to register the ocx (by adding it to the toolbox using the rigth-click menu), make sure to launch the VB exe file with the "Run as Administrator" option.

With Visual Basic.Net 2008 Express, we have found that it is not necessary to run it as administrator.

We have found problems to register the ocx correctly with regsvr32.exe under Windows Vista, so we recommend that you use VB5, VB6, VB.Net 2008 or the development environment that you are using in order to register the ocx. Recently we have included an utility named RegHMITalk.exe that registers the ocx correctly in your Vista system.

To install TAS-HMITalk in your machine follow these steps:

- Download the TAS-HMITalk distribution .zip file from http://www.cpksoft.com.
- Extract the .zip file contents to a local folder.
- Locate the hmitalk.ocx file, right-click over it and select "Open with...".
- Browse to 'C:\Windows\System32' and select 'regsvr32.exe' and Accept.
- The ocx file should now be registered by Windows in your machine.
- Repeat the same steps with linechrt.ocx and grid32.ocx.
- Now you can add TAS-HMITalk to your Visual Basic toolbox and/or open the examples.

The xs7ppi.tlk driver was successfully tested in several applications with PLCs belonging to the S7-200 family using the following cable:

- Cable PC/PPI multimaster
- 6ES7 901-3CB30-0XA0
- E-STAND:03

This cable can be ordered to Siemens as follows:

Smart RS232/PPI cable with built-in RS232/RS485 level converter (6ES7 901-3CB30-0XA0)

Suggested Cable Dip Switches Configuration: Read More »

TAS-HMITalk and any of its drivers can be used in any of the following configurations, with direct RS-232 connections, connections through RS-232/485 converters, connections through ethernet/serial converters, connections through virtual serial ports, etc.:

Last week we had the chance to test the Moxa NPort 6150 Secure Serial Port Server Module with TAS-HMITalk to communicate with the serial port of a DanLoad 6000 electronic preset through the ethernet LAN at a fertilizer plant from Petrobras in Campana, Argentina.

The Moxa device was provided by RCL Systems, a company specialized in integrating InTouch factory suite applications for oil&gas industries.

The loopback tests worked great, showing that TAS-HMITalk could talk to the MOXA module directly, without the need of installing any COM port redirector software. TAS-HMITalk could properly recover from our intentionally-caused communication errors, such as cable disconnections and module power-off and on.

The DanLoad 6000 didn ... Read More »

1. Configure your HMITalk object properties according to what the driver help file says for the chosen driver and command. Leave default values for properties not mentioned in the help file.
2. Leave the ScanActive=False and uncheck the ScanAutoTrigger property.
3. Create a Button to send the data
4. In the Button_Click event, place this code:
    HMITalkxxx.PointValue(0) = <the value to be sent>
    HMITalkxxx.Trigger ' To dispatch the writing action
5. Then just listen to the OnSuccessfullySent event or the OnErrorSending event.

All drivers are configured using the same set of properties DriverP0 to DriverP9 and the meaning of these properties changes from one driver to other.

For example, to read a register value at address D0000 from a device supporting Modbus RTU, you should configure one TAS-HMITalk object as follows:
 
DriverName = “XModbusb”
DriverDataType = Analog_Input (because you will be reading words this time)
DriverNumPoints = 1 or whatever number ob registers you want to read (up to 125)
DriverP0 = PLC station number (project1.exe uses 1, which seemed to work OK)
DriverP1 = 3 or 4, depending on what your PLC supports.
DriverP2 = the starting address to be read (32768 for D0000)
DriverP3 to DriverP9 are not used for this case.
 
If you want the HMITalk object to periodically read your device, you don't need to call the .Trigger method each time. Y ... Read More »

The best approach to read data on a periodic basis is:

1. Set the ScanActive to True
2. Let the OnSuccessfullyReceived event or the OnPointValueChanged events do the work for you.

The best approach for on-demand reading is:

1. Call the Trigger method
2. Again, let the OnSuccessfullyReceived event or the OnPointValueChanged events do the work for you.

1. To build a closed PID loop, you will need two TAS objects. One to read the process variable and the other to send the control signal back to the plant.
2. Only the TAS object that is reading the process variable needs to have its PID properties set. The TAS object which sends the output is configured as you do with any other normal TAS object.
3. The EnablePIDs TAS general property must be True for PIDs to operate.
4. You will need to devote one PointValue for each PID loop you need.
5. The PointPIDEnable property of that point must be set to True
6. As a minimun, the PointPIDSetpoint, PointPIDKp, PointPIDKi and PointPIDKd must be set to appropriate values.
7. The PointPIDLowPhysic and PointPIDHighPhysic properties will scale the control signal between 0% and 100%.
8. The value of the control signal generated by the PID algor ... Read More »
   
   

The "timeout threshold", the "CommTimeout property" or the "timeout value", which are all the same thing, is an amount of time that you configure and that the driver uses to know when it is time to abandon a communication if no response was received. If a timeout value is too big, an HMITalk object could remain waiting for an answer for a long time. The only reason a timeout exists is to prevent the driver to stay waiting forever. So it is important to define how long you want to wait in order to be sure that the device will not respond anyway after that time.

The timeout is a software setting at the driver side and it does not affect the device behaviour, but the driver behaviour. It does have nothing to do with some physical or electrical thing. It is just a maximum time period and the driver checks what happens first: a reply arrival or the timeout period expiration.

A timeout cannot be too short either. If you set a timeout to ... Read More »

There is no way you can specifically distinguish a device power-off from a cable problem or some other link problem. All you can positively determine is wether or not you are receiving an answer from the device. A device that is not responding is not necessarily powered off. It could be disconnected from the com port, it could be using a different baud setting than HMITalk, it could be using a different protocol, it could have a different station or device number than expected, etc.

All you can do is to act when you receive a timeout error, which in some cases could really mean that the power went off. The error occurrence is signalled by the OnErrorReceiving event which is the one we suggest you to use.

What you could do in your application to show a power-off or a communication error condition is the following:
 
1) Use the OnErrorReceiving event to show the values as "disabled labels" or "gray colored" l ... Read More »

TAS-HMITalk is the "engine" of a SCADA application. It is what enables your HMI to "talk" to the external equipment. As an activex object, its functionallity can be used within any ActiveX-compatible container. It is true that it could potentially be used within a web enabled application but its essence is to be used to bring communication capabilities to HMI/SCADA applications developed with Visual Basic or Delphi. With VB or Delhi, what you typically get are executable files (the customized applications) that are then distributed to the end users (at the factory plant, for example), along with the required TAS-HMITalk ocx and driver files.
 
In a few words, when you place an HMITalk object in your application, what you will get after you configure it is something that will automatically poll a specific device at regular intervals using a specific protocol over a specific COM port and that will report to your application (by firing events) when ... Read More »

If you had to read for example 270 values and the driver that you are using was designed to read in groups of 15 maximum (which is true for xtis505t for Texas Instruments TI-505, for example), then you would need 18 HMITalk objects to cover all the required values.

If you are using Modbus RTU instead, itnhas a limit of 127 consecutive registers for each HMITalk. As you can see, this limit varies for each driver, since it depends on the protocol (messages format) being used by each device. The messages transmitted and received have a limit in length (number of bytes) that in turn imposse a limit in the number of actual values that can be exchanged with the PLC.

If you cannot read all the required information with one single HMITalk object, then you can decide to use additional HMITalk objects until you cover all the memory positions that need to be read.

You can create up to 500 objects in your machine so this should not be a limit f ... Read More »

There is a delay of some milliseconds that could be of up to one or two seconds related to changing the DriverNumPoints property dynamically in runtime. The problem is that the DriverNumPoints property reallocs internal HMITalk memory to hold a different number of registers and this must be done under the safest possible conditions. This is, HMITalk has some internal waiting loops that monitor the COM activity until it stops completely to assure that no events will try to access PointValues that no longer exist.

Changing the DriverNumPoints property is not a usual scenario, anyway. If you need to read some groups of registers from different parts of the PLC memory map, users typically create several HMITalk object to read each part. You can have as many as 500 HMITalk objects working cooperatively, sharing the COM port in turns. There is an internal scheduler that automatically assigns priorities to each HMITalk that needs to communicate.

If for some reason you ... Read More »

1. Check that the DriverP0 to DriverP9 parameters have been configured according to what is stated in the help for the driver and the particular command that you are trying to execute.
2. Check that you are selecting the right PC COM port in your CommPort property, which must be the port where you have connected the cable that links your PC and the external device.
3. Check that the CommTimeOut property is not set to a value too small. In general, you should allow at least 1000 milliseconds to get an answer before HMITalk abandons that communication and triggers a Timeout Error.
4. Check that the CommBaudRate property matches the baud rate used by your device.
5. Check that the CommParity property matches the parity used by your device.
6. Check that the CommDataBits property matches the databits used by your device.
7. Check that the CommStopBits pro ... Read More »
   
   

After any communication it is important that you consider what are you getting in the DriverStatus property. You can see it in the Driver Status box and it indicates if everything is OK with your communication. If there is any error present, point values will return -1 (in fact, they will return the previous value they had, which is -1 when the application starts).

An error can occur even if you are actually receiving some answer from your device. This is possible because the answer in the rx box can be a wrong answer and thus it can be invalidated and discarded by the driver.

The OnSuccessfullyReceived event is fired after the Rx message was correctly validated, and that’s why this is a good place to check for the received point values. Another event (which is the one we use in most of the examples), is the OnPointValueChanged event. This event is fired for each individual point value after the rx message is validated and only if the received value is differen ... Read More »

The Trigger method just queues an order to initiate a new comunication process. It is not directly linked to the firing of the OnRequestStart event. Events work asynchronously and it might take some time between the call to Trigger and the moment HMITalk starts reacting to that. Perhaps it is better to use the ScanActive=True solution, which is just an automated way that HMITalk uses to call the Trigger method at regular intervals. In fact, the trigger method is used only for on-demand communications. But if you have to continously poll a device, the ScanActive=True approach is the best.

You should use multiple writes only when you need to send a set of values simultaneously, as it happens when you are for example configuring a recipe in a PLC. In this case, be sure to disable the ScanAutoTrigger feature so HMITalk does not start sending the package at the very first PointValue you load. You should manually call the Trigger method when the last PointValue in the packet has been loaded with its value.
 
If you have many registers to be written but this can be done at different times, it is recommended that you write points one at a time which allows you to to use the same HMITalk object for all the outputs that need to be sent to a particular device. You can save yourself from configuring a lot of HMITalk objects by reusing the same object where you dinamically set the DriverP0 to DriverP9 parameters before you load the PointValue to be sent and you Trigger the output. In other words, you first set the desired address in the corresponding driver para ... Read More »

With the unlimited license, you can freely develop and run your applications in any number of machines. The Unlimited License enables you to create unlimited signed copies of hmitalk.ocx that check for a specific PC Id when they are executed in the target machine that you decide.

When HMITalk runs, it reads the current PC’s ID from the end user's machine and it compares it against an encrypted signature that it carries embedded in the ocx binary code. If there is a match, the hmitalk.ocx will fully enable both design and runtime in the indicated PC. If the end user moves the ocx to a different machine, HMITalk will behave as an unregistered evaluation copy in that machine.

In order to create a signed copy of hmitalk.ocx for a specific target machine, you need to know the PC Id of the target machine. You can obtain the PC Id number by executing the getpcid.exe command-line utility at the end user’s PC command prompt. This stand-alone utility is included within t ... Read More »