DeltaDTB48 Protocol Implementation
OOP Concept in Reality, Is It Applicable?
Object Oriented Concept is that something has been scattered among programmers since 80’s when some oncoming languages as small-talk had just been released to acquaint programmers with new OOP worlds. If we expand our viewing point and do not stick to the programming area, we can feel the world surrounding us as a complete sample of object orienting implementation. We, as humankind are looked upon as an complex-object among other ones, the base object of each of which is atom (somehow, others may complain that there is a sub-atom and something like that, but let us not penetrate any more, you know, I’m not a physic professor and my knowledge is limited up to here!). By this concept, it got easier to model everything all around. If we could model the re-action and activation of some sort of atoms which are common (the accuracy of modeling depends on the time spent and also measuring devices which are implemented), then we can simulate simple components and molecules, then this simulating can respectively continue up to a complete complex form of existence object. Let’s not go further, in programming the same method, fortunately, has been being implanted from simple Windows application program to developing a comprehensive national data base bank. The base is simple, if something is dividable, break it down and make your work simple (the best form of divide and conquer algorithm).
All that rambling was just for introducing the idea of Object Orienting Implementation in Industrial Controlling System based on embedded system. The extra long name might make you confused, but the using way is so simple and popular that you perhaps never have paid attention before. Let me give an example, it might be more familiar with guys who are engaged in the automation field. PLC is the most common industrial device used. At first look, no matter whether you use Siemens, Omron, Delta or some other marks; it does not have something especial except a combination of Ladder and sometimes STL language(s) to support the main idea of controlling a repeated process of production in most cases. There are different approaches working for programming such devices, but unfortunately the weak method has dominated. Weak method, based on what has been defined in “A Structured Framework for the Modeling and Control of Modular Machining Centers”, indicates 3 main points:
- Neither systematic nor formal models and methodologies are adopted for the control design
- There is no separation between what the controller should do, the so-called control law, and how a correct implementation of such a control law can be obtained, and
- There is no integration between the mechanical and control system projects.
The systematic design which is mentioned and emphasized in OOP, has roots in thinking OOP, which might think that exists, but just superficially has been scattered now.
OOP and Embedded Systems, A Practical Implementation Sample
During one of my last projects, the main goal was controlling pressure how it adjusted to set point – defined by user with no repeat ion limitation and in limited range - meanwhile try to measure the flow. In a normal controlling procession, a PLC had to be implemented to read sensors, adjust appropriate related voltage or current to actuators, but due to OOP impression, we decided to use some simpler but most effective PID controller stock on each line control and monitor the process (Delta Temperature Controller DTB Series). They might seem to be specialized for temperature, but their enormous ability made it possible to use them instead of PLC which is a so-called expensive automation device. All processes were simple, we made a distributed controlling network backing on Bus topology, bought a RS485/232 Converter, set the internal configuration of each embedded PID controllers, and then started the test. The result was tremendously prefect. The controllers adjusted exactly as set point demanded.
The delta controller protocol resembled ModBus protocol, but in an easier format. I hope there is someone who is interested in simplifying the industrial controlling process. Now let’s drill into the protocol.
In the provided sample application, there is a good demonstration on how to include the component. Moreover, the use of the component is very well demonstrated. The only thing that must be paid attention to is data transition protocol itself.
The data transition generally is divided in two portions, first, requesting what user intends, it perhaps is reading a specific register or bit status or setting value to, and the second is getting response determines not only controller has received the request, but it also sends you back the feedback.
1. Requesting contents/status:
- Note 1: In most cases, the unit number is in range of 01xH to F7xH.
- Note 2: 02xH is dedicated for reading bit and 03xH is dedicated for reading the contest of register
- Note 3: The range of register/bit is mentioned in catalog accompanies the controller, so, please note do not exceed the range.
- Note 4: You’re allowed to read maximum 8 registers contest or 16 bits status. Demanding more executes error response.
Friend Function delta_read_bit(ByVal unit_num As Integer, _
ByVal bit_add As Delta_Bit_Add) As String
...
Dim str_address As String = Hex(bit_add)
If str_address.Length < 4 Then str_address = _
New String("0", 4 - str_address.Length) & str_address
If str_address.Length > 4 Then str_address = Mid(str_address, 1, 4)
If Not comm_Serial.IsOpen Then comm_Serial.Open()
str_responce = comm_Serial.ReadExisting
comm_Serial.Write(":" & Trim(LRC_CheckSum_
(unit_no & "02" & str_address & "0001")) & vbCrLf)
...
End Function
Friend Function delta_read_word(ByVal unit_num As Integer, _
ByVal reg_Add As Delta_Reg_Add) As String
...
Dim str_address As String = Hex(reg_Add)
If str_address.Length < 4 Then str_address = _
New String("0", 4 - str_address.Length) & str_address
If str_address.Length > 4 Then str_address = Mid(str_address, 1, 4)
If Not comm_Serial.IsOpen Then comm_Serial.Open()
str_responce = comm_Serial.ReadExisting
comm_Serial.Write(":" & Trim(LRC_CheckSum_
(unit_no & "03" & str_address & "0001")) & vbCrLf)
...
End Function
There are two possible responses, register reading response and bit reading response. The one which is indicating for register is shown below.
- Note 5: Please pay attention that each register contains two bytes, so e.g. if you’ve requested 2 registers contents, the byte # = 2 x 2 = 4, and in requesting 5, it’ll be byte #=5 x 2 = 10.
The one which is indicating for bit reading is shown below:
- Note 6: The bi(s) status is the sum of requested bit(s) status respectively. E.g. if you’ve requested the bits 0811xH to 0813xH (3 consecutive) and their current status are 0811xH = On, 0812xH = On, 0813xH = off, the result is 1 x (2^0) + 1 x (2^1)+0 x (2^2) = 3, means the greater bit address indicates higher 2’s exponent.
2. Writing value/setting status:
...
Dim str_address as string = hex(bit_add)
If str_address.Length < 4 Then str_address = _
New String("0", 4 - str_address.Length) & str_address
If str_address.Length > 4 Then str_address = Mid(str_address, 1, 4)
If Not comm_Serial.IsOpen Then comm_Serial.Open()
...
str_responce = comm_Serial.ReadExisting
comm_Serial.Write(":" & Trim(LRC_CheckSum_
(unit_no & "05" & str_address & IIf(reg_data, "FF00", "0000"))) & vbCrLf)
...
Acknowledgement
It's my appreciation to thank Prof. Kamalaldin Farzaneh, who is not only my manager, but also my master and teacher who has let me test, fall and rise again.
Update History
- Monday August 1st 2011, LabView 7.0 Implementation added