การเชื่อมต่อ CompactLogix กับ DeltaV ผ่าน Modbus RTU: การออกแบบบทบาท

ลิงก์ CompactLogix-to-DeltaV Modbus RTU สามารถแลกเปลี่ยนค่าได้เพียงไม่กี่สิบค่า แต่ยังกลายเป็นหนึ่งในอินเทอร์เฟซที่คาดเดาได้ยากที่สุดในโรงงาน โปรโตคอลนั้นเรียบง่าย แต่ขอบเขตทางวิศวกรรมนั้นไม่ง่าย ความล้มเหลวส่วนใหญ่เริ่มต้นก่อนการเดินสาย เมื่อทั้งสองทีมไม่ได้กำหนดว่าใครเป็นผู้ส่งคำขอ ใครเป็นเจ้าของคำสั่ง ที่อยู่จะแสดงในรูปแบบใด หรือแต่ละระบบควรดำเนินการอย่างไรกับข้อมูลที่ค้างเก่า

การเชื่อมต่ออนุกรมที่เสถียรต้องมีผู้เริ่มต้นคำขอเพียงหนึ่งราย สัญญารีจิสเตอร์ที่มีการลงนามรับรอง สถานะคุณภาพที่กำหนดไว้อย่างชัดเจน และเซกเมนต์ RS-485 ที่จัดทำอย่างถูกต้อง

การตัดสินใจด้านสถาปัตยกรรมคือเรื่องแรกที่ต้องพิจารณา DeltaV อาจสื่อสารผ่านอินเทอร์เฟซอนุกรม ขณะที่ CompactLogix โดยทั่วไปต้องใช้โมดูลสื่อสารภายในแชสซีหรือเกตเวย์ภายนอก เอกสารข้อมูลอินเทอร์เฟซอนุกรม DeltaV M-series ของ Emerson ระบุว่ารองรับ Modbus RTU และ Modbus ASCII อย่างไรก็ตาม ยังต้องยืนยันรุ่นของโมดูล เฟิร์มแวร์คอนโทรลเลอร์ เฟิร์มแวร์เกตเวย์ และโทโพโลยีที่รองรับให้ตรงกับระบบที่ติดตั้งจริง

กำหนดผู้เริ่มต้นคำขอหนึ่งรายต่อเซกเมนต์อนุกรม

คำศัพท์ Modbus แบบดั้งเดิมใช้คำว่า master และ slave ปัจจุบันเอกสารจำนวนมากใช้คำว่า client และ server บนเซกเมนต์ Modbus RTU จะมีไคลเอนต์เพียงหนึ่งรายที่เริ่มต้นธุรกรรม และเซิร์ฟเวอร์จะตอบกลับคำขอที่ระบุที่อยู่ถึงตน ไคลเอนต์อิสระสองรายไม่สามารถใช้สายสัญญาณสองเส้นร่วมกันได้อย่างปลอดภัย เพราะไม่มีฝ่ายใดประสานจังหวะข้อความกับอีกฝ่าย

หาก DeltaV เป็นไคลเอนต์ ฝั่ง CompactLogix ต้องเปิดเผยข้อมูลผ่านอินเทอร์เฟซเซิร์ฟเวอร์ Modbus โปรแกรม PLC จะเขียนค่าที่ได้รับอนุมัติลงในพื้นที่ข้อมูลของเกตเวย์ แล้วเกตเวย์จะตอบกลับการโพลจาก DeltaV หาก PLC ต้องเป็นผู้เริ่มต้นการอ่านและการเขียน ให้ใช้พอร์ตหรือเส้นทางเกตเวย์แยกต่างหาก อย่าสันนิษฐานว่าอุปกรณ์ที่ระบุว่า “รองรับ Modbus” จะสามารถทำหน้าที่ทั้งสองบทบาทได้พร้อมกัน

หน้า ข้อมูลจำเพาะของ Modbus Organization แยกคู่มือการใช้งานอนุกรมฉบับปัจจุบันออกจากเอกสารปี 1996 ที่เลิกใช้แล้ว ความแตกต่างนี้สำคัญเมื่อข้อกำหนดโครงการระบุเพียงว่า “ใช้ Modbus” โดยไม่ได้ระบุเลเยอร์กายภาพและกฎการใช้งาน

ถือว่าแผนผังรีจิสเตอร์เป็นสัญญาอินเทอร์เฟซ

แผนผังรีจิสเตอร์ที่มีประโยชน์ไม่ใช่เพียงรายการอ้างอิง 4xxxx แต่ละจุดควรกำหนดออฟเซ็ตของโปรโตคอล หมายเลขอ้างอิงที่แสดง ฟังก์ชันโค้ด ชนิดข้อมูล ลำดับเวิร์ด ลำดับไบต์ สเกล หน่วยวิศวกรรม ทิศทางการอ่านหรือเขียน ช่วงค่าที่ถูกต้อง คาบการอัปเดต เจ้าของแหล่งข้อมูล และพฤติกรรมเมื่อเกิดความล้มเหลว ควรใส่หมายเลขการแก้ไขและบันทึกการอนุมัติ เพื่อให้ทั้งสองระบบใช้งานแผนผังเดียวกัน

การกำหนดที่อยู่ควรได้รับการตรวจสอบโดยเฉพาะ เครื่องมือกำหนดค่าบางชนิดแสดง holding register 40001 แต่ส่งออฟเซ็ตเป็นศูนย์ ขณะที่บางชนิดขอออฟเซ็ตแบบเริ่มนับจากศูนย์โดยตรง แผนผังที่บันทึกทั้งสองรูปแบบจะช่วยป้องกันปัญหาเลื่อนทีละรีจิสเตอร์ที่พบกันบ่อย ทดสอบด้วยรูปแบบค่าที่จดจำได้ก่อนโหลดค่าจริงเข้าสู่การผลิต

ค่าที่ใช้หลายรีจิสเตอร์ต้องระบุรายละเอียดให้ชัดเจนเช่นกัน ค่า REAL แบบ 32 บิตใช้รีจิสเตอร์ขนาด 16 บิตสองตัว แต่ผลิตภัณฑ์แต่ละรุ่นอาจใช้ลำดับรีจิสเตอร์แตกต่างกัน ทดสอบด้วยรูปแบบบิตที่ทราบค่าแทนการพึ่งพาป้ายกำกับอย่าง “big endian” ซึ่งแต่ละทีมอาจใช้ในความหมายต่างกัน จำนวนเต็มมีเครื่องหมาย จำนวนเต็มไม่มีเครื่องหมาย การบรรจุบูลีน และค่าจำนวนเต็มที่ผ่านการสเกล ก็ต้องมีกฎการแปลงที่จัดทำเป็นเอกสารเช่นกัน

แยกคำสั่ง สถานะ และการตอบรับ

อย่าให้การเขียนจาก DCS ส่งตรงไปยังเอาต์พุตทางกายภาพ ให้เขียนคำสั่งลงในพื้นที่พักข้อมูลภายใน CompactLogix โปรแกรม PLC ควรตรวจสอบโหมด เงื่อนไขอนุญาต ช่วงค่า ลำดับ ความใหม่ของข้อมูล และสิทธิ์ความเป็นเจ้าของ ก่อนเปลี่ยนสถานะที่ควบคุม จากนั้นจึงส่งกลับสถานะยอมรับ สถานะปฏิเสธ หรือรหัสเหตุผล

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

สร้างเลเยอร์ RS-485 ให้เหมาะกับโรงงานจริง

