CS-CS.Net: Лаборатория Электрошамана

Устройства (модули ввода-вывода ОВЕН), готовые к настройке по базе данных CS CRM

Сегодня я расскажу вам об очень серьёзном дополнении к своей CS CRM-системе, в которой я уже как лет 15 веду весь учёт и проектирую щиты (в том числе). Про неё есть много постов, которые собраны по тэгу «CRM».

На этот раз я придумал и за полтора месяца вечернего отдыха написал систему учёта устройств (оборудования), которая имеет такой набор функций:

• Быстрый поиск по любой части названия, серийного номера, ID;
• Хранение названия, ID и логического назначения устройства или оборудования;
• Привязка устройства или оборудования к Номенклатуре (пост про неё вот здесь);
• Привязка устройства к Договору (заказу, объекту) для быстрого поиска или отбора;
• Хранение заводских и аппаратных настроек (серийный номер, версия железа, прошивки, дата выпуска, поверки, интервал поверки);
• Хранение настроек связи (адрес, интерфейс, протокол, режим работы, скорость связи, порядок байт);
• Хранение произвольных свойств (значений регистров, настроек каналов измерения);
• Хранение истории изменений статусов устройства (Покупка, Настройка, Запуск, Ремонт, Поверка, Утилизация) с привязкой к документам ТМЦ или документам Актов;
• Хранение вложений (актов, паспортов и других). Есть быстрый выбор вложений из Номенклатуры, общей для всех экземпляров устройства (документация, фотографии);
• Создание распечаток параметров в кратком (без истории статусов) или полном (со статусами) вариантах для того, чтобы хранить настройки на объекте в распечатанном виде или передать их на объект для настройки нового устройства.

Дальше я расскажу о том, почему и как я её создал (я честно спрашивал чужой опыт на форуме ОВЕНа, где на меня примерно 70% людей посмотрели как на идиота и сказали, что экселя достаточно), и как она работает. А в самом конце поста будет видео (впервые про мою CS CRM — до этого были только посты).

1. Проблемы, которые нужно было решить: Сервис, Серийники, Настройки.

До того, как я создал эту систему, у меня накапливались различные бизнес-операции, которые начинались с малого, но потом стали приносить проблемы из-за того, что информация о них хранилась в CS CRM не явно или не хранилась вообще.

Первая проблема — это то, как сохранить адресацию устройств Modbus. Чаще всего это модули ввода-вывода (напоминаю подробный и концептуальный пост про модули от ОВЕН), которые стоят внутри щита вместе с ПЛК, и которые он опрашивает по интерфейсу RS-485.

Например, вот один из старых проектов на ОВЕН ПЛК110 в Митино, где такие модули и установлены:

Пример щита с ПЛК и модулями ввода-вывода по RS-485

В таких проектах всё было просто. Открываем исходник проекта и берём оттуда адреса модулей. Вот так:

То, как можно узнать базовые настройки оборудования: смотрим в проект ПЛК

Вроде бы всё просто, да? Да-да! Вот именно так я и начинал: все модули ввода-вывода — только дискретные, и максимум что надо настроить — это адрес и параметры связи.

Когда я начал делать большие проекты, то устройства (всякие датчики климата, например от ОВЕН или от WirenBoard) стали появляться вне щита, и их стало больше.

Тогда я стал хранить это всё в XLS-файле таблицы IO сигналов (она была упомянута в посте про методику программирования и отладки ПЛК, а сами датчики относятся к посту про Проклятый Проект):

То, как можно узнать базовые настройки оборудования: смотрим в XLS-таблицу, если её заранее кто-то составил

В принципе это тоже читаемо, и меня не беспокоило до некоторого времени. Если какое-то устройство сдохнет, и его надо будет заменить — то откроем табличку и посмотрим его адрес. Возьмём новое и настроим его так же…

Вторая проблема, которая иногда возникала — это хранение серийного (заводского) номера устройства при обращении в сервис. У ОВЕНа этот заводской номер требуется постоянно, и сама система у них сделана круто: по серийнику определяется дата выпуска, срок поверки и то, будет ли ремонт гарантийным.

До этого весь мой учёт был на базе документов ТМЦ: Заказ, Покупка, Продажа, Списание, Перемещение между складами. Так как мне хотелось хранить ещё и статистику брака (про это я когда-нибудь напишу пост, и ещё и на сайт выгрузку сделаю), то всё что я придумал — это записать серийник дохлого ПЛК в комментарии к документу замены брака (сам этот документ из заказа на Марка Шагала, где мне попался ПЛК с дохлой платой SOM).

Операция ремонта устройства, при которой надо сохранить его заводской номер

Так как при отправке устройства в Сервис надо составить Акт рекламаций, то, чтобы он не пропал, я воспользовался механизмом вложений и прикрепил его к этому же документу:

Вложения к документу ремонта устройства - акт рекламаций

Документ хранится внутри базы (и бэкапится вместе с ней). Его можно открыть прямо из базы и посмотреть:

Содержимое вложения (акта рекламаций) для текущего устройства в документе ТМЦ

Эту бизнес-операцию можно назвать костылём: мы храним информацию там, где её будет очень сложно найти. Вместо какого-то объекта «Устройство -> Серийный номер» или «Устройство -> Статус -> Ремонт» нам надо найти этот заказ, найти этот документ с признаком ремонта брака и потом там почитать комментарий и найти заводской номер. Это очень плохо!

Дополнительно плохо здесь и то, что я отдаю все паспорта устройств заказчику вместе со щитом и после этого не смогу восстановить серийные номера этих устройств. А в паспорте ещё и не пишут, какой из четырёх модулей вывода в моём проекте имеет маркировку «W06», какой «W07», и так далее.

Третья проблема, которая стала возникать после того, как WirenBoard в прошлом году дописали прошивку датчиков WB-MSW на чтение регистров подряд (ещё раз напоминаю пост про эти датчики) — это хранение истории обновлений прошивок и действий с ними.

Так как два года назад никаких таких функций у меня не было, то я написал всё в комментариях к документу «Покупка ТМЦ» вот так вот:

Попытка сохранить серийный (заводской) номер и версию прошивки устройств в документе ТМЦ - прямо в комментариях

Здесь плохо всё, что только можно: вместо «Получено 9 датчиков» надо добавлять их построчно, чтобы для каждого сохранить отдельную информацию. Серийный номер, сигнатура железа, версия прошивки и то, что я её обновил, хранятся вперемешку в комментарии.

Чтобы найти эту информацию, мне нужно было бы вспоминать, под какой заказ я получал эти датчики, снова искать документ ТМЦ и там читать эти комментарии.

И, наконец, четвёртая проблема — это хранение настроек устройств. Не зря в первой проблеме я говорил, что достать адреса модулей ввода-вывода из исходника проекта было просто до тех пор, пока все модули ввода-вывода были только с дискретными каналами! Для дискретных каналов нет настроек, кроме защиты от дребезга (всегда включена) и безопасного состояния (всегда выключено).

А вот для аналоговых каналов (напоминаю пост про аналоговый ввод-вывод) настроек много: тип датчика, диапазон масштабирования, коррекция сдвига и наклона, смещение десятичной точки и так далее.

Для настройки модулей ввода-вывода у ОВЕНа есть свой конфигуратор (у меня показан для старой линейки модулей). В этом конфигураторе все настройки можно сохранить в файл, который приложить к исходникам проекта ПЛК и по которому все эти настройки можно будет восстановить.

Процесс настройки модуля аналоговых вводов ОВЕН МВ110-8А для датчиков ДТС014

И… я был ОЧЕНЬ удивлён тому, что такие конфигураторы и удобство настроек есть только у ОВЕНа! А в большинстве устройств предполагается то, что вы возьмёте условный Modbus Poll и руками будете записывать настройки в нужные регистры.

Вот вам пример — кусочек из документации на датчики климата RazumDom MSU44 с дисплеем (я упоминал о них вот в этом посте):

Пример настроек сложного устройства, для которых нужно сохранять значения регистров Modbus

Конфигуратора — нет! Учёта таких настроек — нет! Как и куда их записать? Где сохранить в удобном виде? В общем-то, есть в моей базе функция вложений, и при помощи неё можно сохранить все такие настройки в файл и прикрепить этот файл к документу «План щита» или «Договор»… но никакого поиска и учёта тут явно не будет.

А ведь ещё есть просто ДАТЧИКИ (все посты про них — по тэгу «Датчики»), у которых есть заводской номер, дата выпуска, дата поверки, характеристики и для которых надо сделать красивые наклейки с тем, какой датчик куда предназначен и какой ID имеет. И это тоже как-то надо учитывать!

Пример монтажа датчика давления ОВЕН ПД100-ДИ на объекте заказчика

А ещё! Ещё некоторые устройства могут даже путешествовать между складами! А ещё и между заказами: например, какой-то датчик или модуль ввода-вывода могут снять, отдать мне, а я могу поставить его на другой объект…

А сам ОВЕН часто спрашивает при обращении в сервис ещё и дату первого запуска, время наработки…

И я принял решение: делаю свою учётную систему под свои нужды! Давайте же посмотрим на неё!

2. Основное окно списка Устройств и его функции.

Моя система учёта построена на базе Справочника 1Ски, главное окно которого выглядит так:

Главное окно списка устройств базы CS CRM

Я долго думал, как лучше поступить: пойти от Договора (заказа) и привязывать к нему устройства через какие-то документы и действия 1Ски, или же сделать единый большой справочник, в котором будут все-все устройства с возможностью группировать их по папкам и привязывать к нужному договору, если это надо. Остановился на этом варианте.

В главном окне слева есть дерево папок, в котором можно создать нужные группы по ID Договоров (они у меня имеют определённую структуру и будут хорошо сортироваться по алфавиту), а справа выводится список устройств с нужными колонками. О том, какие у них могут быть характеристики, я расскажу позже. Предполагается, что при перемещении устройства между разными заказами оно будет перемещаться по разным папкам этого справочника (при этом история привязок к заказам сохранится).

Колонки можно настроить, выбрав те, которые будут актуальны. Если мы часто работаем с датчиками — то можно включить колонки «Дата выпуска» и «Дата поверки», а если с устройствами Modbus (как я) — то колонку «Адрес и параметры связи».

Функции главного окна списка устройств: настройка показываемых колонок

В списке устроств обязательно есть поиск по части какой-то характеристики — Названию, ID, Заводскому номеру, Адресу, Модели и так далее.

Функции главного окна списка устройств: поиск объектов по разным полям (или по всем сразу)

На самой форме списка устройств есть быстрые сервисные кнопки. Одна позволяет быстро открыть список вложений для текущего устройства и для Номенклатуры, которая к нему привязана (если есть).

Функции главного окна списка устройств: быстрый просмотр вложений Устройств и Номенклатуры

Это очень удобно, если надо быстренько открыть вложенный паспорт или инструкцию. Выбрал из меню нужное вложение — оно и открылось.

Другая позволяет быстро создать новый статус устройства. Например, если нам надо пометить устройство как установленное — то достаточно выбрать из меню нужный пункт (при выборе документа статус будет сразу привязан к этому документу), заполнить поля открывшегося окна — и всё: не надо открывать само устройство и там добавлять новый статус.

Функция быстрого добавления статуса из основного окна списка устройств

Также на форме есть кнопка печати выделенного устройства или всей их группы. Про это я вам расскажу далее.

3. Основные данные об Устройстве (Название, Заводские параметры).

Главное окно устройства хранит много разных данных, которые относятся к самым базовым и важным.

Основные данные об Устройстве: Название, ID, Привязка к Договору, Заводские параметры

Я пробегусь по их списку:

• Наименование — Понятное название устройства в нашей базе. Может состоять как из модели товара, так и из его назначения или общего названия. Например «Датчик давления ГВС Ввод», «Основной ПЛК», «Модуль расширения 1» или «Датчик AI: ГВС Стояк (ОВЕН ДТС3224-PT1000.B.3.43.ЭС/2)».
• Модель — Привязка устройства к Номенклатуре (ссылка на элемент справочника). Из Номенклатуры можно достать вложения (инструкции, документацию, схему включения), а так же заполнить Название при помощи специальной кнопки.
  Есть история последних выбранных значений для быстрого ввода:
  

  Быстрый выбор последних значений Номенклатуры для добавления в Устройства

