Debug Daikin Bacnet/IP gateway

In a presumably simple migration and upgrading job, some things could be really simple when you use the black box concept. It could also gets really complicated when the black box concept is applied.

This is a presumably simple Scada upgrading project. Objective: To upgrade an old desktop PC with Indusoft Web Studio v6.1 to a new Beckhoff Panel PC equipped with latest Indusoft Web Studio v7.1

The old PC has Windows XP Prof and it is connected to a Mitsubishi PLC A series and Daikin D-bac gateway. The PLC controls the exhaust fans and pumps in various blocks of the building. As for Daikin gateway is for control of VRV located in different rooms. The Indusoft Web Studio is version 6.1

The new Beckhoff Panel PC equipped with latest Intel CPU and Windows 7 Prof. The Indusoft Web Studio was upgraded to latest version 7.1 SP3.

There are several black box assumptions made here:

1) the target devices (ie. PLC and Bacnet Gateway) are fully functional since it has been working fine with the old PC.

2) Indusoft driver remains the same even with the upgraded version.

3) cable and connection remains the same when upgrading from old to new PC.

When we arrived at the work site, we installed the new Beckhoff PC and powered it up. Then, we plugged in the serial cable that connects to the Mitsubishi PLC and tested the comms. Viola! Everything was working as expected and assumptions were correct thus far.

The "fun" comes when we plug in the Ethernet cross cable which connects to the BacNet/IP gateway. The comms fails to work. We turned to the protocol analyzer, field read/write command in IWS log. The only message we get is "device is unavailable".

In the old PC, there was a Bacnet-OPC server (from Scada Engine) that passes information through Opc-DA protocol. In the new PC, we are removing the Bacnet-OPC server and uses the build in BacNet/IP driver from Indusoft. We expects that the comms will works the same way since it's standardized on a well renown Bacnet standard.

After many attempts and trials, we decided to go really deep into the protocol by using Wireshark to monitor the network traffic and protocol send between the 2 devices. Only then did we realize that the Daikin BacNet Gateway is totally ignoring all the read commands from the new PC.

Therefore, our black box assumptions could be wrong after all. We have no idea what to expect from the BacNet gateway and we can't tell for sure if the target device is functioning properly.

Our 2nd assumption on the Indusoft driver could also be wrong too. As the older Indusoft project uses OPC-DA, by assuming that things will works the same when we use BacNet/IP in replacement is a big mistake.

At the end of the day, we'll need Daikin specialist to provide us with professional advice if these assumptions are to be proven correct or not. That's just parts and parcels of an engineer life. Debug!

The black box

Engineering succeeds and fails because of the black box.

A black box is a conceptual container for the knowledge, processes, and working assumptions of an.engineering specialty. On multidisciplinary design teams, the output of one discipline's black box serves as the input for the black boxes of one or more other disciplines. The designer of a fuel system, for example, works within a "fuel system black box" that produces an output for the engine designer; the engine designers' blacks box output to the automatic transmission designer, and so on.

Design solution don't emerge linearly, however, and design teams work in interconnected webs of relationships. Hence, the black box model works best when employed as a momentary ideal that is adjusted and redefined throughout the design process as constraints become evident, opportunities emerge, prototypes are tested, and goals are clarified. It fails when expected to be permanent and orderly.

Excerpt from "101 things I learned in engineering school" by John Kuprenas with Matthew Frederick

The 5R

5S is the name of a workplace organization method that uses a list of five Japanese words: seiri, seiton, seiso, seiketsu, and shitsuke.

http://en.m.wikipedia.org/wiki/5S_(methodology)

While conducting Twincat PLC seminar, I was introduced to the 5R concept by a group of trainees who were mainly from the maintenance department.

Till date, 5R concept always works without fail. The 5R are Reset, Restart, Reboot, Relax, and last but also the most important R among the Rs is "Read The Manual"!!

Introduction

Hi everyone,

My name is Roland. I am working as programmer/engineer for more than a decade. My field of work involve software, hardware and sometimes human behavior troubleshooting.

In the scope of work, I found that there are some troubleshooting (aka debug) principles that are not taught in technical college nor university.

Thus with this in mind, my objective is to share troubleshooting principles with everyone who are involve in some sort of troubleshooting. I shall include practical examples of how to troubleshoot a PC that goes on strike, Electrical appliances that fails on you, Software that doesn't behave and, last but not least,Human that don't seems to understand you.

That's all folks. Please feel free to give comments/feedback if you have any. And also share with us your immeasurable knowledge and experience so that it may help some people out there too. Bye!

Roland