Это вообще при чем? Какой-то чудак не контролировал работу датчиков запыленности, а виновато реле???
Вид для печати
Кек, а в чем проблема? Припаян просто разъём мама на плату на один элемент больше, он просто не используется. Создали проблему ради проблемы))) На модулях S7-1200 тоже есть разъёмы которые не используются, давайте на немцев наезжать. :D
В том, что при такой распайке разъёма подключено всё будет в полном соответствии с законом Мёрфи. И к чему это приведёт, одному богу ведомо. В конце концов, подключениями частенько занимаются не инженеры на лабораторном столе, а рядовые монтажники в полевых условиях. Покажи мне хоть один немецкий девайс, где фишку можно вставить не так, как надо.
ну как-то совсем не по-пацански производителю отвечать "подумаешь, нашли проблему, проверять надо перед установкой"
вполне логичное замечание, раньше в прку клали красные элементы для однозначного определения положения разъема, но нигде не написали что это, потому их все выбрасывали, а потом совсем упразднили. вот сюда надо было вложить пакетик с этими ограничителями и маленькой инструкцией.
Ой было, девки, было©, ага. Были в старых чёрных ПР200 и ключи, было и описание на них.
Вложение 57983
А перестали класть, видимо, оттого, что ими редко кто пользовался. Когда прибор разведён в щите, питание с интерфейсом не перепутаешь. Перепутать можно только интерфейсы или интерфейс с выходом 24В. К выходу интерфейсной платы из строя это не ведёт (таки-да, я путал:)). Ну а у остальных фишек просто разное количество контактов. Скорее всего, ключи можно где-то и отдельно купить, ежели очень надо. Кста, у Phoenix существуют и заглушки для неиспользуемых пинов. Ежели бы Овен заглушил лишний пин, этой темы вообще бы не случилось.
Вложение 57982
Сегодня при скачке напряжения во вторичной цепи БК питающего ПР. Произошло полное обнуление энергонезависимых переменных в ПР. При чем данные в эти переменные были записаны с Лоджика.
Кто что объяснит по этому поводу.
При превышении ВТОРИЧНОГО напряжения БП выше 24В + заявленные характеристики (вроде гарантийный случай? или стабилизарованный БП допускает это?), поступающих на вход контроллера, у которого своя схема питания CPU и FLASH...
При этом стираются все данные, но не происходит выход контроллера из строя?
Я не могу озвучить, как автор. Но какие есть варианты?
Проблема была такая: В вторичной цепи произошел перегруз, БП стал вываливаться в защиту с последующей попыткой восстановиться.Т.е произошла "дребезжалка" пока не выключили. БП30Б-Д3-24С. ПР не вышла из строя. Но пришлось все данные вручную вбивать.
Вопрос вот в чем. Почему обнулились энергонезависимые забитые с лоджика. Вопрос: приоритетность этих заранее вбиваемых? ПР работает в связке с ИП320. Я уже сам предполагаю что скачки вызвали обнуление данных в ИП и они записались в ПР.
Получается в лоджике просто предустановка, и если их извне обнулить то потом они не восстановятся.
Если у вас энергонезависимые переменные могут перезаписываться (например с ИП), то при любом сбое или форсмажоре могут слететь (обнулиться). Делайте уставки (наработку) только для чтения и проблем будет на порядок меньше! Всё зависит от программиста, хотя бывает и жёсткие диски слетают.
Скажите пожалуйста, пр100 с rs-485 в режиме slave поддерживает широковещательный запрос от мастера?
Шоу маст гоу он!
Вчера получил новые ПР100. Угадайте, что с ними не так. Ни за что не угадаете.
Они точно такие же как и старые, то есть на 10-ти контактную вилку приходится 11-ти контактное гнездо.
Серийные номера уже другие - большие. То есть с момента огласки проблемы завод продолжал ляпать корявые поделки...
X200881 если вы про групповой опрос, то в режиме slave ПР-ки поддерживают это. Они сами не умеют опрашивать группой, если являются мастером.
Вот пример опроса ПР200 со стороны Scada
Цитата:
Отправка (8): 01 03 02 00 00 15 85 BD
Приём (5/5): 01 03 2A 00 00
Приём (42/42): 00 00 00 00 CC CD 42 74 00 00 42 6E 99 9A 41 19 00 00 41 C0 33 33 41 D3 CC CD 42 2C 00 00 00 00 00 00 00 00 00 00 00 00 88 FC
OK!
OlegM в гнезде одеть на штырек термоусадку и так несколько раз :)
не видел ни одного устройства Modbus, которое бы отвечало на широковещательный запрос, как правило это прием команды всеми устройствами в сети.
Не надо путать широковещательный запрос с групповым.
keysansa покажите хоть одно устройство, которой ответит на широковещательный запрос ???? очень интересно увидеть
Вообще-то широковещательный(по адресу "0") запрос лучше не применять, приборы на него не отвечают и непонятно будет записались данные или нет!
ну вообще то в пр в режиме мастера нулевой адрес и не прописать
Если это так, это говорит лишь о том, что в режиме мастера ПР не поддерживает широковещательный запрос!
В данном случае ПР выступает в режиме подчинённого устройства, это, как говорят, две большие разницы, короче, это ещё не говорит о том что в режиме слейв, ПР не поддерживает широковещательный запрос, хотя аналогия напрашивается!
Нет, я про широковешательный запрос от мастера (не Овен), несколько пр100 slave. https://ru.wikipedia.org/wiki/Modbus
Так всё же, Вам уже задавали этот вопрос, чего Вы хотите добиться широковещательным запросом, я так понимаю, пока Вы что-то хотели, забыли, что хотели?!
И проверить - минутное дело, пошлите широковещательный запрос и проверьте приняли его ПР или нет, я так понимаю приборов у Вас пока нет, Вы так для интереса, на будущее спросили?
У меня только один вопрос - чего вы широковещательным запросом хотите в них записать?
Вопрос был дискретный.:) Подумал здесь найду ответ. Конечно попробую, что логично.
Широковещательный запрос нужен например: для аварийного одновременного закрытия всех клапанов подачи концентрированной кислоты.
Да мало ли для чего. Это стандартная функция модбус, не мной придумана, потому и спрашивал.
Ещё раз напишу, видимо туго доходит!
Для важных команд, тем более лучше знать прошла команда или нет! Для аварийных - не подходит в принципе!!!
И, мне кажется, можно сделать "по человечьи", в смысле передавать битовой маской, сразу число регистров в 16 раз сократится и задержка уменьшится.
Вероятно, Вы там натворите делов?!