диспетчеризация устройств через Modbus

[Mike[]]

Здравствуйте, уважаемые! Есть вопрос, имеется 17 приборов учета электроэнергии, соединенных последовательно по modbus rs-485, протяженность линии порядка 2 километров, подскажите какую-нибудь систему диспетчеризации, которую можно запрограммировать силами электротехнического персонала с базовыми знаниями асу тп. т.е. чтобы не вникать глобально к примеру в программирование decodesys или сименс?

[Jackson]

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

Это очень резиновое описание квалификации, от "здравствуй, дерево" до "мастер на все руки".
Можно подробно описать задачу и поставить её поставщику системы - он сам всё запрограммирует, но за это придется заплатить.

Учёт коммерческий?

[Parliament74]

modbus rs-485

В протоколе точно уверены? Modbus RTU? Какие счётчики (модель) стоят?

[Looker]

запрограммировать силами электротехнического персонала с базовыми знаниями асу тп. т.е. чтобы не вникать глобально

«Оставь надежду, всяк сюда входящий» (с) Данте Алигьери.

[Mike[]]

Раскроем маленько тему, стоит 17 универсальных приборов eem-ma400 phenix contact для контроля показаний токов, напряжений, мощности на небольшом производстве, они в составе действующей системы диспетчеризации на данный момент, однако планируется расширять систему, предусматривая подключение дополнительных устройств, счетчиков эл. энергии, реле LTMR, частотных преобразователей, связь предпочтительнее Modbus через rs-485.
На данный момент система состоит из контроллера Fastwell CPM713, программа на decodesys 2.3. Связь контроллера и fastwell Modbus opc server уже через Modbus tcp, скада система InTouch 2012 r2, всего в системе 471 тэг

В протоколе точно уверены? Modbus RTU? Какие счётчики (модель) стоят?

насколько я разбираюсь приборы идут как slave устройства, cpm713 как master, связь выполнена экранированным двухпроводным кабелем

Учёт коммерческий?

учет внутренний, более того нет необходимости писать что-либо в устройства, только читать holding registers

хотелось бы узнать можно ли как- нибудь оптимизировать данную систему, например через siemens s7-1200, есть некоторый опыт работы, либо еще как-то, и каковы будут примерно по стоимости коммерческие предложения?
Либо есть смысл разбираться и дорабатывать существующую систему?

[alex45]

Раскроем маленько тему

Ну вот с этого и надо было начинать. А то сидим тут, гадаем...

запрограммировать силами электротехнического персонала

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

и каковы будут примерно по стоимости коммерческие предложения?

Думаю, на этот вопрос здесь никто не ответит. Разрабатывайте тех. задание, направляйте потенциальным исполнителям, запрашивайте ТКП.

Либо есть смысл разбираться и дорабатывать существующую систему?

Наверное, это самый оптимальный вариант.

[misha_os]

Вопрос по линии RS485 протокол Modbus RTU 2 км, это работающая линия? Вроде бы линия не должна превышать 1000 м при минимальной скорости передачи данных.
Для CPU CPM713 среда разработки наверное Codesys v.2.3?
При подключении на одну линию RS485 устройств разных производителей можете получить разные нежданчики.
Все что касается разработки своими силами, это Вам виднее. Цены от других узнать, запросите ТКП у фирм которые этим занимаются.

[Mike[]]

Вопрос по линии RS485 протокол Modbus RTU 2 км, это работающая линия? Вроде бы линия не должна превышать 1000 м при минимальной скорости передачи данных.

там вроде как две параллельные линии, обьединяются на входе cpm713, по протяженности каждая под километр

Для CPU CPM713 среда разработки наверное Codesys v.2.3?

все верно, вот основная проблема в этом проекте разобраться, там циклический опрос устройств, и запись значений в opc server

как InTouch берет данные из opc c этим я думаю разберемся

[Jackson]

программа на decodesys

Логично. Раз есть Codesys, значит где-то должен быть и Decodesys. :)

