YarrowSoft

Архив : Автоматизация технологических процессов, системы управления промышленными установками, информационно-измерительные системы

Ближайшие найденные письма:

[Предыдущее - нет] [Следующее - нет]

Письма за один день 26 Июля 2005 с 31 -54 из 54

Письмо #2899

Тема: [asutp] Проблема с панелью оператора EBelt 240. Подскажите пожалуйста!
Начало этой темы: [asutp] Проблема с панелью оператора EBelt 240. Подскажите пожалуйста!
Это ответ на: нет
Ответ на это письмо: нет
От: indian Дата: 26 Июля 2005 18:19

Панель оператора EBelt 240, находится в сети PROFIBAS с контроллером
S7-300, также в сети стоят частотники.

После включения установки, примерно 4-6 минут горит на контроллере BF на
панели тоже горит BF панель находится в режиме теста (горят все диоды),
затем кратковременно тухнут, потом загораются... так происходит минуты 3,
затем BF гаснет и панель запускается.

Подскажите пожалуйста, что может быть с профибасом?

----
E-mail автора: E-Mail
(по данным регистрации на iprog.pp.ru/forum)


Письмо #2898

Тема: RE: [asutp] Распределенная система АСУ через GSM
Начало этой темы: RE: [asutp] Распределенная система АСУ через GSM
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 18:40

Не хочу рекламировать, но рассмотрите похожий проект:

http://www.industrialsystems.ru/solutions.asp?div
=telepipe

Работает (я им занимался, будучи в стане Заказчика) много лет в очень
суровых условиях. Доступ к большей части КП был только летом, да и то пешком
(дорогу размывало). Зимой- только вездеходом, да и то пару раз всего за 3
года (моего участия).

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

Уточнение: насосов на объектах от четырех до восьми - по -опыту знаю.
Постоянных каналов связи нет и не предвидится.
Все находится в пойме в лесу. Любые линии связи обслуживать почти
невозможно.
Программа автоматического регулирования контроллером если и нужна будет ,
то не скоро.
Вопрос в деньги упирается.


Письмо #12251

Тема: RE: [asutp] Распределенная система АСУ через GSM
Начало этой темы: RE: [asutp] Распределенная система АСУ через GSM
Это ответ на: Re: [asutp] Распределенная система АСУ через GSM
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 18:40

Не хочу рекламировать, но рассмотрите похожий проект:

http://www.industrialsystems.ru/solutions.asp?div
=telepipe

Работает (я им занимался, будучи в стане Заказчика) много лет в очень
суровых условиях. Доступ к большей части КП был только летом, да и то пешком
(дорогу размывало). Зимой- только вездеходом, да и то пару раз всего за 3
года (моего участия).

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

Уточнение: насосов на объектах от четырех до восьми - по -опыту знаю.
Постоянных каналов связи нет и не предвидится.
Все находится в пойме в лесу. Любые линии связи обслуживать почти
невозможно.
Программа автоматического регулирования контроллером если и нужна будет ,
то не скоро.
Вопрос в деньги упирается.


Письмо #2897

Тема: RE: [asutp] СУБД РВ - очередной маркетинговый ход?
Начало этой темы: RE: [asutp] СУБД РВ - очередной маркетинговый ход?
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Власов Дата: 26 Июля 2005 19:49

Здравствуйте, Дмитрий!

>> Дмитрий, насколько я понимаю в этой теме, то в InSQL (как и в другом
>> подобном ПО под довольно стандартным названием Historian), реляционные БД
>> используются =только= лишь для хранения настроек и предоставления данных. >>
И не участвуют в сборе информации и ее архивации.

Как я это знаю: сбором занимаются интерфейсы (сервера ввода/вывода), за
фильтрацию отвечает программная прослойка, хранением занимается MS SQL.
Отсутствие фильтрации на стороне интерфейса приводит к увеличению сетевого
трафика. Все значения данных хранятся MS SQL (в таблицах Runtime.*History и
Runtime.*Live). Что интересно, выборка данных из InSQL  реализована несколько
странно: в стандартных SQL запросах не допускается применять математические или
текстовые функции, нельзя применять GROUP BY, ORDER BY. Все запросы
перенаправляются MSSQL. Есть API, но это лишь обертка для SQL запросов, поэтому
функциональности не добавляет.

