TCP ต่อติด State 4 แต่ SentBytes เป็น 0 ตลอด บน PLCSIM สองตัว

พอดีผมต้องทดสอบลิงก์ระหว่าง PLC สองตัวบน simulator ก่อนส่งงาน เปิด S7-PLCSIM ขึ้นมาสอง instance ให้คุยกันผ่าน TSEND_C กับ TRCV_C แล้วข้อมูลไม่ไป ผมรายงานเจ้าของงานว่า simulator รุ่นนี้ต่อ TCP ระหว่างกันไม่ได้ ซึ่งผิด พออ่านคู่มือแล้วแก้คำเป็นว่าคู่มือบอกว่าได้แต่ไม่ทราบสาเหตุ ก็ยังผิดอีก เพราะทั้งสองรอบผมไม่ได้วัดอะไรเลย บทความนี้เล่าวิธีวัดที่ทำให้ได้คำตอบจริง คือ handshake ผ่าน สถานะขึ้น connected แต่ข้อมูลไม่ไหลผ่าน PROFINET interface ตัวที่สองของ CPU

รายงานผิดสองรอบ ก่อนจะยอมวัด

ลำดับที่เกิดจริงเป็นแบบนี้ ตอนแรกผมทดสอบ logic ทีละ PLC บน S7-PLCSIM V15.1 รุ่น Compact ที่มากับ TIA Portal ไม่ใช่ PLCSIM Advanced ผ่านหมด แล้วลองเปิดสอง instance ให้ Main PLC กับ Station PLC คุยกันจริงผ่านบล็อกสื่อสาร ไม่ติด ผมเลยเขียนลงรายงานว่า PLCSIM V15.1 ต่อ TCP ระหว่าง instance ไม่ได้ ข้อสรุปนี้มาจากความพยายามครั้งเดียว

รอบสอง ผมกลับไปอ่านคู่มือ S7-PLCSIM V15 หน้า 143 ถึง 146 ซึ่งระบุชัดว่า TSEND_C กับ TRCV_C ระหว่าง S7-1500 สอง instance รองรับ มีเงื่อนไขว่า IP ต้องไม่ซ้ำ การตั้ง connection ต้องอยู่ในโปรแกรม และรับได้ 1024 ไบต์ต่อครั้ง ผมเลยแก้คำในรายงานเป็น "คู่มือบอกว่าได้ สาเหตุที่ไม่ติดไม่ทราบ"

เจ้าของงานอ่านแล้วบอกให้ไปค้นแล้ววัดให้ได้ข้อเท็จจริง ซึ่งเป็นคำสั่งที่ถูก รอบที่สามผมเลยเลิกเขียนข้อสรุป แล้วไปทำเครื่องวัดก่อน

วางเครื่องวัด OB วินิจฉัยทั้งสองฝั่ง

บล็อก TSEND_C กับ TRCV_C เก็บทุกอย่างที่อยากรู้ไว้ใน instance ของมันอยู่แล้ว ทั้ง STATUS ล่าสุด และผลของ T_DIAG ที่บล็อกเรียกใช้ภายใน ได้แก่สถานะของ connection จำนวนไบต์ที่ส่งไปแล้ว และจำนวนไบต์ที่รับมาแล้ว ปัญหาคือค่าพวกนี้เปลี่ยนเร็ว และ STATUS ของ error อยู่แค่ scan เดียว เปิด watch table ดูด้วยตาไม่ทัน ผมเลยเพิ่ม OB ทดสอบในสำเนาทดสอบของทั้งสองฝั่ง ให้มันคัดลอกค่าจาก instance ตัวจริงลง DB สรุปตัวเดียว แล้วนับ error ไว้ด้วย

// OB วินิจฉัย (เฉพาะสำเนาทดสอบ) - คัดลอกค่าจาก instance ที่ network ใช้จริง
TestDB.Send_STATUS   := Inst_Send.STATUS;
TestDB.Send_State    := Inst_Send.s_TDIAG_Status.State;
TestDB.Send_Sent     := Inst_Send.s_TDIAG_Status.SentBytes;
TestDB.Recv_STATUS   := Inst_Recv.STATUS;
TestDB.Recv_State    := Inst_Recv.s_TDIAG_Status.State;
TestDB.Recv_Received := Inst_Recv.s_TDIAG_Status.ReceivedBytes;

