PRG — самостоятельный элемент, FB — шаблон самостоятельного элемента. Соответственно PRG можно вызвать, а FB — нельзя (вызывается экземпляр, созданный по шаблону).Цитата:
а в чем тогда разница FB и PRG?
Вид для печати
PRG — самостоятельный элемент, FB — шаблон самостоятельного элемента. Соответственно PRG можно вызвать, а FB — нельзя (вызывается экземпляр, созданный по шаблону).Цитата:
а в чем тогда разница FB и PRG?
И откуда такой несусветный бред? :eek: блок PRG выполнился, и далее управление снова передаётся в PLC_PRG, к первой команде после блока. Иначе не было бы особого смысла в подпрограммах.Цитата:
Если модуль имеет тип PRG - то после выполнения будет прерван цикл ПЛК, и часть кода, размещенная после модуля не будет выполняться никогда.
Ничто не мешает в PRG создать VAR_INPUT, VAR_OUTPUT, часто так делаю.Цитата:
У FB есть локальные переменные VAR_INPUT, VAR_OUTPUT, VAR, а у PRG только VAR.
Вставлю свои 5 копеек в интересное обсуждение. На сколько я понимаю PRG - это глобальный элемент и может использоваться в задачах. Его не надо описывать в разделе переменных, а FB напоминает мне описание типа структуры, только с кодом (хотя можно и без него), для его использования надо создать соответствующую переменную.Цитата:
а в чем тогда разница FB и PRG?
А чем это оно интересное? ;) Это азы языка, поддерживающего ООП, без них далеко не "уедешь".Цитата:
Вставлю свои 5 копеек в интересное обсуждение.
Просто на этом форуме многие учатся азам, а в документации не всегда таким мелочам уделяется внимание.
Что , понижение IQ глобальное , или память подзафрагментировалась?!
И не лузеры вроде-бы :
ВОЛЬД - У PRG Легко могут быть переменные var_input and var_output.
Функциональный блок или функция вызывается с присвоением входных переменных и выходных , при этом функциональный блок отличается от функции тем , что у него может быть выхдных переменных более 1й . Программа вызывается просто по имени.
Но! В ST можно ВСЕ вызвать просто по имени и оно выполнится , но как ... одному процессору ведомо .
В приложенном проекте каша какая-то , должна быть ИЕРАРХИЯ , а там ... как будто кто-то специально извратился , чтобы все запутать .
Кстати программу по идее в ST можно вызвать даже из функционального блока и это выполнится , но .... результат выполнения программы (ЛЮБОЙ) тот , что соответствует логике процессора и не всегда соответствует желанию (хотению , думке и тд) программиста.
-------------------------------
функциональный блок или функция (зависит от функционала) применяются для вызова ЭКЗЕМПЛЯРА КОДА с различными присвоенными входными значениями в СКАНЕ программы . Типа TON или аналогичными .
НО !
Все , что написано корректно с точки зрения компилятора БУДЕТ ВЫПОЛНЕНО !!! Единственное условие выхода из Экземпляра программы или функционального блока или функции - оператор RETURN !
--------------------------------
Интересно сам Афтар логическую цепочку приложенной программы просекает ?
Я особо не разгребал , но в примерах открытие-запись-закрытие выполняется в одном цикле , какого ... разбивать процесс оператоом CASE ??? И !!! делать это в экземпляре ФБ !!!
Есть инструмент хороший TRACE с его помощью можно проследить что и когда реально происходит .
--------------------------------
Сегодня , или нет уже вчера День города КРАСНОДАР . 220 с каким-то лет , более чем государствам некоторым , например США.:)
Такое краткое замечание вызвало такую длинную полемику:)
Хотя бы иногда нужно пользоваться справкой.
Вложение 14529 Вложение 14528
1) Не только в ST
2) Полностью согласен. А часть кода вообще лишняя.
Например
Вложение 14530
3)"открытие-запись-закрытие выполняется в одном цикле" Не верное утверждение, каждое условие CASE будет выполняться в разные циклы ПЛК.
"И !!! делать это в экземпляре ФБ !!!" нет там никаких экземпляров ФБ:)
Вложение 14532
Хотя ненужно было использовать CASE внутри одного шага программы на SFC, но по другой причине. Ведь каждое условие CASE эквивалентно отдельному шагу SFC. Можно было операции открытие-запись-закрытие файла и открытие-чтение-закрытие файла сделать отдельными шагами SFC.
Как ни странно, но если разрешать в проекте работать только "Read_Tools_Gidropushitel" или только "Write_Tools_Gidropushitel", то операции чтения из файла и запись в файл работают корректно.
А не работает программа по тому, что "сам Афтар логическую цепочку приложенной программы НЕ просекает". И согласно ошибке,имеющейся в логике программы, при попытке записать в файл по команде с панели, одновременно будут работать обе подпрограммы - "Write_Tools_Gidropushitel" и "Read_Tools_Gidropushitel".:(
ЗЫ. Не смотря на то, что каждое условие CASE будет выполняться в разные циклы ПЛК, в коде есть ошибка. В результате которой закрытие файла будет происходить сразу после записи в файл или чтения из файла, в одном и том же цикле ПЛК (в одном и том же условии CASE)
Вложение 14536
Бубны в сторону:rolleyes:.
И так, что нужно изменить в программе, что бы файлы и писались и читались
1. В коде HMI(PRG) нужно сделать такие изменения
Вложение 14537
Теперь в принципе все должно работать, по крайней мере в PLCWinNT сразу начинает работать(у меня нет возможности проверить в ПЛК110).
Но лучше продолжить изменения в проекте.
2. С учетом этого замечанияВ код действия для Step1 программы Read_Tools_Gidropushitel нужно внести измененияЦитата:
Не смотря на то, что каждое условие CASE будет выполняться в разные циклы ПЛК, в коде есть ошибка. В результате которой закрытие файла будет происходить сразу после записи в файл или чтения из файла, в одном и том же цикле ПЛК (в одном и том же условии CASE)
Вложение 14538
А в код действия для Step1 программы Write_Tools_Gidropushitel нужно внести такие изменения
Вложение 14539
3. У автора почему-то не предусмотрено чтение сохраненной информации из файла после старта ПЛК :confused:. Тогда к чему все эти "нелепые телодвижения" с сохранением настроек в файл?
Исправить этот недостаток очень просто. Нужно добавить начальное значение переменной "State_Read_Tools_Gidropushitel"
Вложение 14540
Это разрешит однократное чтение настроек из файла и передачу сохраненных значение в панель при старте ПЛК.
В SFC программах "Read_Tools_Gidropushitel" и "Write_Tools_Gidropushitel" есть много несуразностей, которые требуют отдельного обсуждения
Не сочтите за невежество попробую оправдаться по поводу кода
- Объявленные переменные но отсутствующие в коде - просто части кода не имеющие отношения к проблеме были удалены чтобы не загружать лишним видимо обрывки остались :) конкретно переменная Count
- Cоunt_prg=100 потому что чтобы исключить заход в шаг Step2_Re.... когда начинались танцы с бубном в этом шаге читались настройки из файла при Cоunt_prg=1 при старте
-Просто хотел сделать меньшее количество шаговЦитата:
Хотя ненужно было использовать CASE внутри одного шага программы на SFC, но по другой причине. Ведь каждое условие CASE эквивалентно отдельному шагу SFC. Можно было операции открытие-запись-закрытие файла и открытие-чтение-закрытие файла сделать отдельными шагами SFC.
По поводу чтения- записи литература, говорит автора не вспомню: чтение, открыл- прочитал -закрыл лучше разделять на несколько циклов
запись: открыл-записал-закрыл то же несколько циклов поэтому СASE
"Read_Tools_Gidropushitel" "Write_Tools_Gidropushitel" вызываются вместе но одновременно не находятся в шагах записи и чтения вернее наверное не должны находится.
Вот где собака зарыта.Цитата:
Не смотря на то, что каждое условие CASE будет выполняться в разные циклы ПЛК, в коде есть ошибка. В результате которой закрытие файла будет происходить сразу после записи в файл или чтения из файла, в одном и том же цикле ПЛК (в одном и том же условии CASE)
Видимо когда копировал часть кода с другой программы для плк 100 что то за парил - спешка нужно при ловле блох.
Да еще и опыта маловато пробелы в мат части начинаешь просто иной раз загоняться и начинают терзать сомнения :)
а сомнения от не знания поэтому Оооогромное человеческое СПАСИБО!! всем тем кто подсказывает нам с какой стороны легче грызть гранит науки!!
Как доберусь до компа сразу возьмусь за исправления с учетом замечаний еще раз большое спасибо всем откликнувшимся