Еще один аспект. InSQL работает, как и положено надстройке над СУРБД, в
архитектуре клиент-сервер. Т.е. нужно мне (клиенту) данные - я прошу сервер - он
мне их дает. Пока я его не спрошу - не узнаю, что данные изменились. Другой
вариант архитектура подписка-уведомление. При изменении интересующих меня данных
сервер сам присылает мне уведомление. Такой подход впервые реализован только в
MS SQL 2005 + MTS (среди MS SQL).

>> Ну в самом деле- не придумывать же для такой стандартной задачи свою
>> собственную СУБД со всеми вытекающими по разработке, поддержке и т.п.
>> (что несомненно удорожает продукт) :)

Сопровождать СУБД все равно придется. Не Microsoft же будет ее сопровождать.  А
продавать собственный _серийный_ продукт было всегда выгоднее, чем платить за
лицензию чужого. В самом деле InSQL не использует всей мощи MS SQL, мало того,
еще и урезает пользователя. Хотя он (пользователь) платит деньги за все.
Microsoft ведь не выпускала специальную урезанную версию своего сервера
специально под нужды Wonderware и по специальной цене. Конечно, использовать
чужой, пусть не совсем подходящий продукт, проще. Пользователь платит лишние
деньги, но это его проблемы.

Я, Дмитрий, с Вами полностью согласен относительно PI. Действительно
единственная система отвечающая моим представлениям о СУБД РВ. Хотя PI скорее
MES; как по классу решаемых задач, так и по цене.

---
С уважением,
Дмитрий Власов mailto:E-Mailrom.ru


Письмо #12250

Тема: RE: [asutp] СУБД РВ - очередной маркетинговый ход?
Начало этой темы: RE: [asutp] СУБД РВ - очередной маркетинговый ход?
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Власов Дата: 26 Июля 2005 19:49

Здравствуйте, Дмитрий!

>> Дмитрий, насколько я понимаю в этой теме, то в InSQL (как и в другом
>> подобном ПО под довольно стандартным названием Historian), реляционные БД
>> используются =только= лишь для хранения настроек и предоставления данных. >>
И не участвуют в сборе информации и ее архивации.

Как я это знаю: сбором занимаются интерфейсы (сервера ввода/вывода), за
фильтрацию отвечает программная прослойка, хранением занимается MS SQL.
Отсутствие фильтрации на стороне интерфейса приводит к увеличению сетевого
трафика. Все значения данных хранятся MS SQL (в таблицах Runtime.*History и
Runtime.*Live). Что интересно, выборка данных из InSQL  реализована несколько
странно: в стандартных SQL запросах не допускается применять математические или
текстовые функции, нельзя применять GROUP BY, ORDER BY. Все запросы
перенаправляются MSSQL. Есть API, но это лишь обертка для SQL запросов, поэтому
функциональности не добавляет.

Еще один аспект. InSQL работает, как и положено надстройке над СУРБД, в
архитектуре клиент-сервер. Т.е. нужно мне (клиенту) данные - я прошу сервер - он
мне их дает. Пока я его не спрошу - не узнаю, что данные изменились. Другой
вариант архитектура подписка-уведомление. При изменении интересующих меня данных
сервер сам присылает мне уведомление. Такой подход впервые реализован только в
MS SQL 2005 + MTS (среди MS SQL).

>> Ну в самом деле- не придумывать же для такой стандартной задачи свою
>> собственную СУБД со всеми вытекающими по разработке, поддержке и т.п.
>> (что несомненно удорожает продукт) :)

Сопровождать СУБД все равно придется. Не Microsoft же будет ее сопровождать.  А
продавать собственный _серийный_ продукт было всегда выгоднее, чем платить за
лицензию чужого. В самом деле InSQL не использует всей мощи MS SQL, мало того,
еще и урезает пользователя. Хотя он (пользователь) платит деньги за все.
Microsoft ведь не выпускала специальную урезанную версию своего сервера
специально под нужды Wonderware и по специальной цене. Конечно, использовать
чужой, пусть не совсем подходящий продукт, проще. Пользователь платит лишние
деньги, но это его проблемы.

Я, Дмитрий, с Вами полностью согласен относительно PI. Действительно
единственная система отвечающая моим представлениям о СУБД РВ. Хотя PI скорее
MES; как по классу решаемых задач, так и по цене.

---
С уважением,
Дмитрий Власов mailto:E-Mailrom.ru


Письмо #2896

Тема: RE: [asutp] СУБД РВ - очередной маркетинговый ход?
Начало этой темы: RE: [asutp] СУБД РВ - очередной маркетинговый ход?
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 20:04

Дмитрий, согласен в какой-то мере по InSQL, но не нем одном свет клином
сошелся. Да и задачи все же подобного класса продукты выполняют достаточно
определенные и узкие- чтож от них требовать чего-то большего?
Мне вот странно, что под Oracle (вместо MS SQL) ничего нет подобного, но это
маркетинг...

А что касается PI как MES - ой нет, посоветовал здесь быть очень осторожным
с терминами. Ну, в каком-то приближении- отдельные модули- да, но без модуля
оперативного планирования...PI довольно узко будет. Да и работы масса по
доведению PI до MES. Дешевле в итоге будут другие производители.

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

Сопровождать СУБД все равно придется. Не Microsoft же будет ее сопровождать.
А
продавать собственный _серийный_ продукт было всегда выгоднее, чем платить
за
лицензию чужого. В самом деле InSQL не использует всей мощи MS SQL, мало
того,
еще и урезает пользователя. Хотя он (пользователь) платит деньги за все.
Microsoft ведь не выпускала специальную урезанную версию своего сервера
специально под нужды Wonderware и по специальной цене. Конечно, использовать
чужой, пусть не совсем подходящий продукт, проще. Пользователь платит лишние
деньги, но это его проблемы.

Я, Дмитрий, с Вами полностью согласен относительно PI. Действительно
единственная система отвечающая моим представлениям о СУБД РВ. Хотя PI
скорее
MES; как по классу решаемых задач, так и по цене.


Письмо #12249

Тема: RE: [asutp] СУБД РВ - очередной маркетинговый ход?
Начало этой темы: RE: [asutp] СУБД РВ - очередной маркетинговый ход?
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 20:04

Дмитрий, согласен в какой-то мере по InSQL, но не нем одном свет клином
сошелся. Да и задачи все же подобного класса продукты выполняют достаточно
определенные и узкие- чтож от них требовать чего-то большего?
Мне вот странно, что под Oracle (вместо MS SQL) ничего нет подобного, но это
маркетинг...

А что касается PI как MES - ой нет, посоветовал здесь быть очень осторожным
с терминами. Ну, в каком-то приближении- отдельные модули- да, но без модуля
оперативного планирования...PI довольно узко будет. Да и работы масса по
доведению PI до MES. Дешевле в итоге будут другие производители.

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

Сопровождать СУБД все равно придется. Не Microsoft же будет ее сопровождать.
А
продавать собственный _серийный_ продукт было всегда выгоднее, чем платить
за
лицензию чужого. В самом деле InSQL не использует всей мощи MS SQL, мало
того,
еще и урезает пользователя. Хотя он (пользователь) платит деньги за все.
Microsoft ведь не выпускала специальную урезанную версию своего сервера
специально под нужды Wonderware и по специальной цене. Конечно, использовать
чужой, пусть не совсем подходящий продукт, проще. Пользователь платит лишние
деньги, но это его проблемы.

Я, Дмитрий, с Вами полностью согласен относительно PI. Действительно
единственная система отвечающая моим представлениям о СУБД РВ. Хотя PI
скорее
MES; как по классу решаемых задач, так и по цене.


Письмо #2895

Тема: Re[2]: [asutp] Распределенная система АСУ через GSM
Начало этой темы: [asutp] Распределенная система АСУ через GSM
Это ответ на: Re: [asutp] Распределенная система АСУ через GSM
Ответ на это письмо: нет
От: Alexander Burmistrov Дата: 26 Июля 2005 20:20

Здравствуйте, Дручинин Валерий!

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

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

С уважением,
Александр Бурмистров,
KASKAD group,
http://www.kaskadgroup.ru


Письмо #2894

Тема: Re: [asutp] Распределенная система АСУ через GSM
Начало этой темы: Re: [asutp] Распределенная система АСУ через GSM
Это ответ на: нет
Ответ на это письмо: нет
От: indian Дата: 26 Июля 2005 22:21

У "ЕТ-Автоматика"
http://et-a.ru
есть типовое решение подобной проблемы.
Называется "мониторинг удаленных объектов". На объекте стоит
микроконтроллер с GSM-модемом (Siemens). Обмен SMS-сообщениями. Отправка
контроллером по возникновению события (изменение конроллируемого
параметра), диспетчером - по необходимости. Контроллер принимает сообщение
только от абонентов из списка - отправлять может в т.ч. и на несколько
объектов. Для дискретных сигналов, при использовании GSM связи, считаю
такой способ самым эффективным. Первая реализация была на Богословском
алюминиевом - контроль шламонасосных станций. Уровень диспетчерской был
выполнен на InTouch. Позже посчитали, что это дороговато и сделали
собственную программу, позволяющую использовать любую "подложку" (карту,
план местности etc.), имеющую три уровня детализации и настройку на объект
контроля.  Сейчас на этом решении реализуется даже контроль лифтов жилого
дома, с обеспечением двусторонней связи :)
Минимальная конфигурация из реализованных - контроллер M9019B1A
(Unitronics), 10 DI (pnp), 6 RO. В нашем случае один из входов завязан" на
импульсный счетчик электроэнергии, для возможности дистанционного "снятия"
показаний (требование заказчика). Используемый контроллер хорош еще и тем,
что его можно перепрограммировать не выезжая на объект.
С уважением,
Владимир Широков

----
E-mail автора: E-Mail
(по данным регистрации на iprog.pp.ru/forum)


Письмо #2891

Тема: [asutp] уточнение
Начало этой темы: [asutp] уточнение
Это ответ на: нет
Ответ на это письмо: RE: [asutp] уточнение
От: egorov Дата: 26 Июля 2005 22:38

Добрый день, Дмитрий, мне очень приятно, что Вам нравится наша рубрика
"Круглый стол". Приглашаем  и Вас принять участие в дискуссии "Круглого
стола" на интересующую Вас тему.
Огромное спасибо, что Вы повысили меня в должности, но главный редактор у
нас Корнеева Алла Ильинична.

С уважением, зам. главного редактора
журнала "Промышленные АСУ и контроллеры"
Егоров Александр Александрович
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

"Промышленные АСУ и контроллеры"  
http://www.asucontrol.ru

Издательство "Научтехлитиздат"          
http://www.tgizdat.ru


----- Original Message -----
From: "Дмитрий Милосердов" <E-Mail>
To: <E-Mail>
Sent: Monday, July 25, 2005 4:20 PM
Subject: [asutp] Плагиаторы :)


>В очень хорошем смысле этого слова. Сейчас журнал Пром АСУ и Контроллеры
> принесли, в которой моя любимая рубрика Круглый стол. Читаю и улыбаюсь :)
>
> Мой респект Александру Александровичу Егорову, как ведущему этой рубрики и
> главреду журнала!
>
> --
> С уважением,
> Дмитрий Н. Милосердов                          mailto:E-Mail
> Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ
>
>
>
> Yahoo! Groups Links
>
>
>
>
>


Письмо #2893

Тема: Re: [asutp] Компиляторы на C/C++ под однокристальные процессоры
Начало этой темы: Re: [asutp] Компиляторы на C/C++ под однокристальные процессоры
Это ответ на: нет
Ответ на это письмо: нет
От: indian Дата: 26 Июля 2005 22:55