IF Inst_Send.ERROR THEN
    TestDB.ErrCount := TestDB.ErrCount + 1;
    TestDB.LastErr  := Inst_Send.STATUS;      // เก็บ error ที่อยู่แค่ scan เดียว
END_IF;

ตัวเลขที่ต้องดูคู่กันมีสามชุด State บอกว่า connection อยู่ขั้นไหน ค่า 4 คือต่อติดแล้ว SentBytes กับ ReceivedBytes บอกว่ามีข้อมูลผ่านจริงหรือเปล่า ถ้า State เป็น 4 แต่ตัวนับไบต์ไม่ขยับ แปลว่าปัญหาไม่ได้อยู่ที่การต่อ connection

เครื่องวัดอย่างเดียวยังไม่พอ ต้องมี control case ด้วย คำถามที่ผมกังวลคือ simulator อาจจะรายงาน State 4 ให้ทุก connection โดยไม่ได้ต่ออะไรจริงเลยก็ได้ ผมเลยเพิ่มลิงก์ควบคุมอีกเส้นในสำเนาทดสอบ ชี้ไปหา IP ของ partner ที่ไม่มีอยู่ในวง ถ้าเส้นนี้ขึ้น State 4 เหมือนกัน แปลว่า State เชื่อไม่ได้ ถ้าเส้นนี้ฟ้อง error แปลว่า State 4 ของเส้นอื่นเกิดจาก handshake จริง

ดึงตาราง connection ออกจากโครงการ

ก่อนจะอ่านผลวัด ต้องรู้ก่อนว่าแต่ละเส้นถูกตั้งค่าไว้อย่างไร พารามิเตอร์ของ connection อยู่ใน connection DB ซึ่ง TIA Portal เก็บไว้ในกลุ่มบล็อกของระบบ ไม่ได้โผล่อยู่กับบล็อกปกติ ถ้าเดินเฉพาะ BlockGroup.Blocks จะไม่เจอ ต้องเดิน SystemBlockGroups ของ PlcSoftware.BlockGroup ผม export ออกมาเป็น XML ทั้งหมดด้วย Openness จาก Windows PowerShell 5.1

# รันใน Windows PowerShell 5.1 บนเครื่องที่เปิด TIA Portal V15.1 กับสำเนาทดสอบอยู่
$dll = 'C:\Program Files\Siemens\Automation\Portal V15_1\PublicAPI\V15.1\Siemens.Engineering.dll'
[Reflection.Assembly]::LoadFrom($dll) | Out-Null
$tia = [Siemens.Engineering.TiaPortal]::GetProcesses()[0].Attach()
$prj = $tia.Projects[0]
$out = 'C:\Projects\conn_export'
New-Item -ItemType Directory -Force -Path $out | Out-Null

function Dump($group) {
    foreach ($b in $group.Blocks) {
        $f = Join-Path $out (($b.Name -replace '[\\/:*?"<>|]', '_') + '.xml')
        if (Test-Path $f) { Remove-Item $f -Force }
        $b.Export([IO.FileInfo]$f, [Siemens.Engineering.ExportOptions]::WithDefaults)
    }
    foreach ($g in $group.Groups) { Dump $g }
}

foreach ($dev in $prj.Devices) {
    foreach ($item in $dev.DeviceItems) {
        $type = [Siemens.Engineering.HW.Features.SoftwareContainer]
        $sc = $item.GetType().GetMethod('GetService').MakeGenericMethod($type).Invoke($item, $null)
        if ($sc -and $sc.Software -is [Siemens.Engineering.SW.PlcSoftware]) {
            foreach ($sys in $sc.Software.BlockGroup.SystemBlockGroups) { Dump $sys }
        }
    }
}

PowerShell เรียก generic method ตรง ๆ ไม่ได้ เลยต้องอ้อมผ่าน MakeGenericMethod แบบในโค้ด ได้ XML มาแล้วผมใช้ Python ดึง start value ของ member ที่เกี่ยวกับ connection ออกมาเรียงเป็นตาราง

import glob, os
import xml.etree.ElementTree as ET