хотелось бы узнать можно ли как- нибудь оптимизировать данную систему,

Наверняка. Вопрос - надо ли. А это решать только Вам.

каковы будут примерно по стоимости коммерческие предложения

Шлите запросы в соответствующие фирмы - тогда будут предложения. На форуме Вы их не найдёте.

Либо есть смысл разбираться и дорабатывать существующую систему?

Это Вам решать. Мы ещё даже задания-то не видели. Но силами имеющегося электроперсонала - забудьте. Каждый своим делом должен заниматься.

Вам данные куда девать надо в итоге? По какому каналу связи? Сколько всего точек измерения будет?

Я так понимаю, учёт технический. Если так то есть уйма измерителей которые в т.ч. и энергию считают, так что отдельные счётчики может и не нужны.

[Looker]

Вопрос по линии RS485 протокол Modbus RTU 2 км, это работающая линия?

1.2 км, при скорости 19200. Должно работать, все остальное как повезет. А, раз на раз, не приходится.

PS. Гоняли DH-485 (физика RS-485, а как протокол жестче, чем Modbus RTU, в части времени ответа) - 800 метров, из них петля около 270 градусов вокруг электродуговой печи. Кабель был Belden 9842.

[Jackson]

И ещё, полагаю что для диспетчерского мониторинга скорости 9600, которая реально может получиться на 2 километрах, для 17 устройств с количеством тэгов, приближающимся видимо к 1000 (сейчас почти 500), может быть недостаточно.

Показания счетчиков чаще чем раз в сутки вряд ли нужны. Остальное - Вам виднее.

Скорее всего всё упрется в медленную связь. Так что я бы занялся в 1 очередь им. Рядовым электроперсоналом это точно не под силу. Это АСУшников дело. Модернизированную Вашу систему надо будет обслуживать, это опять не электриков дело. Так что начинать следует с оргвопросов. Добавить АСУшника(ов) в штат, выделить им места и оклады, и уж они Вашу систему и пускай поднимают. Вот где ядро задачи, а не в контроллерах.

А что до связи - решите сколько должно быть АРМов, нужен ли архив данных и журналов. Если нет - с этим справится даже вейнтек, если нужны - СКАДА на ПК. Тут даже наша справится, специально и создавалась для ненагруженных объемом данных задач. Что на вейнтек что на скаду - проект надо сделать, железо купить. Для связи пойдёт сервер портов, возможно конверторы (я бы уже про оптику подумал на таких расстояниях, или о проводном Ethernet), или коммутаторы и шлюзы. Тут думать надо. Но в любом случае я бы не слишком усложнял.
А без контроллеров вообще можно обойтись, если задача стоит так как описано. Нечего тут контроллерам делать, лишняя головная боль только.

Если что-то связанное с генерацией, электроэнергетикой - у нас для этого есть кое-что.

[Andreywys]

У нас на 70 точек учёта, предложения были 700000-1000000.
Написали свою астуэ :)

[Jackson]

У нас на 70 точек учёта, предложения были 700000-1000000

Непонятно, что сюда входит, но в целом цена адекватна.

Написали свою астуэ :)

Рабочий день одного инженера стОит порядка 20 т.р. 700'000 - это примерно 35 рабочих дней одного инженера. Или 17 дней если вдвоём, или 11 если втроём, и т.д.
Вот и вспоминайте, сколько времени делали сами, плюсуйте затраты на документирование и сравнивайте, что в итоге оказалось бы дешевле. :)

АСТУЭ можно даже на облаке сделать. Помнится, делали такую, скрещивали с классической СКАДА - то есть данные с точек летели в облако, а потом в обычную БД, СКАДа брала данные из БД, а мониторинг на вспомогательных АРМах - из облака, причём вспомогательные АРМЫ - это смартфоны и планшеты у персонала: где б ты ни был - обстановку на объекте видишь. Но это были серьезные требования к хранению и доступу к архивным данным. Без таких требований можно только облаком обойтись. И СКАДА и облачный сервис и модемы у нас собственные. Так решилась проблема медленных интерфейсов на больших расстояниях - не пришлось оптику класть и Ethernet с промежуточными коммутаторами тоже не понадобился, так оказалось проще и дешевле.
Кстати на больших расстояниях что оптику класть что медь - одна и та же цена и затраты.

