Мы попытаемся рассказать про опыт проектирования и разработки устройства на контроллере ESP32 для мониторинга закрытой разработчиком промышленного оборудования, который является важным производственным процессом в изготовлении пластин для свинцово-кислотных аккумуляторов.
Задача была следующая – реализовать удаленный мониторинг и ведение статистики работы оборудования. Из интересующих значений выделены:
- - Установленные и фактические влажность и температура в камере;
- - Общее время работы и текущее время работы шага;
- - Текущая программа и шаг.
На борту у оборудования сборка Siemens S7-200 Smart + HMI Proface, обмен связи MPI.
На момент реализации, нам дали информацию, что ПЛК и HMI защищенны паролем с завода, что значительно усложнило задачу и привело нас к решению разработать внешнее устройство “снифер” на ESP32.
И так, с чего же все началось, а началось все с определение скорости MPI. На этот момент мы уже подключились параллельно к RS485 готовым анализатором логики с использованием ПО Logic:
Получив осциллограммы сигналов, я использовал инструмент программы Analyzer и начал подбирать скорость, битность, паритет и стоп-бит, чтобы получить посылки нужного вида и без ошибок. Нужный вид посылки для себя определил, почитав статью за этом же сайте https://habr.com/ru/articles/748844/ , статья про создания своего slave устройства для Profibus, с нее же вышел на весьма подробное описание Profibus интерфейса от Макса Фелсера https://felser.ch/profibus-manual/index.html .
Таким образом, спустя непродолжительный кусок времени, параметры интерфейса были определены, и типовые посылки, из статей описанных выше, стали проглядываться:
В этой статье не будет подробно описан интерфейс, если вам это интересно, вы можете прочитать статьи, которые мы упомянули выше.
Что ж, после этого этапа, следует более интересный – найти в этом непроглядном количестве байт нас интересующие. Для этого, мы уже подготовили ESP32 + MAX485 на Serial2, который имел примерно следующий вид:
Написался быстро небольшой скрипт, который читал ответы ПЛК на запросы HMI, и выводил мне их в исходном байтовом виде. Так мы избавились от посылокзапросов, токена, телеграммы без полезной нагрузки (SD1) и т.д. Для вывода сообщения мы подготовили себе следующее условие:
if (SerialBuffer[0] == 0x68 and SerialBuffer[3] == 0x68 and SerialBuffer[6] == 0x08)
//////////
SerialBuffer[0] == 0x68 – Посылка с переменной длинной;
SerialBuffer[6] == 0x08 – FunctionCode ответ слейва на запрос;
В итоге у нас получились 2 вида телеграмм по длине ответа, с размером 0x27 и 0x33, так я их в итоге благополучно и начал разделять, и ложить информацию с этих телеграмм в разные массивы. Код ниже:
if (SerialBuffer[0] == 0x68 and SerialBuffer[3] == 0x68 and SerialBuffer[6] == 0x08)
{
int PDULenght = int(SerialBuffer[2]);
switch (SerialBuffer[2])
{
case 0x27:
{
// Serial.println("Message 0x27");
for (int i = 0; i < PDULenght; i++)
{
QuringInfo.Registers27[i] = SerialBuffer[i + 7];
if (i > 250)
break;
}
TimeLastNewData = millis();
}
break;
case 0x33:
{
// Serial.println("Message 0x33");
for (int i = 0; i < PDULenght; i++)
{
QuringInfo.Registers33[i] = SerialBuffer[i + 7];
if (i > 250)
break;
}
TimeLastNewData = millis();
}
break;
}
memset(SerialBuffer, NULL, sizeof(SerialBuffer));
}
После этого, началось самое неинтересное, я добавил в код периодичный вывод в Serial состояния всех регистров в массивах QuringInfo.Registers33 и QuringInfo.Registers27, и сохранял их в Word, предварительно зафиксировав и записав все текущие значения отображаемые на HMI оборудования. Позже, томным летним вечером, я начал искать в полученных байтах записанные значения и довольно быстро нашел программу и ее шаг. С температурами и влажностями было сложнее, эти значения передавались необычно, не с помощью little-endian или big-endian, не числом с плавающей точкой – значения температур и влажностей в телеграмме передавались с умножением на 10.
То есть, когда бы на HMI была температура 44.5, то в интерфейсе она бы выглядела как два байта 0x01 и 0xBD, 0x01BD (HEX) -> 445 (DEC).
В итоге найдя таким весьма неэффективным способом все переменные, написал следующее:
QuringInfo.TempNow = ((QuringInfo.Registers27[24] << 8) | QuringInfo.Registers27[25]) / 10.0;
QuringInfo.TempSet = ((QuringInfo.Registers27[26] << 8) | QuringInfo.Registers27[27]) / 10.0;
QuringInfo.HumidityNow = ((QuringInfo.Registers27[30] << 8) | QuringInfo.Registers27[31]) / 10.0;
QuringInfo.HumiditySet = ((QuringInfo.Registers27[28] << 8) | QuringInfo.Registers27[29]) / 10.0;
QuringInfo.Program = int(QuringInfo.Registers27[33]);
QuringInfo.Step = int(QuringInfo.Registers27[35]);
QuringInfo.Step_Hours = int(QuringInfo.Registers33[27]);
QuringInfo.Step_Minutes = int(QuringInfo.Registers33[31]);
QuringInfo.Step_Seconds = int(QuringInfo.Registers33[35]);
QuringInfo.Global_Hours = int(QuringInfo.Registers33[39]);
QuringInfo.Global_Minutes = int(QuringInfo.Registers33[43]);
QuringInfo.Global_Seconds = int(QuringInfo.Registers33[47]);
После всех перепроверок, чтобы значения соответствовали действительности в Serial мониторе, подошла очередь до проектирования печатной платы и корпуса.
Разработка платы и корпуса устройства:
Эти шаги тоже подробно описывать в этой статье не будем, боимся, что сильно раздуем материал.
Пользовательский интерфейс :
На момент полной реализации и отладки устройства, наш коллега уже полностью подготовил сервер, написанный на nodejs, обмен связи 6 устройств с сервером происходит по WebSocket и спустя примерно месяц после первого подключения к RS485 имеем такой результат:
Поставленная задача полностью выполнена.