FBD чайникам

[Arsie]

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

И еще один вопросик. Можно ли в Лоджике измерить время между двумя импульсами. Нужно для измерения мгновенного расхода. На форуме искал, справку читал, из стандартных блоков ничего не подходит. В Кодесисе есть блок FREQ_MEASURE, на базе его и делали. Пробовал пример который нашел на форуме, но работает он немного не так.

Это делает счётчик для медленных импульсов и математика для быстрых.

Счётчик покажет, сколько тиков сигнал был пассивен.

Математика (кол-во импульсов делить на время замера) покажет длительность.

PS. Расход - это не расстояние между импульсами, это расстояние между фронтами импульсов.

[GTS]

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

Это делает счётчик для медленных импульсов и математика для быстрых.

Счётчик покажет, сколько тиков сигнал был пассивен.

Математика (кол-во импульсов делить на время замера) покажет длительность.

PS. Расход - это не расстояние между импульсами, это расстояние между фронтами импульсов.

Блок FREQ_MEASURE измеряет частоту следования импульсов. Причем период измерения мы не использовали, в этом блоке устанавливается количество периодов для усреднения.
"Счётчик покажет, сколько тиков сигнал был пассивен." - но это не время между фронтами импульсов!

[Arsie]

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

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

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

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

"Счётчик покажет, сколько тиков сигнал был пассивен." - но это не время между фронтами импульсов!

Первый фронт запускает счётчик, второй фронт останавливает. Получается время между фронтами.

[GTS]

Мы не обсуждаем кодесис, это пример реализации счетчика на другой платформе. Частотный вход вы имеете ввиду FREQ? Насколько я понял, у него есть ограничения? Меньше 1 ГЦ он не считает?

"Первый фронт запускает счётчик, второй фронт останавливает. Получается время между фронтами."
Покажите как или чем это сделать!

[Arsie]

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

Мы не обсуждаем кодесис, это пример реализации счетчика на другой платформе. Частотный вход вы имеете ввиду FREQ? Насколько я понял, у него есть ограничения? Меньше 1 ГЦ он не считает?

Период измерения 1 сек. Даже 2 герца уже маловато для него.

Поэтому призываем на помощь математику:

1) запоминаем показания счётчика

2) отмеряем не одну секунду, а нужное нам количество секунд

3) вычитаем из текущих показаний те, которые запомнили и делим на количество секунд

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

"Первый фронт запускает счётчик, второй фронт останавливает. Получается время между фронтами."
Покажите как или чем это сделать!

D-триггер обеспечит переключение входа "+" счётчика. Первый импульс на строб триггера взведёт его, подав на счётчик разрешение на счёт. Второй импульс сбросит триггер, запретив счётчику считать.

[GTS]

Поэтому призываем на помощь математику:

1) запоминаем показания счётчика

2) отмеряем не одну секунду, а нужное нам количество секунд

3) вычитаем из текущих показаний те, которые запомнили и делим на количество секунд


Вы чего этими умозаключениями посчитать собираетесь, расход? Какой, зачем? У меня есть 32 счетчик, я знаю все его характеристики: 1 имп=10л, Qmin=0,24 м3/ч, Qmax=12 м3/ч, Qnom=6 м3/ч. Итого, даже при Qmax F=0,33 Гц частотный вход не соответствует нашим требованиям, про Qmin молчим. Это к слову: " Поясните, пожалуйста, зачем мы вообще обсуждаем кодесис, если вы используете счётные входы модуля МС, у которого частота считается аппаратно?" Я задал простой вопрос, как померить время между Фронтами импульсов или частоту следования этих импульсов. Если бы вход FREQ работал должным образом или был вышеуказанный блок для замера частоты я бы Вам, уважаемый, не задавал вопросы. Если у Вас в Лоджике нет этой возможности, просто покажите как вы справляетесь с этой задачей с помощью костылей!!! Я просто уже не знаю как Вас любезно попросить, или этот труд денег стоит?

[ATS]

Ну примерно так Расход.msl. С измерением периода. cntr - счетный вход MC, MR, 2Gi

[Arsie]

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

Вы чего этими умозаключениями посчитать собираетесь, расход?

Расход именно так и считается. Любыми счётчиками на любом железе. Даже упомянутый вами блок кодесиса считает ровно также.

Вот вы только-только написали мне конкретные данные. Но почему-то уже успели дважды обидеться на то, что я даю вам расплывчатые советы. Извините, но на плохие вводные можно дать только плохие советы.

Теперь касаемо умозаключений. Я понимаю, что вы наш клиент и можете себе позволить меня хоть матом крыть. Но вы задаёте вопросы, который касаются теории АСУ, а не конкретных продуктов. То, что я вам советовал ранее и советую сейчас - это как таблица умножения в математике. Это базовые основы АСУ, не зависящие не от лоджика, ни от кодесиса, ни от кого-либо.

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