Алексей, а что делать, если указанный вами форум (телесис) невозможно
читать из-за кучи флейма? Может, разрешите все же поддержать тему?
Если кто знает, откуда можно скачать демо этого софта (для 8051)? На
кейле.ком чо то я в трех соснах не разберусь.
И еще буду рад, если кто подскажет ссылку на учебный материал на русском
языке, в том числе по прототипам функций и конфигу контроллера. Хочу
перескочить с асмы, достала.
Спасибо.
Можно ответить на мыло.

----
E-mail автора: E-Mail
(по данным регистрации на iprog.pp.ru/forum)


Письмо #2892

Тема: Re: [asutp] Распределенная система АСУ через GSM
Начало этой темы: Re: [asutp] Распределенная система АСУ через GSM
Это ответ на: нет
Ответ на это письмо: Re[2]: [asutp] Распределенная система АСУ через GSM
От: Андрей Мурашко Дата: 26 Июля 2005 23:00

Уважаемый Александр !
     Для реализации конкретного вопроса , желательно взять что-то , что
работает.
Пусть даже не глобально , не так универсально, но быстро. Людям надо
помочь.

Ну а что касается системы то передача данных через GPRS на мой взгляд
имеет будущее.
Конечно не считая военных применений.

Идет мобильная связь в самые отдаленные углы.

Качество неуклонно будет повышаться. Там и третье поколение сетей не за
горами.
А использование обычных сотовых  телефонов позволит дешево и оперативно
догонять прогресс. Ведь любой модем стоит куда дороже чем навороченный
смартфон с операционкой и пр. Да и задачи не такие дорогие.

   С уважением...

----
E-mail автора: E-Mail
(по данным регистрации на iprog.pp.ru/forum)


Письмо #2890

Тема: Re: [asutp] Распределенная система АСУ через GSM
Начало этой темы: Re: [asutp] Распределенная система АСУ через GSM
Это ответ на: нет
Ответ на это письмо: нет
От: Андрей Мурашко Дата: 26 Июля 2005 23:07

Уважаемый Владимир !

    Если можно по вашей системе дайте информацию. Как вариант я размышлял
о такой возможности работать через SMS.

Можно ли ее модифицировать для работы с телефоном?
Собственно, модем в нем  есть.

Ну и практические вопросы по цене...

С уважением...

----
E-mail автора: E-Mail
(по данным регистрации на iprog.pp.ru/forum)


Письмо #2889

Тема: Re: [asutp] Распределенная система АСУ через GSM
Начало этой темы: Re: [asutp] Распределенная система АСУ через GSM
Это ответ на: нет
Ответ на это письмо: RE: [asutp] Распределенная система АСУ через GSM
От: Андрей Мурашко Дата: 26 Июля 2005 23:15

Уважаемый Дмитрий!

Я тоже сторонник правильного подхода к созданию технических систем.
Проблема только что обеспечение этого подхода , зачастую, дороже самой
проблемы.
Да и обсудить варианты лучше не имея готового рецепта.
А уж когда вариант отобран, тех задание просто необходимо. Не однократно
на моих глазах точка зрения заказчика менялась, по мере реализации
проекта.
Вот тут то и нужен ГОСТ.
   А пока поговорим...

  С уважением...

  (E-Mail)


Письмо #2888

Тема: RE: [asutp] уточнение
Начало этой темы: RE: [asutp] уточнение
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 23:23

Добрый день, Александр Александрович,

Да, с должностью я немного промахнулся (меня Виталий Семенович уже
поправил). По поводу приглашения- что касается данной темы, то мнение свое я
уже неоднократно выражал и оно на 100% совпадает с мнением Вашего
"Специалиста А" :)
Поучаствовать в других дискуссиях не против, большое спасибо за приглашение.

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

Добрый день, Дмитрий, мне очень приятно, что Вам нравится наша рубрика
"Круглый стол". Приглашаем  и Вас принять участие в дискуссии "Круглого
стола" на интересующую Вас тему.
Огромное спасибо, что Вы повысили меня в должности, но главный редактор у
нас Корнеева Алла Ильинична.


Письмо #12248

Тема: RE: [asutp] уточнение
Начало этой темы: RE: [asutp] уточнение
Это ответ на: [asutp] уточнение
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 23:23

Добрый день, Александр Александрович,

Да, с должностью я немного промахнулся (меня Виталий Семенович уже
поправил). По поводу приглашения- что касается данной темы, то мнение свое я
уже неоднократно выражал и оно на 100% совпадает с мнением Вашего
"Специалиста А" :)
Поучаствовать в других дискуссиях не против, большое спасибо за приглашение.

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

Добрый день, Дмитрий, мне очень приятно, что Вам нравится наша рубрика
"Круглый стол". Приглашаем  и Вас принять участие в дискуссии "Круглого
стола" на интересующую Вас тему.
Огромное спасибо, что Вы повысили меня в должности, но главный редактор у
нас Корнеева Алла Ильинична.


Письмо #2887

Тема: [asutp] Re: Массовые расходомеры SIEMENS
Начало этой темы: [asutp] Re: Массовые расходомеры SIEMENS
Это ответ на: нет
Ответ на это письмо: RE: [asutp] Re: Массовые расходомеры SIEMENS
От: kavlaskin Дата: 26 Июля 2005 23:32

> Мне кажется Вы несколько заблуждаетесь.> Механическая инерция не как не зависит от свойств сжимаемости, текучести,> хрупкости и пр. Как Вы думаете: что тяжелее(инерционнее) килограмм железа или> килограмм пуха? ;)Ну а как вы думаете, в каком случае воздействие будет сильнее если по неосторожности килограмм железа или пуха выскользнет из рук и упадёт на ногу.   
С Уважением,Константин Власкин


Письмо #2886

Тема: RE: [asutp] Распределенная система АСУ через GSM
Начало этой темы: RE: [asutp] Распределенная система АСУ через GSM
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 23:35

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

Варианта всего 2 на мой взгляд:
1. "классическая" телемеханика с радиосвязью. Имеет ряд минусов (стоимость и
проблемы с выбиванием частот), но зато очень надежна и обкатана.
2. Новые веяния мобильной связи- на мой взгляд решение красивое и дешевое,
но критичное в плане устойчивости связи + легкой возможности потери данных.
Опять же - критично к скорости передачи. Лично я пока подхожу к этому
варианту очень настороженно, но это ИМХО. Связь оставляет желать лучшего, да
и операторы сотовой связи ничего не гарантируют и главное- ни за что не
отвечают. Сколько раз было - Новый год = полная невозможность куда-либо
дозвониться в течение нескольких часов. Любой теракт (тьфу 3 раза)-
аналогично.
В общем, минусов пока больше, чем плюсов. На месте Заказчика я бы не стал
рисковать. Но это опять же сугубо ИМХО.

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

Я тоже сторонник правильного подхода к созданию технических систем.
Проблема только что обеспечение этого подхода , зачастую, дороже самой
проблемы.
Да и обсудить варианты лучше не имея готового рецепта.
А уж когда вариант отобран, тех задание просто необходимо. Не однократно
на моих глазах точка зрения заказчика менялась, по мере реализации
проекта.
Вот тут то и нужен ГОСТ.
   А пока поговорим...


Письмо #12247

Тема: RE: [asutp] Распределенная система АСУ через GSM
Начало этой темы: RE: [asutp] Распределенная система АСУ через GSM
Это ответ на: Re: [asutp] Распределенная система АСУ через GSM
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 23:35

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

Варианта всего 2 на мой взгляд:
1. "классическая" телемеханика с радиосвязью. Имеет ряд минусов (стоимость и
проблемы с выбиванием частот), но зато очень надежна и обкатана.
2. Новые веяния мобильной связи- на мой взгляд решение красивое и дешевое,
но критичное в плане устойчивости связи + легкой возможности потери данных.
Опять же - критично к скорости передачи. Лично я пока подхожу к этому
варианту очень настороженно, но это ИМХО. Связь оставляет желать лучшего, да
и операторы сотовой связи ничего не гарантируют и главное- ни за что не
отвечают. Сколько раз было - Новый год = полная невозможность куда-либо
дозвониться в течение нескольких часов. Любой теракт (тьфу 3 раза)-
аналогично.
В общем, минусов пока больше, чем плюсов. На месте Заказчика я бы не стал
рисковать. Но это опять же сугубо ИМХО.

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

Я тоже сторонник правильного подхода к созданию технических систем.
Проблема только что обеспечение этого подхода , зачастую, дороже самой
проблемы.
Да и обсудить варианты лучше не имея готового рецепта.
А уж когда вариант отобран, тех задание просто необходимо. Не однократно
на моих глазах точка зрения заказчика менялась, по мере реализации
проекта.
Вот тут то и нужен ГОСТ.
   А пока поговорим...


Письмо #2885

Тема: RE: [asutp] Re: Массовые расходомеры SIEMENS
Начало этой темы: RE: [asutp] Re: Массовые расходомеры SIEMENS
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 23:39

Константин, при чем тут нога? :) Кориолисы измеряют массовый расход. Потому
не важно- чего именно. И газ и жидкость одинаково свободно текут в трубе,
разница лишь в объеме. Физика однако...

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

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


Письмо #12246

Тема: RE: [asutp] Re: Массовые расходомеры SIEMENS
Начало этой темы: RE: [asutp] Re: Массовые расходомеры SIEMENS
Это ответ на: [asutp] Re: Массовые расходомеры SIEMENS
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 23:39

Константин, при чем тут нога? :) Кориолисы измеряют массовый расход. Потому
не важно- чего именно. И газ и жидкость одинаково свободно текут в трубе,
разница лишь в объеме. Физика однако...

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

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


Письмо #2883

Тема: RE: [asutp] Re: Массовые расходомеры SIEMENS
Начало этой темы: RE: [asutp] Re: Массовые расходомеры SIEMENS
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 23:42

Или сам кориолисовый расходомер выскользнет из рук :)
А он, бывает, весит килограмм до 600- в зависимости от расхода...
Представили себе, что после этого будет с ногой? :) Опасная вещь...

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

А тем более, если этот килограмм выскользнет не из рук, а из кориолисова
расходомера!.. :-)))))))))))


Письмо #12245

Тема: RE: [asutp] Re: Массовые расходомеры SIEMENS
Начало этой темы: RE: [asutp] Re: Массовые расходомеры SIEMENS
Это ответ на: нет
Ответ на это письмо: нет
От: Дмитрий Милосердов Дата: 26 Июля 2005 23:42

Или сам кориолисовый расходомер выскользнет из рук :)
А он, бывает, весит килограмм до 600- в зависимости от расхода...
Представили себе, что после этого будет с ногой? :) Опасная вещь...

--
С уважением,
Дмитрий Н. Милосердов                          mailto:E-Mail
Начальник Управления АСУ ТП Дирекции по ИТ ОАО ВМЗ

А тем более, если этот килограмм выскользнет не из рук, а из кориолисова
расходомера!.. :-)))))))))))


Письмо #2884

Тема: RE: [asutp] Re: Массовые расходомеры SIEMENS
Начало этой темы: RE: [asutp] Re: Массовые расходомеры SIEMENS
Это ответ на: нет
Ответ на это письмо: нет
От: Shchekin Sergey I. Дата: 26 Июля 2005 23:44

> -----Original Message-----
> From: E-Mail [mailto:E-Mail] On
> Behalf Of kavlaskin
> Sent: Tuesday, July 26, 2005 3:32 PM

> Ну а как вы думаете, в каком случае воздействие будет сильнее если по
> неосторожности килограмм железа или пуха выскользнет из рук и
> упадёт на
> ногу.   

А тем более, если этот килограмм выскользнет не из рук, а из кориолисова расходомера!.. :-)))))))))))

С уважением,
Сергей Щекин
TRICONEX


Страницы: [1|2]

[2001|2002|2003|2004|2005|2006|2007|2008] [Январь|Февраль|Март|Апрель|Май|Июнь]
[01|02|03|04|05|06|07|08]