Промышленные весы по RS-232 в системе управления
Как получать массу от весового терминала по RS-232: сборка сообщений, устойчивый вес, единицы, тара и привязка результата к изделию.
Весовой терминал показывает нормальную массу, а ПЛК иногда получает число в десять раз больше или привязывает предыдущий результат к новой таре. В журнале порта при этом есть читаемые символы. Наличие строки ещё не доказывает, что программа получила полное сообщение и правильно поняла состояние весов.
Разберём обмен с весовым терминалом на уровне сообщений: границы строки, статус устойчивости, единицы, тара и связь результата с операцией. Электромонтаж последовательного интерфейса и метрологическое подтверждение весов здесь не рассматриваются.
Короткий ответ
Приём весового значения должен завершаться разбором целого сообщения с проверкой статуса и единиц. Сетевой пакет или порция байтов из последовательного драйвера не обязаны совпадать с одной строкой протокола. Динамическое значение и устойчивый результат следует хранить отдельно. Для каждой принятой массы нужны время, состояние терминала и идентификатор операции. Команды тары и нуля выполняют по документации устройства с контролем результата, а не по принципу «послали и забыли».
Сначала выяснить режим обмена
Весы могут непрерывно передавать показания, отвечать на запрос или выдавать результат по событию. Это разные схемы интеграции. Если терминал ждёт команду, пассивный приём ничего не даст. Если он передаёт непрерывно, добавленный опрос может смешать ответы и потоковые строки.
В руководстве фиксируют параметры порта, разделители, формат знака, количество пробелов, единицы и правила статусов. Нельзя предполагать, что первое число в строке всегда масса. В сообщении могут присутствовать номер канала, код состояния, масса тары и результат нетто.
MT-SICS у METTLER TOLEDO служит примером протокола, в котором различаются запросы устойчивого и немедленного значения и передаются статусы. Это не означает, что все промышленные терминалы понимают эти команды. Для своей модели нужно проверить доступный набор и ответ при невозможности выполнить запрос.
Почему один вызов чтения не равен одному весу
Порция от драйвера может содержать половину строки, несколько строк или окончание старой и начало новой. Правильный приёмник накапливает данные в буфере и выделяет сообщения по документированным границам. Незавершённый остаток остаётся до следующего чтения, но не бесконечно.
Нужно ограничить длину сообщения и время его сборки. Если терминатор потерян, переполнение буфера не должно повреждать соседние данные. Приёмник регистрирует ошибку формата и восстанавливает синхронизацию по принятому правилу. Молчаливо извлекать «похожее число» из повреждённого сообщения опасно для качества данных.
Проверку удобно начать с записи исходного обмена. По одному итоговому тегу нельзя увидеть лишний знак, двоичный символ или неправильную границу. В техническом журнале сохраняют образцы сообщений с отмеченными управляющими символами и результатом разбора, не превращая его в бесконтрольный многолетний дамп порта.
Масса без статуса не является завершённым результатом
Показание во время установки тары меняется. Для визуального наблюдения оно полезно, но для записи результата партии может требоваться устойчивое состояние. Устойчивость должна подтверждаться способом, предусмотренным весовым терминалом и процедурой взвешивания.
Несколько одинаковых округлённых чисел подряд не обязательно означают устойчивую массу. Отображение могло иметь низкое разрешение, поток мог повторять старую строку, а процесс ещё не установился. Если используется дополнительный программный критерий, его нужно описывать отдельно от признака устойчивости прибора.
Перегрузка, недогрузка, занятость или невозможность выполнить команду должны давать явное состояние. Записать ноль при любой ошибке удобно для типа данных и плохо для производства: настоящий нулевой вес станет неотличим от потери результата.
Единицы и числовой разбор
Предположим, приходит +12.340 kg. После разбора масса равна 12,340 кг, или 12340 г. Нельзя просто убрать точку и всегда считать граммы: количество десятичных знаков и единица могут измениться вместе с настройками терминала. Нужен разбор числа и отдельное преобразование единицы.
Разделитель десятичной части берут из протокола, а не из региональных настроек компьютера. Пробелы выравнивания удаляют в допустимых местах, знак сохраняют. Отрицательная масса после тары может быть корректным показанием, а не ошибкой последовательного порта.
Хранить результат можно в целых минимальных единицах или в подходящем вещественном типе. Выбор зависит от диапазона и требуемого разрешения. Больше десятичных знаков в базе не означает большей точности весоизмерения; формат результата должен сохранять смысл прибора и процедуры.
Тара и ноль имеют разные последствия
Тарирование изменяет представление массы нетто относительно принятой тары. Нулевая операция имеет другой смысл и условия допустимости. Для обмена важно проверить не только отправку команды, но и её завершение либо отказ. Время ожидания команды и срок получения результата не обязаны совпадать с обычным опросом массы.
Команда тары должна относиться к известной таре и состоянию поста. Если оператор успел заменить ёмкость, задержанный ответ нельзя автоматически считать подтверждением новой операции. Порядок действий и идентификатор сеанса помогают связать ответ с правильным контекстом.
После восстановления связи некоторые сообщения могут оставаться в буфере преобразователя интерфейсов. Поэтому «первая строка после подключения» не всегда равна свежему результату текущего изделия. Для ответственного шага нужен новый согласованный цикл запроса либо иной подтверждённый способ получения актуального измерения.
Привязка к изделию
Взвешивание удобно представить как сеанс: изделие предъявлено, тара определена, измерение получено, результат принят, изделие убрано. Каждому сеансу присваивают собственный идентификатор. Один и тот же вес может законно принадлежать разным изделиям, поэтому дедупликация только по числу массы непригодна.
При запросном обмене в системе обычно держат известное число незавершённых запросов и понимают порядок ответов. Если протокол не возвращает номер транзакции, нельзя автоматически добавить его в прибор. Привязку обеспечивают режимом взаимодействия, очисткой контекста и управлением жизненным циклом сеанса.
Для передачи в MES полезен атомарный результат: идентификатор изделия, масса, единица, статус, время принятия и версия операции. Изменять только значение массы в наборе отдельных тегов рискованно: верхний уровень может прочитать новый вес со старым номером изделия.
Таблица обработки сообщений
| Событие | Решение приёмника | Что сохранять |
|---|---|---|
| Пришла часть строки | Продолжить сборку | Буфер и срок ожидания |
| Пришли две строки | Разобрать обе по очереди | Отдельные результаты |
| Неверная единица | Отклонить для операции | Причину и исходное сообщение |
| Вес динамический | Показать как текущее значение | Статус динамики |
| Устойчивое значение | Проверить контекст сеанса | Массу, единицу, время, изделие |
| Команда тары отклонена | Не считать тарирование выполненным | Код и условия отказа |
Тестирование приёмника без реальных весов
Перед подключением производства полезно собрать набор зафиксированных сообщений из документации и разрешённой записи обмена. Для каждого образца указывают ожидаемое число, единицу, статус и решение об использовании. Это проверяет именно разбор протокола и не требует каждый раз ставить физический груз.
Один и тот же правильный ответ передают разными порциями: целиком, по одному байту, с разрывом перед терминатором и вместе со следующим сообщением. Результат должен оставаться одинаковым. Если программа работает только при удачном размере буфера драйвера, такая серия быстро обнаружит зависимость.
Добавляют сообщения с лишним символом, неизвестной единицей, предельной длиной и отсутствием завершения. Для каждого случая проверяют не только отказ, но и восстановление: следующая правильная строка должна разбираться по принятому правилу. Один повреждённый пакет не должен навсегда сдвинуть границы всех последующих результатов.
Эмуляция протокола не проверяет электрический интерфейс, метрологию и поведение конкретного терминала. Она закрывает другой слой. После неё нужны реальные испытания команд, статусов и времени ответа выбранной модели. Раздельные проверки помогают локализовать проблему вместо одновременного поиска в кабеле, библиотеке и настройках весов.
Сценарий «тара, изделие, результат»
Рассмотрим условный пост, где пустая ёмкость устанавливается перед каждой операцией. Система открывает сеанс и ждёт подтверждённого действия с тарой. После его завершения начинается этап получения массы продукта. Если тарирование отклонено, последующее число нельзя автоматически объявлять чистой массой нового изделия.
Далее принимают результат по согласованному критерию. В запись входят сам вес и его контекст. При снятии ёмкости сеанс закрывается, даже если терминал ещё передаёт остаточные строки. Они могут быть полезны для диагностики, но не должны становиться новым результатом предыдущего изделия.
Теперь оператор снимает ёмкость слишком рано. Приёмник может получить устойчивую строку, относящуюся уже к пустой платформе. Поэтому критерий «статус устойчив» без знания этапа не защищает от смысловой ошибки. Наличие изделия и границы операции проверяются в общей последовательности поста.
Если связь пропала между тарированием и результатом, система должна знать, какие факты подтверждены. Повторить тару автоматически на уже заполненной ёмкости значит изменить смысл нетто. Возможность продолжения выбирают по состоянию процесса и документированной процедуре, а не только по тому, что порт снова открылся.
Разделение брутто, тары и нетто
Нужно установить, какие величины реально передаёт терминал и как они связаны. Иногда в потоке есть только отображаемое значение, а его режим меняется с панели. В другом исполнении доступны отдельные результаты. Предполагать постоянный смысл отображаемого числа без проверки конфигурации нельзя.
Если система сама вычисляет нетто как разность брутто и тары, обе величины должны относиться к совместимой операции и единицам. Ошибочно использовать сегодняшнюю тару со вчерашним сохранённым брутто только потому, что оба тега доступны. Для набора результата полезны номер сеанса и признак согласованности.
Расхождение арифметической проверки тоже не всегда означает неисправность. Значения могут быть округлены или получены в разные моменты. Прежде чем назначать точный допуск, выясняют разрешение и семантику передаваемых полей. Источник истины для результата операции должен быть определён заранее.
При ручной замене тары сохраняют основание и инициатора. Такая корректировка может быть допустимой по процедуре, но должна оставаться отличимой от штатного получения. Иначе последующий анализ обнаружит красивую последовательность масс и потеряет факт ручного вмешательства.
Диагностика задержанного ответа
Протокол без номера транзакции требует особенно аккуратного порядка запросов. Если один запрос ещё не завершился, отправка следующего может затруднить привязку ответа. Параметры и возможности последовательной обработки берут из руководства, а не из предположения, что любые строки приходят строго по времени команды.
При таймауте нужно определить, как очистить или завершить текущий контекст. Поздний ответ не должен стать ответом на новый запрос только из-за совпадения формата. Для отдельных протоколов возможна команда отмены или повторная синхронизация; её пригодность проверяют для конкретной модели.
В журнале полезно иметь моменты отправки, начала и завершения приёма, результат разбора и состояние автомата. Тогда видно, задержался прибор, преобразователь или прикладная обработка. Одна отметка времени записи в базу не позволяет разделить эти причины.
Вопросы при работе
Можно брать число с дисплея терминала через OCR? Когда доступен штатный протокол, он обычно даёт больше смысла: статус, единицы и ответы на команды. Распознавание картинки создаёт собственные ошибки и требует отдельной проверки. Оно не становится метрологическим интерфейсом автоматически.
Нужна ли задержка после установки тары? Время может участвовать в процедуре, но одна задержка не подтверждает пригодный результат. Следует учитывать состояние прибора, устойчивость и условия операции. Число секунд выбирают по проверке поста, а не по общему примеру.
Почему в архиве повторяется предыдущий вес? Возможны непрочитанный старый буфер, удержание последнего результата и неверная граница сеанса. Проверяют исходную строку, время её приёма и идентификатор операции. Изменение частоты опроса без этих данных мало что объяснит.
Что нужно для восстановления рабочего обмена
Сохраните модель и версию терминала, настройки интерфейса, выбранный режим передачи, перечень используемых команд и несколько проверенных сообщений. Это позволяет отличить изменение протокола от проблемы приёмника после замены оборудования. Настройки преобразователя интерфейсов, если он есть, также относятся к цепочке.
Резервная копия программы ПЛК без конфигурации терминала может оказаться недостаточной. Новый прибор способен передавать другую единицу, иной режим отображения или дополнительные поля. Поэтому восстановление завершается контрольной операцией с проверкой сырой строки и принятого результата.
Для операторской инструкции важно явно назвать момент принятия массы. Нажатие кнопки, появление числа и подтверждение результата в системе могут происходить последовательно. Если человек считает операцию законченной раньше, чем система зафиксировала результат, возможны снятая тара и привязка следующего чтения к неверному сеансу.
Проверенный обмен должен восстанавливаться по описанным параметрам и контрольному примеру. Это практичнее, чем зависимость от единственного компьютера с удачным набором незафиксированных настроек порта.