Bộ điều khiển động cơ truyền thông Ethernet: Giao thức, tích hợp và lựa chọn

Tại sao Ethernet đã thay thế Fieldbus cũ trong điều khiển động cơ

Trong hai thập kỷ, các giao thức dựa trên RS-485 như Modbus RTU và CANopen đã thống trị giao tiếp điều khiển động cơ. Chúng đáng tin cậy, mang tính quyết định và chi phí thực hiện rẻ. Chúng cũng chậm, hạn chế về cấu trúc liên kết và ngày càng không tương thích với nhu cầu dữ liệu của dây chuyền sản xuất tự động hiện đại. Việc chuyển sang Ethernet công nghiệp không phải do thời trang thúc đẩy mà do toán học thúc đẩy.

Các hệ thống bus trường kế thừa thường hoạt động ở tốc độ 1–12 Mbps với cấu trúc liên kết mạng giới hạn ở vài chục nút trước khi hiệu suất giảm. Các giao thức Ethernet công nghiệp chạy ở tốc độ 100 Mbps đến 1 Gbps, hỗ trợ hàng trăm nút trên một phân đoạn mạng và cung cấp thời gian chu kỳ dưới một phần nghìn giây mà việc phối hợp chuyển động đa trục yêu cầu. Theo báo cáo Thị phần Mạng Công nghiệp năm 2025 của HMS Networks, 79% nút tự động hóa nhà máy mới hiện được cung cấp giao thức Ethernet công nghiệp chứ không phải là một fieldbus truyền thống—một con số mà cách đây một thập kỷ có vẻ khó tin.

Đối với các nhà thiết kế bộ điều khiển động cơ và nhà tích hợp hệ thống, quá trình chuyển đổi này có hệ quả trực tiếp thực tế: giao diện truyền thông không còn là thông số kỹ thuật phụ. Nó xác định bộ điều khiển có thể làm gì trong hệ thống truyền động phối hợp, cách nó tích hợp với PLC và HMI và liệu nó có thể tham gia vào đường ống dữ liệu IIoT mà không cần cổng trung gian hay không. Bộ điều khiển động cơ DC không chổi than cho các ứng dụng B2B công nghiệp ngày càng mang giao diện Ethernet như một tính năng tiêu chuẩn thay vì một tiện ích bổ sung tùy chọn—phản ánh mức độ thay đổi giao thức đã thâm nhập vào thị trường ổ đĩa.

Các giao thức Ethernet công nghiệp chính dành cho bộ điều khiển động cơ

Bốn giao thức chiếm phần lớn trong việc cài đặt điều khiển động cơ được kết nối Ethernet trên toàn thế giới. Mỗi loại có một cách tiếp cận kiến ​​trúc khác nhau để giải quyết cùng một thách thức cốt lõi: truyền dữ liệu điều khiển một cách đáng tin cậy và có thể dự đoán được qua phần cứng Ethernet tiêu chuẩn.

EtherCAT (Ethernet cho công nghệ điều khiển tự động hóa) được phát triển bởi Beckhoff Automation và trở thành tiêu chuẩn IEC vào năm 2005. Sự đổi mới mang tính định nghĩa của nó là "xử lý nhanh chóng": thay vì mỗi nút nhận một gói chuyên dụng, một khung EtherCAT duy nhất sẽ lưu thông qua tất cả các nút phụ theo trình tự, trong đó mỗi nút đọc dữ liệu riêng của nó và chèn dữ liệu phản hồi khi khung đi qua. Điều này giúp loại bỏ chi phí chuyển mạch gói và mang lại thời gian chu kỳ dưới 100 micro giây với độ giật dưới 1 micro giây—hiệu suất giúp việc đồng bộ hóa hàng chục trục servo thực sự khả thi. các Tài liệu kỹ thuật chính thức của Tập đoàn Công nghệ EtherCAT nêu chi tiết cách giao thức đạt được sự tuân thủ IEC 61158 trong khi hỗ trợ các cấu trúc liên kết đường dây, cây, sao và vòng mà không cần bộ chuyển mạch được quản lý.

PROFINET , được quản lý bởi PROFIBUS & PROFINET International (PI), là công ty kế thừa trực tiếp cho Profibus và thống trị thị trường công nghiệp Châu Âu. Nó hoạt động ở hai chế độ: PROFINET RT (Thời gian thực) với thời gian chu kỳ từ 1–10 mili giây cho các ứng dụng I/O tiêu chuẩn và PROFINET IRT (Thời gian thực đẳng thời) với thời gian chu kỳ thấp tới 250 micro giây để điều khiển chuyển động chính xác. Lợi thế chính cho các dự án trang bị thêm là hỗ trợ proxy Profibus gốc—các thiết bị Profibus hiện có có thể giao tiếp qua mạng PROFINET thông qua proxy cổng, cho phép di chuyển dần dần mà không cần thay thế thiết bị đã cài đặt.

EtherNet/IP , được ODVA duy trì và xây dựng trên Giao thức công nghiệp chung (CIP) xếp lớp trên TCP/IP và UDP/IP tiêu chuẩn, là giao thức thống trị trong sản xuất rời rạc ở Bắc Mỹ. Chạy trên cơ sở hạ tầng CNTT thông thường không có bộ chuyển mạch chuyên dụng, nó cung cấp khả năng tích hợp đơn giản vào mạng nhà máy hiện có và hỗ trợ hệ sinh thái rộng lớn gồm PLC, ổ đĩa và mô-đun I/O từ nhiều nhà cung cấp. Thời gian chu kỳ điển hình là 2–10 mili giây phù hợp với hầu hết các ứng dụng I/O rời rạc và ổ đĩa tốc độ vừa phải; đồng bộ hóa chặt chẽ hơn có sẵn thông qua tiện ích mở rộng CIPsync.

Modbus TCP là tùy chọn đơn giản nhất và được hỗ trợ rộng rãi nhất—bản dịch trực tiếp mô hình đăng ký Modbus RTU cổ điển sang TCP/IP. Nó không có đảm bảo về thời gian thực riêng, điều này khiến nó không đủ điều kiện tham gia các vai trò điều khiển chuyển động đòi hỏi khắt khe, nhưng khả năng hỗ trợ thiết bị phổ quát và chi phí cấp phép bằng 0 khiến nó trở thành một lựa chọn thiết thực cho các lớp giám sát, cấu hình và ghi nhật ký dữ liệu nơi không cần đến tính xác định.

So sánh giao thức: Thời gian chu kỳ, cấu trúc liên kết và khả năng tương thích

Việc lựa chọn trong số các giao thức này yêu cầu các đặc điểm giao thức phải phù hợp với yêu cầu ứng dụng—không mặc định cho bất kỳ giao thức nào quen thuộc nhất. Bảng dưới đây tóm tắt những điểm khác biệt chính của bốn lựa chọn chính:

Một mẫu nổi bật trong dữ liệu: Lợi thế về thời gian chu kỳ của EtherCAT không phải là nhỏ—nó nhanh hơn EtherNet/IP một bậc trong các điều kiện tương đương. Đối với các ứng dụng yêu cầu đồng bộ hóa chặt chẽ trên nhiều trục động cơ, chẳng hạn như máy công cụ CNC, cánh tay robot hoặc hệ thống băng tải phối hợp, khoảng cách đó sẽ chuyển trực tiếp thành độ chính xác định vị. Đối với các ổ đĩa đơn trục trong thiết bị xử lý tiêu chuẩn, sự khác biệt hiếm khi quan trọng trong thực tế và tính quen thuộc cũng như khả năng tương thích cơ sở hạ tầng của EtherNet/IP hoặc PROFINET RT thường vượt xa tốc độ thô.

Cấu trúc liên kết mạng cũng có trọng lượng thực tế. Kiến trúc chuỗi vòng của EtherCAT loại bỏ nhu cầu về các thiết bị chuyển mạch được quản lý, giảm cả không gian tủ và chi phí trong các hệ thống có nhiều nút ổ đĩa phân tán. Yêu cầu của PROFINET IRT đối với các thiết bị chuyển mạch có khả năng định thời gian sẽ làm tăng thêm chi phí cơ sở hạ tầng nhưng cho phép đồng bộ hóa đồng hồ trên các nút trải rộng về mặt địa lý mà cấu trúc liên kết tuyến tính của EtherCAT không thể dễ dàng đáp ứng.

Tích hợp giao tiếp Ethernet vào bộ điều khiển động cơ BLDC

Việc thêm giao diện Ethernet vào bộ điều khiển động cơ DC không chổi than bao gồm các quyết định ở ba cấp độ: phần cứng vật lý, chương trình cơ sở ngăn xếp giao tiếp và triển khai cấu hình ổ đĩa lớp ứng dụng.

Ở cấp độ phần cứng, việc tích hợp EtherCAT thường dựa vào các ASIC của bộ điều khiển nô lệ chuyên dụng—chẳng hạn như các dòng ET1100 hoặc ESC10—xử lý việc xử lý khung độc lập với MCU chính. Việc giảm tải này giúp cho thời gian chu kỳ dưới 100 micro giây: quá trình xử lý Ethernet không bao giờ cạnh tranh về chu kỳ CPU với vòng điều khiển động cơ. Việc triển khai PROFINET và EtherNet/IP thường sử dụng các mô-đun RAM cổng kép hoặc triển khai lõi mềm trên FPGA, mang lại tính linh hoạt cao hơn nhưng yêu cầu quản lý độ trễ cẩn thận hơn trong kiến ​​trúc phần sụn.

Ở cấp độ phần sụn, cấu hình biến tần xác định cách ánh xạ các lệnh điều khiển động cơ vào giao thức mạng. Cấu hình ổ đĩa CiA 402—ban đầu được phát triển cho CANopen—đã trở thành tiêu chuẩn lớp ứng dụng thống trị cho các ổ đĩa động cơ trên EtherCAT (thông qua CoE, CANopen qua EtherCAT), triển khai PROFINET và EtherNet/IP. Nó xác định các máy trạng thái để bật/tắt ổ đĩa, chế độ vận hành (vị trí, vận tốc, mô-men xoắn) và xử lý lỗi theo cách trung lập với nhà cung cấp nhằm đơn giản hóa việc lập trình PLC trên các nhãn hiệu bộ điều khiển. Các bộ điều khiển triển khai CiA 402 chính xác thường có thể được vận hành với bất kỳ PLC tuân thủ IEC 61131-3 nào mà không cần các khối chức năng tùy chỉnh.

Đối với các hệ thống đa trục phối hợp, đồng bộ hóa đồng hồ phân tán là tính năng phần mềm quan trọng. Cơ chế đồng hồ phân tán của EtherCAT đồng bộ hóa tất cả các nút phụ trong khoảng cách 1 micro giây với nhau—điều kiện tiên quyết cho truyền động điện tử, lập hồ sơ cam và các chức năng chuyển động được đồng bộ hóa khác. Việc thực hiện điều này một cách chính xác đòi hỏi phải chú ý cẩn thận đến việc bù độ trễ lan truyền và hiệu chỉnh độ lệch đồng hồ trong phần sụn phụ. Bộ điều khiển động cơ dòng T hiệu suất cao kết hợp kiến trúc xử lý cần thiết để duy trì tốc độ cập nhật vòng lặp hiện tại chặt chẽ cùng với khả năng xử lý truyền thông mạng—sự cân bằng mà các thiết kế bộ điều khiển cấp cơ bản thường thỏa hiệp.

Ngoài các bộ điều khiển truyền động thuần túy, việc tích hợp giao tiếp ở cấp hệ thống còn mở rộng đến các đơn vị giám sát. Bộ điều khiển phương tiện có kết nối mạng tích hợp tổng hợp dữ liệu ổ đĩa từ nhiều bộ điều khiển động cơ, quản lý máy trạng thái ở cấp hệ thống và cung cấp cổng Ethernet ngược dòng cho viễn thông và chẩn đoán từ xa—một chức năng ngày càng quan trọng hơn khi đội xe và thiết bị công nghiệp chuyển sang mô hình bảo trì dự đoán. Đối với các ứng dụng xe điện và xe điện nhẹ hơn, Bộ điều khiển động cơ xe đạp điện và đèn EV ngày càng kết hợp các giao diện Bluetooth và CAN làm lớp giao tiếp, đóng vai trò là cầu nối giữa các giao diện người dùng đơn giản hóa và vòng lặp điều khiển động cơ cơ bản.

Chọn giao thức phù hợp cho ứng dụng điều khiển động cơ của bạn

Việc lựa chọn giao thức hiếm khi phụ thuộc vào một yếu tố duy nhất. Sáu câu hỏi bao gồm không gian quyết định thực tế cho hầu hết các thiết kế hệ thống điều khiển động cơ:

1. Ứng dụng chuyển động yêu cầu thời gian chu kỳ nào? Việc phối hợp servo đa trục thường yêu cầu thời gian chu kỳ dưới 1 mili giây—trỏ tới EtherCAT hoặc PROFINET IRT. Các ổ đĩa tốc độ có thể thay đổi một trục trong thiết bị xử lý thường chạy thoải mái ở tốc độ cập nhật 5–10 mili giây, trong đó EtherNet/IP hoặc PROFINET RT hoạt động đầy đủ.
2. PLC hoặc bộ điều khiển chuyển động nào đã có trong hệ thống? Đây thường là yếu tố quyết định. Bộ điều khiển Siemens S7 ưu tiên PROFINET; Hệ thống Rockwell/Allen-Bradley được xây dựng dựa trên EtherNet/IP; Nền tảng chuyển động Beckhoff và Omron tiêu chuẩn hóa trên EtherCAT. Có thể vượt qua ranh giới giao thức thông qua các cổng, nhưng làm tăng thêm độ trễ và độ phức tạp làm xói mòn lợi thế về hiệu suất của giao thức gốc.
3. Mạng sẽ hỗ trợ bao nhiêu trục ổ đĩa? Giới hạn nút lý thuyết của EtherCAT là 65.535 thiết bị trên một mạng vượt xa bất kỳ cài đặt thực tế nào, nhưng cấu trúc liên kết chuỗi cúc của nó có nghĩa là việc thêm các nút sẽ kéo dài thời gian truyền khung hình một chút. Đối với các cài đặt rất lớn với hàng trăm điểm I/O phân tán, cấu trúc liên kết hình sao dựa trên chuyển đổi của PROFINET có thể cung cấp bố cục vật lý linh hoạt hơn.
4. An toàn chức năng có được yêu cầu ở lớp mạng không? Cả EtherCAT (thông qua FSoE, Chức năng an toàn qua EtherCAT) và PROFINET (thông qua PROFIsafe) đều hỗ trợ giao tiếp an toàn tuân thủ IEC 61508 trên cùng cơ sở hạ tầng cáp như dữ liệu quy trình tiêu chuẩn. EtherNet/IP hỗ trợ CIP Safety cho các ứng dụng tương đương. Nếu cần có chức năng tắt mô-men xoắn an toàn hoặc tốc độ an toàn SIL 2 hoặc SIL 3, hãy xác nhận rằng chương trình cơ sở an toàn của bộ điều khiển động cơ được chứng nhận cho phần mở rộng an toàn của giao thức đã chọn.
5. Những hạn chế về cơ sở hạ tầng và bảo trì là gì? Việc loại bỏ các thiết bị chuyển mạch được quản lý của EtherCAT giúp đơn giản hóa thiết kế tủ và giảm các điểm hỏng hóc. PROFINET và EtherNet/IP tận dụng cơ sở hạ tầng chuyển mạch CNTT tiêu chuẩn mà các nhóm bảo trì nhà máy có thể quản lý và dự trữ phụ tùng thay thế—một lợi thế thực tế ở các cơ sở không có chuyên môn về mạng tự động hóa chuyên dụng.
6. Bộ điều khiển ghép nối với động cơ mục tiêu như thế nào? Giao thức truyền thông và kết hợp động cơ phụ thuộc lẫn nhau: bộ điều khiển được tối ưu hóa cho giao tiếp mạng băng thông cao cũng phải duy trì tốc độ cập nhật vòng lặp hiện tại theo nhu cầu liên tục về thời gian điện của động cơ. Đang xem xét bộ điều khiển động cơ và hướng dẫn ghép nối động cơ trước khi thực hiện kết hợp giao thức-bộ điều khiển, hãy đảm bảo rằng thông số kỹ thuật giao diện mạng không vượt quá hiệu suất truyền động cơ bản mà động cơ thực sự có thể sử dụng.

Điểm mấu chốt đối với các nhóm mua sắm và kỹ thuật: giao thức chính xác là giao thức phù hợp với hệ sinh thái PLC, đáp ứng yêu cầu về thời gian của chu kỳ chuyển động và phù hợp với cấu trúc liên kết lắp đặt—theo thứ tự đó. Tối ưu hóa tốc độ giao thức thô trong một ứng dụng không cần nó sẽ làm tăng thêm chi phí mà không mang lại lợi ích. Việc xác định không đúng mức cho một ứng dụng cần đồng bộ hóa xác định sẽ tạo ra các vấn đề về độ tin cậy mà không có mức độ điều chỉnh nào có thể khắc phục hoàn toàn.