ใช้สายหลักแบบต่อพ่วงเป็นทอด ๆ แทนการต่อแบบดาว ติดตั้งตัวต้านทานปลายสายเฉพาะที่ปลายทางกายภาพทั้งสองด้าน รักษาสายแยกแขนงให้สั้น คงขั้วตัวนำให้ถูกต้อง และติดตั้งวงจรไบแอสในตำแหน่งที่ควบคุมได้เพียงจุดเดียวตามคู่มืออุปกรณ์ การต่อลงกราวด์ของชีลด์ต้องเป็นไปตามการออกแบบระบบกราวด์ของสถานที่และคำแนะนำของอุปกรณ์ การต่อแบบดัดแปลงอาจสร้างปัญหาโหมดร่วมแทนที่จะแก้ปัญหา

ทุกโหนดต้องใช้บอดเดียวกัน พาริตี บิตหยุด และโหมดเฟรมเดียวกัน Modbus RTU และ Modbus ASCII ไม่สามารถอยู่ร่วมกันบนเซกเมนต์เดียวกันได้ และไม่สามารถนำ DF1 มาผสมบนสายหลัก Modbus ได้โดยตรง เกตเวย์แปลงโปรโตคอลจะสร้างเครือข่ายสองชุดแยกจากกัน โดยมีจังหวะเวลา การวินิจฉัย และความรับผิดชอบแยกกัน

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

ส่งข้อมูลคุณภาพควบคู่กับทุกบล็อกค่า

ตัวเลขที่ดูน่าเชื่อถืออาจอันตรายกว่าความขัดข้องที่เห็นได้ชัด แต่ละบล็อกข้อมูลที่แลกเปลี่ยนควรมีสถานะสุขภาพการสื่อสาร เวลาที่สำเร็จครั้งล่าสุด อายุข้อมูล และเกณฑ์ข้อมูลค้างที่กำหนดไว้ ผู้ใช้ข้อมูลต้องทราบว่าค่านั้นเป็นข้อมูลปัจจุบัน ค่าที่คงไว้ ค่าที่แทนที่ หรือไม่ถูกต้อง

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

ทดสอบการเดินระบบตั้งแต่สายสัญญาณจนถึงการทำงานของกระบวนการ

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

ถัดไป ทดสอบคำสั่งแต่ละรายการตลอดเส้นทาง: คำขอจาก DCS การถ่ายโอนผ่านเกตเวย์ การตรวจสอบโดย PLC การทำงานของเอาต์พุต สัญญาณป้อนกลับ และการตอบรับ รวมถึงคำขอที่ถูกปฏิเสธ ค่าที่อยู่นอกช่วง การสูญเสียการสื่อสารระหว่างธุรกรรม การปิดเปิดเครื่อง และการกู้คืน การอ่านข้อมูลจริงได้สำเร็จไม่ได้หมายความว่าอินเทอร์เฟซควบคุมผ่านการยอมรับแล้ว

ฮาร์ดแวร์อินเทอร์เฟซที่เกี่ยวข้องรวบรวมไว้ใน คอลเลกชัน ProSoft อุปกรณ์ระบบโฮสต์โดยรวมอยู่ภายใต้ ระบบ DCS และระบบควบคุม การเลือกควรพิจารณาคอนโทรลเลอร์ เฟิร์มแวร์ พอร์ต การแยกวงจร และข้อกำหนดด้านสภาพแวดล้อมที่รองรับ ไม่ใช่พิจารณาจากชื่อโปรโตคอลเพียงอย่างเดียว

มุมมองทางวิศวกรรม

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

ดังนั้น อินเทอร์เฟซที่ดีที่สุดจึงไม่ใช่อินเทอร์เฟซที่มีแผนผังขนาดใหญ่ที่สุด แต่เป็นอินเทอร์เฟซที่ยังคงทำความเข้าใจได้ในอีกหลายปีข้างหน้า ทั้งด้านความเป็นเจ้าของ จังหวะเวลา คุณภาพ การทำงานสำรอง และหลักฐานการทดสอบ นั่นคือสิ่งที่เปลี่ยนการเชื่อมต่ออนุกรมแบบเรียบง่ายให้กลายเป็นขอบเขตระบบควบคุมที่บำรุงรักษาได้