 | |
Предыдущие результаты
Ещё результаты
ОК, давайте не будем подменять понятия. Заземление - это не минусовый полюс (минусовая шина) источника питания, это отдельная цепь. Оставим заземление в стороне.
Ниже схема подключения 1756-OB16D. Вы можете показать на ней, где у вас какой потенциал и в чём у Вас, собственно, проблема?
[img:689f34b198]http://i64.tinypic.com/2pyrgg1.jpg[/img:689f34b198]
|
[quote:b657fa22cd="Serega77"]
С заземление все нормально, каждый блок питания заземлен , все на одной шине , шина подключена к контуру заземления . Речь идет как раз о наличие напряжения между двумя минусами.[/quote:b657fa22cd]Путаетесь в показаниях.
Возможно, по схеме всё ДОЛЖНО БЫТЬ так, но вот в реальности что-то одно:
- или "все на одной шине";
- или "наличие напряжения между двумя минусами".
Проверяйте монтаж.
П.с. "Шина" - это не брошенная шлейфом "сопля", а реально эквипотенциальный по всей своей длине мощный проводник (точка, полоса, болт), к которому сходятся все остальные проводники.
[URL=http://radikal.ru/fp/1f9cdd75c3154ad1805f843338b22176][img:b657fa22cd]http://s019.radikal.ru/i626/1604/8f/4ff819a6c885t.jpg[/img:b657fa22cd][/URL]
На фото (кликнуть для увеличения) слева SG, а справа PE. Они могут быть соединены между собой проводником, но кошернее осуществлять такое соединение в одной точке - на ГЗШ системы уравнивания потенциалов.
|
[quote:81fd18407f]Я имел в виду, что эквипотенциальную шину должен представлять собой минусовый полюс неинтерфейсного источника питания.
Минусовой контакт с интерфейсного блока 1756-PA75R брать не только не нужно, но и вредно, т.к. он должен быть гальванически изолирован от неинтерфейсных цепей. Само собой, что его там неоткуда и взять.[/quote:81fd18407f]
У нас как раз получается что минус интерфейсного питания доступен через контакт 16 и 32 модуля 1756-OB16D . И на эти клеммы мы должны подавать питание от другого ИП . Потенциал м\у не подключенной клеммой (16,32) модуля и минуса второго ИП - ~ 3 вольта .
[quote:81fd18407f]
Serega77 писал(а):
Что делать с гашением потенциалом минусов через модуль?
Не "заземлять" через модуль, а организовать шину "цифровой земли".
Вообще, давным-давно одним из первых на русский язык был переведён документ "Руководство по подключению и заземлению в устройствах промышленной автоматики".
Настоятельно рекомендую.[/quote:81fd18407f]
С заземление все нормально, каждый блок питания заземлен , все на одной шине , шина подключена к контуру заземления . Речь идет как раз о наличие напряжения между двумя минусами.
|
[quote:73b9acf8f3="Serega77"]Что делать с гашением потенциалом минусов через модуль?[/quote:73b9acf8f3]Не "заземлять" через модуль, а организовать шину "цифровой земли".
Вообще, давным-давно одним из первых на русский язык был переведён документ [url=http://vdt-automation.de/docs_ru/Controllers/Grounding/1770-41-RU.pdf]"Руководство по подключению и заземлению в устройствах промышленной автоматики"[/url].
Настоятельно рекомендую.
|
[quote:27e76db37e="Serega77"]
Единственное нас же никто не спрашивает - есть умные дяди проектировщики , есть жесткие стандарты зарубежной компании, есть инженера этой самой компании, которые следят за тем, что бы все соответсвовало этим стандартам . А мы всего лишь исполнители и наше дело маленькое. )[/quote:27e76db37e]
Интересно, что за компания такая? Данные ситуации иногда происходят при пусконаладочных работах, простая человеческая ошибка, посмотрите в электросхеме как должно быть, у самого такое постоянно
|
[quote:cdc4069fd1="mp3corp"]Объясните мне, для чего все эти танцы с -1.#QNAN, если можно привязать любую анимацию на верхнем уровне при проверки переменной ...Fault?[/quote:cdc4069fd1]
Над тем, что вы называете верхним уровнем, есть еще один уровень, самый верхний. Там принимаются решения сколько какого продукта изготовить и сколько кому зарплаты выдать. Это называется система управления производством и там нет никаких "анимаций", там есть архивы, статистика и отчеты. Вот туда нужно отправлять данные по OPC.
[quote:cdc4069fd1="maxim"]Здравствуйте, пишите в Value например -1 или -8888, если есть ошибка канала.[/quote:cdc4069fd1]
Магические константы и изобретение велосипеда... По возможности хотелось бы все-таки использовать стандартные средства OPC для этой задачи. Это было бы более гибкое и поддерживаемое решение.
[quote:cdc4069fd1="dv_"]Или [b:cdc4069fd1]-1.#QNAN[/b:cdc4069fd1], если тег REAL - RSLinx Classic сам подставит BAD.[/quote:cdc4069fd1]
Хорошая идея, но в RSLinx Enterprise эту фичу убрали.
Emulate5000 > RSLinx Classic > OPC Test Client:
[img:cdc4069fd1]http://i.imgur.com/1sVzGZj.png[/img:cdc4069fd1]
Кстати, формулировка причины не та, но уже что-то.
Emulate5000 > RSLinx Enterprise > FactoryTalk Live Data Test Client:
[img:cdc4069fd1]http://i.imgur.com/kTFWgXj.png[/img:cdc4069fd1]
В принципе с этим тоже можно работать. По крайней мере, NAN - это лучше чем -8888.
|
[img:3f41f31ad3]http://i.imgur.com/d28Wrvj.png[/img:3f41f31ad3]
[b:3f41f31ad3]mp3corp[/b:3f41f31ad3] Есть моя система, FactoryTalk, в ней все хорошо, а том числе и сообщения при обрывах.
Есть общезаводская система учета, в которую нужно отсылать ключевые технологические параметры.
В случае обрыва сенсора, отправляются данные о том, что: Value=0 Quality=Good - то есть наглая ложь; Quality не должно быть Good, ведь я знаю что наступил Channel Fault!
[b:3f41f31ad3]Ryzhij62[/b:3f41f31ad3]
[quote:3f41f31ad3]Признак качества в теге OPC отражает не валидность физического значения, а качество ПЕРЕДАЧИ самого значения (качество связи) . [/quote:3f41f31ad3]
Я этого и добиваюсь. Обрыв езернета к контроллеру уже приводит к Bad Quality встроенными средствами FactoryTalk Gateway.
Я хочу, чтобы дополнительно к этому, обрыв между контроллером и сенсором тоже генерировал Bad Quality. Неужели это противоречит философии OPC?
|
Есть расходомер с выходом 4-20мА, считываемый аналоговым входным модулем 1756-IF16, вставленным в контроллер L72, входящий в систему FactoryTalk View SE, отдающую данные во внешний мир по OPC с помощью FT Gateway.
Есть аналоговый тег Ch0Data, показывающий ток втекающий в модуль.
Есть дискретный тег Ch0Fault, показывающий что в токовой петле есть обрыв/КЗ или модуль неисправен, проще говоря на Ch0Data уже можно не смотреть.
Мы хотим передать данные о расходе в вышестоящую систему (АСУП/MES). Если принять в качестве значения расхода величину Ch0Data, то при обрыве токовой петли Gateway выдает расход равным нулю, вводя в заблуждение OPC-клиента. Надо как-то показать, что показания датчика не равны нулю и не равны максимуму шкалы, они вообще ничему не равны, а просто недоступны.
В спецификации OPC DA описан именно такой механизм, уведомляющий клиентов о том, что значение неточно/недоступно/некорректно - флаги Quality. Можно ли в FactoryTalk Gateway создать OPC Item, у которого Value зависит от Ch0Data, а Quality зависит от Ch0Fault?
|
[quote:a63fa310c4="Eugeny"][b:a63fa310c4]Опросник от Rockwell Automation[/b:a63fa310c4]
[url]http://www.rockwellautomation.com/services/training/training-quiz.page?utm_medium=Email&utm_source=EMEA_NL_ALL_AT_Mar16&utm_campaign=Corporate_EMEA_XX_XX_2016_AT_3-16&utm_content=EMEA_NL_Russia_AT_Mar16[/url][/quote:a63fa310c4]
:oops: грустно блин .... я двоичник :cry: :x
|
[b:dc57ebfdf4]Опросник от Rockwell Automation[/b:dc57ebfdf4]
[url]http://www.rockwellautomation.com/services/training/training-quiz.page?utm_medium=Email&utm_source=EMEA_NL_ALL_AT_Mar16&utm_campaign=Corporate_EMEA_XX_XX_2016_AT_3-16&utm_content=EMEA_NL_Russia_AT_Mar16[/url]
|
Предыдущие результаты
Ещё результаты |
|
| |
|