Отправлено спустя 11 минут 52 секунды:
Автору надо брать лист формата А3, карандаш и ластик и рисовать расположение точек с расстояниями и границами, строить интерфейсы, расставлять АРМы, подбирать железо и ПО и определять исполнителей каждого этапа. Если автор и этого не может, а полагает что всё это ляжет на местный подручный электроперсонал - он сильно ошибается и значит первым делом дорога либо за новыми штатными единицами либо в сторонние фирмы за решением под ключ включая монтаж и туда же за ТО, которое обязательно понадобится.

[misha_os]

Если хотите, разбираться в ценообразовании, тогда выставляйте соответствующие технические требования, этапы выполняемых работ и запрашивайте ТКП со сметой и по ней смотрите и прикидывайте что сколько стоит. Или сами осмечивайте данную работу и получите результат.

[olexsa]

Показания счетчиков чаще чем раз в сутки вряд ли нужны. Остальное - Вам виднее.

Все зависит от целей и задач этой системы.
Есть такая в эксплуатации (познания косвенные - не в моей зоне ответственности). Показания считываются каждые 5 минут.
Одна из целей - оптимизация энергозатрат. То есть минимизация потребления.

[Andreywys]

Непонятно, что сюда входит, но в целом цена адекватна.

Снимок.PNG

Рабочий день одного инженера стОит порядка 20 т.р. 700'000 - это примерно 35 рабочих дней одного инженера. Или 17 дней если вдвоём, или 11 если втроём, и т.д.
Вот и вспоминайте, сколько времени делали сами, плюсуйте затраты на документирование и сравнивайте, что в итоге оказалось бы дешевле. :)

Рабочий день "своего" инженера стоит немного меньше. Я тоже за этот подход, что время инженера стоит денег, но есть еще желание самого инженера освоить что-то новое и применить/развить некоторые свои навыки. А если это еще потом мотивировать какой-то премией за экономию, то всем хорошо. Делалось все в свободное от работы время вдвоем по вечерам около полугода. Развивалось как pet проект.

Снимок.PNG

[Jackson]

Рабочий день "своего" инженера стоит немного меньше.

А Вы посчитайте сначала. Одинаковых цифр быть не может, везде всё своё, но порядок такой.
Впрочем, это Ваш бизнес. :) Дело личное.

но есть еще желание самого инженера освоить что-то новое и применить/развить некоторые свои навыки.

Вообще-то, это его обязанность согласно должностной инструкции.

Отправлено спустя 3 минуты 54 секунды:
И кстати, у автора своих инженеров нет ни штуки.

[Andreywys]

Впрочем, это Ваш бизнес. :)

К сожалению, не мой :)

Вообще-то, это его обязанность согласно должностной инструкции.

Если это записано в должностной инструкции.

И кстати, у автора своего инженера нет ни штуки.

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

[Jackson]

К сожалению, не мой :)

И это тоже дело личного отношения. А от этого и расчёт стоимости рабочего времени очень сильно зависит.

Если это записано в должностной инструкции.

А это там записано, если взяли типовую и особо не придумывали. Мониторить новые разработки, их осваивать и применять инженер обязан. Иначе он может клепать релейные схемы и строить ламповые АВМ, не дуя в ус. Посмотрите, полезно иногда вспомнить за что деньги платят. :)

Опыт я получил полезный, но работа заняла очень много времени.

Вот об этом и речь.

Впрочем это всё - уже далеко от вопроса автора.

[Profa]

Здравствуйте. По непонятным причинам и несистемно статус Opc сервера переходит в режим suspend (приостановлен). в чем может быть причина?