TAS-HMITalk Support

I cannot register hmitalk.ocx in Windows Vista

Wed, 18 Mar 2009 18:31:00 GMT

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.

Quick steps to install TAS-HMITalk

Sat, 22 Nov 2008 21:34:00 GMT

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.

New TriggerAndWait method

Thu, 02 Oct 2008 21:46:00 GMT

A new method called TriggerAndWait has been added to the TAS-HMITalk activex. This method triggers a new communication and then blocks the execution of the application thread until the communication has finished. This way it is easier to implement a communication strategy where several TAS-HMITalk objects must be cascaded in a particular order.

Following is an example of a routine to handle a button event in an application written in C# with Visual Studio 2005 that reads data from a relay:

private void button1_Click(object sender, EventArgs e)

{

axHMITalk1.CommPort = HMITalkLib.enumCommPort.COM1;

axHMITalk1.CommBaudRate = HMITalkLib.enumCommBaudRate._19200_Bauds;

axHMITalk1.CommParity = HMITalkLib.enumCommParity.None;

axHMITalk1.CommDataBits = HMITalkLib.enumCommDataBits._8_Bits;

axHMITalk1.CommStopBits = HMITalkLib.enumCommStopBits._1_Bit;

axHMITalk1.DriverP0 = "1"; // Numero de rele

if (axHMITalk1.TriggerAndWait()) // Se dispara la lectura y si resulta exitosa, se muestran los valores recibidos

{

listBox1.Items.Clear();

listBox1.Items.Add("Numero de Rele: " + axHMITalk1.DriverP0);

listBox1.Items.Add("Eventos disponibles (0=No/1=Sí): " + axHMITalk1.get_PointValue(5).ToString());

listBox1.Items.Add("Alarma declarada (0=No/1=Sí): " + axHMITalk1.get_PointValue(6).ToString());

listBox1.Items.Add("Disparado (0=No/1=Sí): " + axHMITalk1.get_PointValue(7).ToString());

listBox1.Items.Add("Relay 0 (0=No/1=Sí): " + axHMITalk1.get_PointValue(50).ToString());

listBox1.Items.Add("Relay 1 (0=No/1=Sí): " + axHMITalk1.get_PointValue(51).ToString());

listBox1.Items.Add("Relay 2 (0=No/1=Sí): " + axHMITalk1.get_PointValue(52).ToString());

listBox1.Items.Add("Relay 3 (0=No/1=Sí): " + axHMITalk1.get_PointValue(53).ToString());

listBox1.Items.Add("Relay 4 (0=No/1=Sí): " + axHMITalk1.get_PointValue(54).ToString());

listBox1.Items.Add("Relay 5 (0=No/1=Sí): " + axHMITalk1.get_PointValue(55).ToString());

listBox1.Items.Add("Relay 6 (0=No/1=Sí): " + axHMITalk1.get_PointValue(56).ToString());

listBox1.Items.Add("Relay 7 (0=No/1=Sí): " + axHMITalk1.get_PointValue(57).ToString());

listBox1.Items.Add("Corriente en fase A [I0 en Amp]: " + axHMITalk1.get_PointValue(94).ToString());

listBox1.Items.Add("Corriente en fase B [I1 en Amp]: " + axHMITalk1.get_PointValue(95).ToString());

listBox1.Items.Add("Corriente en fase C [I2 en Amp]: " + axHMITalk1.get_PointValue(96).ToString());

listBox1.Items.Add("Corriente en fase N [IN en Amp]: " + axHMITalk1.get_PointValue(90).ToString());

listBox1.Items.Add("Frecuencia [Hertz]: " + axHMITalk1.get_PointValue(8).ToString());

listBox1.Items.Add("Cantidad de operaciones del relay: " + axHMITalk1.get_PointValue(122).ToString());

listBox1.Items.Add("Tensión en fase A [V0 en Volts]: " + axHMITalk1.get_PointValue(104).ToString());

listBox1.Items.Add("Tensión en fase B [V1 en Volts]: " + axHMITalk1.get_PointValue(105).ToString());

listBox1.Items.Add("Tensión en fase C [V2 en Volts]: " + axHMITalk1.get_PointValue(106).ToString());

listBox1.Items.Add("Tensión en fase N [VN en Volts]: " + axHMITalk1.get_PointValue(100).ToString());

}

else MessageBox.Show("Se produjo el siguiente error durante la lectura: " + axHMITalk1.DriverStatus);

}

