Цитата(Сергей Долганов @ 9.10.2008, 17:23) [snapback]301002[/snapback]
Вот Вам и первый плюс профибаса с профинетом. Мне не нужен сторонний софт для создания сети. Если я соединяю к примеру мастер сименса и слейв другого производителя, мне нужен только STEP7, сиречь оболочка программирования контроллеров сименс.
Сторонний софт для создания единого проекта сети преследует некоторые важные цели:
- разделение труда между инженерами. Одни занимаются разработкой ПО устройств, а другие - интеграцией в сеть. В последнее время мировые тенденции таковы, что интеграторы могут не иметь особого образования, это очень важно при инсталляции крупных объектов, где требуется ОЧЕНЬ МНОГО инженерных ресурсов (и соответственно финансирования этих работ). В то время как большинство систем - шаблонные. Рекомендую посмотреть, что делают для этого Neuron Systems, в их схеме установки с сетей должен быть один хороший специалист, который создает шаблоны для инсталляций, а потом менее профессиональный состав занимается пуско-наладкой объекта.
- в связи с "шаблонностью" систем максимально актуальны функции copy-paste при создании сети, а также быстрое внесение изменений в уже установленную сеть. Предположим, в 200 похожих системах нужно заменить одну из связей между устройствами. При этом настройки контроллеров могут быть индивидуальны, просто они подгрузятся отдельно. А в Вашем случае придется ковырять программу под каждую конфигурацию контроллеров и еще содержать архив файлов для каждого из них (вместо единой базы сети). Потом см. выше про разделение труда. ИМХО по возможности не стоит в случае, когда задача решается на "менее квалифицированном" уровне (то бишь переконфигурация сети, возможно, изменение настроек Configuration properties на устройствах), залезать на более выский уровень (изменение ПО контроллеров). Это очень важно и при последующей эксплуатации проекта. Кстати в сетевых инструментариях LON есть разделение уровней доступа, что очень полезно.
Цитата
Это как плюс так и минус, быстрое программирование стандарных задач зачастую делает невозможным программирование не стандартных.
Скажем так, в 90 и более % случаев проблем с нестандартными задачами не возникает, соответстенно получается серьезная экономия, см. выше про разделение труда.
Цитата
Не так уж дороги маленькие тачскрины нонче.
Много ли тач-скринов, которые Заказчику (т.е. с учетом накрутки цены поставщиком) обойдутся до 300 евро и устроят по дизайну? Учтем еще и источник питания, и какую-то коробку для его размещения (равно как и место для размещения и подвод питания), в то время как в KNX и LON'е куча панелек с питанием от линии.
Да и надо ли ставить тач-скрин, когда нужно 4 кнопки управления и мониторинг температурной уставки? Да, большинство климатических панелек имеют встроенный датчик для измерения температуры воздуха. В случае тач-скрина нужен будет внешний датчик и соответственно где-то аналоговый вход для него. Если датчик сетевой, то добавляется узел сети.
Сразу оговорюсь, что эти факторы по-настоящему важны когда речь идет не о трех панельках на объект, а когда их десятки.
Цитата
Вобще цена это вопрос отдельный, не будем привязыватся к этому критерию потому как сравнение может оказаться не в пользу домушных протоколов (как раз из-за Вами же указаной простоты программирования).
Как раз к цене и надо привязываться в первую очередь, иначе это всё сплошная теория.
А теперь насчет простоты программирования. Если эту процедуру не сделал производитель, то ложится она на интегратора. И как следствие, в первом случае расходы по разработке ПО разделятся вообще на всех, кто покупает эти устройства, а во втором случае - только на данный проект.
Цитата(ggg__ggg @ 9.10.2008, 4:51) [snapback]300732[/snapback]
Отладка по сети ПО - удобно, но совсем не обязательно. Поясню. Отлаживать АЛГОРИТМЫ нужно находясь недалеко от оборудования, чтобы непосредственно наблюдать реакцию "железа". Проводить по сети диагностику системы или перенастройку - тоже проблематично по сети, т.к. тоже надо "живьем" наблюдать за реакцией.
За реакцией можно наблюдать по дистанционно передающемуся состоянию хардварных входов-выходов. Естественно при этом предварительно система должна быть хорошо прозвонена и налажена, в общем должна быть УВЕРЕННОСТЬ в том, что ничего страшного не произойдет.
У меня были случаи наладки систем, состоящих из нескольких контроллеров, навороченно связанных друг с другом по сети peer-to-peer и сильно разнесенных дистанционно (например, система электроснабжения с резервированием, единая на несколько корпусов объекта). При этом возникала необходимость понять, почему же соседние контроллеры не выдают ожидаемую реакцию, а по одним лишь SNVT догадаться в чем дело - нереально.
Вообще беготня по большому объекту в момент стройки (когда часть лифтов не работает, а другая часть вечно занята строителями, проход по коридору закрыт в связи с укладкой плитки, ключи от венткамеры - у дяди Феди, который, говорят, ушел на минус 2-й этаж не то в раздевалку обедать, не то в ЦТП, не то на склад, ) - отнимает очень много полезного времени, причем часто нужно сделать какую-то 3-минутную ерунду, ради которой убьется полчаса.
Когда создается проект комплексной автоматизации здания любые протоколы оказываются в равных условиях, потому что "с нуля" систему можно поднять на чем угодно.
) СРЕДСТВ ДИАГНОСТИКИ систем, в том числе собственно сети. Спорный аспект.
. Вы часто манипулируете словами, которые на кого-то естественно действуют, но это именно - манипуляции. К тому же, вместо того, чтобы последовательно и логично идти по пути нормального обсуждения, Вы, к сожалению, "расширяете поляну", нарушая последовательность диалога. Типичный пример с постом в котором Вы зачем-то упомянули видео системы???
Нет комментариев.
