TAS-HMITalk Support

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.