Ну примерно так Вложение 4314. С измерением периода. cntr - счетный вход MC, MR, 2Gi

Используйте CNTR(16) и выход EU, иначе ошибка на один тик будет на каждый цикл измерений.

[LordN]

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

Расход именно так и считается. Любыми счётчиками на любом железе. Даже упомянутый вами блок кодесиса считает ровно также.

Вот вы только-только написали мне конкретные данные. Но почему-то уже успели дважды обидеться на то, что я даю вам расплывчатые советы. Извините, но на плохие вводные можно дать только плохие советы.

Теперь касаемо умозаключений. Я понимаю, что вы наш клиент и можете себе позволить меня хоть матом крыть. Но вы задаёте вопросы, который касаются теории АСУ, а не конкретных продуктов. То, что я вам советовал ранее и советую сейчас - это как таблица умножения в математике. Это базовые основы АСУ, не зависящие не от лоджика, ни от кодесиса, ни от кого-либо.

все равно былоб неплохо иметь на счетном входе или время следования импульсов или их частоту. на низком уровне это таки проще и надежней сделать чем на верхнем..

[Arsie]

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

все равно былоб неплохо иметь на счетном входе или время следования импульсов или их частоту. на низком уровне это таки проще и надежней сделать чем на верхнем..

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

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

На верхнем даже наверное понадёжнее, т.к. можно детектить провалы питания и подобное.

[ATS]

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

Используйте CNTR(16) и выход EU, иначе ошибка на один тик будет на каждый цикл измерений.

Там лишний тик вычитается... И кстати это не цикл измерения.

[Arsie]

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

Там лишний тик вычитается... И кстати это не цикл измерения.

Да, действительно. А что же тогда считает счётчик, если это не цикл измерения?

[GTS]

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

Ну примерно так Вложение 4314. С измерением периода. cntr - счетный вход MC, MR, 2Gi

Спасибо за пример, увидел наконец как считается время между импульсами.

[Arsie]

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

Спасибо за пример, увидел наконец как считается время между импульсами.

Это не подсчёт времени между импульсами. Это готовый компонент пересчёта количества импульсов за период времени в частоту.

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

[GTS]

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

Расход именно так и считается. Любыми счётчиками на любом железе. Даже упомянутый вами блок кодесиса считает ровно также.

Вот вы только-только написали мне конкретные данные. Но почему-то уже успели дважды обидеться на то, что я даю вам расплывчатые советы. Извините, но на плохие вводные можно дать только плохие советы.

Теперь касаемо умозаключений. Я понимаю, что вы наш клиент и можете себе позволить меня хоть матом крыть. Но вы задаёте вопросы, который касаются теории АСУ, а не конкретных продуктов. То, что я вам советовал ранее и советую сейчас - это как таблица умножения в математике. Это базовые основы АСУ, не зависящие не от лоджика, ни от кодесиса, ни от кого-либо.




Используйте CNTR(16) и выход EU, иначе ошибка на один тик будет на каждый цикл измерений.

1) Хоть убей не понимаю зачем мне стоять у счетчика с секундомером если у меня есть все данные на счетчик.
2) Велик и могуч наш родной язык и я никогда бы не подумал что слово "умозаключения" относится к оскорбительным.
3) Матом крыть незнакомого человека который мне ничего плохого не сделал последнее дело, я этим не занимаюсь.
4) Я у Вас лекций по ТАУ не просил, хотя всегда рад любой помощи, и благодарен за неё. Мой вопрос был: Как в Лоджике можно измерить частоту, какими блоками?
5) Человек за один пост показал, то что мы с вами выясняли наверно в 15.
6) Почему бы вам (Сегнетикс) не сделать такой макрос стандартно в библиотеке.
По-моему мы с Вами друг друга не поняли, предлагаю удалить этот пост, дабы не засорять форум и перейти к конструктивному диалогу.

[ATS]

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

Это не подсчёт времени между импульсами. Это готовый компонент пересчёта количества импульсов за период времени в частоту.
Если вам нужно именно считать время между импульсами, то это делается не так.

Правда? А я период измеряю...
И этот вариант для частот меньше 1 герца (период больше 5-10 тиков)

[maks]

Трим. Необходимо создать массив в энергонезависимой памяти, в котором фиксируется время включения и выключения трима. Это возможно?

[LordN]

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

Трим. Необходимо создать массив в энергонезависимой памяти, в котором фиксируется время включения и выключения трима. Это возможно?

если речь о снятии и подаче питания, то:
включение делается просто, любой фронт в начале программы + готовность блока записи в ЕЕ
выключение уже требует внешнего сигнала, обработанного раньше, чем кончится питание на триме.
на пикселе хватало овеновского бп30 или бп60 с реле на фазе и контактами на ди.

[maks]

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

если речь о снятии и подаче питания, то:
включение делается просто, любой фронт в начале программы + готовность блока записи в ЕЕ
выключение уже требует внешнего сигнала, обработанного раньше, чем кончится питание на триме.
на пикселе хватало овеновского бп30 или бп60 с реле на фазе и контактами на ди.

Спасибо, это понятно. Хотелось бы обойтись совсем без внешних компонентов. Ведь трим живет еще 5-10 секунд после отключения питания и, возможно, есть какая-то служебная информация о том, что питание отключено.

[LordN]

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

Спасибо, это понятно. Хотелось бы обойтись совсем без внешних компонентов. Ведь трим живет еще 5-10 секунд после отключения питания и, возможно, есть какая-то служебная информация о том, что питание отключено.

нужно только что-то внешнее, 146%.

[Arsie]

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

Спасибо, это понятно. Хотелось бы обойтись совсем без внешних компонентов. Ведь трим живет еще 5-10 секунд после отключения питания и, возможно, есть какая-то служебная информация о том, что питание отключено.

Не живёт. Спит. А потом молча умирает, если не подали питание.

[maks]

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

Не живёт. Спит. А потом молча умирает, если не подали питание.

Т.е. даже не надеяться, что будет системный бит "отключено питание" ?

[LordN]

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

Т.е. даже не надеяться, что будет системный бит "отключено питание" ?

интересно, как вы себе представляете такой системный бит при диапазоне входного ac/dc 24...230?
тут целый отдельный контроллер придётся ставить

[Arsie]

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

Т.е. даже не надеяться, что будет системный бит "отключено питание" ?

Даже если его и вывести в FBD, то как спящий контроллер его обработает? Он же спит.

Типовое промышленное решение - это автономный источник тока, который позволяет контроллеру работать некоторое время после отключения. У сименса это специальные блоки питания с батарейками/аккумуляторами для той же 400-й серии.

Это доступно и нам. Покупаете самый дешёвый ИБП и получаете автономность на несколько минут. Формируйте что вам нужно и обрабатывайте как нужно. Всё равно это гораздо дешевле специализированных БП от сименса)

[maks]

Реле, модуль ввода дискретного сигнала, ИБП и это все, чтобы зафиксировать отключение питания. Это все будет стоить как Трим

[LordN]

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

Реле, модуль ввода дискретного сигнала, ИБП и это все, чтобы зафиксировать отключение питания. Это все будет стоить как Трим

защита от дурака всегда стоит громадных денег, гипербола же, чем меньше шансов вы хотите оставить дураку, тем дороже это стоит.
оптимальное число = 1, но попробуйте чуть сдвинуть шансы дурака к нулю - и цены сразу полетели.

[Arsie]

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

Реле, модуль ввода дискретного сигнала, ИБП и это все, чтобы зафиксировать отключение питания. Это все будет стоить как Трим

Модуль-то зачем? Трим явно не автономно будет использован. Как пропала связь с локальными устройствами, так значит питание и вырубили.

Остальное ЛордН правильно написал: чем больше наворотов, тем дороже. Раскрою секрет, изначально мы планировали дать автономность на 30 сек, но это выливалось в 15 евро на прибор. Отказались.

[LordN]

вопрос, м.б. и не про фбд, но суть такая:
в некоторых случаях надо иметь возможность мониторить систему, но при этом зак хочет иметь уверенность, что в это время какой-нить программист не решит перезалить проект.
вопщем надо какую-то страховку от загрузки нового проекта при полностью управляемом по сети контроллере. коряво выразился, но как-то так.
речь конкретно о 2Gi и ему подобным.
речь не о безусловной защите, а о каком-нить типа индикаторе чтоли - на контроллере включена защита от загрузки проекта или както так.
и/или
для модуле МС МР и т.д. сейчас можно в конфиге выбрать только какой-то один безопасный уровень 0/1.
нет ли возможности сделать что-то типа защелки для выхода на время потери связи с контроллером, при перезаливке проекта и т.д.
т.е. был выход в 1, и остается в ней пока не появится связь и т.д.
разумеется решение должен принимать программист.

[Arsie]

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

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

Защита проста: придумываете новый пароль рута и без него ничего не получится сделать удалённо. Чем сложнее пароль, тем абсолютнее защита.

При этом контроллер полностью управляем с точки зрения прикладного проекта. Шины расширения шинят, модбас модбасит и т.д. А вот залить проект не получится.

Как появится необходимось программисту залить проект, меняете пароль на стандартный или известный этому программеру, он заливает и меняете обратно.

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

для модуле МС МР и т.д. сейчас можно в конфиге выбрать только какой-то один безопасный уровень 0/1.
нет ли возможности сделать что-то типа защелки для выхода на время потери связи с контроллером, при перезаливке проекта и т.д.
т.е. был выход в 1, и остается в ней пока не появится связь и т.д.
разумеется решение должен принимать программист.

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

[LordN]

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