Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Вопросы по приборам фирмы Логика (страница 28)

Версия для печати (настроить)
Тема закрыта  Тема закрыта (Valera). Страницы: 1 2 3 4 5 6 7 8 9 10 13 16 19 22 23 24 25 26 27 28 29 30 31 32 33 34 37 40 43 44 45 46 47 48 49 50

Новая тема | Тема закрыта

Подписаться

Автор Тема:   Вопросы по приборам фирмы Логика
Cadall
Junior Member

Сообщений: 1
Регистрация: Ноябрь 2010

написано 20 Ноября 2010 14:20ИнфоIP

Наболело!!!
Решил и я бросить свой камень в огород Логики. Имеется ПО и сервер MS SQL где хранятся данные с приборов. Но Логика не поддерживается. Пришлось самому кодить прогу которая считывает данные с СПТ и СПГ и сохраняет данные в отдельной базе. В связи со срочностью пошел по простейшему пути - с использованием DDE-серврера. Тем более, что для примера в СП-сеть имеется файл Exel. Сделал в VBA - работает. Начал делать полноценный продукт в Visual Studio - получил в ответ матек, смысл которого - "Ты че, мужик! DDE - полнейший отстой о котором мы уже забыли и больше не поддерживаем!" И ни какой альтернативы не предлагают.
Начал переписывать свое творение под OPC-сервер Логика. Но, VBA-шный продукт тем временем начал выдавать что-то невообразимое: СПТ961М. Магистраль на статике. Давление в прямой - около 1 МПа(избыточное). СПТ961М архивирует только абсолютное, т.е. около 1,1 МПа. А в базе данных сохраняется значение 40179 МПа!!! Это происходит в том случае, если давление равно точно 1,1. При малейшем отклонении от этой цифры проблема исчезает. При этом Пролог и СП-сеть считывают и отображают значение вполне корректно - 1,1 Мпа. Мало того, в окне транзакций СПсервера это принятое значение так-же 1,1 Мпа. Но в VBA передается АХИНЕЯ!!!
Быстренько переписал все в VB6 (поддерживает DDE) - результат - тот же самый
А где гарантии, что таких "мин" нет при других значениях параметров!???
Поэтому пишу сейчас прогу с опросом непосредственно через СОМ-порт. Минуя ОРС и DDE серверы. Значение 1,1 считывается нормально.
Но, верить тому, что написано в описании протокола СП-сети НЕЛЬЗЯ!!!
Подробно описывать всю лажу слишком долго. А если кратко - Все передается в текстовом формате, стаффинг отсутствует. Кратчайший путь - исследование запросов и ответов с использованием Portmon.exe Марка Русиновича. Проблема остается одна - варианты ответов приборов с сообщениями об ошибках. Они не так однозначны, как в описании.
Кстати, перевод с языка С на VB функции подсчета контрольной суммы (приведенной в описании) не работает!
И еще, в довесок: Даже при опросе по COM-порту приборы периодически "подвисают" (при считывании архивных данных один раз в час!). Поэтому тем, кто мечтает о диспетчеризации могу посоветовать: "Оставь надежды всяк..." их (приборы) получивший!!!
Уф-ф-ф... С облегчением!...

ivamat
Junior Member

Сообщений: 5
Откуда: Россия, СПб
Регистрация: Октябрь 2010

написано 21 Ноября 2010 23:32ИнфоIP

Слишком эмоционально. В целом не все так уж плохо, хотя не без проблем. Имеем 70 узлов на которых смонтированы тепловычислители от "Логика". Наверно уже лет 10 опрашиваем их удаленно. Так как этим занимаемся давно, со временем проблем становится меньше. Протоколы взаимодействия с тепловычислителем лежат на ресурсах производителя, а это главное. Пишется библиотека (драйвер) для взаимодействия и далее получаемые данные грузят в любую СУБД, обрабатываются по вкусу либо средствами СУБД, либо пишутся свои интерфесы для пользователей.

На мой взгляд существует глобальная проблема при работе с подобными устройствами. Уважающий себя производитель на мой взгляд должен (обязан) предоставлять библиотеки им же (производителем) и разработанные для пользователей своих устройств. Так же пора бы производителям тепловычислителей как то собраться вместе и договориться между собой о унификации протоколов. Однако, думается мне, рыночный подход этому не способствует, так что наверно этого не будет в обозримом будущем, а очень хотелось бы. Хотя бы рекомендации разработали (типа RFC) это было бы большим шагом на пути к унификации.