What cable should I use to connect TAS-HMITalk to my Siemens S7-200 PLCs?

Tue, 12 Aug 2008 20:56:00 GMT

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:

- 1    0
- 2    1    9600 bauds
- 3    0
- 4    X    Spare
- 5    1    Multimaster
- 6    0    Local DCE
- 7    0    11 bits
- 8    X    Spare

Important Note:

The suggested configuration will only work with TAS-HMITalk. If you want to communicate using MicroWin, you will need to set dip switch 5 to 0 in order tohave the cable work as Freeport/PPI instead of Multimaster. Besides, you will need to uncheck the "Multimaster" and "Advanced PPI" options in the MicroWin configuration. Set dip switch back to 1 if you want to communicate using TAS-HMITalk.

How can I get connected to my devices with TAS-HMITalk?

Mon, 21 Jul 2008 22:23:00 GMT

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.:

MOXA Serial-to-Ethernet NPort 6150 module tested wiith TAS-HMITalk

Sun, 01 Jun 2008 21:06:00 GMT

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't notice any difference between a true serial communication and a serial-over-ethernet communication managed by the MOXA device. A wonderful solution that can allow you to access serial devices in your plant from PCs in any node of your tcpip network. You can visit the Moxa website here.

Comments about sending outputs

Mon, 26 May 2008 23:59:00 GMT

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.
Leave the ScanActive=False and uncheck the ScanAutoTrigger property.
Create a Button to send the data
In the Button_Click event, place this code:
HMITalkxxx.PointValue(0) =
HMITalkxxx.Trigger ' To dispatch the writing action
Then just listen to the OnSuccessfullySent event or the OnErrorSending event.

Example configuring a Modbus RTU communication

Mon, 26 May 2008 23:50:00 GMT

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. You can set the ScanActive property to ON and the object will automatically do the poll every ScanInterval milliseconds (no need to setup a Timer object in your application).

In order to WRITE data to your device, you can use the Force Single Coil command to force one single digital output (on/off), Force Multiple Coils to write several digital outputs at once, Preset Single Register as 16-bit Integer to write one single analog value (one word) or Preset Multiple Registers as 16-bit Integers to write several words at once. If you check in the xmodbusb.htm file, you will find how to set the properties for each command. You will have to add HMITalk objects to your application in order to support more commands and more PLCs. We suggest that you use the Trigger method when you send data instead of the ScanActive property. This way, data is only sent on demand and not on a periodic basis.

Periodic reading vs. On-demand reading

Mon, 26 May 2008 23:38:00 GMT

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

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

The best approach for on-demand reading is:

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

Comments about configuring a PID loop

Mon, 26 May 2008 23:33:00 GMT

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.
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.
The EnablePIDs TAS general property must be True for PIDs to operate.
You will need to devote one PointValue for each PID loop you need.
The PointPIDEnable property of that point must be set to True
As a minimun, the PointPIDSetpoint, PointPIDKp, PointPIDKi and PointPIDKd must be set to appropriate values.
The PointPIDLowPhysic and PointPIDHighPhysic properties will scale the control signal between 0% and 100%.
The value of the control signal generated by the PID algorithm can be read from the PointPIDControlSignal property.
To close the loop, use the OnPointControlSignalChanged event to write the code that assigns the PointPIDControlSignal property value to the corresponding PointValue of the TAS in charge of sending the output. Use the same event to trigger the sending of the output.
You can use the PointPIDDeadBand property to determine the minimum variation in the control signal that produces a call to the OnPointControlSignalChanged event.
You can use the PointPIDMinControlSignal and PointPIDMaxControlSignal to limit the values the control signal can take (for example, between 0 and 100 only).

Understanding how the CommTimeout property works

Mon, 26 May 2008 23:27:00 GMT

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 1 millisecond, it will never be possible to send a message and receive a response within that short time. So the timeout will have to be set to a value longer than that. If you define the timeout to 60000 milliseconds, you will have to wait one minute before the driver discards the current request and is ready for the next request. A right value will be something between 1 and 60000 ms and the typical setting is 2000 ms, this is, 2 seconds.

The minimum value for a timeout should be at least the time it takes for a device to return a complete valid answer plus a few milliseconds. If a communication log file shows that a valid communication takes 60 ms to be completed (from tx to rx), then the timeout will have to be greater than that. If you set the timeout to a value smaller than 60, you will always receive a timeout error because the timeout period expiration will happen before the reply was received. In this case, the timeout should be at least of 120 ms, which is two times the time required to communicate when the device responds well. It must be greater because you must be tolerant to some unknown factors that could cause minimal delays and make the conversation time to fluctuate.

As an analogy, imagine when you make a phone call. How many rings do you wait until you say: "Ok, there is no body there, lets hang up". Do you wait for 50 rings?. Too much. specially if you have too many other calls to make. Do you wait for 1 ring and then you hang up?. Too short and probably you will never have the chance to speak to anybody. What we define with the CommTimeout property is "how many rings do we have to wait".If you know that the average person answers the phone at the 3rd or 4th ring, you will probably wait up to 6 rings before hanging up. You will not wait strictly for 3 rings because probably some times you will lose the call just when the other person was about to pick up the phone.

There is no problem to set a timeout that is longer or even much longer than the time actually involved in a valid communication. Continuing with the phone rings analogy, think of HMITalk as a secretary who has many phone numbers to call. She starts calling one by one, and waits up to 6 rings for each phone to answer. She expects people to answer within the 3 first rings. If everybody answers within the 3 rings, she will never have to wait for the 6 rings. This shows that the timeout value is only the "maximum number of rings" that she will wait. But if everything is OK, this value is "never used" because that limit is never reached.

Now imagine that only some of the phone numbers that she has to call are not available. Sometimes they answer, sometimes not. What does she do when she attempts with those numbers?. Instead of going immediately to try with the next number, she might retry 2 or 3 times with each failed number. The person she was trying to reach could have been busy at that moment, so it is worth a retry. At the HMITalk level, this can be donde by configuring the ScanRetries property.

Now, how long would it take to this secretary to complete all the phone calls? Does it depend on her "finger dialing skills"?. Would you say that she is a "slow person" if she takes too much time to complete the cycle?. Is it her fault that nobody answers at random patterns to certain numbers in an unpredictable way?. What would you do? Change the secretary?. Increase the number of rings she waits for?. Or check why there are some numbers that are not responding as quickly as they should?. The problem is probably not on the secretary side. Focus on the adapter, the radio link, the noise conditions of your line, etc.

Ideas about handling communication errors with TAS-HMITalk

Mon, 26 May 2008 22:51:00 GMT

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" labels when the device is not connected so the user can realize that the values are not new. Some users set the current values to 0 or to -1, but it is much better to show the last value with another color or as a disabled label.
2) Enable the labels or turn them to their real color when the communication is back OK. You can use the OnSuccessfullyReceived eventr for this.

You could have your application start with disabled labels that remain disabled until the first successful communication takes place. In summary:

1) Leave all labels start as disabled during design-time (enabled=false) so they are grayed when the application starts.
2) When you receive the OnSuccessfullyReceived event, use it to enable the labels (for example: label1.enabled=true, label2.enabled=true, etc.)
3)If you receive some OnErrorReceiving event, use it to disable all labels (for example: label1.enabled=false, label2.enabled=false, etc.).

Comments about TAS-HMITalk

Mon, 26 May 2008 22:38:00 GMT

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 a certain I/O point has changed its value, exceeded an alarm threshold, etc. The important thing about HMITalk is that you don't need to write most of the tedious routines required to keep track of all the things that happen behind-the-scenes in a typical SCADA application: COM handling, polling schedule, protocol messages format, variables required to hold I/O point values, detect changes, alarms, etc. There are over 100 drivers to choose from, all included in the installation package at no extra charge, and this list is growing. There is no limit in the number of tags or I/O points that can be requested or written.

