Тогда вымотаются люди, которым прийдется делать двойную работу (и прототип и продукт).
Ну и двойная работа — это время х 2. А за двойное время заказчик на котлеты пустит.
Разговор был не о ценах, а о новых функционале и ПО, которые «нужны вчера».
Но полное понимание нового ПО и нового функционала — оно приходит только с опытом работы на этом новом ПО с новым функционалом.
Изначально же опыт в данном вопросе по определению равен 0.
Поэтому приступать к задаче — получается нельзя? :)
С одной стороны факт — конкуренция вынуждает к использованию нового ПО с новым функционалом.
С другой стороны совет — приступай к задаче после полного ее понимания и используй только проверенный код.
По моему противоречащие друг-другу вещи.
Либо новое ПО с новым функционалом, либо все понятно и отлажено на куче обьектов…
Нет?
У нас лет 7 назад были метания в этом направлении. В конечном итоге остановились на секундах.
Милисекунды излишне точно, минуты на каком-то из обьектов для эксплуатации показались недостаточно точными…
Не ГОСТ конечно, но менять все равно не очень хочется :)
Да и визуализация — она все-таки IMHO вторична.
Если ПЛК работает, но не отображает на АРМ состояния — это пол беды.
Гораздо хуже если он отображает всё корректно, но работает не так, как надо.
Поэтому упор был именно на алгоритмы, а вывод на экран добивался в конце, по мере сил.
Несанкционированный АО агрегата — это сильно.
Могу только посочувствовать.
А подтверждения от сменных операторов?
> Выделили бы под время 2 байта с жестким ограничением и их хватило бы всем :)
Так один байт — уже был чуть ли не с двойным запасом :)
Старое оборудование 1970 кажется года наложило свои коррективы.
Просто чем старше обьект, тем порой больше в нем самопального и неожиданного…
Там же, если память не изменяет, подготовились к насосной станции (десяток водяных насосов + что-то по мелочи), приехали, развернулись… и с любопытством обнаружили, что порядка 3 лет назад вместо части насосов, местные протащили небольшую трубу к соседнему обьекту.
Долго бегал там с бумагами, согласовывал новые алгоритмы, призывал на головы проектировщиков всякое страшное…
В общем как говорил один знакомый: знал бы где упаду — соломы было-бы до горизонта :)
> И на этапе тестирования полезно погонять с максимальными-минимальными значениями, даже без железа, столько ошибок может вылезти.
Полностью согласен.
По поводу тестирования без железа правда есть нюансы.
У GE нет эмулятора ПЛК например.
> Какое оборудование и сеть, кстати, что идет битва за трафик?
GE Fanuc (в настоящее время GE) PAC Rx3i.
В общей сложности было порядка десяти CPU310.
Сеть — сотня.
Постоянно приходится учитывать, что следующим шагом возможно дальнейшее расширение системы, причем в непонятных объемах. Поэтому спокойнее бывает всё по возможности минимизировать, и не так сильно волноваться за будущее.
В общем получить необходимое и достаточное :)
Ну на то она и ошибка, чтобы быть какой-то не очень правильной :)
Программировались одновременно SCADA и ПЛК, часть ограничений была наверху, часть из-за кнопок в ПЛК.
Несогласованность.
В принципе можно было просто запретить ввод времен больше 255 секунд, и это было-бы самым правильным решением. Но эксплуатация спросила нечеловеческим голосом — Где мы вам новую механику возьмем, ироды?
И пришлось разбивать на 2 независимых слова.
Пожалуйста. Рад, что понравилось.
.
А ошибки связи — IMHO отдельная проблема.
Про связь часто забывается в первую очередь. И вспоминается в последнюю, когда все остальные варианты уже отброшены.
В общем наверное это можно обьяснить тем, что системный блок с гигабайтами ПО вызывает гораздо больше опасений, чем какой-то провод…
И провод этим ловко пользуется.
Ну и двойная работа — это время х 2. А за двойное время заказчик на котлеты пустит.
Но полное понимание нового ПО и нового функционала — оно приходит только с опытом работы на этом новом ПО с новым функционалом.
Изначально же опыт в данном вопросе по определению равен 0.
Поэтому приступать к задаче — получается нельзя? :)
С одной стороны факт — конкуренция вынуждает к использованию нового ПО с новым функционалом.
С другой стороны совет — приступай к задаче после полного ее понимания и используй только проверенный код.
По моему противоречащие друг-другу вещи.
Либо новое ПО с новым функционалом, либо все понятно и отлажено на куче обьектов…
Нет?
Милисекунды излишне точно, минуты на каком-то из обьектов для эксплуатации показались недостаточно точными…
Не ГОСТ конечно, но менять все равно не очень хочется :)
Да и визуализация — она все-таки IMHO вторична.
Если ПЛК работает, но не отображает на АРМ состояния — это пол беды.
Гораздо хуже если он отображает всё корректно, но работает не так, как надо.
Поэтому упор был именно на алгоритмы, а вывод на экран добивался в конце, по мере сил.
Несанкционированный АО агрегата — это сильно.
Могу только посочувствовать.
А подтверждения от сменных операторов?
Так один байт — уже был чуть ли не с двойным запасом :)
Старое оборудование 1970 кажется года наложило свои коррективы.
Просто чем старше обьект, тем порой больше в нем самопального и неожиданного…
Там же, если память не изменяет, подготовились к насосной станции (десяток водяных насосов + что-то по мелочи), приехали, развернулись… и с любопытством обнаружили, что порядка 3 лет назад вместо части насосов, местные протащили небольшую трубу к соседнему обьекту.
Долго бегал там с бумагами, согласовывал новые алгоритмы, призывал на головы проектировщиков всякое страшное…
В общем как говорил один знакомый: знал бы где упаду — соломы было-бы до горизонта :)
> И на этапе тестирования полезно погонять с максимальными-минимальными значениями, даже без железа, столько ошибок может вылезти.
Полностью согласен.
По поводу тестирования без железа правда есть нюансы.
У GE нет эмулятора ПЛК например.
> Какое оборудование и сеть, кстати, что идет битва за трафик?
GE Fanuc (в настоящее время GE) PAC Rx3i.
В общей сложности было порядка десяти CPU310.
Сеть — сотня.
Постоянно приходится учитывать, что следующим шагом возможно дальнейшее расширение системы, причем в непонятных объемах. Поэтому спокойнее бывает всё по возможности минимизировать, и не так сильно волноваться за будущее.
В общем получить необходимое и достаточное :)
Программировались одновременно SCADA и ПЛК, часть ограничений была наверху, часть из-за кнопок в ПЛК.
Несогласованность.
В принципе можно было просто запретить ввод времен больше 255 секунд, и это было-бы самым правильным решением. Но эксплуатация спросила нечеловеческим голосом — Где мы вам новую механику возьмем, ироды?
И пришлось разбивать на 2 независимых слова.
.
А ошибки связи — IMHO отдельная проблема.
Про связь часто забывается в первую очередь. И вспоминается в последнюю, когда все остальные варианты уже отброшены.
В общем наверное это можно обьяснить тем, что системный блок с гигабайтами ПО вызывает гораздо больше опасений, чем какой-то провод…
И провод этим ловко пользуется.