• Назначение — Описание логического назначения устройства или датчика. Нужно для более подробного пояснения. Например, в наименовании может быть «Датчик давления ГВС Ввод», а в Назначении — «Измерение давления воды по вводу для контроля её отключения в доме».
• ID — Основной идентификатор устройства: обозначение в щите, на этикетке или в документации (обычно ему же соответствует идентификатор кабеля, который приходит к этому устройству). Это может быть обозначение модульки ОВЕН в щите («W01», «W02»), обозначение устройства вида «AD08X14» (так на атомных станциях делают) или какой-то общий вариант обозначения вида «DD-01».
• Этикетка — Описание датчика на этикетке-наклейке. Это поле заведено на будущее, и сейчас автоматическая печать этикеток датчиков пока не поддерживается. Нужно оно из-за того, что этикетка имеет меньшие размеры, чем длина Наименования и Назначения устройства, и текст этикетки должен быть короче.
• Договор — Привязка устройства к конкретному Договору (Заказу) для быстрого отбора или поиска. Договор может быть указан в папке устройств, и тогда он автоматически подставляется в каждое новое устройство, которое в ней создаётся.
• Заводской номер — Самое главное поле для устройств от ОВЕН (и других хороших производителей). Серийный номер — это вообще чуть ли не самая основная характеристика каждого устройства.
• Hardware / Прошивка — Версии железа (печатной платы, аппаратной ревизии) и прошивки. Можно указывать в вольном формате, типа «1.2 (Старый конфигуратор)» или «Binary v1.1.0, ПО v2.0, STM32 v114».
• Дата выпуска, Дата поверки, Интервал поверки — Даты выпуска и поверки устройства, а так же стандартный интервал поверки, который выбирается из списка значений:
  

  Быстрый выбор интервала дат поверки для устройства

  
  Поле даты поверки не хранит историю значений, так как мне не хотелось усложнять свою систему. Историю поверок можно хранить в виде Статусов, про которые я скажу дальше.
• Характеристики — Описание базовых характертистик устройства (или датчика), которые тоже будут использованы в наклейке для него или для справки.

Большинство полей имеют кнопки для выбора ранее введённых значений (это моя фишка, и я всегда её делаю на всех формах). Таким образом я упрощаю ввод данных и создаю возможность их формализации: ввода одинаковых значений для одинаковых случаев. Говоря простым языком, чтобы в первый раз можно было ввести «t ОТП Комната», а потом снова выбрать его для похожего устройства, а не вводить снова «Темп. ОТП Комната» или «T. ОТП Комната», вспоминая, как же там ты раньше вводил: через «t» или через «T».

Пример маркировки этикеткой под крышкой датчика ОВЕН ДТС125М-RS

Для того, чтобы вводить заводские (серийные) номера, я наконец-то прикупил себе самый простой сканер штрихкодов. Брал на Wildberries модель «U2-WB» (так написано на его коробке). Он сканирует 1D и 2D коды (QR-коды — тоже), и имеет беспроводной модуль, который вставляется в USB как мышка.

Простой сканер штрих кодов U2-WB с беспроводным интерфейсом и режимом эмуляции клавиатуры

Главное его достоинство в том, что он умеет эмулировать клавиатуру: код, который он отсканировал, передаётся в виде нажатий на кнопки так, как если бы мы набирали его руками на клавиатуре. Благодаря этому мне не надо доделывать свою 1Ску под работу со сканером, а можно просто поставить курсор в поле заводского номера и отсканировать его с коробки или устройства.

4. Параметры связи устройства (Интерфейс, Протокол, Адрес).

Этот раздел параметров устройства предназначен прежде всего для устройств, которые опрашиваются по какому-нибудь протоколу (Modbus): внешних датчиков, модулей ввода-вывода.

Параметры связи устройства: Адрес, Интерфейс, Протокол, Скорость обмена

Сюда я вынес самые базовые и самые важные параметры связи, которые есть почти у всех таких устройств:

• Адрес — Основной адрес устройства на шине данных.
• Режим — Режим работы устройства (Master, Slave, Spy).
• Интерфейс — Интерфейс связи устройства (RS-232, RS-485, Ethernet).
• Протокол — Протокол обмена или тип сигналов (Modbus RTU, Mobus ASCII, 4-20 мА).
• Порядок байт — Порядок байт для значений, которые занимают два регистра (FLOAT, DWORD).
• Задержка ответа — Время задержки ответа от устройства (связано с протоколом Modbus и настраивается на некоторых устройствах, чтобы увеличить стабильность пауз между запросами и ответами и линии связи RS-485).
• Таймаут Аварий — Таймаут, после которого устройство переходит в аварийное состояние (актуально для модулей ввода-вывода ОВЕН), а его выходы — в заданное безопасное состояние.
• Параметры обмена — Параметры обмена: скорость, чётность, число стоп-битов или другие.