Архитектура подобного поделия (диспетчеризация) может быть примерно такой, пишется некое ядро, которое посылает запросы различным устройствам в соответствии с алгоритмом вас устраивающим. При опросе конкретного устройства подгружается соответствующая библиотека (драйвер устройства) который кодирует/декодирует запросы/ответы и загружает в СУБД. А там уже работа с данными по вкусу. Для программиста тут широкое поле для применения своих знаний и навыков, и работа с последовательным портом, и многопоточность, и СУБД, и написание интерфесов в общем интересная работа. Прошу прощения, не сочтите за флейм. А вот интересно, тут бывают сами разработчики тепловычислителей?

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

[Это сообщение изменил ivamat (изменение 21 Ноября 2010 23:56).]

Cadall
Junior Member

Сообщений: 2
Регистрация: Ноябрь 2010

написано 22 Ноября 2010 23:09ИнфоIP

Слишком эмоционально.
Я излил только малую толику эмоций. Да и то, только благодаря моей природной флегматичности.
В целом не все так уж плохо
"Все относительно", как говорил один мой приятель. Кажется его звали Альберт
Конечно было бы гораздо хуже, если бы не прилагались к приборам даже Руководства по эксплуатации.. А подробные описания протоколов, варианты ответов и пр. - это такая мелочь... О чем говорить!
Ну подвисают приборы периодически. Ну и что? Было бы гораздо хуже, если бы они вообще не отвечали...
А так зациклил прогу в опросе и сиди, кури бамбук. Когда-нибудь ответит... Сейчас уже сделал пятикратное повторение запрос-ответ. На всякий случай. Двух повторов бывает недостаточно. Увы...
Для программиста тут широкое поле для применения своих знаний и навыков, и работа с последовательным портом, и многопоточность, и СУБД, и написание интерфесов в общем интересная работа.
Согласен на все 100 !!!
А под диспетчеризацией я подразумевал постоянное считывание текущих (не архивных) значений параметров. А с такими зависаниями о чем можно вести речь? Хоть 100 потоков организуй - если приборы "сидят" на одном СОМ-порте - проку от этого нет ни какого.
Кстати, у вас для каждого из 70-и приборов свой персональный COM-порт выделен?
А разработчиков здесь не бывает. Не опускаются небожители до нас смертных.
Даже на оффсайте не изволят выложить инфу по-подробнее. Видел где-то там ссылку "... обращайтесь к Жесану по тел...". Обращался. Отвечает. На простейшие вопросы. Наверное нравится чувствовать себя нужным человеком.
Что-то я заболтался...
С уважением Cadall..

ivamat
Junior Member

Сообщений: 6
Откуда: Россия, СПб
Регистрация: Октябрь 2010

написано 23 Ноября 2010 14:45ИнфоIP

А под диспетчеризацией я подразумевал постоянное считывание текущих (не архивных) значений параметров.
Не совсем понимаю какие Вы решаете задачи, тем не менее, считаю что мгновенные значения не дают объективную информацию состоянии тепловой сети. В момент считывания Вы можете получить пиковые значения, которые, на мой взгляд нельзя считать достоверными. Более объективная информация это часовые архивы, это усредненные данные за час и выполняет это сам тепловычислитель. Вы тоже можете обрабатывать получаемую информацию, но достоверность будет лежать на Ваших плечах. Хотя, повторюсь, не знаю какие задачи Вы решаете.

Кстати, у вас для каждого из 70-и приборов свой персональный COM-порт выделен?
Тут тоже не совсем понятно, это ж сколько портов может понадобиться? Хотя все зависит от архитектуры сети и используемого транспорта. У нас применяется циклический опрос с использованием аналоговых модемов (коммутируемые линии связи) и опрос по сети (IP) через преобразователь интерфейсов Moxa 5110 в режиме Server IP, это устройство можно использовать и как виртуальный порт, тогда да, будет много портов. Однако в любом случае Вы работаете с тепловычислителем через последовательный порт.

