Цитата(@Ark @ Mar 26 2010, 15:46)
Тут дело не совсем в везении, хотя оно, конечно, никогда не лишнее.
С моей точки зрения, при построении системы, нужно стремиться, чтобы устройства и их ПО, не зависели от конкретной реализации каналов, которые они используют. По возможности, конечно. (Как-то дебатировали на эту тему с ув.
rezident-ом. Не найду уже, где.) Тогда можно, впоследствии, заменить каналы, без переделки системы, а иногда, и даже без перенастройки.
Угу. А вот скада. Времени ждать некогда. Послали запрос - нет ответа, пошли дальше и как правило за секунду порой надо пройти десяток приборов. На той системе, что сейчас смонтирована придется OPC сервер писать заново, как я называю - с поведеньицем, чтбы определял, что упал обмен и начать его восстанавливать. Пока честные порты были - все нормально. Я не смотрел какие моксы стоят, вернее смотрел, но пусть проектанты системы разбираются, как оно у них работает. (найду что там стояло - напишу). А как в канале что -то появилось, такой подход оказывается неприемлимым (и вообще говоря, оказывается, что никакая скада не будет работать по такому каналу). Более того на неделе общался с одним из разработчиком известной-преизвестной нашей скады. Так он мне говорит, а у нас один параметр по тайм ауту - общий для всех приборов на линии. Я ему - ай яй яй. Вот не знаю чем дело кончится, лепят они свое добро давно , стали наше железо подключать , а тут начало выясняться что не все гуд, как у нас (вернее у нас не гуд, потому что у софта все настраивается по самому медленному), но что страшнее - у них. Софт-то на объектах уже крутится по всей стране.
Пы Сы: Программистов, кто пишет без паяльника и осциллографа, поубивал бы.
виртуальный com порт, кто что пробовал
Mar 22 2010, 18:14