И, конечно же, здесь тоже есть быстрый выбор ранее введённых значений.

5. Свойства Устройств и их редактирование.

Свойства устройства прездназначены для сохранения различных нестандартных значений настроек, под которые неудобно добавлять поля на форму (если эти поля будут использоваться очень редко и не во всех устройствах).

Свойства для устройства: возможность сохранять и добавлять свои собственные параметры или настройки

Механизм добавления свойств похож на свойства Номенклатуры (напоминаю пост про неё). Собственно, оттуда он и был взят, и мне пришлось переписать вообще ВЕСЬ код работы со свойствами, который был сделан примерно в 2015 году. Поста про свойства номенклатуры у меня нет, поэтому я расскажу про них прямо здесь на примере устройств.

Где можно использовать свойства устройств? Чаще всего я собираюсь использовать их для того, чтобы хранить настройки каналов модулей ввода-вывода (тип датчика, настройки масштабирования, цифровой фильтрации) или регистров Modbus, если настройка устройства выполняется ими. Как раз на верхнем скриншоте видно то, как сохранены регистры настройки дисплея для датчика RazumDom MSU44.

Если в 2015ом году свойства были только для номенклатуры, и каждое свойство можно было добавлять только один раз, то сейчас свойства можно добавлять в Контрагентов (в дополнение к реквизитам, про которые было рассказано тут), Номенклатуру, Устройства и Файлы Медиа (про них я рассказал здесь).

Сами свойства разделены по подсистемам так, чтобы одно и то же свойство можно было использовать в нескольких объектах и не плодить одни и те же наименования свойств для каждого вида справочника (Reuse, Reduse, Recycle ©).

Ну и наконец некоторые свойства (для которых это указано) можно добавлять к одному и тому же объекту неограниченное число раз: они могут быть не уникальными. Эта функция нужна для того, чтобы завести одно свойство с названием вида «Значение регистра Modbus» или «Настройки канала» и добавлять его по нужному числу каналов, а не делать отдельные свойства вида «Примечание 1», «Примечание 2», «Примечание 3», как у меня было ранее.

Так как свойства будут иметь разделение по подсистемам, но пользователь должен иметь возможность подставить свойство из другой подсистемы, если ему это надо, то я переписал окно выбора свойств на список, где выводятся свойства для текущей подсистемы с группировкой по разделам или все сразу.

Система свойств объектов CS CRM: Окно добавления свойства

Сами свойства имеют жёстко заданные наименования, тип и единицу измерения и хранятся в общем справочнике. Я так и хотел: иметь один общий справочник с фильтрацией по подсистемам, а не заводить справочники «Наименования свойств Номенклатуры», «Наименования свойств Устройств» и так далее.

Система свойств объектов CS CRM: Справочник всех типов и видов свойств

В группе свойств можно задать базовые параметры и подсистемы, к которой она относится.

Система свойств объектов CS CRM: Группа (раздел) свойств

А в самом свойстве есть (и появилось) много настроек. Базовые — это название, ID, тип и единица измерения.

Система свойств объектов CS CRM: Редактирование Свойства (в том числе и значений по умолчанию)

Из новых — это выбор подсистем, к которым оно относится, галочки настройки параметров: Служебное, Не пустое, Не уникальное (тот самый новый функционал).

Ещё можно заранее ввести список стандартных значений свойства, разделённых знаком » | » (с пробелами). В этом случае даже если вы добавляете такое свойство первый раз (и ранее введённых значений для выбора нет), вам будет показан этот самый список стандартных значений. Очень удобно!

Система свойств объектов CS CRM: Добавление Свойства с заданными по умолчанию значениями

Все операции со свойствами теперь одинаковы для Контрагентов, Номенклатуры, Устройств и Файлов Медиа.

6. История Статусов Устройства и их добавление и редактирование.

Теперь поговорим о статусах устройств — способе хранить историю изменений, включений, настроек, наладки и других действий с устройством.

История статусов устройства с привязкой к Договору и документам ТМЦ

Список статусов индивидуален для каждого устройства. Их можно добавлять как из формы самого устройства, так и из формы списка устройств при помощи кнопки быстрого добавления статуса.

Сами виды статусов формализованы и отсортированы так (уточнения к статусам добавляются при помощи комментария):

• Покупка — Получение устройства на склад от поставщика;
• Продажа — Отгрузка устройства кому-либо без ведения складского запаса (отдали заказчику, он установил — и всё);
• Списание — Удаление устройства со склада без ведения складского запаса (выбросили, сломалось);
• Перемещение — Перемещение устройства между разными объектами или складами с ведением складского запаса (например, перевезли от меня родственникам или занесли на склад резерва);
• Тестирование — Проверка работы устройства (включение по временной схеме, проверка срабатывания установленного датчика, и так далее);
• Поверка — Операция поверки устройства (датчика);
• Установка — Физическая установка (монтаж) устройства в щит, на объект;
• Настройка — Операция какой-либо настройки (параметров связи, каналов ввода-вывода);
• Запуск — Включение устройства в работу (первую, тестовую, на постоянную работу);
• Обновление — Операция обновления железа, компонентов устройства, прошивки;
• Замена — Замена устройства на новое или по истечению срока службы;
• Ремонт — Ремонт устройства в сервис-центре;
• Демонтаж — Физический демонтаж устройства (для списания, уничтожения, замены, ремонта);
• Утилизация — Физическое уничтожение устройства (разобрали, сдали на переработку, выкинули на помойку).

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

Окно добавления и редактирования статуса выглядит так:

Просмотр или изменение статуса устройства

В каждом статусе устройства хранится следующая информация:

• Договор — Привязка статуса к объекту (Договору). По умолчанию подставляется текущий Договор Устройства, но есть кнопки для быстрого выбора из: Договора папки устройств, Договора устройства и Договора документа статуса.
  Привязка к договору обычно не редактируется для того, чтобы можно было хранить историю того, как устройство путешествовало между заказами, если такое случалось: в «старых» статусах будет привязка к прошлому заказу, а в «новых» — к текущему.
• Статус — Сам статус устройства, про который я только что говорил выше.
• Дата, Время — Дата и время статуса. Их можно выбрать или по текущим или взять из документа статуса.
• Комментарий — Дополнительное пояснение к стандартному статусу, например для статуса «Обновление» можно написать «Обновлена прошивка до версии 2.3.19G», а для статуса «Запуск» — «Первое включение (подача питания)», что видно на окне списка статуса устройства.
• Документ — Это документ привязки статуса к ЛЮБОМУ документу в CS CRM. Сделано это для того, чтобы из статуса устройства можно было быстро открыть документ 1Ски. Можно сказать, что это отсылка к тому, с чего всё начиналось, когда я в документе «Покупка ТМЦ» в комментариях записывал серийники устройств. Теперь можно сделать правильно: создать в устройствах статус «Покупка» и привязать туда документ «Покупка ТМЦ».
  Привязка документа должна отражать реальные бизнес-процессы. Например, если при настройке устройства был создан Акт, то и документ акта (у меня в CS CRM есть такой) можно тоже привязать к статусу, а потом открыть его щелчком по кнопке.
  Дополнительно из привязанного документа можно достать номер заказа/счёта, а во вложениях найти и открыть этот самый счёт или заказ.
  Если такой документ выбран — то дата и время статуса берутся из него автоматически. Это очень удобно, если мы вносим устройства и их статусы в базу задним числом.

Статусы при добавлении выбираются из списка:

Создание нового статуса устройства: выбор статуса

Комментарий статуса — тоже из списка ранее введённых:

Создание нового статуса устройства: выбор комментария к статусу

Есть возможность ограничить список выбора комментариев только теми, которые были введены для текущего статуса. А можно вывести в этот список все комментарии всех статусов, как показано на скриншоте выше.

Для быстрого выбора документа самых распространённых типов есть удобное меню (по аналогии с меню в форме списка устройств):

Создание нового статуса устройства: выбор документа ТМЦ для статуса

При просмотре текущего статуса (область под их списком) подробно выводятся все данные. А при помощи кнопок можно сразу же открыть Договор или Документ статуса.

7. Вложения файлов к Устройствам (Паспорта, Акты).

Как я уже много раз говорил, к большинству объектов в моей CS CRM у меня сделаны вложения (ко ВСЕМ документам и к самым важным справочникам). Конечно же, Устройства тоже поддерживают вложения.

Вложения для устройства (Паспорта, Документы)

Вложения добавляются при помощи стандартного окна, где можно указать файл, понятное название вложения и то, надо ли удалить файл-источник вложения (тогда вложение будет полностью внесено в базу и храниться там). При необходимости можно открыть вложение напрямую из базы.

