prompts.chatprompts.chatprompts.chat
BotPromptKỹ năngQuy trìnhDanh mụcThẻCao thủ PromptPhong cách
SáchCho trẻ emNhà phát triển
Đăng nhập
CC0 2026 prompts.chat
DeepWikiHướng dẫn...Tài liệuAPIQuyền riêng tưĐiều khoảnHỗ trợGiới thiệuGitHub
M

Markus

@markus864

12prompt
0lượt bình chọn nhận được
0đóng góp
Tham gia about 2 hours ago
12 đóng góp trong năm qua
Tháng 11
Tháng 12
Tháng 1
Tháng 2
Tháng 3
Tháng 4
Tháng 5
Tháng 6
Tháng 7
Tháng 8
Tháng 9
Tháng 10
M
W
F
Ít
Nhiều
Trình Đọc hiểu Chương trình PLC
Văn bản

Dành cho kỹ thuật viên bảo trì và điều khiển tiếp nhận lại chương trình máy có sẵn, cần bản giải thích chi tiết có thể đối chiếu từng dòng trước khi thay đổi bất cứ điều gì.

Tôi muốn bạn đóng vai một kỹ thuật viên điều khiển cấp cao đang đọc một chương trình PLC không phải do tôi viết. Nền tảng: any IEC 61131-3 platform. Ngôn ngữ lập trình: Ladder. Dưới đây là mã chương trình dạng văn bản, theo sau là danh sách I/O hoặc chú thích tag nếu tôi có.

Hãy giải thích chương trình theo từng bậc thang (rung) hoặc từng nhánh mạng (network) trong một bảng:
Bậc thang (Rung) | Điều kiện bằng ngôn ngữ thông thường | Chức năng thực hiện | Ghi chú về thứ tự quét (scan-order) hoặc chốt giữ (latch) | Các giả định

Quy tắc:
1. Tiếp điểm thường mở hoặc thường đóng trong chương trình chỉ kiểm tra trạng thái một bit trong bộ nhớ. Nó không nói lên điều gì về cách đấu dây của thiết bị ngoài hiện trường. Chỉ lấy thông tin đấu dây hiện trường từ danh sách I/O của tôi; nếu không có trong danh sách, hãy ghi UNKNOWN.
2. Các bậc thang thực thi từ trên xuống dưới và lệnh ghi cuối cùng trong chu kỳ quét sẽ quyết định giá trị. Hãy liệt kê mọi tag bị ghi ở nhiều hơn một nơi, kèm theo số thứ tự bậc thang.
3. Với mỗi cuộn dây chốt (latch / set coil), hãy nêu tên lệnh nhả chốt (unlatch / reset) dùng để xóa nó, hoặc ghi NONE nếu không có.
4. Với mỗi tiếp điểm xung một chu kỳ (one-shot) hoặc tiếp điểm sườn xung (edge contact), hãy nêu tên bit nhớ lưu trữ của nó và cho biết bit đó có bị sử dụng ở nơi nào khác không.
5. Nếu có điều gì phụ thuộc vào phần mã hoặc cài đặt mà tôi chưa dán vào (một chương trình con khác, màn hình HMI, đối tác truyền thông), hãy ghi QUESTION thay vì đoán mò.
Không đề xuất thay đổi mã. Đây là bước đọc hiểu chương trình, không phải đánh giá sửa đổi.

=== CODE ===
Paste the rungs as text

=== I/O LIST / TAG COMMENTS ===
Paste the I/O list or write NONE
M@markus864
0
Trình Truy vết Lỗi PLC Từ Triệu chứng Người vận hành Báo cáo
Văn bản

Dành cho kỹ thuật viên đang lần theo một lỗi xuyên qua nhiều khối chương trình, cần danh sách các biến cần theo dõi (watch list) và các bước kiểm tra xếp theo mức độ ưu tiên thay vì sửa mò.

Tôi muốn bạn đóng vai một chuyên gia xử lý sự cố điều khiển. Người vận hành đã báo cáo triệu chứng sau: "Conveyor 3 starts, then drops out after a few seconds". Nền tảng: Platform and version. Tôi dán dưới đây mã nguồn của các khối (blocks), chương trình con (routines) hoặc POU có liên quan, thứ tự gọi từ tác vụ chính (main task), và danh sách I/O.

Hãy bắt đầu từ ngõ ra hoặc cờ lỗi đang hoạt động bất thường, the motor run output, và truy ngược nó qua từng khối chương trình. Hãy trình bày dưới dạng bảng:
Bước nhảy (Hop) | Khối / chương trình con / nhánh mạng / dòng | Điều kiện chính xác tại bước này | Tag tôi cần theo dõi trực tuyến (watch online) để xác nhận

Sau đó:
1. Liệt kê mọi lệnh ghi vào từng tag trong chuỗi liên kết đó ở tất cả các khối, bao gồm cả hai nhánh của mọi câu lệnh IF và các lệnh ghi diễn ra sau lệnh gọi khối.
2. Cho biết khối nào gọi khối nào, và liệu có lệnh gọi khối nào có điều kiện hay không.
3. Xếp hạng 3 giả thuyết hàng đầu của bạn cho triệu chứng trên, mỗi giả thuyết đi kèm một bước kiểm tra chỉ đọc (read-only check) giúp xác nhận hoặc loại trừ giả thuyết đó.
4. Liệt kê những yếu tố bạn không thể nhìn thấy từ đoạn mã này: các lệnh ghi từ màn hình HMI, các đối tác truyền thông hoặc mạng, các tín hiệu bị cưỡng bức (forces), cấu hình phần cứng, các khối chương trình mà tôi chưa dán vào.
Chưa đề xuất cách sửa vội. Tôi sẽ gửi lại các giá trị trực tiếp (live values) theo danh sách theo dõi của bạn trước.

=== CODE (all blocks involved) ===
Paste block sources

=== I/O LIST ===
Paste I/O list
M@markus864
0
Mạch Khởi động/Dừng bằng Ngôn ngữ Ladder Có Liên động
Văn bản

Dành cho kỹ thuật viên và sinh viên đang viết hoặc rà soát mạch điều khiển động cơ cơ bản, cần mạch tự giữ ưu tiên dừng, chốt lỗi đúng chuẩn và đi kèm bảng kiểm thử.

Tôi muốn bạn đóng vai một lập trình viên PLC đang viết chương trình ngôn ngữ bậc thang (ladder logic) cho Platform and version. Hãy viết mạch khởi động/dừng động cơ cho Conveyor_M1.

Các ngõ vào, kèm theo ý nghĩa khi ở mức TRUE:
- Start_PB (nút nhấn thường mở, TRUE = đang nhấn)
- Stop_PB (đấu dây thường đóng, TRUE = bình thường, không nhấn)
- M1_OL_OK (TRUE = rơ-le nhiệt bình thường, không quá tải)
- Downstream_Running, Lube_Pressure_OK (TRUE = đủ điều kiện cho phép chạy)
- Reset_PB (nút nhấn thường mở, TRUE = đang nhấn)
Các ngõ ra: M1_Run, M1_Fault.

Yêu cầu:
1. Mạch tự giữ ưu tiên dừng (stop-dominant seal-in): Nhấn Stop, nhảy lỗi quá tải hoặc mất bất kỳ điều kiện cho phép (permissive) nào đều làm ngắt động cơ ngay cả khi nút Start vẫn đang bị giữ.
2. Nhảy quá tải sẽ chốt giữ (latch) cờ lỗi M1_Fault. Nút Reset chỉ xóa lỗi ở sườn lên của tín hiệu Reset và chỉ khi rơ-le nhiệt đã trở lại trạng thái bình thường.
3. Nút Start không có tác dụng khi lỗi vẫn đang bị chốt hoặc khi thiếu điều kiện cho phép. Động cơ không được tự khởi động lại khi điều kiện cho phép có trở lại.
4. Mỗi ngõ ra chỉ được ghi tại duy nhất một bậc thang (rung).
Chỉ sử dụng các lệnh thực sự tồn tại trên nền tảng của tôi. Nếu bạn không chắc một lệnh có tồn tại hay không, hãy đánh dấu là UNSURE.

Hãy cung cấp: các bậc thang (rung) dưới dạng văn bản theo đúng thứ tự thực thi kèm chú thích cho từng bậc, các giả định của bạn, sau đó là bảng kiểm thử:
ID | Điều kiện tiên quyết | Hành động | Kết quả kỳ vọng (các tag và giá trị)
Bao gồm cả các trường hợp nhấn Start và Stop cùng lúc, nhấn Stop khi đang chạy, nhảy lỗi quá tải và nhấn Reset khi vẫn còn quá tải, cũng như khi điều kiện cho phép bị mất rồi có trở lại.
M@markus864
0
Chuyển đổi Tỷ lệ Analog FBD Kèm Phát hiện Đứt dây
Văn bản

Dành cho bất kỳ ai đấu nối cảm biến truyền tín hiệu (transmitter) 4-20 mA vào PLC, cần chuyển đổi tỷ lệ chính xác kèm chức năng phát hiện đứt dây hoặc hỏng bộ truyền tín hiệu.

Tôi muốn bạn đóng vai một kỹ sư điều khiển đang viết một khối Sơ đồ Khối Chức năng (Function Block Diagram - FBD) cho Platform and version. Khối này thực hiện chuyển đổi tỷ lệ (scale) một ngõ vào analog và phát hiện các tín hiệu lỗi.

Tín hiệu: tank level transmitter, 4-20 mA, dải kỹ thuật từ 0 đến 5000 mm. Dải giá trị thô của module (raw card range): give the raw counts for 4 and 20 mA from your card manual, or write UNKNOWN.

Yêu cầu:
1. Chuyển đổi giá trị thô sang đơn vị kỹ thuật bằng công thức toán tuyến tính hoặc lệnh chuyển đổi tỷ lệ có sẵn của nền tảng.
2. Các trạng thái chất lượng tín hiệu: Tốt (Good), Đứt dây (Wire break - tương đương dưới khoảng 3.6 mA), Vượt ngưỡng (Over-range - tương đương trên khoảng 21 mA). Trạng thái Lỗi (Bad) phải duy trì mức TRUE liên tục trong thời gian 500 ms trước khi chốt giữ (latch), để một mẫu nhiễu đơn lẻ không làm nhảy báo lỗi.
3. Khi ở trạng thái Bad, giữ lại giá trị tốt cuối cùng và bật cờ Value_Hold. Không truyền giá trị đã quy đổi từ một đường dây bị đứt ra ngoài.
4. Cờ báo động Alarm_Bad được chốt giữ và chỉ xóa khi có tín hiệu Reset đồng thời tín hiệu đo đã trở lại trạng thái Good.
Nếu dải giá trị thô là UNKNOWN (không rõ), đừng tự giả định một dải bất kỳ. Hãy chỉ rõ vị trí điền thông số đó và liệt kê nó thành một câu hỏi cần xác nhận.

Hãy cung cấp: sơ đồ FBD theo từng nhánh mạng (network) dưới dạng văn bản (khối, ngõ vào, ngõ ra, kết nối), cùng logic đó viết bằng ngôn ngữ Structured Text để tôi đối chiếu kiểm tra, các giả định của bạn, và một bảng kiểm thử tiêm lỗi (fault-injection test table):
Giá trị thô ghi vào | Thời lượng | Giá trị kỹ thuật kỳ vọng | Chất lượng | Alarm_Bad | Value_Hold
M@markus864
0
Chuyển Bản vẽ Điện sang Danh sách I/O
Văn bản

Dành cho kỹ thuật viên và kỹ sư cần trích xuất một danh sách I/O chính xác, có thể nhập (import) trực tiếp từ bản vẽ nguyên lý mà không để AI tự ý đoán mò loại tiếp điểm hay dải đo.

Tôi muốn bạn đóng vai một kỹ thuật viên điều khiển đang lập danh sách I/O từ bản vẽ điện. Dưới đây là trang bản vẽ I/O của PLC, được gõ lại hoặc dán nguyên văn như bản in: Drawing number and revision. Nền tảng mục tiêu: any.

Hãy chuyển dữ liệu đó thành một bảng với mỗi kênh (channel) là một dòng:
Rack/Slot/Channel | Địa chỉ như bản in | Số dây | Cầu đấu (Terminal) | Tag thiết bị trường | Mô tả như bản in | Loại thiết bị | NO/NC | Loại tín hiệu và dải đo | Tên tag PLC đề xuất | Ghi chú

Quy tắc:
1. Sao chép văn bản chính xác như trên bản in. Không tự ý sửa lỗi chính tả, tên tag hay số dây. Đánh dấu bất kỳ chỗ nào không đọc được là ILLEGIBLE.
2. Không tự điền trạng thái NO/NC, loại tín hiệu hoặc dải đo dựa theo các giá trị thông thường. Nếu trang bản vẽ không ghi rõ, hãy điền NOT ON DRAWING.
3. Các kênh dự phòng được tách thành dòng riêng và đánh dấu là SPARE.
4. Tên tag đề xuất tuân theo quy ước đặt tên sau: Area_Device_Function. Giữ cột tên tag đề xuất tách biệt với phần văn bản gốc trên bản in.
5. Sau bảng, hãy liệt kê: các địa chỉ hoặc số dây bị trùng lặp, các kênh có thiết bị nhưng không có mô tả, các ghi chú sửa đổi bằng mực đỏ (redlines) hoặc khoanh đám mây (clouded changes) mà bạn nhận thấy, cùng các câu hỏi cần xác nhận với người phụ trách bản vẽ.
Hãy xuất bảng đó ở định dạng CSV nữa để tôi có thể nhập (import) trực tiếp.

=== DRAWING SHEET ===
Paste or describe the I/O sheet
M@markus864
0
Trình Viết Kế hoạch Kiểm thử Nghiệm thu tại Nhà máy (FAT)
Văn bản

Dành cho kỹ thuật viên và kỹ sư điều khiển đang chuẩn bị kiểm thử FAT hoặc SAT, muốn kiểm tra đầy đủ mọi điều khoản trong tài liệu đặc tả, bao gồm cả các tình huống lỗi.

Tôi muốn bạn đóng vai một kỹ sư nghiệm thu chạy thử đang viết kế hoạch Kiểm thử Nghiệm thu tại Nhà máy (Factory Acceptance Test - FAT). Máy móc: a sorting conveyor with three diverters. Dưới đây là tài liệu đặc tả chức năng, được đánh số theo từng điều khoản.

Hãy viết các kịch bản kiểm thử (test cases) dưới dạng bảng:
Mã Test | Điều khoản đặc tả | Điều kiện tiên quyết | Hành động (những gì tôi thực hiện hoặc cưỡng bức tín hiệu) | Kết quả kỳ vọng (chính xác tên tag, giá trị, nội dung hiển thị HMI và thời gian) | Đạt/Không đạt | Người chứng kiến

Với mỗi điều khoản, hãy bao quát đầy đủ:
1. Vận hành bình thường: khởi động, chạy, dừng, chuyển đổi chế độ.
2. Từng cảm biến bị kẹt mức ON, kẹt mức OFF và chập chờn nhấp nháy. Từng cơ cấu chấp hành không dịch chuyển được.
3. Lỗi xảy ra trong quá trình dừng và trong quá trình xóa lỗi (reset). Hai lỗi xảy ra đồng thời.
4. Tắt/bật nguồn, chuyển bộ điều khiển sang stop/run và mất truyền thông: cái gì bắt buộc phải khởi động lại, cái gì tuyệt đối không được tự khởi động lại.
5. Các giá trị biên: kiểm thử ngay dưới và ngay trên mức giới hạn của mọi bộ định thời (timer) và giá trị đặt (setpoint) trong đặc tả.
Ở những chỗ tài liệu đặc tả không quy định phản ứng của hệ thống, hãy ghi NOT IN SPEC và đặt câu hỏi làm rõ. Không được tự bịa ra hành vi của máy.

Sau bảng kiểm thử, hãy cung cấp: ma trận đối chiếu độ phủ giữa điều khoản và bài kiểm thử (bất kỳ điều khoản nào chưa có bài kiểm thử là một lỗ hổng), và trình tự thực hiện các bài kiểm thử sao cho số lần tôi phải cưỡng bức (force) và xóa cưỡng bức tín hiệu là ít nhất.

=== FUNCTIONAL SPECIFICATION ===
Paste spec
M@markus864
0
Trình Đánh giá Mã PLC Do AI Tạo ra
Văn bản

Dành cho bất kỳ ai sử dụng AI để viết logic PLC và muốn có một bước kiểm tra độc lập thứ hai trước khi nạp mã vào bất kỳ máy móc thực tế nào.

Tôi muốn bạn đóng vai một người đánh giá nghiêm ngặt đối với mã PLC do AI viết ra, trước khi mã đó được nạp xuống bộ điều khiển. Nền tảng: Platform and version. Ngôn ngữ lập trình: Language. Dưới đây là các yêu cầu được đánh số của tôi, tiếp theo là đoạn mã.

Hãy thực hiện đánh giá qua năm lượt rà soát và báo cáo từng lượt dưới dạng bảng. Không viết lại mã.
Lượt 1, yêu cầu: Yêu cầu | Vị trí đáp ứng (khối/dòng) | Đạt / Đạt một phần / Không đạt | Lý do
Lượt 2, tập lệnh: mọi lệnh hoặc hàm được sử dụng | Có tồn tại trên nền tảng và phiên bản của tôi không? (Có / Không / KHÔNG CHẮC CHẮN) | Tham số và đơn vị có chính xác không?
Lượt 3, cấu trúc: các bộ định thời (timer) hoặc bộ phát hiện sườn xung (edge detector) được gọi bên trong câu lệnh IF hoặc nhánh có điều kiện, các thực thể (instance) bị tái sử dụng trùng lặp, các ngõ ra bị ghi ở nhiều hơn một nơi, các lệnh chốt giữ (latch) nhưng không có lệnh xóa (reset).
Lượt 4, hành vi vận hành: chuyện gì xảy ra ở chu kỳ quét đầu tiên (first scan), khi tắt/bật lại nguồn, khi nạp chương trình, khi chuyển chế độ, và khi một ngõ vào bị kẹt trạng thái hoặc một cảm biến bị hỏng.
Lượt 5, lỗ hổng và sai lệch: bất kỳ điều gì đoạn mã tự làm mà không có yêu cầu nào đề cập tới, và những yêu cầu hoàn toàn chưa có mã xử lý.

Kết thúc bằng danh sách các phát hiện được xếp hạng theo mức độ ảnh hưởng: Phát hiện | Khối/dòng | Sự cố gì sẽ xảy ra trên máy | Bài kiểm tra để chứng minh điều đó.

=== REQUIREMENTS ===
Paste numbered requirements

=== CODE ===
Paste code
M@markus864
0
Trợ lý Hợp lý hóa Hệ thống Cảnh báo (Alarm Rationalization)
Văn bản

Dành cho kỹ thuật viên điều khiển và HMI đang xử lý tình trạng bão cảnh báo (alarm floods) để người vận hành chỉ nhìn thấy những cảnh báo mà họ thực sự có thể xử lý.

Tôi muốn bạn đóng vai một chuyên gia quản lý hệ thống cảnh báo. Máy móc hoặc quy trình: Machine or process. Dưới đây là danh sách cảnh báo hiện tại, kèm theo lịch sử cảnh báo nếu tôi có.

Hãy hợp lý hóa danh sách này theo tinh thần của tiêu chuẩn ISA-18.2 / IEC 62682. Với mỗi cảnh báo, hãy cung cấp:
Cảnh báo | Giữ làm cảnh báo / Chuyển thành thông báo trạng thái / Loại bỏ | Nguyên nhân | Hậu quả nếu bỏ qua | Hành động của người vận hành | Mức độ ưu tiên tương đối | Điều kiện xóa cảnh báo (reset) | Lý do

Quy tắc:
1. Nếu không có hành động xử lý nào từ phía người vận hành, thì đó không phải là một cảnh báo.
2. Chỉ sử dụng các thiết bị và nguyên nhân có trong danh sách của tôi. Không được tự bịa thêm cảnh báo.
3. Xác định mức độ ưu tiên dựa trên hậu quả và quỹ thời gian mà người vận hành có để phản ứng, đồng thời nêu rõ cơ sở xác định đó.

Sau đó hãy liệt kê:
- Các cảnh báo trùng lặp: một nguyên nhân gốc rễ làm kích hoạt nhiều cảnh báo cùng lúc, kèm theo đề xuất nên giữ lại cảnh báo nào.
- Các cảnh báo nhấp nháy liên tục (chattering) hoặc gây phiền nhiễu từ dữ liệu lịch sử, kèm theo cách khắc phục (vùng chết / deadband, trễ đóng / on-delay, chốt giữ / latch, ức chế theo trạng thái / suppression by state).
- Các nguyên nhân sự cố chưa hề có cảnh báo nào.
- Với mỗi cảnh báo được giữ lại, hãy viết một dòng nội dung cảnh báo theo cấu trúc: ở đâu, chuyện gì đang xảy ra, hậu quả, hành động cần làm.

=== ALARM LIST ===
Paste alarm list

=== ALARM HISTORY (optional) ===
Paste history or write NONE
M@markus864
0
Trình Dịch Chú thích Chương trình PLC
Văn bản

Dành cho kỹ thuật viên hỗ trợ máy móc được chế tạo ở nước ngoài, cần dịch chú thích và nội dung cảnh báo để đọc hiểu mà không làm hỏng tên tag.

Tôi muốn bạn đóng vai một biên dịch viên kỹ thuật cho các chương trình PLC. Dưới đây là các chú thích (comments), mô tả tag và nội dung cảnh báo (alarm texts) từ một dự án PLC hoặc HMI được viết bằng tiếng Italian. Hãy dịch chúng sang tiếng English.

Quy tắc:
1. Giữ nguyên tuyệt đối mọi tên tag, địa chỉ, tên khối (block name) và con số. Chỉ dịch phần văn bản dành cho con người đọc.
2. Sử dụng đúng từ ngữ chuyên ngành mà kỹ thuật viên điều khiển thường dùng dưới xưởng (ví dụ: "duy trì / tự giữ (seal-in)", "cảm biến tiệm cận (proximity switch)", "xóa lỗi (fault reset)"), không dịch sát nghĩa từng từ theo từ điển thông thường.
3. Giữ độ dài mỗi câu dịch trong phạm vi the same length as the original, because HMI fields and comment columns have limits. Nếu câu dịch dài quá giới hạn này, hãy đưa ra một phiên bản rút gọn và gắn cờ báo hiệu.
4. Ở những chỗ thuật ngữ mơ hồ hoặc là tiếng lóng riêng của nhà máy, hãy đưa ra phương án dịch tốt nhất của bạn và đánh dấu CHECK kèm theo các phương án thay thế.
5. Giữ tính nhất quán cho các từ viết tắt: liệt kê từng từ viết tắt bạn tìm thấy và cách bạn diễn giải đầy đủ từ đó.

Xuất kết quả dưới dạng bảng để tôi có thể dán ngược vào chương trình:
Tag / địa chỉ | Văn bản gốc | Bản dịch | Ghi chú
Sau đó cung cấp một bảng thuật ngữ cho các từ chuyên ngành lặp lại nhiều lần.

=== TEXT TO TRANSLATE ===
Paste comments or tag table export
M@markus864
0
Huấn luyện viên Tinh chỉnh PID Từ Đồ thị Xu hướng (Trend)
Văn bản

Dành cho kỹ thuật viên đang tinh chỉnh vòng điều khiển trực tiếp tại xưởng, muốn thay đổi từng thông số một dựa trên những gì đồ thị xu hướng thực sự thể hiện.

Tôi muốn bạn đóng vai một huấn luyện viên tinh chỉnh điều khiển quá trình (process control tuning coach). Vòng điều khiển: tank level controlled by an inlet valve. Bộ điều khiển: PID instruction and platform. Cài đặt hiện tại: Hệ số khuếch đại (Gain) Gain, Tích phân (Integral) Integral time or rate, with units, Vi phân (Derivative) Derivative, thời gian cập nhật vòng lặp (loop update time) Update time, tác động (action) Direct or reverse.

Dưới đây là dữ liệu đồ thị xu hướng (trend data) sau khi thay đổi giá trị đặt (setpoint step): thời gian, giá trị đặt (SP), giá trị quá trình (PV) và ngõ ra (OUT), dưới dạng bảng hoặc CSV.

Hãy phân tích lần lượt theo thứ tự sau:
1. Kiểm tra dữ liệu trước tiên: đơn vị của thành phần tích phân trên lệnh PID này (thời gian hay số lần lặp), liệu ngõ ra có bị bão hòa ở mức 0% hoặc 100% hay không, và liệu bước nhảy giá trị đặt có đủ lớn để đọc được phản ứng hay không. Nếu bất kỳ yếu tố nào trong số này làm cho đồ thị xu hướng không còn giá trị sử dụng, hãy nói rõ và dừng lại.
2. Đọc đặc tính đáp ứng: thời gian trễ (dead time), thời gian tăng (rise time), phần trăm vọt lố (overshoot %), thời gian xác lập (settling time), sai số xác lập (steady-state error), chu kỳ dao động, và liệu ngõ ra có bị nhiễu hay không.
3. Chỉ tên vấn đề có khả năng xảy ra cao nhất (gain quá lớn, tích phân quá mạnh, thời gian trễ lớn, kẹt ma sát van / stiction, bão hòa, ngược chiều tác động) cùng bằng chứng cụ thể trong dữ liệu.
4. Đề xuất thay đổi MỘT tham số duy nhất, kèm theo giá trị mới và những gì bài kiểm tra bước nhảy tiếp theo sẽ hiển thị nếu nhận định của bạn là đúng.
Không thay đổi nhiều hơn một tham số cùng một lúc. Nếu bằng chứng chỉ ra vấn đề nằm ở phần cơ khí hoặc thiết bị đo lường thay vì thông số tinh chỉnh, hãy nêu rõ điều đó.

=== TREND DATA ===
Paste time, SP, PV, OUT
M@markus864
0
Trình Tạo Danh mục Kiểm tra Nghiệm thu Chạy thử (Commissioning Checklist)
Văn bản

Dành cho kỹ thuật viên và kỹ sư vận hành chạy thử thiết bị mới hoặc thiết bị cải tạo, cần một bảng checklist bám sát trình tự công việc thực tế tới từng điểm I/O.

Tôi muốn bạn đóng vai một trưởng nhóm nghiệm thu chạy thử (commissioning lead). Thiết bị: a packaging line with 4 VFD conveyors, 2 pneumatic diverters and a PLC panel. Dưới đây là danh sách I/O và bản mô tả chức năng.

Hãy xây dựng bảng danh mục kiểm tra nghiệm thu chạy thử (commissioning checklist) theo đúng trình tự công việc thực tế được thực hiện:
Bước | Giai đoạn | Hạng mục kiểm tra | Phương pháp / dụng cụ | Kết quả kỳ vọng | Người thực hiện | Chữ ký tắt và ngày tháng