KEYS = ('InterfaceId', 'ID', 'ConnectionType', 'ActiveEstablished',
        'ADDR', 'RemotePort', 'LocalPort')

def local(tag):
    return tag.split('}')[-1]

def start_values(node, prefix=''):
    for child in node:
        kind = local(child.tag)
        if kind == 'Member':
            name = prefix + child.get('Name', '')
            for sv in child:
                if local(sv.tag) == 'StartValue' and sv.text:
                    yield name, sv.text.strip()
            yield from start_values(child, name + '.')
        elif kind == 'Subelement':                      # สมาชิกของ array
            name = prefix.rstrip('.') + '[' + child.get('Path', '') + ']'
            for sv in child:
                if local(sv.tag) == 'StartValue' and sv.text:
                    yield name, sv.text.strip()
        else:
            yield from start_values(child, prefix)

for path in sorted(glob.glob(r'C:\Projects\conn_export\*.xml')):
    rows = [(n, v) for n, v in start_values(ET.parse(path).getroot())
            if any(k in n for k in KEYS)]
    if rows:
        print(os.path.basename(path))
        for name, value in rows:
            print(f'   {name:<28} {value}')

ตารางที่ได้หน้าตาแบบนี้ ค่า IP กับ port ผมเปลี่ยนเป็นค่าตัวอย่างแล้ว ส่วนโครงสร้างกับค่า InterfaceId เป็นไปตามที่อ่านได้จริง

คอลัมน์ที่สำคัญที่สุดคือ InterfaceId โครงการฝั่งกลางใช้ 72 กับทุกลิงก์ ส่วนฝั่งสถานีใช้ 64 บน CPU ที่มี PROFINET สองพอร์ต 64 คือ interface ตัวแรกหรือ X1 และ 72 คือตัวที่สองหรือ X2 ตอนนั้นผมยังไม่รู้ว่าเรื่องนี้สำคัญ แค่จดไว้ว่าสองฝั่งไม่เหมือนกัน

ผลวัด ทุกเส้นที่พังผ่าน X2

โหลดสำเนาทดสอบลงทั้งสอง instance ปล่อยให้วิ่งแล้วอ่าน DB สรุป ได้ผลแบบนี้

แถวสุดท้ายคือตัวที่ทำให้อ่านแถวอื่นได้ ลิงก์ที่ชี้ไปหา IP ที่ไม่มีเครื่องอยู่ฟ้อง 16#80C5 ไม่ได้ขึ้น State 4 แปลว่า simulator ไม่ได้ตอบ connected ให้ทุกเส้นแบบมั่ว ๆ State 4 ของเส้น Main ที่ออกจาก X2 เลยเป็นของจริง มี handshake เกิดขึ้นจริง แต่หลังจากนั้นไม่มีข้อมูลสักไบต์ผ่านไป

พอเอาผลวัดไปวางทับตาราง connection รูปแบบก็ชัด ทุกเส้นที่มีปัญหาเริ่มหรือจบที่ interface ตัวที่สองของ CPU ฝั่งกลาง เส้นที่ออกจาก X2 ส่งไม่ออก เส้นที่เข้าที่ X2 รับไม่ได้ ส่วนฝั่งที่อยู่บน X1 ทำงานปกติ ตัวนับไบต์ขยับ ข้อสรุปที่ผมเขียนลงรายงานรอบที่สามคือ PLCSIM V15.1 รุ่นนี้แสดง IP ของ X2 ให้เห็น รับ TCP handshake ให้ด้วย แต่ไม่ส่งข้อมูลของบล็อก T ผ่าน interface ตัวที่สอง ลิงก์บน X1 ใช้ได้

ข้อสรุปนี้ต่างจากสองรอบแรกตรงที่มันบอกขอบเขตได้ ไม่ใช่ "TCP ไม่ได้" และไม่ใช่ "ไม่ทราบสาเหตุ" แต่เป็น "เส้นที่ผ่าน X2 ไม่ได้ เส้นบน X1 ได้" ซึ่งเอาไปตัดสินใจต่อได้ทันที เรื่องสัญญาณที่ดูเหมือนผ่านแต่ไม่ได้แปลว่าใช้ได้ ผมเคยเขียนฝั่งงานเว็บไว้ใน บทความเรื่องสัญญาณหลอกของ sandbox รอบนี้เป็นเรื่องเดียวกันในโลกของ simulator PLC

กับดักตอนวัด อ่าน instance ผิดตัวได้ 16#7000

ระหว่างทำเครื่องวัดผมพลาดไปหนึ่งรอบ ซึ่งถ้าไม่จับได้จะกลายเป็นข้อสรุปผิดรอบที่สาม โครงการนี้มี instance ของบล็อกสื่อสารสองแบบปนกัน แบบแรกเป็น single-instance DB คือ DB แยกหนึ่งตัวต่อหนึ่งบล็อก แบบที่สองเป็น multi-instance คือ instance เป็น member อยู่ใน DB ของบล็อกอื่น และบางชื่อมีทั้งสองแบบอยู่ในโครงการพร้อมกัน โดยที่ network ใช้จริงแค่ตัวเดียว

รอบแรก OB วินิจฉัยของผมอ่านจากตัวที่ network ไม่ได้ใช้ ค่าที่ได้คือ STATUS 16#7000 ซึ่งหมายถึงบล็อกไม่มีงานให้ทำ ถ้าเชื่อค่านี้ ผมจะวินิจฉัยว่าโปรแกรมไม่เคยสั่งส่ง ซึ่งผิดทั้งหมด วิธีกันคือเปิด XML ของบล็อกที่เรียก TSEND_C หรือ TRCV_C แล้วดูว่า Part นั้นอ้าง instance ชื่ออะไร

import sys
import xml.etree.ElementTree as ET

def local(tag):
    return tag.split('}')[-1]

root = ET.parse(sys.argv[1]).getroot()          # XML ของ FC/FB ที่เรียกบล็อกสื่อสาร
for part in root.iter():
    if local(part.tag) != 'Part' or part.get('Name') not in ('TSEND_C', 'TRCV_C'):
        continue
    for inst in part:
        if local(inst.tag) != 'Instance':
            continue
        names = [c.get('Name') for c in inst if local(c.tag) == 'Component']
        print(part.get('Name'), inst.get('Scope'), '.'.join(names))

ถ้าผลออกมาเป็นชื่อเดียว คือ single-instance DB ถ้าออกมาเป็นชื่อ DB ตามด้วยชื่อ member คือ multi-instance OB วินิจฉัยต้องอ่านจากชื่อที่สคริปต์นี้พิมพ์ออกมาเท่านั้น

อีกเรื่องที่ต้องตัดออกก่อนสรุปคือโปรแกรมได้สั่งส่งจริงหรือเปล่า บล็อกส่งในโครงการนี้ถูกทริกเกอร์ด้วยบิตของ clock memory byte ถ้า clock memory ไม่ได้เปิดใช้ใน hardware config ของสำเนาทดสอบ บล็อกจะไม่ถูกสั่งเลย และอาการภายนอกจะเหมือน SentBytes ค้างที่ 0 ทุกประการ ผมเลยเพิ่มอีกสองสามบรรทัดใน OB เดียวกัน นับขอบของบิต 1 Hz กับ 5 Hz และนับจำนวน scan

// ยืนยันว่า clock memory เดินจริง และ OB นี้ถูกเรียกจริง
TestDB.ScanCount := TestDB.ScanCount + 1;

IF "Clock_1Hz" AND NOT TestDB.Last1Hz THEN
    TestDB.Edge1Hz := TestDB.Edge1Hz + 1;
END_IF;
TestDB.Last1Hz := "Clock_1Hz";

IF "Clock_5Hz" AND NOT TestDB.Last5Hz THEN
    TestDB.Edge5Hz := TestDB.Edge5Hz + 1;
END_IF;
TestDB.Last5Hz := "Clock_5Hz";

ตัวนับทั้งสามต้องขยับ ถ้าตัวนับขอบไม่ขยับ ปัญหาอยู่ที่ทริกเกอร์ ไม่ใช่ที่เครือข่าย ต้องแก้ตรงนั้นก่อนแล้วค่อยกลับมาดู State กับตัวนับไบต์

