Определить обмен PLC–зрение через явные состояния

Задача и исходные условия

Короткий импульс и неподтверждённый результат могут терять детали или повторять решения. Согласуйте состояния до привязки к реальным сигналам и протоколу. Приложение — концептуальный псевдокод.

Подготовка испытания

Определите готовность, занятость, результат и отказ с номером детали и совпадающим подтверждением. 200 ms обработки и 500 ms ожидания подтверждения — допущения, не рабочие пределы.

До I/O или протокола напишите контракт приложения: кто создаёт идентичность, владеет состоянием, подтверждает и решает судьбу детали при ошибке. Ready, Busy, Result, Fault — концепции, не обещанные регистры. Проверьте интерфейсы и отделите электрические/сетевые времена. Без идентификатора транзакции спроектируйте проверенную привязку, не считайте следующий результат следующим изделием. Наблюдайте трассами или сигналами.

Порядок работы

1. Принимайте запрос только в готовности, сохраняя номер до перехода в занятость.
2. Публикуйте номер и результат вместе, удерживая их неизменными.
3. Возвращайтесь в готовность только после подтверждения того же результата; чужой номер отклоняется.
4. При тайм-ауте или ошибке захвата выдавайте отказ, не показывая старый OK как новый.
5. Проверьте запрос при занятости, дубликаты, потерю подтверждения и перезапуск.

VENDOR-NEUTRAL PSEUDOCODE — state semantics, not protocol commands
# Serialize these application events; names below are conceptual.
state = READY
generation = new_generation()
active_token = none
on_request(id):
    if state != READY: record_rejected_request(id); return
    active_token = (generation, id)
    state = BUSY
    arm_processing_deadline(active_token)
    start_bounded_inspection(active_token)
on_completed(token, value):
    if state != BUSY or token != active_token:
        record_stale_result(token); return
    cancel_processing_deadline(token)
    if not application_payload_valid(value):
        enter_fault(token, INVALID_PAYLOAD); return
    publish_stable_result(token, value)
    state = RESULT
    arm_acknowledgement_deadline(token)
on_acknowledge(token):
    if state != RESULT or token != active_token:
        record_unmatched_acknowledgement(token); return
    cancel_acknowledgement_deadline(token)
    clear_published_result()
    active_token = none
    state = READY
on_timeout(token, expected_state):
    if token != active_token or state != expected_state:
        record_stale_timer(token); return
    enter_fault(token, TIMEOUT)
on_acquisition_failure(token):
    if state == BUSY and token == active_token:
        enter_fault(token, ACQUISITION_FAILURE)
enter_fault(token, reason):
    cancel_all_deadlines(token)
    invalidate_pass_result()
    record_fault_and_pending_part(token, reason)
    state = FAULT
on_authorized_recovery:
    if state != FAULT: return
    resolve_part_disposition()
    stop_pending_work_and_clear_events()
    generation = new_generation()
    active_token = none
    state = READY

Ready принимает запрос и связывает идентификатор до захвата. Busy сохраняет его, явно отклоняет или ставит новые в очередь, не подменяет. Публикуйте решение и идентификатор до правильного подтверждения. Чужое подтверждение не очищает. Срок, захват или неверные данные переводят в Fault, отменяя старый проход. Возврат после разрешённого восстановления с решением по детали. Это процессная координация, не независимое управление безопасностью.

Пример протокола испытания

Это условный пример, а не результаты измерений Deyi. Замените значения собственными утверждёнными протоколами испытаний.

Сохраняйте результат и идентификатор T300 до соответствующего подтверждения или заданного перехода в ошибку. Проверьте второй запрос при Busy, подтверждение T299, завершение после срока и перезапуск контроллера. Запишите состояние и фактическое решение по детали. Отменяйте старые таймеры или проверяйте поколение, чтобы срок T300 не нарушил следующий запрос. Приложение описывает поведение; сигналы и формат сообщений требуют выбранного протокола контроллера.

У таймера есть владелец, начало и поколение. Условные сроки относятся к разным ожиданиям, не рекомендуются. Отменяйте при выходе или проверяйте идентичность. Позднее завершение после ошибки остаётся диагностикой. Потеря подтверждения отличается от ошибки: решение может быть годным, транзакция открыта. Определите повтор, удержание или операторскую сверку. Восстановление сети не закрывает прошлую деталь.

Две схемы процесса

Поиск неисправностей

• Слишком короткий импульс требует изменения сигналов или протокола.
• Подтверждение чужого номера указывает на ошибку очереди или последовательности.
• Автоматический сброс отказа может скрывать непроверенную деталь.

Приёмка и передача

Проследите каждый запрос до конечного исхода без перезаписи. Испытайте тайм-ауты, сброс и потерю питания с обеих сторон. 200/500 ms не доказывают совместимость.

Назначьте критерии приёмки до испытания и сохраните исходные данные. Примеры не подтверждают возможности поставляемой модели.

Испытайте ожидаемую таблицу: норму, запрос при Busy, чужое и двойное подтверждение, отсутствие кадра, опоздание, обрыв и перезапуск. Сравните состояние, идентичность, результат и деталь. Старый проход не становится новым. Проверьте границы для старых таймеров и гонок, повторите норму. Передайте определения, таймеры, трассы, восстановление и сигналы. Нейтральное приложение требует проверки устройств, не является инструкцией PLC или функцией Deyi.

Связанные материалы

До выбора оборудования изучите связанные руководства по подбору и применению. Для технического рассмотрения подготовьте изображения образцов, требуемый результат, условия работы и протокол испытаний.