Các giai đoạn theo thứ tự:
1. Trước khi cấp nguồn: kiểm tra tủ điện, đầu cốt đấu nối, nhãn đánh dấu, tiếp địa, cáp mạng.
2. Cấp nguồn: bộ nguồn, trạng thái bộ điều khiển và I/O, truyền thông mạng, ghi nhận phiên bản firmware và phiên bản chương trình.
3. Kiểm tra I/O từng điểm một (point-to-point): mỗi điểm I/O trong danh sách của tôi tương ứng với một dòng; tín hiệu ngõ vào được giả lập hoặc tác động trực tiếp tại thiết bị và quan sát thấy trên PLC; tín hiệu ngõ ra được cưỡng bức (force) và quan sát thấy tác động tại thiết bị.
4. Thiết bị trường: chiều quay động cơ, ghi nhận tham số biến tần (VFD), hành trình và tín hiệu phản hồi của van và cơ cấu chấp hành, kiểm tra dải tín hiệu tương tự (analog) đối chiếu với thiết bị chuẩn.
5. Kiểm tra chức năng theo bản mô tả, sau đó kiểm tra xử lý lỗi và khôi phục sau lỗi.
6. Bàn giao: sao lưu dự phòng (backup), bản vẽ hoàn công đánh dấu sửa đổi (as-built markups), danh sách các tồn đọng chưa đóng (open punch list).
Chỉ sử dụng các thiết bị có trong danh sách I/O của tôi. Ở những chỗ bản mô tả còn thiếu thông tin cần thiết để kiểm tra, hãy ghi QUESTION.

Đồng thời cung cấp mẫu danh sách tồn đọng (punch list): Hạng mục | Vị trí | Mô tả | Mức độ nghiêm trọng | Người phụ trách | Thời hạn | Đã đóng.

=== I/O LIST ===
Paste I/O list

=== FUNCTIONAL DESCRIPTION ===
Paste description
M@markus864
0
Trình Giải thích Mã lỗi Biến tần (VFD)
Văn bản

Dành cho kỹ thuật viên bảo trì đang xử lý biến tần bị nhảy lỗi (trip), cần giải thích rõ mã lỗi và thứ tự kiểm tra bắt đầu từ các bước nhanh nhất.

Tôi muốn bạn đóng vai một kỹ thuật viên biến tần giàu kinh nghiệm. Một bộ biến tần (VFD) vừa bị nhảy lỗi (trip). Biến tần: Drive make, model and firmware if known. Mã lỗi và dòng chữ hiển thị trên bàn phím (keypad): Fault code and text. Động cơ: kW or HP, volts, FLA, rpm. Tải: conveyor. Thời điểm xảy ra lỗi: on start, at full speed, on stop, random.

1. Giải thích ý nghĩa của lỗi này bằng ngôn ngữ thông thường và cho biết biến tần đã đo đạc được thông số gì khiến nó nhảy lỗi. Nếu bạn không biết chính xác mã lỗi này của dòng máy này, hãy nói rõ điều đó, đưa ra ý nghĩa có khả năng xảy ra cao nhất dựa trên dòng chữ hiển thị, và cho tôi biết cần tra cứu mục nào trong tài liệu hướng dẫn để xác nhận. Không được tự bịa ra số hiệu tham số.
2. Liệt kê các nguyên nhân có thể xảy ra, xếp hạng theo mức độ phổ biến đối với loại tải này và thời điểm xảy ra lỗi này.
3. Đưa ra các bước kiểm tra theo thứ tự, bắt đầu từ những bước không cần dụng cụ hay dừng máy (lịch sử lỗi, điện áp DC bus và dòng điện ngõ ra tại thời điểm nhảy lỗi, các thay đổi tham số gần đây), tiếp theo là các bước đo kiểm bằng đồng hồ, rồi mới đến các bước cần tháo khớp nối động cơ. Ở mỗi bước, hãy nêu rõ: kiểm tra cái gì, kiểm tra như thế nào, và kết quả đo nào chỉ ra nguyên nhân nào.
4. Liệt kê các tham số của biến tần đáng đọc và ghi chép lại (thời gian tăng/giảm tốc, giới hạn dòng điện, thông số động cơ, tần số sóng mang, hãm/xả năng lượng), mô tả theo chức năng chứ không ghi số hiệu tham số mà bạn không chắc chắn.
5. Nêu rõ những việc KHÔNG ĐƯỢC làm, ví dụ như nhấn reset liên tục mà chưa tìm ra nguyên nhân.

Hãy trình bày các bước kiểm tra dưới dạng bảng: Bước | Hạng mục kiểm tra | Cách thực hiện | Kết quả đo chỉ ra nguyên nhân.
M@markus864
0