1. หาชื่อ instance ที่ network ใช้จริงจาก XML ของบล็อก ไม่เดาจากชื่อ DB
2. ยืนยันว่าทริกเกอร์ส่งเดินจริงด้วยตัวนับขอบของ clock memory
3. อ่าน STATUS, State, SentBytes และ ReceivedBytes ของทั้งสองฝั่งพร้อมกัน
4. เพิ่มลิงก์ควบคุมไปหา partner ที่ไม่มีอยู่ เพื่อดูว่า error จริงหน้าตาเป็นอย่างไร
5. ดึงตาราง connection ออกมาวางเทียบกับผลวัด หาตัวแปรที่เส้นพังมีร่วมกัน
6. เขียนข้อสรุปเป็นขอบเขต อะไรได้ อะไรไม่ได้ ภายใต้เงื่อนไขไหน

ทางออกเชิงปฏิบัติ และอาการข้างเคียงของ PLCSIM

รู้ขอบเขตแล้วทางเลือกมีสองทาง ทางแรก ถ้าลิงก์ของโครงการอยู่บน X2 จริงและต้องคงไว้อย่างนั้น ให้ยอมรับว่าทดสอบด้วย simulator สองตัวไม่ได้ ต้องไปทดสอบบน PLC จริง ทางที่สอง ในสำเนาทดสอบเท่านั้น ย้าย connection DB ของทั้งสองฝั่งไปใช้ X1 บน subnet เดียวกัน เพื่อทดสอบ logic ของการแลกข้อมูล โดยรู้อยู่ว่าสิ่งที่ทดสอบไม่ใช่เส้นทางเครือข่ายของจริง ไม่ว่าเลือกทางไหน เอกสารส่งมอบต้องมีหัวข้อรายการที่ยังไม่ได้ทดสอบ และต้องเขียนไว้ในนั้นว่าลิงก์จริงระหว่าง PLC ต้องตรวจตอน commissioning

ระหว่างเปิดปิด instance ไปมาหลายสิบรอบ ผมเจออาการของ PLCSIM ที่ควรรู้ไว้ จะได้ไม่เอาไปปนกับปัญหาของลิงก์

บทเรียน เครื่องมือทำไม่ได้ต้องมีหลักฐานสองชั้น

สรุปคือสองรอบแรกผมผิดด้วยเหตุผลเดียวกัน คือเขียนข้อสรุปก่อนมีผลวัด รอบแรกโทษเครื่องมือ รอบสองยกคู่มือมาอ้างแล้วหยุดแค่นั้น ทั้งสองแบบทำให้เจ้าของงานตัดสินใจต่อไม่ได้ เพราะไม่รู้ว่าอะไรทดสอบได้ อะไรทดสอบไม่ได้

กติกาที่ผมใช้กับตัวเองตั้งแต่งานนี้ คือก่อนจะเขียนว่าเครื่องมือตัวไหนทำอะไรไม่ได้ ต้องมีครบสองอย่าง อย่างแรกคือหน้าคู่มือที่บอกว่าเครื่องมือนั้นรองรับหรือไม่รองรับอะไร อย่างที่สองคือผลวัดที่แยกตัวแปรทีละตัว และมี control case ที่รู้คำตอบล่วงหน้าไว้เทียบ ถ้ามีแค่อย่างเดียวให้เขียนว่ายังไม่รู้ และบอกว่าจะวัดอะไรต่อ

ข้อจำกัดของผลชุดนี้ก็ต้องบอกไว้ด้วย ผมวัดบน PLCSIM V15.1 รุ่น Compact รุ่นเดียว กับ CPU รุ่นที่มี PROFINET สองพอร์ต ไม่ได้ลองบน PLCSIM Advanced และไม่ได้ลองรุ่นอื่นของ TIA Portal ใครใช้รุ่นอื่นให้วัดเองด้วยวิธีเดียวกันก่อนเชื่อ ส่วนงานที่ลิงก์นี้รับใช้อยู่ คือ watchdog ของลิงก์ระหว่าง PLC ผมแยกไว้ใน บทความเรื่องช่องโหว่ 3 วินาทีแรกหลังเปิดเครื่อง ตรงไหนที่ผลวัดบนรุ่นอื่นออกมาไม่ตรงกับที่ผมเขียน เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