PLC สองตัวแลกข้อมูลได้สามแบบ เลือกผิดแล้วข้อมูลช้าหรือสั่งซ้อนกัน
คำถามว่าจะให้ PLC สองตัวคุยกันด้วยบล็อกไหนเป็นคำถามลำดับท้าย คำถามแรกคือข้อมูลก้อนนั้นต้องสดทุก scan หรือไม่ และใครเป็นเจ้าของเอาต์พุตที่มันไปสั่ง
สรุปใน 1 นาที
- อาการ/ปัญหา
- เลือกวิธีแลกข้อมูลระหว่าง PLC ผิดแบบ ข้อมูลช้าหรือสั่งเอาต์พุตซ้อนกัน
- ใครควรอ่าน
- วิศวกรควบคุมที่ต้องให้ PLC สองตัวคุยกัน
- ทางแก้แบบสั้น
- แยกสามแบบคือ Data Link, Remote I/O และ Message Service ตอบห้าคำถามเรื่องความสดของข้อมูลกับเจ้าของเอาต์พุตก่อนเลือก
พอดีผมกำลังวางแบบให้ PLC สองตัวในชุดทดลองแลกข้อมูลกัน แล้วสังเกตว่าตัวเองเรียกทุกอย่างรวม ๆ ว่า "ส่งข้อมูลหากัน" ตอนนั้นผมคิดว่าคำถามมีข้อเดียวคือจะใช้บล็อกสื่อสารตัวไหน พอไปเปิดคู่มือเครือข่ายของ Omron อ่านเพื่อหาแนวเทียบ ถึงเห็นว่าเขาแยกการแลกข้อมูลระหว่าง PLC ออกเป็นสามแบบที่คนละเรื่องกันเลย แต่ละแบบมีขีดจำกัดเป็นตัวเลข และที่สำคัญกว่าตัวเลขคือแต่ละแบบตอบคำถามไม่เหมือนกันว่าใครเป็นเจ้าของเอาต์พุต ผมเลยเอากรอบสามแบบนี้มาเขียนเก็บไว้ พร้อมจับคู่กับของฝั่ง Siemens ที่ผมใช้อยู่
บอกระดับหลักฐานไว้ก่อน ตัวเลขฝั่ง Omron ทั้งหมดในบทความนี้ผมอ่านจากคู่มือ ยังไม่ได้ลองกับเครื่องจริง คู่มือที่ใช้คือ Controller Link Units Operation Manual (W309-E1-12) กับ CS/CJ DeviceNet Units Operation Manual (W380-E1-10) บางตัวเลขมาจากเอกสารอบรมรุ่นปี 2007 ที่ผมตรวจกับคู่มือแล้ว เลขหน้าที่อ้างเป็นเลขหน้าของไฟล์ PDF ไม่ใช่เลขที่พิมพ์บนหน้ากระดาษ ส่วนการจับคู่กับ Siemens เป็นการวิเคราะห์ของผมเอง ไม่ได้มาจากคู่มือ Omron จะเขียนกำกับไว้ตรงหัวข้อนั้นอีกที
ทั้งสามแบบในบทความนี้เป็นการแลกข้อมูลเพื่อการควบคุมปกติ interlock ด้านความปลอดภัย เช่น ปุ่มหยุดฉุกเฉิน ประตูนิรภัย ม่านแสง ต้องเป็นวงจรสายแข็งหรือระบบ safety ที่ออกแบบมาโดยเฉพาะ ตัวเลขขีดจำกัดที่ยกมาเป็นของรุ่นอุปกรณ์ที่คู่มือเล่มนั้นครอบคลุม งานจริงต้องเปิดคู่มือฉบับที่ตรงรุ่น และให้วิศวกรผู้รับผิดชอบเครื่องจักรเป็นคนตัดสินใจ
สามแบบที่คู่มือแยกไว้
คู่มือ W309 หัวข้อ 1-1 Overview อธิบายสองแบบแรกไว้คู่กัน Data Link คือการแชร์ข้อมูลตลอดเวลาในพื้นที่ที่กำหนดไว้ล่วงหน้า โดยไม่ต้องมีโปรแกรมสื่อสารใน PLC ส่วน Message Service คือการส่งข้อมูลหาโหนดใดโหนดหนึ่งตามเงื่อนไขเมื่อต้องการ ด้วยคำสั่งสื่อสารในโปรแกรม แบบที่สามอยู่ในคู่มือ DeviceNet คือ Remote I/O แบบ Master/Slave ที่ฝั่งหนึ่งเป็นเจ้าของ logic และอีกฝั่งเป็น I/O ให้
ข้อมูลไหลเองตลอดเวลา
กำหนดพื้นที่ไว้ครั้งเดียว ที่เหลือเครือข่ายทำให้ ทั้งสองฝั่งต่างมีโปรแกรมของตัวเองและใช้ข้อมูลของอีกฝั่งประกอบ ไม่มีใครเป็นเจ้าของอีกคน คำถามเรื่องเจ้าของเอาต์พุตเลยต้องตอบเองในโปรแกรม
ฝั่งเดียวเป็นเจ้าของ logic
Master ตัดสินใจ Slave ทำตาม เอาต์พุตของ Slave เป็นของ Master โดยโครงสร้าง คำถามเรื่องเจ้าของถูกตอบตั้งแต่เลือกรูปแบบ และมีสวิตช์ให้กำหนดว่าเมื่อสื่อสารขาดจะ hold หรือ clear
แบบที่สาม Message ไม่ได้อยู่ในตารางเทียบข้างบนเพราะมันไม่ใช่การไหลของข้อมูล มันคือการร้องขอทีละครั้ง ส่งคำสั่งไป รอคำตอบ จบ แล้วค่อยส่งใหม่เมื่อโปรแกรมสั่งอีก
Data Link พื้นที่ร่วมวนรอบ ไม่ต้องเขียนโปรแกรมส่ง
Data Link ของ Controller Link ทำงานบนเครือข่ายแบบ token bus ความเร็วกับระยะมีให้เลือกสามคู่ คือ 2 Mbps ที่ 500 เมตร, 1 Mbps ที่ 800 เมตร และ 500 kbps ที่ 1 กิโลเมตร แต่ละโหนดมีพื้นที่ data link ได้ 2 พื้นที่ พื้นที่ 1 เข้าถึงแบบบิต พื้นที่ 2 เข้าถึงแบบ word
การตั้งค่ามีสองทาง และทั้งเครือข่ายเลือกได้ทางเดียว
- Automatic ตั้งพารามิเตอร์ใน DM ของ PLC ก็ใช้ได้ ทุกโหนดส่งข้อมูลขนาดเท่ากัน มี 4 รูปแบบ คือ Equality, 1:N แบบ common, 1:N แบบ 1-to-1 และ 1:N แบบ chain
- Manual สร้าง Data Link Table กำหนดพื้นที่ ขนาด และโหนดต้นทางได้อิสระ บางโหนดส่งอย่างเดียวหรือรับอย่างเดียวได้ และรับเพียงบางส่วนของพื้นที่ที่โหนดอื่นส่งก็ได้
จุดที่คนตั้งครั้งแรกจะพลาดคือ โหมดกับตารางต้องตั้งที่ startup node ถ้าไม่ตั้ง Data Link จะไม่ทำงานเลย ตัวอย่างในเอกสารที่ผมอ่านเป็นเครือข่ายสามโหนด ข้อมูลใน CIO 0 ถึง 9 ของโหนด 1 ไปปรากฏที่ CIO 50 ถึง 59 ของโหนด 2 และ CIO 100 ถึง 109 ของโหนด 3 ผมเขียนแนวคิดนั้นออกมาเป็น JSON เพื่อให้เห็นว่าตารางมีข้อมูลอะไรบ้าง
{
"_note": "แนวคิดของ Data Link Table แบบ Manual เขียนให้อ่านง่าย ไม่ใช่รูปแบบไฟล์จริงของเครื่องมือผู้ผลิต",
"mode": "manual",
"must_be_set_on": "startup node",
"links": [
{
"source_node": 1,
"source_area": "CIO 0-9",
"words": 10,
"receivers": [
{ "node": 2, "area": "CIO 50-59" },
{ "node": 3, "area": "CIO 100-109" }
]
}
]
}
ขีดจำกัดเป็นตัวเลขขึ้นกับรุ่นของยูนิต ตรงนี้คือจุดที่เอกสารอบรมรุ่นเก่ากับคู่มือฉบับล่าสุดให้ตัวเลขไม่เท่ากัน ซึ่งไม่ได้แปลว่าใครผิด แค่เป็นคนละรุ่น
ตามคู่มือ W309 หน้า 6 และ 31 ของไฟล์ PDF รุ่น -V1 ส่งได้ 1,000 words ต่อโหนด CS/CJ รับ-ส่งรวมได้ 12,000 words และทั้งเครือข่ายรวม 32,000 words ส่วนรุ่น CLK23 ส่งได้ 4,000 words ต่อโหนด และ CS/CJ ตั้งแต่ Unit Ver. 1.2 ขึ้นไปรับ-ส่งรวมได้ 20,000 words มีเงื่อนไขในหัวข้อ 1-5 Application Precautions ของคู่มือเล่มเดียวกันที่ผมว่าสำคัญกว่าตัวเลข คือ 4,000 words ใช้ได้กับ data link แบบ Manual เท่านั้น และถ้าในเครือข่ายเดียวกันมียูนิตรุ่นอื่นปนอยู่ จะตั้งเกิน 1,000 words ต่อโหนดไม่ได้ กับข้อมูล 20,000 words จะถูกแบ่ง refresh ข้ามสามรอบ scan ของ CPU คู่มือเขียนเตือนตรง ๆ ว่าต้องเอาเวลาตอบสนองนี้ไปคิดในการออกแบบ
ข้อหลังนี่แหละคือความหมายของคำว่า "ข้อมูลช้า" ที่ผมใส่ไว้ในหัวเรื่อง Data Link ให้ข้อมูลต่อเนื่องก็จริง แต่ต่อเนื่องไม่ได้แปลว่าทันทุก scan ยิ่งใส่ข้อมูลมาก รอบสื่อสารยิ่งยาว และ scan time ของ PLC ก็ยาวตาม
Remote I/O แบบ Master/Slave ฝั่งเดียวเป็นเจ้าของ logic
แบบที่สองผมอ่านจากคู่มือ DeviceNet ปกติ DeviceNet ใช้ต่อ Master กับอุปกรณ์ I/O แต่ Master unit ของ PLC ตั้งให้ทำตัวเป็น Slave ได้ด้วย เพื่อแลกข้อมูลระหว่าง PLC กับ PLC และยูนิตเดียวเป็นทั้ง Master และ Slave พร้อมกันก็ได้ ผลคือ PLC ตัวหนึ่งมอง PLC อีกตัวเป็นก้อน I/O ธรรมดา
การจองพื้นที่มีสองวิธี
| รายการ | Fixed allocation | User-set allocation |
|---|---|---|
| พื้นที่ฝั่ง Master | OUT CIO 3200-3263 / IN CIO 3300-3363 โหนดละ 1 word ตามเลขโหนด | OUT และ IN อย่างละ 2 block, block ละ 500 words เมื่อตั้งผ่าน Configurator |
| จำนวนจุดรวม | 2,048 จุด | 32,000 จุด |
| จำนวน Slave | สูงสุด 63 โหนด | สูงสุด 63 โหนด |
| พื้นที่เมื่อยูนิตเป็น Slave | OUT CIO 3370 / IN CIO 3270 ขนาด 1 word | ได้ block ละ 100 words |
แบบ fixed นั้นตำแหน่งข้อมูลผูกกับเลขโหนดตายตัว word ที่ n คือโหนด n คำนวณได้ตรง ๆ
def fixed_alloc(node):
"""Fixed allocation ชุดแรกของ DeviceNet master: word n = node n โหนดละ 1 word"""
if not 0 <= node <= 63:
raise ValueError('node address ของ DeviceNet คือ 0-63')
return f'node {node:2d}: OUT CIO {3200 + node} / IN CIO {3300 + node}'
for n in (0, 1, 2, 63):
print(fixed_alloc(n))
# node 0: OUT CIO 3200 / IN CIO 3300
# node 1: OUT CIO 3201 / IN CIO 3301
# node 2: OUT CIO 3202 / IN CIO 3302
# node 63: OUT CIO 3263 / IN CIO 3363
จุดเด่นของแบบนี้ไม่ได้อยู่ที่ปริมาณข้อมูล แต่อยู่ที่สองเรื่องที่ถูกตอบมาให้ตั้งแต่ต้น เรื่องแรก ใครเป็นเจ้าของ logic ชัดเจนโดยโครงสร้าง Master เป็นคนตัดสิน Slave เป็น I/O เรื่องที่สอง พฤติกรรมเมื่อสื่อสารขาดกำหนดได้จาก DIP switch หน้ายูนิต ว่า Slave จะ hold หรือ clear เอาต์พุต และ Master จะสื่อสารต่อหรือหยุดเมื่อเกิด error รายละเอียดขาสวิตช์กับการเทียบว่าลิงก์ที่เขียนเองต้องสร้างอะไรทดแทน ผมเขียนไว้ใน เช็กลิสต์ตรวจลิงก์ระหว่าง PLC แล้ว ไม่ยกมาซ้ำ
Message Service ร้องขอแล้วรอคำตอบเป็นครั้ง
แบบที่สามใช้คำสั่งใน ladder สามตัว คือ SEND(090) ส่งข้อมูลไปเขียนที่โหนดปลายทาง RECV(098) ขอข้อมูลจากโหนดอื่นมาเก็บ และ CMND(490) ส่งคำสั่ง FINS อะไรก็ได้ ตัวเลขของ SEND ที่ผมเก็บมามีดังนี้
| พารามิเตอร์ของ SEND | ช่วง |
|---|---|
| จำนวน word ต่อครั้ง | 0-990 words |
| โหนดปลายทาง | 1-62 (FF คือ broadcast) |
| จำนวนครั้งส่งซ้ำ | 0-15 ครั้ง |
| port ภายในของ CPU | 0-7 |
| เวลารอ response | 0.1-6553.5 วินาที |
| ความยาวข้อความสูงสุด | 2,012 ไบต์ |
ช่วง 0 ถึง 990 words กับ broadcast ที่ FF ผมยืนยันกับ W309 หน้า 194 ของไฟล์ PDF แล้ว คู่มือหน้าเดียวกันมีหมายเหตุที่ควรอ่านให้จบ คือ message service ไม่รับประกันว่าข้อความจะไปถึงปลายทาง อาจหายกลางทางเพราะสัญญาณรบกวนได้ คู่มือเลยแนะนำให้ตั้งจำนวนครั้งส่งซ้ำเป็นค่าที่ไม่ใช่ 0
พออ่านถึงตรงนี้ผมก็เห็นว่าความเข้าใจเดิมของผมผิดตรงไหน ผมเคยคิดว่าถ้าอยากได้ข้อมูลจาก PLC อีกตัว ก็เขียนคำสั่งอ่านวนไปเรื่อย ๆ ก็ได้ผลเหมือน Data Link แต่มันไม่เหมือน แต่ละครั้งที่ร้องขอต้องจอง port หนึ่งใน 8 port รอคำตอบ จัดการกรณีไม่ตอบ แล้วถึงขอใหม่ได้ ข้อมูลที่ได้เลยมาเป็นจังหวะตามรอบของโปรแกรมที่สั่ง ไม่ใช่ตามรอบของเครือข่าย ถ้าเอาไปใช้ตัดสินเอาต์พุตทุก scan โปรแกรมจะตัดสินด้วยค่าเก่าเป็นส่วนใหญ่ เกณฑ์ที่คู่มือให้ไว้เลยสั้นมาก Data Link เมื่อต้องการข้อมูลต่อเนื่องตลอดเวลา Message เมื่อส่งหรือรับเป็นครั้ง ๆ
CMND ส่งคำสั่ง FINS ได้ทุกชนิด รวมถึงคำสั่งเปลี่ยนโหมดการทำงานของ CPU ปลายทาง ตัวอย่างในเอกสารที่ผมอ่านใช้ CMND ส่งคำสั่ง 0402 ไปโหนดอื่น แล้ว CPU ของโหนดนั้นเปลี่ยนเป็น PROGRAM mode แปลว่าโหนดใดในเครือข่ายก็สั่งหยุด PLC ตัวอื่นได้ ถ้าไม่ได้จำกัดว่าโปรแกรมไหนมีสิทธิ์ใช้คำสั่งนี้ รายละเอียดอยู่ใน บทความเรื่องคำสั่ง FINS
จับคู่กับของ Siemens ส่วนนี้ผมวิเคราะห์เอง
หัวข้อนี้ไม่ได้มาจากคู่มือ Omron และไม่ได้มาจากคู่มือ Siemens เล่มใดที่เขียนเทียบไว้ เป็นการจับคู่ของผมเองจากหน้าที่ของแต่ละวิธี ใครเห็นต่างก็ไม่แปลก
| แบบของ Omron | ของฝั่ง Siemens ที่ทำหน้าที่ใกล้กัน | สิ่งที่ต่าง |
|---|---|---|
| Data Link | ส่ง DB ทั้งก้อนวนรอบด้วย TSEND_C/TRCV_C | เป็น Data Link ที่เขียนขึ้นเอง ต้องทำสถานะรายโหนดและ heartbeat เอง |
| Message Service | PUT/GET หรือการอ่านเขียนเป็นครั้ง | ร้องขอเมื่อโปรแกรมสั่ง ไม่ได้ไหลเอง |
| Remote I/O Master/Slave | I-Device, Shared Device หรือ I/O ที่เดินสายตรง | มีเจ้าของชัดในระดับโครงสร้าง |
แถวแรกคือแถวที่ผมต้องระวังที่สุด การส่ง DB วนรอบบน TCP ให้ความรู้สึกเหมือน Data Link ทุกอย่าง แต่ของที่ Data Link ของจริงให้มาในตัว เช่นสถานะว่าโหนดไหนยังอยู่ โปรแกรมของโหนดนั้นรันอยู่หรือไม่ ไม่ได้ตามมาด้วย ต้องเขียนเองทั้งหมด
อีกจุดคือ ถ้าเลือกส่ง DB วนรอบ แต่ต้องการให้ฝั่งหนึ่งเป็นเจ้าของ logic แบบ Remote I/O ก็ทำได้ โดยให้ฝั่งเจ้าของเขียนคำสั่งลงก้อนข้อมูล แล้วฝั่งสถานีทำหน้าที่แค่คัดลอกคำสั่งนั้นออกเอาต์พุตจริงที่เดียว ไม่มี logic ตัดสินใจของตัวเอง เป็นการเอาสายส่งแบบ Data Link มาใช้กับการแบ่งหน้าที่แบบ Master/Slave ตัวอย่างการลงมือทำแบบนี้อยู่ใน บทความเรื่องย้าย I/O ไปเป็น remote I/O บนลิงก์ TCP
ห้าคำถามที่ใช้เลือก
ก่อนจะเปิดโปรแกรมเขียนอะไร ผมตอบห้าข้อนี้ลงกระดาษก่อน
- ข้อมูลนี้ใช้ตัดสินเอาต์พุตทุก scan หรือเป็นข้อมูลรายงาน ถ้าทุก scan ตัดแบบ Message ทิ้งได้เลย
- ใครเป็นเจ้าของ logic ของแอคชูเอเตอร์ตัวนั้น กฎพื้นฐานคือห้ามเขียนเอาต์พุตตัวเดียวกันจากสองที่ ถ้า PLC สองตัวต่างมี logic สั่งวาล์วตัวเดียวกัน นั่นคืออาการที่กฎนี้เตือน
- เมื่อสื่อสารขาด ต้องการให้เอาต์พุต hold หรือ clear และใครเป็นคนยืนยัน
- ปริมาณข้อมูลกับรอบเวลา พอดีกับขีดจำกัดของวิธีที่เลือกหรือไม่ และรอบเวลาที่ได้จริงทันกับกระบวนการหรือไม่
- ข้อมูลนี้เป็น interlock ด้านความปลอดภัยหรือไม่ ถ้าใช่ ต้องเป็นสายแข็งหรือระบบ safety ไม่ใช่ผ่านลิงก์ข้อมูล
ข้อ 2 คือที่มาของคำว่า "สั่งซ้อนกัน" ในหัวเรื่อง ถ้าเลือกแบบ Data Link แล้วปล่อยให้ทั้งสองฝั่งต่างมี logic ตัดสินเอาต์พุตตัวเดียวกันจากข้อมูลของอีกฝั่ง จะได้ระบบที่สองเครื่องสั่งทับกัน และพฤติกรรมขึ้นกับว่ารอบไหนใครเขียนทีหลัง ผมเอาคำถามทั้งห้ามาเขียนเป็นฟังก์ชันสั้น ๆ ไว้ใช้ทวนตัวเอง ลำดับของเงื่อนไขคือสิ่งที่ผมอยากให้เห็น ความปลอดภัยมาก่อน เจ้าของมาที่สอง แล้วค่อยถึงเรื่องเทคนิค
def choose(safety_related, single_owner, every_scan, on_loss_defined, words):
if safety_related:
return 'สายแข็งหรือระบบ safety ไม่ส่งผ่านลิงก์ข้อมูล'
if not single_owner:
return 'หยุดก่อน ยังมี logic สองที่สั่งเอาต์พุตตัวเดียวกัน'
if every_scan and not on_loss_defined:
return 'หยุดก่อน ยังไม่ได้ตกลงว่าลิงก์ขาดแล้ว hold หรือ clear'
if every_scan:
return 'remote I/O หรือ data link วนรอบที่มีตัวบอกความสด'
if words <= 990:
return 'message เป็นครั้ง ตั้งจำนวนครั้งส่งซ้ำไม่ใช่ 0'
return 'เกิน 990 words ต่อครั้ง แบ่งส่งหลายรอบหรือย้ายไป data link'
print(choose(False, True, True, True, 40))
print(choose(False, True, False, True, 1500))
print(choose(False, False, True, True, 40))
แล้วบันทึกคำตอบไว้กับโครงการเป็นไฟล์ ให้คนที่มารับงานต่อรู้ว่าเลือกแบบนี้เพราะอะไร
exchange: Main_PLC -> Station_A
purpose: คำสั่งขับเอาต์พุตของสถานี
used_every_scan: true
logic_owner: Main_PLC # Station_A คัดลอกคำสั่งออกเอาต์พุตอย่างเดียว
on_link_loss: clear # ยืนยันโดยผู้รับผิดชอบเครื่อง ลงชื่อและวันที่ในเอกสารแยก
safety_interlock: false # ของจริงเดินสายแข็ง ไม่อยู่ในก้อนข้อมูลนี้
pattern: remote-io-over-cyclic-db
size_words: 40
ข้อจำกัดของบทความนี้
เอกสารอบรมที่ผมใช้ประกอบเป็นของปี 2007 รุ่นอุปกรณ์เป็นของยุคนั้น ตัวเลขทุกตัวที่จะเอาไปออกแบบให้ยึดคู่มือทางการฉบับที่ตรงกับรุ่นที่ซื้อ อย่างที่เห็นในหัวข้อ Data Link แค่เปลี่ยนรุ่นยูนิต ขีดจำกัดก็ขยับจาก 1,000 เป็น 4,000 words ต่อโหนดแล้ว ตัวเลขของ Fixed allocation, User-set allocation และพารามิเตอร์ของ SEND ผมเก็บจากเอกสารที่อ่าน บางตารางในเอกสารเป็นรูปภาพ หน้าที่ผมไม่ได้เปิดดูอาจมีเงื่อนไขที่ตกหล่น และทั้งหมดนี้ผมยังไม่ได้ทดลองกับฮาร์ดแวร์ Omron จริงสักตัว
สรุปคือ สามแบบนี้ไม่ได้แข่งกัน มันตอบคนละคำถาม Data Link ตอบเรื่องข้อมูลที่ต้องมีตลอดเวลา Remote I/O ตอบเรื่องใครเป็นเจ้าของเอาต์พุต Message ตอบเรื่องงานที่ทำเป็นครั้ง ในระบบเดียวใช้ปนกันได้และควรใช้ปนกัน ส่วนตัวผมถ้าข้อมูลก้อนไหนลงเอยที่เอาต์พุตของเครื่องจักร ผมเลือกโครงแบบที่มีเจ้าของคนเดียวไว้ก่อนเสมอ ข้อมูลรายงานหรือค่าที่อ่านนาน ๆ ครั้งจะใช้แบบไหนก็ตามสะดวก ตรงไหนผมจับคู่ผิดหรืออ่านคู่มือคลาดเคลื่อน เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai



ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย