Пожелания

[ailcat]

Arsie
1) ваш макрос хоть и написан за 40 секунд - таки не является элементом "задержка включения" или "задержка отключения", требуя переработки (хотя и демонстрирует логику пересчета времени в тики)
2) зачем извращаться с реализацией блока задержки как комбинации математики и счетчиков, если на Си (или на чем там написано ядро?) эта задержка явно реализуется куда проще, чем каждый из предлагаемых FB? (офф: в ассемблере PIC16x87 - целых 14 команд. Правда, постоянно "крутится" один на все тайм-блоки схемный таймер с предделителем).
3) задержка должна быть "синхронной", т.е. на момент очередного тика проверяется, прошла уже задержка (и тогда меняется состояние выхода) или еще нет (и тогда выход остается в прежнем состоянии).
Единственной проблемой может оказаться такая ситуация: на конкретный тик задержка уже отработалась, но в этом же тике программа сбросила вход. Возможно, стоит принять логику Сименса: задержки проверяются всегда перед началом "тика", таким образом, даже если программа сбросила вход - сброс выхода произойдет только к следующему тику (т.е. единичка зафиксируется в течении 1 тика), реально 1 на выходе не появится только в том случае, если вход сбрасывается ДО того, как задержка будет отсчитана.



Sergey Cherevko
Не отходя от кассы: текущая задача.
полный цикл механизма ~3,5 сек (механически можно уменьшить до 2,7-2,8 сек, но зачем?). При работе с тиком 70 мс - укладываемся, ставим тик 100 мс - 3,6 сек., ставим тик 200 мс - 4,8 сек... 4,8/3,5=1,37. ТРЕТЬ времени - потери исключительно на длинный тик (а, да - у меня тут на первом варианте программы получился реал-тик аж 508 мс - в итоге полный цикл механизма занял больше 12 секунд! т.е. потери из-за недостаточного быстродействия контроллера были втрое больше, чем сам рабочий цикл!).
Вполне естественно, что при загрузке программы тик задается лишь немного бОльшим, нежели реальное время цикла программы...

Да, немного соффтоплю: по ТЗ на установку, куда я пробую SMH-2G, на цикл собственно механизма отводится примерно 4,2 сек. Сама логика "укладывается" в 136-137 мс, но довесок в виде минимальной "защиты от дурака" и утоптанного по самое нехочу настроечного интерфейса - увеличивает цикл до 202-203 мс...



New
Собственно, на Сименс Лого математики нет как класса. Зато есть несколько видов таймеров, реализующих всевозможные задержки (из которых в технологических установках заняты практически только задержки включения/выключения со статичным входом или активацией по фронту).
И, в итоге, алгоритм получается простым и надежным, как топор. Более того - не требующим пересчета времен или использования чего-либо при задании задержек в мс (напомню - Лого начинает обсчет нового "тика" немедленнго по завершении обсчета предыдущего. При этом для максимального разрешенного объема программы гарантируется, что "тик" будет не более 200 мс)
Да, Лого - не контроллер, а интеллектуальное реле - так что в нем математика не требуется. а задержки - более чем. Но, чёрт возьми, и в полноценных контроллерах все временные задержки задаются специальными блоками в явном виде (в миллисекундах)!

[Arsie]

Цитата:

Сообщение от ailcat

Arsie
1) ваш макрос хоть и написан за 40 секунд - таки не является элементом "задержка включения" или "задержка отключения", требуя переработки (хотя и демонстрирует логику пересчета времени в тики)
2) зачем извращаться с реализацией блока задержки как комбинации математики и счетчиков, если на Си (или на чем там написано ядро?) эта задержка явно реализуется куда проще, чем каждый из предлагаемых FB? (офф: в ассемблере PIC16x87 - целых 14 команд. Правда, постоянно "крутится" один на все тайм-блоки схемный таймер с предделителем).

Собственно, на Сименс Лого математики нет как класса. Зато есть несколько видов таймеров, реализующих всевозможные задержки (из которых в технологических установках заняты практически только задержки включения/выключения со статичным входом или активацией по фронту).
И, в итоге, алгоритм получается простым и надежным, как топор. Более того - не требующим пересчета времен или использования чего-либо при задании задержек в мс (напомню - Лого начинает обсчет нового "тика" немедленнго по завершении обсчета предыдущего. При этом для максимального разрешенного объема программы гарантируется, что "тик" будет не более 200 мс)
Да, Лого - не контроллер, а интеллектуальное реле - так что в нем математика не требуется. а задержки - более чем. Но, чёрт возьми, и в полноценных контроллерах все временные задержки задаются специальными блоками в явном виде (в миллисекундах)!

Вы режете меня по живому, я же вам уже дал нужные ссылки. Вам что-то непонятно? Давайте поговорим об этом, а не о Лого или Пике.

Цитата:

Сообщение от ailcat

Arsie
3) задержка должна быть "синхронной", т.е. на момент очередного тика
[...]
сбрасывается ДО того, как задержка будет отсчитана.[/i]

В лоджике иное невозможно. Она и так синхронна.

Цитата:

Сообщение от ailcat

Arsie
Sergey Cherevko
Не отходя от кассы: текущая задача.

Точно также никуда не отходя: 1) SMH-2Gi; 2) Любой контроллер + SMH2010.

Первый вариант комментировать смысла нет - он просто более подходит под вашу задачу. Второй вариант - интерфейс делается отдельно на любом контроллере, который по событию прогружает настройки на SMH2010, который уже в свою очередь рубит программу с минимально возможным ТИКом. Почему SMH2010? Он имеет максимальное быстродействие из семейства "не SMH-2Gi".


.

[LordN]

Цитата:

Сообщение от Arsie

Входа какого?

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

[Arsie]

Цитата

Сообщение от LordN

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

Т.е., типа, чтобы защёлкивался сам факт наличия иголки на этом входе?


.

[LordN]

Цитата:

Сообщение от Arsie

Т.е., типа, чтобы защёлкивался сам факт наличия иголки на этом входе?


.

именно!
сейчас, насколь я понимаю, такой фичи нет. все иголки не попавшие на начало цикла игнорируются. ведь так?

[ailcat]

LordN
Модуль МС, входы din7, din8.
Соединяем их со счетчиками CNT без промежуточных элементов - и они должны отсчитывать даже "иголки"...



P.S. В принципе - парочка счетных (читай - "быстродействующих", не зависящих от "тика" программы") входов - абсолютная норма для любого контроллера.
Не думаю, что Сегнетикс отказался от них (тем паче, что эксперименты с din7 вроде подтверждают его "счетность" - хотя мне нечем "в полевых условиях" создать "иголку" короче ~40 мс - но реал-тик у на тестовой программе системный режим показывает в 70-71 мс, т.е. таки длиннее "иголки"!).

Ну а если нужно ловить ну уж очень короткие "иголки" -
может, стоит прикрутить на модбас-СОМ1 что-то типа IcpDas M-7080 (2 счетчика типа long до 100 кГц - то бишь их можно использовать для отлова "иголок" длиннее 5 мкс),
или неоптоизолированные 500-килогерцовые M-7088 (отлов "иголок" вплоть до 1 мкс),
или даже использовать энкодерные входы модулей M-7083 (модули предназначены для сопряжения с 3-мя энкодерами, поэтому при скважности 2 успевают считать до 1 МГц - т.е. потенциально способны отловить "иголку" длиной всего в 0,5 мкс!)

[ailcat]

Arsie
Мы с вами говорим с разных позиций.
Моя позиция - "хочу как в ..., ибо удобно"
Ваша - "это ж надо напрягаться разработчикам контроллера - так что не считаю нужным".
Да, согласен - с Вашей точки зрения трудозатраты разработчиков сотен (а то и и тысяч) изделий на ваших контроллерах - ничтожны по сравнению с единовременными трудозатратами вашего программиста (тем более, что создать макрос задержки действительно несложно - хотя он обсчитывается и медленнее, чем специально созданный FB).
Мою же точку зрения (что приходится делать навороты, дабы все настройки задавть в мс, а не в тиках) - пока явно поддержал только 1 человек...

В общем, кажется, мы достигли стадии разговора слепого с глухим. За сим предлагаю закончить, НО:
буду признателен, если блок "задержка включения и задержка отключения с заданием времени в миллисекундах" будет включен в программу развития Лоджикса.



Теперь - про мою задачу:
я СЕЙЧАС знаю, что для моих задач отлично подходит SMH-2Gi. Более чем вероятно, что его я и буду закладывать в дальнейшие изделия (тем более, что при всех отмеченных недостатках - контроллер SMH-2G мне в целом понравился).
но в декабре 2010 SMH-2Gi еще не продавался (потому и заказал что было), а изврат с раздельными контроллерами для настройки и собственно работы... (кхм, в такой схеме гораздо удобнее было бы обойтись вообще без вашего изделия - за соизмеримые деньги получив еще и более полную поддержку МЭК 611131-3)

[Arsie]

Цитата

Сообщение от LordN

именно!
сейчас, насколь я понимаю, такой фичи нет. все иголки не попавшие на начало цикла игнорируются. ведь так?

Как правильно уже замечено, есть два таких входа на модуле МС. Ещё есть два счётных входа на модуле MR120.

Это не защёлки, конечно, но по изменению состояния счётчика можно отследить, были ли эти иголки и сколько их было. Для этих входов присутствуют и перестраиваемые фильтры - чтобы слишком мелкие импульсы не ловить.

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

.

[ujin]

Цитата:

Сообщение от Sergey Cherevko

Обычно удобства программиста - его личное дело, а остальным на удобства программиста плевать с высокой колокольни.

Здесь не только программисты участвуют в обсуждении характеристик контроллеров, но и люди принимающие решения о целесообразности их применения. В том числе и исходя из перспектив развития контроллеров и фирмы которая их производит.

[Arsie]

Цитата:

Сообщение от ailcat

Arsie
Мы с вами говорим с разных позиций.
Моя позиция - "хочу как в ..., ибо удобно"
Ваша - "это ж надо напрягаться разработчикам контроллера - так что не считаю нужным".

Если коротко и резко, то: разработчики напрягаются сделать новые контроллеры и расширить функциональность лоджика. Действительно, гонять их из-за пары ленивых пользователей смысла нет. Именно ленивых, ибо взять макрос и подключить к нему 1 (один) блок 1 (одной) связью - это не сверхзадача.

Извините за резкость, но иначе эту мысль мне до вас донести не получается.

Цитата:

Сообщение от ailcat

В общем, кажется, мы достигли стадии разговора слепого с глухим. За сим предлагаю закончить, НО:
буду признателен, если блок "задержка включения и задержка отключения с заданием времени в миллисекундах" будет включен в программу развития Лоджикса.

Вы не понимаете меня. Это не развитие лоджика, это его тупик. Развитие - это создание СМАрт'а, создание "Навигатора" и подобное. И вот когда это всё уже будет, вот тогда уже можно создавать библиотечные макросы из двух блоков.

Технология CISC уже доказала всему миру свою несостоятельность. Вы хотите пройти 50-летний путь развития информатики заново?


.

[Sergey Cherevko]

Цитата:

Сообщение от ailcat

Но, чёрт возьми, и в полноценных контроллерах все временные задержки задаются специальными блоками в явном виде (в миллисекундах)!

Во-первых, в полноценных контроллерах есть как минимум ДВА механизма обработки критичных ко времени процессов: 1.таймеры в скане/цикле/тике программы, 2.обработчики прерываний по времени и от "быстрых" входов.
Во-вторых, эти механизмы реализованы далеко не во всех современных контроллерах. Даже у сименса, который постоянно приводят в пример, не все процессоры даже в одной линейке это умеют.
В-третьих, назовите макрос, который сюда вчера выкладывал Арсений, явным именем "Timer(ms)" и это будет 100% соответствие "специальному блоку в явном виде".
В-четвертых и самых главных, для системы управления нет никакой разницы в чем вы будете задавать задержки внутри программы. Результат будет одинаков в обоих случаях. Блоки таймеров будут обрабатываться так же синхронно, как счетчики тиков. Об этом здесь уже много раз писалось и ваше упрямство вызывает некоторое недоумение.

[Sergey Cherevko]

Цитата:

Сообщение от ujin

Здесь не только программисты участвуют в обсуждении характеристик контроллеров, но и люди принимающие решения о целесообразности их применения. В том числе и исходя из перспектив развития контроллеров и фирмы которая их производит.

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

[ujin]

Есть еще фирма Сегнетикс.

[Sergey Cherevko]

Да, я тоже про такую слышал.

[ailcat]

Sergey Cherevko
Сергей, даже со своей точки зрения - я вас с Арсением могу понять (что для синхронной ПРОГРАММЫ корректнее задавать задержки в тиках).

В то же время, макрос (который вроде как и несложен) - это сочетание нескольких FBD, соответственно, скорость его обработки будет заведомо хуже, чем у специального блока.
Кому-то это неакутально, у меня же управляемое контроллером оборудование выполняет до 200-300 действий в минуту, что уже заставляет задумываться об уменьшении времени тиков до минимально возможного...

Ну а про "удобство для лентяев" - я бы все же назвал эти функции "прозрачностью задания временных величин". Которое гораздо точнее отражает их назначение.
(кстати, причем тут CISC-процессоры? Тем более, что всё та же История не менее наглядно показала, что RISC в реальных приложениях может быть производительным только в сочетании с CISC- или DSP-довесками?)


РЕЗЮМИРУЮ:
как контроллер "общего применения" SMH-2G имеет низковатое быстродействие (т.е. способен заменить лишь "интеллектуальное реле", хотя и обладает для этой функции избыточным функционалом и немного сложнее в программировании из-за необходимости обзаводиться макросами для испольнения наиболее востребованных в "интеллектуальных реле" функций). Однако он есть отличный выход, когда от "интеллектуального реле" требуется повышенное "юзабилити".
А вот его наследник - SMH-2Gi, - если его производительность действительно на порядок выше, чем у SMH-2G - выглядит отличным выбором для несложных задач автоматизации технологических процессов. Особенно с учетом его умеренной цены и большого дисплея с клавиатурой (и - отмечу особо - действительно развитых возможностей Лоджикса. Отсутствие же временных FB должно компенсироваться высокой производительностью контроллера, быстро выполняющей "времЕнные" макросы)


P.S.
Специально для Арсения, которого когда-то терроризировал по эл.почте:
входы MC действительно оказались устойчивыми к ВЧ-помехам (27MHz при 25kV - отлично "пролазят во все щели" даже при качественном заземлении).
При работе системы МС даже не ловил по входам помеху, на самом SMG-2G входы, правда, пришлось подтянуть к "земле" через резисторы 3к3 - но всё работает без сбоев и замечаний (хотя Овен наглухо вис всего через несколько дестяков включений высокого напряжения). Примерно в середине апреля врубим установку на полную нагрузку (16-18 тыс. изделий за смену) - тогда попробую отчитаться подробнее (вдруг кому пригодится и мой опыт)

[Arsie]

Цитата:

Сообщение от ailcat

Sergey Cherevko
Сергей, даже со своей точки зрения - я вас с Арсением могу понять (что для синхронной ПРОГРАММЫ корректнее задавать задержки в тиках).

В то же время, макрос (который вроде как и несложен) - это сочетание нескольких FBD, соответственно, скорость его обработки будет заведомо хуже, чем у специального блока.

Перерасчёт секунд в тики - один блок. Нужно - ставите, не нужно - не ставите. Самое выгодное решение с точки зрения быстродействия.

По моему опыту создания программ, на каждый десяток счётчиков с заданием в тиках требуется один счётчик с заданием в единицах времени. Итого 9 счётчиков будут зря потреблять ресурсы. Это и процессор и память. Не говоря уже о том, что у меня будет болеть голова за то, чтобы обеспечить синхронизацию программы, т.к. если мне нужно отсчитать именно 3 цикла программы, то мне придётся выдерживать длительность цикла относительно постоянной. Иначе счётчик отсчитает не 3 цикла, а иное число.

Счётчиков в сложном алгоритме как правило несколько десятков.

Ваша точка зрения про "удобства" со стороны чистого программиста выглядит абсурдной. Программист изначально думает иными категориями и число 1000 для него не является круглым

Цитата:

Сообщение от ailcat

Кому-то это неакутально, у меня же управляемое контроллером оборудование выполняет до 200-300 действий в минуту, что уже заставляет задумываться об уменьшении времени тиков до минимально возможного...

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

Цитата:

Сообщение от ailcat

Ну а про "удобство для лентяев" - я бы все же назвал эти функции "прозрачностью задания временных величин". Которое гораздо точнее отражает их назначение.

Повторюсь: программисты думают иными категориями. И с точки зрения циклических программ прозрачнее всего времена задавать именно циклами, т.к. все внутренние события измеряются именно циклами, сколько бы они времени не занимали.

Внешние события выгоднее задавать во внешней временнОй системе - это да. Но для этого нужен всего 1 блок. И он есть. Хотите, подключаете к счётчикам. Хотите - к задержкам. Да хоть к мультиплексорам

У программируемых реле число внутренних событий минимально либо они попросту отсутствуют. В наших же контроллерах их может быть тысячи.

Опять же, я вам давал ссылку на макросы задержек, у которых есть задание как в циклах, так и в секундах. Право, уже не знаю как вам угодить.

Цитата:

Сообщение от ailcat

(кстати, причем тут CISC-процессоры? Тем более, что всё та же История не менее наглядно показала, что RISC в реальных приложениях может быть производительным только в сочетании с CISC- или DSP-довесками?)

Дошло до того, что самые популярные CISC процессоры имеют внутри себя RISC, выполняющий микропрограмму эмуляции этого самого CISC. Это всё равно оказалось много более выгодно, CISC упёрся в стенку ещё в 1992 году.

Про DSP не передёргивайте, у них узкий круг задач, решаемый ими успешно с набором команд зачастую ещё меньшим, чем у RISC.

Цитата:

Сообщение от ailcat

РЕЗЮМИРУЮ:

Не забудьте только дописать "в моём узком кругу задач". А то вы как-то одним махом отправили сотни сложных отлично работающих объектов на помойку.

Цитата:

Сообщение от ailcat

P.S.
Специально для Арсения, которого когда-то терроризировал по эл.почте:
входы MC действительно оказались устойчивыми к ВЧ-помехам (27MHz при 25kV - отлично "пролазят во все щели" даже при качественном заземлении).
При работе системы МС даже не ловил по входам помеху, на самом SMG-2G входы, правда, пришлось подтянуть к "земле" через резисторы 3к3 - но всё работает без сбоев и замечаний (хотя Овен наглухо вис всего через несколько дестяков включений высокого напряжения). Примерно в середине апреля врубим установку на полную нагрузку (16-18 тыс. изделий за смену) - тогда попробую отчитаться подробнее (вдруг кому пригодится и мой опыт)

Полезная информация, спасибо.


.