Что касается зависания прибора, то этого не замечал. В основном проблемы с качеством линий связи (тефонные линии) По IP проблем вообще нет, подключил и забыл. Используем СПТ-941, 942, 943 есть и 961, по моему один остался. Есть приборы и от других производителей, но тут разговор про "Логику". Кстати, самые дрянные приборы это приборы от фирмы "Взлет". Это мое личное мнение.

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

[Это сообщение изменил ivamat (изменение 23 Ноября 2010 16:04).]

Unregistered
Junior Member

Сообщений: 8
Откуда: Нерюнгри, Россия
Регистрация: Июль 2010

написано 24 Ноября 2010 03:46ИнфоIP

в сети 6 приборов логика на одной шине. для считывания мгновенных данных используем opc-сервер. перешли на это дело около полугода назад, данные храним в mssqlserver. НИ ОДНОГО СБОЯ.

Cattel
Junior Member

Сообщений: 8
Регистрация: Сентябрь 2007

написано 24 Ноября 2010 09:06ИнфоIP

Уже несколько лет опрашиваем мгновенные с СПТ961 и иже с ними - зависаний замечено не было, все нормально. Пользуемся программой WORM. Все что написал ivamat - полностью согласен. Про Взлет правда не знаю - не пользовались, но отзывы действительно хреновые. В свое время мучился с ТБН КМ-5: хуже их протокола с отвратной реализацией не встречал. А Магистральный протокол Логики, по моему, вполне нормальный.

Cadall писал: "Проблема остается одна - варианты ответов приборов с сообщениями об ошибках. Они не так однозначны, как в описании." - это да, так и есть. Если нужен точный перечень ошибок - будет гемор.

ivamat
Junior Member

Сообщений: 7
Откуда: Россия, СПб
Регистрация: Октябрь 2010

написано 24 Ноября 2010 23:30ИнфоIP

В свое время мучился с ТБН КМ-5: хуже их протокола с отвратной реализацией не встречал.
Вот когда встречаешься с таким, то в голову порой лезут разные мысли о разработчиках. Наверно повторюсь, но мне кажется, что современные средства разработки ПО, позволяют и библиотеку доступа предоставить пользователям и даже компонент можно сваять для того же VB, я уже не говорю о примерах. Однако большого смысла в подобных репликах нет, потому как сами разработчики здесь не бывают, как я понял.

Уже несколько лет опрашиваем мгновенные
Еще хотел добавить по поводу опроса мгновенных значений, в тепловычислителях 942 и 943 есть такой параметр ПИ-период опроса. В 942-х его можно настраивать, в 943-х если мне не изменяет память он изменяется автоматически, это зависит от того какой источник питания используется тепловычислителем. При питании от сети значение ПИ минимально (кажется 5 сек), при питании от батареи ПИ максимально (999 сек, могу ошибаться). По 961 не помню как. Таким образом при опросе мгновенных надо так же руководствоваться и значением ПИ. Таким образом если ПИ=999, то опрос тепловычислителя для получения мгновенных значений, например, каждые 5 сек теряет смысл. Выше уже говорил, что опрос мгновенных все же нельзя считать достоверной информацией.

С уважением ivamat

[Это сообщение изменил ivamat (изменение 24 Ноября 2010 23:47).]

Cattel
Junior Member

Сообщений: 9
Регистрация: Сентябрь 2007

написано 29 Ноября 2010 09:15ИнфоIP

По поводу ПИ. Есть такое дело для 94x, касается давления и температуры, про расход ничего не сказано. В 961 не нашел.

Stanislavskiy
Junior Member

Сообщений: 2
Регистрация: Ноябрь 2010

написано 30 Ноября 2010 00:17ИнфоIP

Доброго времени суток. Напомню, у меня была пробемма с модемом Novacom/ Решилась заменой модема
Пприбор - СПТ 961 1(2)
опрашиваю прибор программой Пролог

вот лог

---:[29.11.2010 22:01:35] Опрос узла 'поиск: "8922xxxxxxx"', попытка 2
INF:[29.11.2010 22:01:35] прибор=?, NT=?, ИД=?
INF:[29.11.2010 22:01:35] Установка соединения (Стандартный модем 9600 bps, 8922xxxxxxx)
INF:[29.11.2010 22:02:02] Установлено соединение (9600 / без коррекции ошибок)
INF:[29.11.2010 22:02:05] Установка сеанса связи с прибором 94x/74x
INF:[29.11.2010 22:02:20] Установка сеанса связи с прибором 96x/76x
INF:[29.11.2010 22:02:20] Запрос сетевых настроек прибора-шлюза
INF:[29.11.2010 22:02:21] параметр 003: (1182000002)
INF:[29.11.2010 22:02:21] Запрос типа прибора (099)
INF:[29.11.2010 22:02:22] тип прибора: (961.2V01-D8A4)
INF:[29.11.2010 22:02:25] идентификатор прибора: (001)
INF:[29.11.2010 22:02:25] чтение данных 'Суточный архив'
ERR:[29.11.2010 22:04:13] таймаут
INF:[29.11.2010 22:04:16] чтение данных 'Суточный архив'
INF:[29.11.2010 22:07:48] чтение данных 'Месячный архив'
INF:[29.11.2010 22:08:25] чтение данных 'Изменения БД'
INF:[29.11.2010 22:08:28] чтение данных 'Перерывы питания'
INF:[29.11.2010 22:08:31] чтение данных 'Нештатные'
ERR:[29.11.2010 22:08:35] ошибка CRC
INF:[29.11.2010 22:08:38] чтение данных 'Нештатные'
ERR:[29.11.2010 22:08:42] ошибка CRC
INF:[29.11.2010 22:08:45] чтение данных 'Нештатные'
ERR:[29.11.2010 22:08:49] ошибка CRC
INF:[29.11.2010 22:08:52] чтение данных 'Нештатные'
ERR:[29.11.2010 22:08:56] ошибка CRC
...
ERR:[29.11.2010 22:20:57] ошибка CRC
INF:[29.11.2010 22:21:19] отмена

Подскажите, может кто знает про эту ошибку.

Cattel
Junior Member

Сообщений: 10
Регистрация: Сентябрь 2007

написано 30 Ноября 2010 08:35ИнфоIP

CRC - контрольная сумма (циклический избыточный код). Добавляется в конце посылки и позволяет выяснить передались данные с ошибками или без. Ошибка CRC обычно указывает на плохую связь.

Cadall
Junior Member

Сообщений: 3
Регистрация: Ноябрь 2010

написано 01 Декабря 2010 18:46ИнфоIP

Такая стабильная ситуация с ошибкой контрольной суммы ответа прибора, имхо, вполне "имеет место быть" с Логикой. Дело в том, что два байта контрольной суммы ответа (запроса) передаются в конце сообщения после символа "конец сообщения" (03h). Но в тексте самого сообщениия этот символ может запросто встретиться в самом неожиданном месте. В этом случае следующие 2 байта сообщения могут быть обработаны как байты CRC с выдачей соответствующего сообщения об ошибке. На практике столкнулся с расшифровкой ответов прибора СПГ741.
При отсутствии данных возвращает ответ из трех элементов 1-й - заголовок запроса, 2-й - строка "Нет данных?", 3-й - что попало ("4Р","s@","^8" и прочая лабуда). Т.е. досрочное появление символа "конец сообщения" (03h) не исключается.
Выход из ситуации вижу один - заполнить массив Нештатных свежими НС, чтобы НС с недопустимым символом исчезла. Или обнулить массив НС, если есть такая возможность.
А на плохую связь это совсем не похоже.

[Это сообщение изменил Cadall (изменение 01 Декабря 2010 19:58).]

Cattel
Junior Member

Сообщений: 11
Регистрация: Сентябрь 2007

написано 02 Декабря 2010 10:36ИнфоIP

Нельзя считать окончанием ответа присутствие конкретного символа, причину Вы сами описали. Окончание ответа лучше смотреть по межбайтовому таймауту. Это подтверждает то, что помогла замена модема.
Честно говоря Прологом давно не пользовался, может там есть настройки для таймаутов и с ними стоило поиграться.

Valera
Member

Сообщений: 1845
Откуда: novosibirsk
Регистрация: Май 2004

написано 03 Декабря 2010 12:41ИнфоIP

Cadall
заполнить массив Нештатных свежими НС
Где-то здесь в пределах -10 страниц, кто-то писал о решении вопроса с НС в 41-43 серии.

вроде так: http://forum.skunksworks.net/Forum10/HTML/000015-13.html#291

Cadall
Junior Member

Сообщений: 4
Регистрация: Ноябрь 2010

написано 03 Декабря 2010 18:58ИнфоIP

Что можно, а что Нельзя считать окончанием ответа, что хуже, а что
лучше смотреть по межбайтовому таймауту Логика, увы, решила без нас... Я же предложил лишь свой вариант. Кстати, когда я писал о конце сообщения, я имел в виду расшифровку уже принятого сообщения. Разумеется, если модем по какой-либо причине самостоятельно изменняет значение межбайтового таймаута, то ошибка CRC будет однозначно. Смущает лишь то, что она стабильно повторяется при считывании НС. Откуда модему знать что он принимает?..

Cattel
Junior Member

Сообщений: 12
Регистрация: Сентябрь 2007

написано 04 Декабря 2010 08:55ИнфоIP

Согласен, непонятная ситуация. С одной стороны и прибор и программа одного производителя и претензии в данном случае (в виду стабильности ошибки именно на НС) к производителю. С другой стороны, замена модема решило проблему. Производитель получается как бы и не причем. Но почему модем так невзлюбил именно НС?

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

Cadall
Junior Member

Сообщений: 5
Регистрация: Ноябрь 2010

написано 04 Декабря 2010 17:25ИнфоIP

Хотя, конечно, кто знает как работает Пролог... Не только Пролог но и сами приборы... Сейчас приходится временно считывать архивы с СПГ741 этим самым Прологом. Несколько раз возникала ситуация:
Прибор имеет ИД - 6833. Опрос проходит без проблем. Появляется сообщение о том, что данные с прибора успешно считаны. После нажатия кнопки ОК выскакивает окно с сообщением "Прибор с ИД 004 не зарегистрирован в базе данных. Зарегистрировать?". Это, на мой взгляд, может творить только сам СПГ. Только он может подставить в сообщение какой-то левый ИД, сформировать сообщение, подсчитать контрольную сумму и отправить его. Пролог считав сообщение и проверив контрольную сумму, не может "разложить по полочкам" эти данные ввиду отсутствия этих "полочек".
И еще. Так получилось, что расчетный час по газу - 10 часов, по остальным приборам - 11. Но для подстраховки (а вдруг завтра снова поменяют?) я решил в своей проге опрашивать это время и соответственно считывать данные за истекшме сутки. Результат - ситуация, описанная мною выше:"Нет данных?". Если бы речь шла о получении данных которые прибору необходимо получить, обработать, вычислить и т.д. - такой ответ был бы объясним. Но, константа, зашитая "намертво" в БД и "Нет данных?" - это абсурд!!! Но этот абсурд "имеет место быть" на практике!

Stanislavskiy
Junior Member

Сообщений: 3
Регистрация: Ноябрь 2010

написано 06 Декабря 2010 02:53ИнфоIP

Спасибо за ответы и участие. Проблема решилась понижением скорости в прошивке модема до 9600 (было 57600) и конечно же изменением спецификации 003 на СПТ961. Прибор стал замечательно работать даже с Новакомом)
Почему возникала ошибка CRC и именно на НС для меня осталось загадкой...

Driver8787
Junior Member

Сообщений: 1
Откуда: Россия
Регистрация: Декабрь 2010

написано 13 Декабря 2010 12:04ИнфоIP

Подскажите пожалуйста, установлены приборы СПТ 941 на подаче и обратке отопления....текущие данные показывает а архивные данные пусты и дата стоит 2001 год в чем может быть проблема????

ivamat
Junior Member

Сообщений: 8
Откуда: Россия, СПб
Регистрация: Октябрь 2010

написано 13 Декабря 2010 12:53ИнфоIP

Подскажите пожалуйста, установлены приборы СПТ 941 на подаче и обратке отопления....текущие данные показывает а архивные данные пусты и дата стоит 2001 год в чем может быть проблема????

Может надо установить правильную дату и подождать пока накопится архив.

Страницы: 1 2 3 4 5 6 7 8 9 10 13 16 19 22 23 24 25 26 27 28 29 30 31 32 33 34 37 40 43 44 45 46 47 48 49 50

Все время MSK

Открыть | Переместить | Удалить

Новая тема | Тема закрыта
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика