ทำไม RSLogix 500 จึงทำงานช้าลงระหว่างการแก้ไขออนไลน์

การแก้ไขออนไลน์ใน RSLogix 500 ที่ช้ามักถูกโทษว่าเกิดจากโปรเซสเซอร์ SLC ที่เก่า แต่ความล่าช้าที่มองเห็นได้อาจเกิดจากหลายจุด ได้แก่ เวิร์กสเตชันวิศวกรรม การสื่อสารของ RSLinx เครือข่ายที่มีการกำหนดเส้นทางหรือมีสัญญาณรบกวน ความไม่สอดคล้องของไฟล์โครงการ หน่วยความจำที่มีอยู่ในคอนโทรลเลอร์ หรือภาระงานของโปรเซสเซอร์ในการรักษาการแก้ไขออนไลน์ การเปลี่ยนฮาร์ดแวร์ก่อนแยกตรวจสอบแต่ละส่วนอาจทำให้ปัญหาที่แท้จริงยังคงอยู่

วัดให้ทราบว่าความล่าช้าเกิดขึ้นในขั้นตอนไหน—การอัปเดตหน้าจอ การค้นหาอุปกรณ์ การอัปโหลด การตรวจสอบ การยอมรับ การทดสอบ หรือการประกอบ—ก่อนเปลี่ยนคอนโทรลเลอร์หรือเครือข่าย

กำหนดอาการให้ชัดเจน

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

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

สร้างค่าพื้นฐานที่ปลอดภัย

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

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

แยกความล่าช้าของเวิร์กสเตชันออกจากความล่าช้าด้านการสื่อสาร

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

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

จากนั้นทดสอบการสื่อสาร สังเกตการวินิจฉัยไดรเวอร์ของ RSLinx และเปรียบเทียบเส้นทางภายในเครื่องโดยตรงกับเส้นทางที่มีการกำหนดเส้นทางตามปกติ เมื่อมีทางเลือกที่ปลอดภัยและรองรับ ตรวจสอบการลองส่งซ้ำหลายครั้ง การแสดงโหนดที่ไม่เสถียร แอดเดรสซ้ำ ข้อผิดพลาดด้านดูเพล็กซ์หรือสวิตช์บน Ethernet และข้อผิดพลาดของชั้นกายภาพบนเครือข่ายอนุกรม DH-485 หรือ DH+ การค้นหาอุปกรณ์ที่สำเร็จในท้ายที่สุดไม่ใช่หลักฐานว่าเส้นทางการเขียนโปรแกรมมีสภาพดี

ตรวจสอบความสอดคล้องของโครงการและเซสชัน

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

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

ทำความเข้าใจต้นทุนที่ฝั่งคอนโทรลเลอร์

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

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

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

ใช้ลำดับการแก้ไขที่ควบคุมได้

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

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

ตีความรูปแบบที่พบบ่อย

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

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

ตัดสินใจว่าเมื่อใดควรหยุดแก้ไขออนไลน์

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

สามารถทบทวนแพลตฟอร์มรุ่นเก่าและทางเลือกในการย้ายระบบได้ใน คอลเลกชัน Allen-Bradley และ คอลเลกชันระบบ PLC และ PAC การย้ายระบบควรดำเนินการตามหลักฐานเกี่ยวกับความเสี่ยงด้านวงจรชีวิต ประสิทธิภาพ อะไหล่สำรอง และการกู้คืน ไม่ใช่จากการแก้ไขที่ช้าเพียงครั้งเดียว

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

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