Вид для печати
LD - это язык программирования релейно контактных схем. Вот когда первая программа на LD была написана, откомпилирована и загружена в ПЛК и можно считать датой его появления. А это 1968 год.Цитата:
Сообщение от lagutin
https://ru.wikipedia.org/wiki/Програ...кий_контроллер
Вот и попался, товарищ выложил ссылку на википедию, где утверждается что первые ПЛК на ЛД(прототипе ЛД) программировались!Цитата:
Сообщение от ПавелП
https://ru.wikipedia.org/wiki/%D0%9F...BB%D0%B5%D1%80
Спор был про языки программирования. Я это и аргументирую.Цитата:
Сообщение от Сергей0308
>> Я же написал - текстовые были первые.
>> Со временем появлялись разные "вывихи", удобные, и не очень.
Вот. А вы, как всегда, не по алгоритму разговора...Цитата:
Сообщение от IVM
Я вообще удивляюсь, как вы программы пишете!??
Вероятно вы думаете на языке ЛД. :)
Сергей0308 - это всё шутки.
Я думаю. А в чём проблема?Цитата:
Сообщение от ПавелП
Это отлично!Цитата:
Сообщение от X200881
Только не к вам вопросы. :)
Тут многие думают, а вот выводы не логические получаются.
Потому спор и ходит кругами "вокруг да около".
Коллеги, подскажите по одному частному случаю:
Вложение 65918
Есть схема блокировки от нажатия 2-х кнопок одновременно (реализовано как на картинке), но при определенных условия (многократные попытки с одновременным нажатием на эти кнопки, т.е. очень быстротечный процесс) иногда сигналы проходят одновременно с двух этих кнопок, т.е. кнопки друг друга не блокируют. Я так понимаю это связано с самой RTOS лог. реле и не лечится. Конечно в реальности вероятность такого нажатия кнопок стремиться к нулю, но хотелось бы разобраться. Есть ли в OwenLogic функционал для определения приоритета исполнения FB?
Добрый день! подскажите пожалуйста макрос для подсчета времени работы программы, в онлайн базе time cycle не работает...
Не знаю, правильно ли я понял задачу, но если сделать так, то при нажатой кнопке другая будет игнорироваться. Приоритет у первой кнопки.Цитата:
Сообщение от julbu
Вложение 65921
Это RS триггерЦитата:
Сообщение от julbu
Схема RS триггера позволяет запоминать состояние логической схемы, но так как в начальный момент времени может возникать переходный процесс (в цифровых схемах этот процесс называется "опасные гонки"), то запоминать состояния логической схемы нужно только в определённые моменты времени, когда все переходные процессы закончены.
Это означает, что большинство цифровых схем требуют сигнала синхронизации (тактового сигнала). Все переходные процессы в комбинационной логической схеме должны закончиться за время периода синхросигнала, подаваемого на входы триггеров. Триггеры, запоминающие входные сигналы только в момент времени, определяемый сигналом синхронизации, называются синхронными.
Можно и проще сделать Вложение 65922Цитата:
Сообщение от Dimensy
Так вам время работы или время цикла надо измерять?Цитата:
Сообщение от Sailor88
Измерение времени цикла, в базе 2 макроса, оба работают, проверял в симуляции, оба 100 ms
первый измеряет за 15 сек, второй быстрее за 5 секВложение 65924
Может лучше применить ФБ "Исключающее ИЛИ".Цитата:
Сообщение от julbu
Мой вариант с приоритетом входов с меньшим числовым значением(верхних) с возможностью дальнейшего расширения количества:
Вложение 65925
Вложение 65926
А есть у вас вариант неодновременного включения выходов при одновременном включении входов с заданной задержкой времени. У меня простенькая задача - есть установка с 8 двигателями. Кажддый запускается по своей логике, но при подаче питания или запуске цикла) они стартуют все. Мне надо поставить в разрыв их цепи пр так чтобы при любой одновременной подаче сигналов на моторы они включались не одновременно ( с настраиваемой паузой между подачей сигнала на выход)и далее пролежали работать? Соответственно отключались при снятии входного сигналаЦитата:
Сообщение от Сергей0308
Первый двигатель тоже с задержкой включения должен быть(типа питающее напряжение пусть устаканится) или начиная со второго? Приоритет, я так понимаю, не важен?Цитата:
Сообщение от bayk
Короче, примерно как-то так:
Вложение 65927
Вложение 65928
Так, с запуском первого насоса без задержки:
Вложение 65929
Даже так:
Вложение 65945
Вложение 65946
И при работе(не только при включении), если поступит команда запуска более одного двигателя с интервалом менее заданного(в данном случае менее 10 секунд), "разрулится" и эта ситуация!
Мой вариантЦитата:
Сообщение от bayk
Нужно считать время работы увлажнителяЦитата:
Так вам время работы или время цикла надо измерять?
Измерение времени цикла, в базе 2 макроса, оба работают, проверял в симуляции, оба 100 ms
первый измеряет за 15 сек, второй быстрее за 5 секНажмите на изображение для увеличения. Название: 1 Измер времени цикла.jpg Просмотров: 4 Размер: 78.2 Кб ID: 65924
Тогда вам нужен макрос наработки, типа OperTimer_ Вложение 65933Цитата:
Сообщение от Sailor88
Находится во вкладке Общие, если надо можно добавить и секунды
Ваш вариант судя по всему рабочий, т.к. синхронизирован по тактам. Красивое решение с элементом сравнения с задержкой на один такт. Спасибо. С остальными вариантами не все однозначно, т.к. в принципе сигналы от кнопок могут прийти с разницей в задержку точно на один такт.Цитата:
Сообщение от Сергей0308
Большое спасибо. 3 вариант самое тоЦитата:
Сообщение от Сергей0308
Очень рад что подошло, вот немного упростил:Цитата:
Сообщение от bayk
Вложение 65956
Вложение 65957
Насчёт настройки приоритетов: сейчас приоритет у входов-выходов с наибольшим числовым значением, в смысле, можно назначить приоритет входам-выходам с наименьшим числовым значением поставив настройки(числовые значения) в свойствах макроса в обратном порядке, короче, приоритеты можно выбирать(настраивать как угодно) настройками в свойствах двух макросов(на входе и на выходе).
Вложение 65963
Вот в виде макроса сделал, изменил приоритет на обратный, теперь у входов-выходов с меньшим числовым значением и установил минимальный период включения выходов равный 10 секундам(если поступила команда включить более одного выхода), находится в свойствах макроса, в смысле можно назначать любой, по своему хотению или надобности, в пределах диапазона типа данных, если не ошибаюсь максимальный около 50(49 с хвостиком) суток:
Вложение 65964
Здравствуйте, подскажите, на входе пр200 есть аналоговый датчик термосопротивления pt1000 от Oven, значение от датчика вывожу на дисплей реле, но данное значение часто может изменяться с большой частотой (например между 23 и 24 градусами), как можно "отфильтровать" значение датчика, чтобы он выводил показания и менял их не чаще раза в несколько секунд?
Fane_Yalie В настройках входа надо подобрать время фильтрации (можно выставить секунду - будет раз в секунду обновляться):
Вложение 65984
А зачем время таймера переключать? Мне кажется, это бессмысленно!Цитата:
Сообщение от Dimensy
Вот, без переключения уставок таймера и всё так же работает, короче, в Вашем стиле супер специализированного макроса:
Вложение 65995
И, в стиле, не супер специализированного макроса:
Вложение 65996
Например: нам нужно "разрулить" не 8, а 32 насоса!
В этом случае ничего и переделывать не обязательно, достаточно взять центральный, с целочисленным входом и выходом макрос и присобачить к нему макросы вставки и извлечения на 32 бит, можно расширить и имеющийся макрос вставки на 8 бит(он с расширением). Короче, можно расширить даже с имеющимися макросами без проблем и переделок, в смысле, ничего нового не придумывать, а пользоваться уже имеющимися макросами! Можно и не объединять эти макросы в отдельный супер специализированный макрос!
Короче, у меня даже до конца не получается рисовать вашими методами, в смысле, я не рисую 8 или более дискретных элементов(функций), а просто ставлю готовый макрос, если надо, то для расширения использую несколько таких макросов или ставлю другой на большее(нужное) количество бит!
Чуть не забыл сказать(уточнить), макросы в этих двух проектах работают не совсем одинаково, в смысле выключаться выхода могут по разному, включаются одинаково, в смысле, для нашего случая, это не имеет значения!
Доброго времени суток. Очень срочный и важный вопрос: контроля Trei теряет связь с пр200, причём перед потерей связи обмен работает в течении несколько дней, и затем без причины связь обрывается. После перезагрузки пр200 связь возобновляет, но затем через несколько дней или неделю вновь обрывается. В чем может быть причина? И как её оперативно можно исправить?
При наличии частотников и силовых установок, все провода по входам и сети RS485, экранировать и заземлять. По RS485, повесить резисторы 120 Ом. Переложить кабели, для уменьшения помех.Цитата:
Сообщение от YaABelov
Для устанения помех и отключений по сети, ставить безперебойник. При наличии БП на 24 В, заменить для проверки.
Ну и на крайняк замена ПР200 на другой, для проверки.
А не "виснет" ли ПР?Цитата:
Сообщение от YaABelov
это не совсем так. время фильтрации это не период обновления данных. это период вычисления скользящего среднего\. если правильно помню програмнную реализацию фильтраЦитата:
Сообщение от Cs-Cs
Вот что пишут и рисуют по поводу этого параметра для ТРМ:
Вложение 66008
В смысле, было бы странно что бы у одной фирмы для одного параметра были бы разные функции, может для ПР не заморачиваются с его объяснением, типа посмотрят в другом месте, может просто ленятся скопировать объяснения для ТРМ, это же отнимет секунд 5-10 их драгоценного времени, в смысле, проще на форуме или в техподдержке объяснить!
Видимо пр и виснит, потому что после перезагрузки связь восстановливается.Цитата:
Сообщение от Sergej_
То есть вы думаете из за помех может так связь зависать? Проблема в том что это происходит на многих Пр200 установленных на том объекте. Вроде даже как на всех, но для выяснения подробностей наш человек на объект отправляется. Помехи могут как то вызывать подвисание? Почему после перезагрузки все нормализуется? Я же правильно понимаю что в режиме Slave Пр200 только отвечает на запросы Мастера, и после перезагрузки никаких пакетов самостоятельно не отправляет? Или есть какое то тестовый ответ? Ещё момент - Пр200 стоит несколько в сети(архитектуру уточняем), а отваливаются они частями, но значительными и вроде как по очередиЦитата:
Сообщение от kondor3000
для начала самое №1 - определитесь - что такое "подвисание"?Цитата:
Помехи могут как то вызывать подвисание?
каким образом вы это фиксируете и как количественно или качественно оцениваете?
потому что Респаун :DЦитата:
Почему после перезагрузки все нормализуется?
правильноЦитата:
Я же правильно понимаю
а это к вам вопрос. если вы свяжете этот вопрос с ответом на №1 "подвисание", вы сами себе и ответите - есть у вас тестовый Запрос, чтобы получить тестовый Ответ - или нет?Цитата:
Или есть какое то тестовый ответ?
вот с этого бы надо и начать - правильно ли нарисована сеть и как она смонтированаЦитата:
(архитектуру уточняем)
Подвисание - отсутствие реакции Пр200 на запросы мастера. Оно проявляется в виде индикации на панели оператора - "неопределённое состояние Пр200" = обрыв связи. Если просьлема все таки в сети, почему неисправность проявляется только со временем? Почему не все Пр200 в этой сети, установленные в том же помещении "выпадают в осадок"?Цитата:
Сообщение от In_Da_Cher_A
И это умножение, переведите булеву переменную во флоат и умножите на производительность ТЭНаЦитата:
Сообщение от Fane_Yalie
отлично. Мы вроде как пришли к выводу - что слейв это тупое устройство, которое только отвечает, если его спросили.Цитата:
отсутствие реакции Пр200 на запросы мастера.
Отсюда вывод - а спросили его или нет?
Вам Кондор и написал - для начала исключите возможные физические проблемы по сети, судя по
Мастер вроде как свою работу сделал - запрос послал, а ответа не получил, куда запрос делся? помехи при включении частотника его забили наглухо по дороге?Цитата:
индикации на панели оператора - "неопределённое состояние Пр200"
а чтобы убедиться, что Мастер свою работу делает идеально, и получить фактуру в виде
допилите код на МастереЦитата:
каким образом вы это фиксируете и как количественно или качественно оцениваете
на каждый слейв поставьте "генератор" импульса и счётчик импульсов и такой же счётчик ответов.
и сравните потом сколько ушло, сколько пришло
А не просто бит статуса связи, который вы скорее всего и используете, чтобы вывесить алярм на панели
когда будут числа, тогда вы сможете сразу количественно и качественно оценить работу Мастера и сети
потому что даже тупо условно длина кабеля влияет на скорость, хотя практика знает работу на чудовищных скрутках и кабелях на дикой длине.Цитата:
Если просьлема все таки в сети, почему неисправность проявляется только со временем? Почему не все Пр200 в этой сети, установленные в том же помещении "выпадают в осадок"?
было бы неплохо нарисовать схему сети с длинами кусков, и с настройками
если на то пошло, то в идеале и проверить тип кабеля, а соответствуют ли характеристики по волновому сопротивлению требованиям кабеля для RS485?
может вам по выпадающим слейвам уменьшить скорость? или время задержки увеличить до впадания в панику?
вам надо системно поработать, чтобы пофиксить проблемы
Спасибо большое, это все обязательно проделаем по прибытию нашего спеца на объект. Мне важно понимать что это проблема не связана с "зависанием" самой Пр200. Все таки так и не понял как перезагрузка ПР200 влияет на возобновление связи. Почему она все таки возобновляется если линия осталась прежней и почему не все ПР200 и только по истечению значительного времени это происходит: наводки на линию вызывают сбой в работе модуля RS485 ПР200 и контроллер ПР200 обрывакт связь по ошибке, затем после перезагрузки возобновляет обмен? Если да, то для чего это сделано и как можно про диагностировать? Опрос мы обязательно запишем и проанализируем, контроль качество линии и сети проведём.Цитата:
Сообщение от In_Da_Cher_A
Это ключевой момент , если ПР зависает, соответственно связи не будет . Если это так, то зависнуть ПР может чаще всго от помех, которые "пролазят" либо по питанию, либо через гальванически неразвязанных АI. Судя по форуму чаще всего виснут ПР-ки с питанием 220. Чем 24 в. Это связано очевидно с тем что в 24в. версии используется dc/dc преобразователь , и при "моргании" напряжение сети , ПР более устойчиво к этим воздействиям нежели версия 220в. без ИБП. Вероятнее всего в таких случаях "дерганьях" сети , версия 220 в. начинает "сворачивать"-"возобновлять" работу и возможно зависает.Цитата:
Сообщение от YaABelov
У меня все Пр-и 24в. ни разу не возникало проблем. Схема простая: Сетевой фильтр-БП- приборы.
а я не говорил, что проблема не в этом. Вы говорите, что часть работает нормально, значит вероятно проблема потери связи не в качестве компонентов ПР200? наверное это самое последнее, на что следовало бы думатьЦитата:
Мне важно понимать что это проблема не связана с "зависанием" самой Пр200.
и без качества ПР200, у вас может быть досточно причин похерить обмен, поэтому исключите сначала их.
мы сейчас может только заниматься гаданием. Проблема может быть где угодно, в том числе и в кривовато сделанной программе на стороне Мастера.Цитата:
и почему не все ПР200 и только по истечению значительного времени это происходит:
потому что (предположение) накопленные ошибки обнулилисьЦитата:
затем после перезагрузки возобновляет обмен?
я не знаю, что и как сделано на Мастере и на Слейве, поэтому вылечить это "по фото" невозможно. мы сейчас даже не знаем структуру сети и количество слейвов и какие данные они гоняют по сети. Может Мастер у вас все 64 регистра тянет с пр? и в каждый регистр ногами данные утоптаны. Групповой опрос или одиночный? причин масса может бытьЦитата:
Если да, то для чего это сделано и как можно про диагностировать?
можно конечно упороться и с осциллографом, но как показывает практика - можно обойтись и без выскоих материйЦитата:
контроль качество линии и сети проведём.
Я говорю из опыта наладки, как простыми способами отловить дефектное место или сузить круг подозреваемых.
исключили физику кабелей - переходим к логике
закомментили все слейвы, кроме первого - запустили в работу, погоняли, нормально? второй включаем и так далее
отвалился какой-то - смотрим где чего как, анализируем, пытаемся повторить
В любом случае - вам нужна системная работа
Вы задали общий вопрос и получили общий ответ, что может быть.Цитата:
Сообщение от YaABelov
Пишите более подробно, для получения конкретных ответов. Проверять всё равно надо по шагам.
Я задал много конкретных вопросов : почему ПР200 прекращает отвечать на запросы спустя какое то время стабильного продолжительного обмена? Допустим ошибка сети/опроса и мы её устранили, но вопрос остается : почему ПР200 не отвечает на запросы? Что стало причиной? Как устронять это? Где в документации на изделие это написано? Какие рамки применимости данного изделия? Вопрос то очень серьёзный. Поставленно значительное количество изделий на серьёзный объект, а тут такая история. И сейчас оперативно нужно решить вопрос, в максимально короткие сроки.Цитата:
Сообщение от kondor3000