Вложения позволят хранить документы и фотографии для конкретного экземпляра устройства. Самое первое, что можно хранить — это сканы паспортов. Можно хранить старые прошивки или какую-то специальную прошивку для этого экземпляра устройства (тестовую). Можно хранить файлы конфигурации устройств.

Если такой скан паспорта будет загружен с типом «Картинка», то он будет отображаться на вкладке «Картинки» для быстрого просмотра:

Быстрый просмотр вложенных изображений для устройства

Если нужно — то вложение (и картинку) можно открыть во внешней программе (запускается связанная программа в Windows) или сохранить назад на диск.

Вложенное изображение (паспорт устройства) открыто во внешней программе

Как-нибудь, если мне захочется заморочиться, я посканирую все паспорта от датчиков и внесу их в базу!

8. Распечатки сведений об Устройстве.

Ну а напоследок покажу то, как сейчас можно распечатать и посмотреть всю информацию об устройстве. Эту распечатку можно положить вместе с документацией на объект, а можно сохранить в PDF и передать заказчику (или инженерам на объекте) для того, чтобы они могли сами настроить новое устройство, если старое вышло из строя.

Сделать это можно из кнопки «Печать» в форме списка устройств. Если курсор стоит на одном устройстве — оно и распечатается. Если стоит на папке (группе) устройств — то будут распечатаны все устройства вместе с подпапками (подгруппами). По желанию можно поставить разрывы страниц между отдельными устройствами в распечатке.

Количество информации в распечатке напрямую зависит от того, сколько её заполнено в самом устройстве. Если указана дата поверки и интервал — то дата следующей поверки тоже рассчитывается и печатается.

Самих вариантов распечаток пока две: без истории статусов и с историей статусов.

Вот распечатка без статусов для простого датчика температуры, который лежит у меня в запасах на складе:

Распечатка сведений об устройстве: простой датчик ДТС без истории статусов

А вот распечатка для того же датчика, но с историей статусов:

Распечатка сведений об устройстве: простой датчик ДТС с историей статусов

А вот распечатка с историей статусов для модуля ввода-вывода. Для примера я ещё и свойств накидал туда.

Распечатка сведений об устройстве: сложное устройство с параметрами связи, свойствами и историей статусов

В общем, бери и настраивай!

Чтобы было удобно видеть все устройства группы справочника (вместе с подгруппами), я почти на коленках составил распечатку в виде сводной таблицы. В ней отображаются ID, Название, Заводской номер вместе с версиями железа и прошивок (если есть), Адрес и параметры связи, Назначение и Характеристики, а так же сама модель товара.

Общая табличная распечатка сведений о всех устройствах в группе

По моей задумке эта таблица пригодится для работы на объекте: чтобы найти нужный датчик по серийному номеру, найти для него бирку с его ID, проверить то, что марка оборудования совпадает с указанной таблицей — и установить его там, где следует.

9. Итоги и удобство.

Благодаря моей системе я сейчас поднимаю все образцы, все даренные приколюхи и данные из заказов (какие могу достать) и вношу их в общую базу, чтобы легко искать их и хранить их настройки (особенно для тестирования, когда настройки меняются, а потом возвращаются на заводские). Все устройства для новых проектов я буду теперь вносить сюда.

И, самое главное, у меня изменилась методика работы. Раньше я делал наклейки на модули ввода-вывода (или устройства), придумывая адреса, потом монтировал их в щит, потом в щите смотрел на эти этикетки, настраивал их, а потом ещё раз смотрел на эти этикетки и вбивал адреса в проект ПЛК.

Сейчас же я делаю всё правильно, с тем же концептом, как и остальные бизнес-процессы: первым делом составляется документация (ТехЗадание, Щит, Устройства), а потом уже по ней выполняется нужная настройка и печать этикеток и программирование ПЛК.

Вот и устройства для SkyFort я сначала внёс в базу, задал им там нужные настройки, затем настроил на столе, а потом уже настроенные установил в щит.

Результат использования функции Устройств CS CRM: заранее настроенные модули ввода-вывода готовы к установке в щит

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

Проекту исполнилось 15 лет! Поддержать проект материально, проспонсировать проекты Автора или сделать ему подарок можно на этой странице: "Донаты и Спонсорство, Список Желаний".