In a few words, with TAS-HMITalk you can be supervising literally in minutes any PLC and watching its values changing. Of course, TAS-HMITalk also can handle everything related to sending data to the devices.

Comments about using several HMITalk object instances in your application

Mon, 26 May 2008 22:33:00 GMT

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 for you. The only thing to consider is that the more objects you create, the more complicated the code can become, specially because you will have to attend events from a higher number of HMITalk objects.

When you have several HMITalk objects in your application, no conflicts occur between their individual property values. Besides, a special polling engine who works in the background will take care of mantaining the polling loop for all those HMITalk objects who have the ScanActive property set to true.

Dynamically changing DriverNumPoints in runtime

Mon, 26 May 2008 22:21:00 GMT

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 think that your application really needs to use only one single HMITalk object and therefore that you need to change DriverNumPoints in runtime and the delay is unacceptable for your application performance, let us know and we can develp a modified version of the driver that please can help on this. If you are using the Modbus RTU xmodbusb driver, it does not require that you redefine DriverNumPoints since you can use DriverP5 to indicate how many registers you want to read/write. Just set DriverNumPoints to the highest number of registers that you plan to read/write. This will actually alloc internal memory for that number of registers. Then use DriverP5 to indicate how many registers you want to really read and you will not experience any delay.

Things to check if you cannot communicate with your device

Mon, 26 May 2008 22:02:00 GMT

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.
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.
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.
Check that the CommBaudRate property matches the baud rate used by your device.
Check that the CommParity property matches the parity used by your device.
Check that the CommDataBits property matches the databits used by your device.
Check that the CommStopBits property matches the stopbits used by your device.
If you are requesting data, make sure that the ScanActive property is set to On.
Also make sure that the ScanInterval and ScanStart properties are both set to reasonable values (default values are good in most cases).
Check that your device is configured to use the same protocol that the driver you are intending to use is expecting (some devices can talk more than one protocol and it must be first selected by the user).
Check that you are connecting the PC to the right external device's communication port.
Check that the device is correctly powered on.
Check that the device has its communication features enabled.
Check that you are using a RS-232/485 adaptor if the device requires it.
Check that the RS-232/485 adaptor is correctly powered on.
Check that you are using the right cable to connect the device and the PC, according to the device's manufacturer suggested pin-out.
Check that you are using the right PC COM port to talk to the device.
Additionally, if you are using a 485 converter to access the scale, set the following properties: CommHoldRTSWhileTransmitting=True and CommHoldRTSWhileReceiving=True.

Comments about the DriverStatus property and the OnPointValueChanged event

Mon, 26 May 2008 22:01:00 GMT

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 different than the previous value in the considered point. This event helps to minimize unnecessary execution of your code when nothing changes.

Comments about the Trigger method

Mon, 26 May 2008 21:45:00 GMT

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.

Comments about single writing vs. multiple writing

Mon, 26 May 2008 20:53:00 GMT

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 parameters and then you use always the same object to execute the command.

You don't need to use the Trigger method if the ScanAutoTrigger property is set. When ScanAutoTrigger=True and you assign a new value to a PointValue property, the message is automatically transmitted to the device ("automatically triggered"). If you also call the Trigger method, you will end up having two messages being transmitted. One of them is unnecesary.

Comments about the Unlimited License

Mon, 26 May 2008 14:10:00 GMT

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 the HMITalk installation package and can be also downloaded as a solitary file at CPKSoft site.page. You will have to run this utility at the end user’s PC to be able to retrieve the PC Id number. There is no need to install the full HMITalk package in order to run this utility.

In order to enter your serial number, you type it, including the minus characters, into the Unlimited License Serial Number textbox which is in the 'About' tab in the HMITalk properties window. To know that the serial number was properly recognized, the LicenseType property should reflect the following text: "Unlimited License". When you distribute your application, you don't need to re-install and re-enter the Unlimited License Serial Number in the target machine. The executable files that you generate will be distributed with copies of the hmitalk.ocx already customized to unlock all TAS-HMITalk features in each target machine.