Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Beremiz
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Программирование
Страницы: 1, 2, 3
yanvasiij
Доброго времени суток!

Несколько слов о том, что я делаю и что получается.
Озадачился портированием вышеупомянутого ПО. Идея была такая: поскольку Beremiz компилирует входные исходники на языках IEC в Си, то эти исходники можно далее компилировать на чем угодно в том числе и под микроконтроллеры. Тогда я взял GCC под ARM embed (GNU Tools ARM Embedded), написал несложный рантайм (если это так можно назвать), который вызывает апи беремиза в задачах ртос. Делал по аналогии с тем как это сделано под платформу Xenomai (.\bremiz\targets\Xenomai). Далее организовал папочку STM32 в .\bremiz\targets c необходимыми питонячими файлами, задача которых прилинковывать при компиляции мой рантайм, плюс несколько несложных манипуляций над исходниками самого Beremizа, чтобы он при компиляции использовался gcc. Теперь в результате компиляции программы на IEC в Beremiz получаю hex готовый для зашивки в микроконтроллер.

Теперь собственно проблема. Для того, чтобы появилась связка между конкретным железом и программой, нужно в beremizу написать плагин и разместить его в папочке plugins, в котором и будет описание связки с "железом". Запустить эти плагины у меня так и не вышло. Я уже не раз видел упоминание Beremiza на этом форуме. Кто-нибудь писал эти плагины? Я бы был очень признателен, если бы мне ответили на несколько вопросов.
unkier
немножко копнул беремиз. давай вместе подумаем. у меня такие же хотелки.
yanvasiij
Вытащил все из официального репозитраия и посмотрел по коммитам: начиная с определенной версии исчезла папка plugins. Плагины теперь не так добавляются. Поэтому начал курить исходники. Я не силен питоне, поэтому удалось придумать пока только следующее: добавил еще одну папку STM32, покидал туда мною созданные питонячие файлы, в которых планирую привязваться к железу. Теперь в дереве проекта можно добавлять еще один тип:

Нажмите для просмотра прикрепленного файла

Пока уперся в то, что не совсем понимаю, как делать привязку гуя к плагину.
unkier
мне про matiec больше интересно. всё равно всё потом им кампилится в C. как сделать вызов сишной функции из кода на IEC языках. вообще не понятно.
yanvasiij
Цитата(unkier @ Jan 5 2016, 21:24) *
мне про matiec больше интересно. всё равно всё потом им кампилится в C. как сделать вызов сишной функции из кода на IEC языках. вообще не понятно.


Очень просто: matiec генерирует С файл, в котором производится вызов, например, Вашей функции в которой происходит связь с железом. А эту функция реализована в другом сишном файле. Потом нужно взять все эти сишные файл скомпилить, например в GCC и слинковать. У меня все это делает Beremiz - сначала передает все необходимые данные matiec'y далее берет результат его работы компилирует в gcc и силнковывает с файлом, где реализована привязка с железом.
unkier
точно, всё оказалось просто )

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

voodoojah
Извините, конечно, не в тему, но вопрос очень волнует.
Вам не приходилось сталкиваться с проблемами при написании в Beremiz функционального блока с передачей массива в качестве параметра?
Я имею в виду ФБ, написанный на C, и подключаемый на target-платформе в виде shared object library. А его описание в виде .xml и .py файла добавленное в beremiz.

Объявить массив переменных в xml файле, описывающем функциональный блок не получается, или я не знаю как. Никакой документации по этому вопросу найти не смог.
Если я правильно все понял, разработчики поддержки такой возможности не делали. На вопросы отвечают очень долго, месяцами.

Пробовал объявить в ФБ параметр, такого же типа как элемент моего массива и передавать первый член массива как аргумент. Предполагалось, что раз массив все равно указатель, а в ФБ передается тоже указатель, то в своем сишном коде я его спокойно разименую и буду использовать.
Но схитрить не получается, при вызове функционального блока, передается не указатель на массив, а указатель на структуру data__, которая перед этим инициализируется значениями из local и global переменных. Таким образом первый член массива передается по значению, как добраться до остальных, непонятно.

Если сталкивались, то как решали? Если я сам что то по глупости упустил, укажите, пожалуйста)
yanvasiij
Обнаружил багу в matiec. При использовании функциональных блоков внутри функций или других функциональных блоков генерируется код, который присваивает структурам целочисленные значения. При компиляции в gcc это приводит к ошибкам. Очень жаль (((
yanvasiij
После беседы в mailing list было "официально" признано, что это бага в matiec. Имейте ввиду, если вы сами это не исправляли, то это бага у вас есть.
yanvasiij
Аналогичная ошибка при передаче массивов параметрами в функции и функциональные блоки.
yanvasiij
Нашел еще несколько очень неприятных ошибок в самом беремизе и matiec, касающиеся пользовательских типов данных.
Без исправления всех вышеперечисленных ошибок использовать беремиз+matiec для компляции более или менее серьезных АСУшных проектов невозможно. Я перенес на беремиз один реальный АСУшный проект (написанный для шнайдеровского контроллера), который использовал большое количество переменных, функциональных блоков, функций, пользовательских типов и т.п. После адаптации обнаружились все эти неприятности. Напрашивается печальный вывод: либо ждать когда исправления появятся в официальном репозитарии, либо обзавестись терпением и самому начать курить исходники matiec, либо не использовать вообще.
griabig
Цитата(yanvasiij @ Apr 7 2016, 14:54) *
Нашел еще несколько очень неприятных ошибок в самом беремизе и matiec, касающиеся пользовательских типов данных.
Без исправления всех вышеперечисленных ошибок использовать беремиз+matiec для компляции более или менее серьезных АСУшных проектов невозможно. Я перенес на беремиз один реальный АСУшный проект (написанный для шнайдеровского контроллера), который использовал большое количество переменных, функциональных блоков, функций, пользовательских типов и т.п. После адаптации обнаружились все эти неприятности. Напрашивается печальный вывод: либо ждать когда исправления появятся в официальном репозитарии, либо обзавестись терпением и самому начать курить исходники matiec, либо не использовать вообще.


Предлагаю объединить усилия и допилить Beremiz/matiec до рабочего состояния. Я исправил некоторые ошибки, которые мне попались в работе в своем репозитории. Кстати, там сделана русская локализация пользовательского интерфейса. Есть части, которые не переведены еще. Но это части кода, которые вообще без поддержки локализации написаны. Это я поправлю, как буду на них натыкаться.

По поводу matiec ничего не могу сказать. Только белгло просмотрел код. Там надо разбираться.
Кстати проблемы, касающиеся matiec, мне кажется, что лучше описывать еще на баг-трекере.


yanvasiij
Цитата(griabig @ Apr 19 2016, 16:17) *
Предлагаю объединить усилия и допилить Beremiz/matiec до рабочего состояния. Я исправил некоторые ошибки, которые мне попались в работе в своем репозитории. Кстати, там сделана русская локализация пользовательского интерфейса. Есть части, которые не переведены еще. Но это части кода, которые вообще без поддержки локализации написаны. Это я поправлю, как буду на них натыкаться.

По поводу matiec ничего не могу сказать. Только белгло просмотрел код. Там надо разбираться.
Кстати проблемы, касающиеся matiec, мне кажется, что лучше описывать еще на баг-трекере.


Поддерживаю Ваше предложение! По поводу баги в matiec я писал Марио на личную почту, он мне ответил обещал исправить.
griabig
Цитата(yanvasiij @ Apr 21 2016, 07:36) *
Поддерживаю Ваше предложение! По поводу баги в matiec я писал Марио на личную почту, он мне ответил обещал исправить.

Замечательно! Но если забудет, то тогда добавим в баг-трекер. Так надежней, уже точно не потеряется.
paulbell
Цитата(yanvasiij @ Apr 6 2016, 11:25) *
Обнаружил багу в matiec. При использовании функциональных блоков внутри функций или других функциональных блоков генерируется код, который присваивает структурам целочисленные значения. При компиляции в gcc это приводит к ошибкам. Очень жаль (((


Здравствуйте, глянул IEC 61131-3:
> 2.5.1 Functions
>...
>Functions shall contain no internal state information, i.e., invocation of a function with the same
>arguments (input variables VAR_INPUT and in-out variables VAR_IN_OUT) shall always yield
>the same values (output variables VAR_OUTPUT, in-out variables VAR_IN_OUT and function
>result).
> It shall be an error if external variables as defined in 2.4.3 cause the violation of this rule.
>...
> 2.5.2 Function blocks
>...
>All the values of the output variables and the necessary internal variables of this data structure
>shall persist from one execution of the function block to the next; therefore, invocation of a
>function block with the same arguments (input variables) need not always yield the same output
>values
>...


Использовать ФБ внутри функций, похоже, нельзя, т.к. при этом невозможно гарантировать,
что функция будет выдавать одни и те же результаты при одних и тех же входах.

Относится ли это к использованию ФБ в качестве входного параметра, не поняно...

yanvasiij
Нельзя, я писал об это лично Марио. Он мне ответил, что это по его мнению даже логично и будет ли он это менять пока не знает.

Но момент с функциональными блоками не такой неприятный, как ошибки вроде той, что проявляется при работе со вложенными CASE'ми. Вот тут я об этом писал.

А это не Вы, тот самый Paul, что выложил ссылку в майлинг листе на свой git-репозитарий? (была неверная ссылка, отредактировал)
paulbell
Цитата(yanvasiij @ Jul 18 2016, 16:41) *
А это не Вы, тот самый Paul, что выложил ссылку в майлинг листе на свой git-репозитарий? (была неверная ссылка, отредактировал)


Да, это я.

Цитата(yanvasiij @ Jul 18 2016, 16:41) *
Но момент с функциональными блоками не такой неприятный, как ошибки вроде той, что проявляется при работе со вложенными CASE'ми. Вот тут я об этом писал.


Ооо, вот это уже более серёзно.

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

Там есть одна беда: тестовая инфраструктура не проработана, совсем.

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

А ещё я не спец по пром автоматизации, я системный программист, связку Beremiz/matiec использовал только потому, что это единственный живой FLOSS-проект.

Соответственно если что-то делать нужны:
а) тестовые файлы (для регрессионного тестирования)
б) кто-то, кто сможет проконсультировать по МЭКовским языкам.
в) время, которого мало, ибо мне надо писать прошивки для трёх приборов...
г) специалист по питону, ибо в)






yanvasiij
Что касается matiec, там действительно все сложно. Это компилятор писался с помощью yacc и bison (инструменты для написания собственных компиляторов). Я сам в этом не шибко силен, насколько я это все понимаю вручную там пишутся только так называемые обработчики токенов, остальное автогенериться с помощью yacc и bison. Поэтому половина кода из репозитария matiec автогенерённая и разобраться там очень сложно.

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

Касательно питона, по самому Beremiz'y очень активное участие проявляет Андрей Скворцов (здесь он griabig). Если есть какие-то замечания, баги рекомендую писать в его баг-трекер, он достаточно оперативно реагирует.

А вот ваши наработки по поводу пошаговой отладки STM32F из беремиза очень интересны. Я так понял отладку вы реализовали через последовательный порт?
paulbell
Цитата(yanvasiij @ Jul 19 2016, 11:15) *
Касательно питона, по самому Beremiz'y очень активное участие проявляет Андрей Скворцов (здесь он griabig). Если есть какие-то замечания, баги рекомендую писать в его баг-трекер, он достаточно оперативно реагирует.

А вот ваши наработки по поводу пошаговой отладки STM32F из беремиза очень интересны. Я так понял отладку вы реализовали через последовательный порт?


Да, через последовательный порт.

Только пошаговой отладки (в смысле прошагивание инструкций) там нет, есть просмотр переменных и лога,
насколько я понял, в Beremiz всё этим и ограничивается, я не видел там свидетельств возможность "шагать", как в том же Си.

Хотя я текстовые языки там не тыкал, могу ошибаться...




Цитата(yanvasiij @ Jul 18 2016, 16:41) *
Но момент с функциональными блоками не такой неприятный, как ошибки вроде той, что проявляется при работе со вложенными CASE'ми. Вот тут я об этом писал.



Кстати, а тот код пробовали обрабаывать с помощью iec2iec? Что генерируется в этом случае?
yanvasiij
Цитата(paulbell @ Jul 19 2016, 11:52) *
Кстати, а тот код пробовали обрабаывать с помощью iec2iec? Что генерируется в этом случае?


Я если честно не совсем понимаю что делает iec2iec, поэтому и не пробовал. Если не затруднит растолкуйте для чего он? Я пробовал через консоль отправлять тот код в iec2c.exe, в генерированном им коде и была та злосчастная ошибка.
paulbell
Цитата(yanvasiij @ Jul 19 2016, 12:02) *
Я если честно не совсем понимаю что делает iec2iec, поэтому и не пробовал. Если не затруднит растолкуйте для чего он? Я пробовал через консоль отправлять тот код в iec2c.exe, в генерированном им коде и была та злосчастная ошибка.



По задумке автора, он нужен для контроля корректности работы парсера (как раз той самой части, которая на bison и yacc/flex ):
берем исходник на ST/LD/SFC, преобразуем в ST, сравниваем с оригиналом, если парсер отработал корректно, - должен получиться оригинал, или что-то близкое к нему.

То есть это нужно для проверки корректности генерации AST и символьных таблиц, из которых в последствии генерируется код на Си.

Такой подход позволяет отделить баги прасера и баги кодогенератора.
yanvasiij
Только что сделал следующее:

Код
..\..\matiec\iec2iec.exe -I ..\..\matiec\lib generated_plc.st > output.txt


В файле generated_plc.st было следующее

CODE
PROGRAM casetest
VAR
LocalVar0 : DINT;
LocalVar1 : DINT;
END_VAR

case LocalVar0 of
0..127:
localvar0 := 1;
case LocalVar1 of
600:
localvar0 := 1;
else
localvar0 := 1;
END_CASE;
end_case;
END_PROGRAM


CONFIGURATION config

RESOURCE resource1 ON PLC
TASK tast1(INTERVAL := T#100ms,PRIORITY := 0);
PROGRAM ubs1 WITH tast1 : casetest;
END_RESOURCE
END_CONFIGURATION


В файле output.txt оказало дофига отладочной информации, но в самом конце было следующее:

CODE
{enable code generation}PROGRAM casetest
VAR
LocalVar0 : DINT;
LocalVar1 : DINT;
END_VAR

CASE LocalVar0 OF
0 .. 127:
localvar0 := 1;
CASE LocalVar1 OF
600:
localvar0 := 1;
ELSE
localvar0 := 1;
END_CASE;
END_CASE;
END_PROGRAM


CONFIGURATION config
RESOURCE resource1 ON PLC
TASK tast1 (INTERVAL := TIME#100ms, PRIORITY := 0);
PROGRAM ubs1 WITH tast1 : casetest;
END_RESOURCE
END_CONFIGURATION


Смею предположить, что парсер отработал все верно.
paulbell
Цитата(yanvasiij @ Jul 19 2016, 12:57) *
Смею предположить, что парсер отработал все верно.



Похоже на то, значит баг в кодогенераторе...


Марио не говорил, какой IDE он пользуется для отладки?

Судя по всему Eclipse, но я не наблюдаю некоторых файлов...



Цитата(yanvasiij @ Jul 19 2016, 12:57) *
Только что сделал следующее:

Код
..\..\matiec\iec2iec.exe -I ..\..\matiec\lib generated_plc.st > output.txt



ОПАЧКИ!

Судя по путям к iecstdlib, у Вас старая версия matiec, скорее всего из Beremiz 1.1,
после этого Марио переписал часть кодогенератора, в частности переписывалась обработка кейсов:
https://bitbucket.org/mjsousa/matiec/commit...e31e?at=default

Дома вечером попробую скомпилить это же код более новой версии iec2c.


А нет, перепутал с сишной частью.

А все таки какая у Вас версия matiec?
yanvasiij
Код
iec2iec.exe -v
matiec version 0.1
changeset id: 7518955c875a


Мы форкнулись от сюда. Уже успели внести некоторые поправки кастельно глобальных переменных. Но изменения из основного репозитария время от времени вытаскиваем.

По-поводу IDE у Марио я не спрашивал, мы редактировали в NetBeans. Но Вы можете ему написать, он достаточно отзывчивый товарищ.
paulbell
Цитата(yanvasiij @ Jul 19 2016, 14:08) *
Код
iec2iec.exe -v
matiec version 0.1
changeset id: 7518955c875a


Мы форкнулись от сюда. Уже успели внести некоторые поправки кастельно глобальных переменных. Но изменения из основного репозитария время от времени вытаскиваем.

По-поводу IDE у Марио я не спрашивал, мы редактировали в NetBeans. Но Вы можете ему написать, он достаточно отзывчивый товарищ.


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

yanvasiij
Этот комит в моей сборке есть.

Ого! Вы правы! Сейчас выкачал последние комиты пересобрал матик и попробовал собрать это код - собралось, работает!
paulbell
Цитата(yanvasiij @ Jul 19 2016, 15:12) *
Этот комит в моей сборке есть.

Ого! Вы правы! Сейчас выкачал последние комиты пересобрал матик и попробовал собрать это код - собралось, работает!



Ну вот и славненько!

А то я сначала прочитал свежие исходники matiec, там все в порядке со скобочками, а потом оказалось, что прасер работает нормально,
следовательно, либо у Вас устаревшая версия, либо в matiec жестокие косяки с архитектурой...

А какие там ещё баги? Ну которые мешают переносу проектов?
yanvasiij
Был еще один баг, но мы его исправили самостоятельно: было невозможно вызывать глобальный функциональный блок из простого экземпляра функционального блока. Я вот сейчас смотрю и не уверен исправлял ли этот баг сам Марио. К сожалению мы поторопились и коментарий к комиту написали по-русски. Поэтому сделать запрос на пуш в оффициальный репозитарий думаю пока не получится, но если надо можем просто открыть свой.
paulbell
Цитата(yanvasiij @ Jul 20 2016, 09:23) *
Был еще один баг, но мы его исправили самостоятельно: было невозможно вызывать глобальный функциональный блок из простого экземпляра функционального блока. Я вот сейчас смотрю и не уверен исправлял ли этот баг сам Марио. К сожалению мы поторопились и коментарий к комиту написали по-русски. Поэтому сделать запрос на пуш в оффициальный репозитарий думаю пока не получится, но если надо можем просто открыть свой.



Я считаю, что лучше открыть issue и добавить патч с исправлением в комменты.

С другой стороны в трекере есть закрытые "незакрытые" баги, так что лучше куда-то форкнуть репозиторий Марио, пропатчить его и проветсти регрессионное тестирование,
по результатам создать все issue, где будут только актуальные баги.

Кстати, я смотрю тут уже есть три организации, заинтересованные в развитии Beremiz/matiec, может объединить усилия?
yanvasiij
Я добавлю issue и патч на днях; и по-поводу "незакрытых" баг - согласен.

По-поводу объединения усилия мы только ЗА. Андрей уже предлагал выше объединиться и отчасти нам это удалось, по мере обнаружения багов в самом Beremiz'e я пишу ему в баг-трекер. Я сам сейчас веду одновременно несколько проектов и в свободное от них время пишу, что-то вроде рантайма для STM32f4xx под беремиз (так же как это делаете Вы, если верить вашему репозитарию) и плагины для этого рантайма в Beremiz'e. У нас была попытка залезть глубоко в потороха matiec для испралления найденных багов, что-то даже удалось, то программист занятый этим переключился сейчас на другой проект, поэтому тут работа стоит.

А, да у Beremiz'a есть IRC чат, Андрей там уже сидит, я все никак не могу поставить на рабочую машину IRC-клиент, поэтому бываю там редко, когда подключусь с телефона только.
paulbell
Цитата(yanvasiij @ Jul 22 2016, 15:16) *
Я добавлю issue и патч на днях; и по-поводу "незакрытых" баг - согласен.

По-поводу объединения усилия мы только ЗА. Андрей уже предлагал выше объединиться и отчасти нам это удалось, по мере обнаружения багов в самом Beremiz'e я пишу ему в баг-трекер. Я сам сейчас веду одновременно несколько проектов и в свободное от них время пишу, что-то вроде рантайма для STM32f4xx под беремиз (так же как это делаете Вы, если верить вашему репозитарию) и плагины для этого рантайма в Beremiz'e. У нас была попытка залезть глубоко в потороха matiec для испралления найденных багов, что-то даже удалось, то программист занятый этим переключился сейчас на другой проект, поэтому тут работа стоит.

А, да у Beremiz'a есть IRC чат, Андрей там уже сидит, я все никак не могу поставить на рабочую машину IRC-клиент, поэтому бываю там редко, когда подключусь с телефона только.



Ну IRС у меня нет, так что там я вряяд ли скоро появлюсь.

Форкнул репозитрий Андрея, исправил один баг в Beremiz, сделал пул-реквест, реакции пока нет.

Андрей часто появляется у себя в bitbucket?
yanvasiij
Я если честно сам редко сижу в ирке, мне не очень удобно там - на работе у меня блокируют туда доступ, поэтому я там либо через телефон, либо из дома. Можно попробовать создать чат в другом мессенджере.

Андрей обычно реагирует очень быстро, практически сразу. Наверно сейчас обстоятельства какие...
paulbell
Цитата(yanvasiij @ Aug 21 2016, 10:32) *
Я если честно сам редко сижу в ирке, мне не очень удобно там - на работе у меня блокируют туда доступ, поэтому я там либо через телефон, либо из дома. Можно попробовать создать чат в другом мессенджере.

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


Уже связались, познакомились, спасибо.

Хорошо бы втроем пообщаться в online-режиме, если интересно сотрудничество, конечно.
yanvasiij
Цитата(paulbell @ Aug 22 2016, 10:47) *
Хорошо бы втроем пообщаться в online-режиме, если интересно сотрудничество, конечно.


Ну вот, что я предлагаю: cвои контакты я отправил Вам в личку, контакты Андрея у Вас тоже есть, я так понимаю, создайте чат (раз уж Вы инициатор online-режима) в мессенджере, который посчитаете удобным, и пригласите в него нас. Я на приглашение точно откликнусь. Да и вообще, все кто хочет поучаствовать думаю смогут туда подключиться через Вас.
griabig
Цитата(yanvasiij @ Aug 22 2016, 10:38) *
Ну вот, что я предлагаю: cвои контакты я отправил Вам в личку, контакты Андрея у Вас тоже есть, я так понимаю, создайте чат (раз уж Вы инициатор online-режима) в мессенджере, который посчитаете удобным, и пригласите в него нас. Я на приглашение точно откликнусь. Да и вообще, все кто хочет поучаствовать думаю смогут туда подключиться через Вас.


Если блокируют сам протокол IRC или нет возможности установить IRC-клиент, то всегда есть возможно войти в IRC чат через вэб.
Например, вот здесь
https://webchat.freenode.net/

Я всегда там, даже если меня в данный момент нет в офисе, то я прочитаю сообщение потом и обязательно отвечу на него.
bullit
Всем Здрасте!

Сразу описание проблемы: в генерируемых исходниках (Си), для доступа (чтение/запись) к объектам Словаря CANOpen в Беремизе используются указатели на переменные. Проблема заключается в том, что доступ к объектам словаря хорошо было бы сделать через функции CANFestival: set/get ODentry(...), так как они вызывают колбэк (если он есть) записи в словарь.
Кто нибудь решал эту проблему?

Была попытка поправить макросы, в accessor.h )) обломался.

Заранее Огромное спасибо!


yanvasiij
Я эту проблему не решал. Но если я правильно все понял, нужно править не accessor.h, а сам модуль CANOpen в беремизе. Кодогенерацией занимается метод CTNGenerate_C(). Если переменные нужно записывать через методы set/get ODentry, а не напрямую, то можно, как вариант отслеживать изменение и производить запись в переменные объектного словаря в функциях __publish и __retrive, которые вызываются соответственно до и после пользовательского цикла. И еще, просто в качестве совета, такие вопросы эффективнее задавать mailing list - ответят быстрее и подробнее.
bullit
Функции __publish и __retrive - используются для режима debug. Но можно переписать и под себя конечно!
Код
/*
* Retrieve input variables, run PLC and publish output variables
**/
void __run(void)
{
    __tick++;
    if (greatest_tick_count__)
        __tick %= greatest_tick_count__;
   /*__retrieve_debug();*/
    config_run__(__tick);
    __publish_debug();
}

Остаётся вопрос откуда взять список переменных, которые юзает код ПЛК, это раз!
И у меня возникает вопрос, а как генерится код ПЛК: не получится ли что код зациклится на ожидании какого нибудь флага, а он соответственно обновится только в следующем цикле! Может быть такой вариант событий?1
А функция CTNGenerate_C() всего лишь запускает iec2c
yanvasiij
Цитата
Функции __publish и __retrive - используются для режима debug.


Нет. Я имел ввиду __publish_X и __retrive_X, которые реализует каждый модуль, при кодогерации. Признаться, после вашего сообщения, сам засомневался, что задал вопрос в ML. Тот же Canfestival реализован, как модуль к Beremiz'у, поэтому и реализует свои __publish_X и __retrive_X при генерации исходников.
bullit
Не удобно когда переменных много! Обновлять всё, чтоб использовать часть! накладно получается!
Пока рабочим вариантом используем переписанные макросы в заголовочных файлах iec_inc.
paulbell
Цитата(bullit @ Feb 9 2017, 17:59) *
И у меня возникает вопрос, а как генерится код ПЛК: не получится ли что код зациклится на ожидании какого нибудь флага, а он соответственно обновится только в следующем цикле! Может быть такой вариант событий?1


Если __publish и __retrive реализовать без циклов, то такого быть не должно.
Iec2c генерирует конечные автоматы, которые работают кооперативно.
T.к. количество автоматов ограничено, то получается гарантия ограниченного WCET для кода,
генерируемого iec2c если он отработал без глюков.
bigmaxtor
Приветствую всех! Сборка проекта matiec из репозитория прошла с незначительными варнингами. Сам beremiz запускается. Однако при попытке запуска его проекта из среды PyDev вываливается куча ошибок. В чем может быть моя ошибка?
yanvasiij
Из какого репозитария Вы взяли Beremiz и matiec? В какой операционной системе Вы работаете? И что за ошибки в pydev, выложите лог? И еще, повторюсь, настоятельно рекомендую спрашивать в mailing list, так гораздо эффективнее поверьте.
bigmaxtor
Цитата(yanvasiij @ Mar 8 2017, 21:07) *
Из какого репозитария Вы взяли Beremiz и matiec? В какой операционной системе Вы работаете? И что за ошибки в pydev, выложите лог? И еще, повторюсь, настоятельно рекомендую спрашивать в mailing list, так гораздо эффективнее поверьте.


Beremiz и matiec - из https://github.com/nucleron. Нам требуется собрать минимально рабочую систему на плате F4Discovery. Из какого репозитория нам будет быстрее это сделать? Работаем в Linux/Ubuntu. IDE - Eclipse+PyDev. Логи соберу, укорочу и выложу.
bullit
Может я чего не знаю или не понимаю. Вы хотите на STMке питоновские скрипты использовать?
yanvasiij
Репозитарий правильный, если быть точным это один из форков официального репозитария (принадлежит paulbell). Если хотите просто развернуть среду Павла, то можно воспользоваться установщиком: https://github.com/nucleron/YAPLC/releases. Под win7 он запускается без проблем, под linux не знаю. Если хотите развернуть все, склонировав его репозитарии то тут список всех необходимых репозитариев: https://sourceforge.net/p/beremiz/mailman/message/35506039/. Один или несколько репозитариев (я уже не помню точно) нужно преварительно собрать разумеется. В качестве таргетов там есть платформы на базе stm32, какие именно лучше посмотреть в исходниках или спросить у автора, сам не помню.
bigmaxtor
Цитата(bullit @ Mar 9 2017, 14:15) *
Может я чего не знаю или не понимаю. Вы хотите на STMке питоновские скрипты использовать?


Это было бы круто, но не сейчас. Сейчас STMка - всего лишь цель для беремиза.

Цитата(yanvasiij @ Mar 8 2017, 21:07) *
Из какого репозитария Вы взяли Beremiz и matiec? В какой операционной системе Вы работаете? И что за ошибки в pydev, выложите лог? И еще, повторюсь, настоятельно рекомендую спрашивать в mailing list, так гораздо эффективнее поверьте.


Видимо, что-то не так с нашей питоновской средой PyDev - похоже, она не видит определения самого беремиза и виджетов.
Мы ставили python-wxgtk2.8.
Мы не поставили какую-то библиотеку или для беремиза лучше другую IDE использовать ?

Наши логи:
Код
============================= ERRORS =============================
Traceback (most recent call last):
  File "/home/igor/.p2/pool/plugins/org.python.pydev_5.5.0.201701191708/pysrc/_pydev_runfiles/pydev_runfiles.py", line 468, in __get_module_from_str
    mod = __import__(modname)
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/Beremiz_service.py", line 88, in <module>
    sys.exit()
SystemExit
ERROR: Module: Beremiz_service could not be imported (file: /home/igor/acs/beremiz/beremiz_test/beremiz/Beremiz_service.py).

============================= ERRORS =============================
Traceback (most recent call last):
  File "/home/igor/.p2/pool/plugins/org.python.pydev_5.5.0.201701191708/pysrc/_pydev_runfiles/pydev_runfiles.py", line 468, in __get_module_from_str
    mod = __import__(modname)
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/PLCOpenEditor.py", line 80, in <module>
    from IDEFrame import IDEFrame, AppendMenu
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/IDEFrame.py", line 9, in <module>
    from editors.EditorPanel import EditorPanel
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/editors/EditorPanel.py", line 27, in <module>
    from controls import VariablePanel
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/__init__.py", line 31, in <module>
    from DebugVariablePanel import DebugVariablePanel
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/DebugVariablePanel/__init__.py", line 1, in <module>
    from DebugVariablePanel import DebugVariablePanel
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/DebugVariablePanel/DebugVariablePanel.py", line 40, in <module>
    from DebugVariableTextViewer import DebugVariableTextViewer
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/DebugVariablePanel/DebugVariableTextViewer.py", line 30, in <module>
    from DebugVariableViewer import DebugVariableViewer
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/DebugVariablePanel/DebugVariableViewer.py", line 33, in <module>
    from dialogs.ForceVariableDialog import ForceVariableDialog
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/dialogs/__init__.py", line 30, in <module>
    from FBDVariableDialog import FBDVariableDialog
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/dialogs/FBDVariableDialog.py", line 37, in <module>
    VARIABLE_CLASSES_DICT = {INPUT : _("Input"),
NameError: name '_' is not defined
ERROR: Module: PLCOpenEditor could not be imported (file: /home/igor/acs/beremiz/beremiz_test/beremiz/PLCOpenEditor.py).

============================= ERRORS =============================
Traceback (most recent call last):
  File "/home/igor/.p2/pool/plugins/org.python.pydev_5.5.0.201701191708/pysrc/_pydev_runfiles/pydev_runfiles.py", line 468, in __get_module_from_str
    mod = __import__(modname)
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/svgui/__init__.py", line 1, in <module>
    from svgui import *
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/svgui/svgui.py", line 8, in <module>
    from py_ext import PythonFileCTNMixin
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/py_ext/__init__.py", line 1, in <module>
    from py_ext import *
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/py_ext/py_ext.py", line 3, in <module>
    from PythonFileCTNMixin import PythonFileCTNMixin
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/py_ext/PythonFileCTNMixin.py", line 6, in <module>
    from CodeFileTreeNode import CodeFile
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/CodeFileTreeNode.py", line 8, in <module>
    from ConfigTreeNode import XSDSchemaErrorMessage
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/ConfigTreeNode.py", line 18, in <module>
    from editors.ConfTreeNodeEditor import ConfTreeNodeEditor
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/editors/ConfTreeNodeEditor.py", line 7, in <module>
    from EditorPanel import EditorPanel
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/editors/EditorPanel.py", line 27, in <module>
    from controls import VariablePanel
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/__init__.py", line 31, in <module>
    from DebugVariablePanel import DebugVariablePanel
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/DebugVariablePanel/__init__.py", line 1, in <module>
    from DebugVariablePanel import DebugVariablePanel
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/DebugVariablePanel/DebugVariablePanel.py", line 40, in <module>
    from DebugVariableTextViewer import DebugVariableTextViewer
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/DebugVariablePanel/DebugVariableTextViewer.py", line 30, in <module>
    from DebugVariableViewer import DebugVariableViewer
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/controls/DebugVariablePanel/DebugVariableViewer.py", line 33, in <module>
    from dialogs.ForceVariableDialog import ForceVariableDialog
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/dialogs/__init__.py", line 30, in <module>
    from FBDVariableDialog import FBDVariableDialog
  File "/home/igor/acs/beremiz/beremiz_test/beremiz/dialogs/FBDVariableDialog.py", line 37, in <module>
    VARIABLE_CLASSES_DICT = {INPUT : _("Input"),
NameError: name '_' is not defined
ERROR: Module: svgui.svgui could not be imported (file: /home/igor/acs/beremiz/beremiz_test/beremiz/svgui/svgui.py).
bullit
Наверное трабла в неподключенных либах.
может поможет:
Pre-requisites
# Ubuntu/Debian :
sudo apt-get install build-essential bison flex autoconf
sudo apt-get install python-wxgtk2.8 pyro mercurial
sudo apt-get install python-numpy python-nevow python-matplotlib

Хотя не факт!
Попробуйте PyCharm.
yanvasiij
Странные ошибки, он не жалуется на отсутствие пакетов, в одном случае он не распознал символ интернационализации, в другом не смог импортировать PLCOpenEditor.py, в третьем не смог импортировать svgui.py.

Какая версия питона у Вас? Какой файл вы запускаете? Если хотите запустить "голый" беремиз нужен Beremiz.py из папки Beremiz. Если хотите запустить среду Павла, со всеми ее возможностями под stm32, нужен файл yaplcide.py из папки IDE. В качестве среды я использую Pycharm, но вы попробуйте просто из под командной строки запустить для начала.
bigmaxtor
Цитата(bullit @ Mar 9 2017, 15:34) *
Наверное трабла в неподключенных либах.
может поможет:
Pre-requisites
# Ubuntu/Debian :
sudo apt-get install build-essential bison flex autoconf
sudo apt-get install python-wxgtk2.8 pyro mercurial
sudo apt-get install python-numpy python-nevow python-matplotlib

Хотя не факт!
Попробуйте PyCharm.


Проверил
sudo apt-get install build-essential bison flex autoconf python-wxgtk2.8 pyro mercurial python-numpy python-nevow python-matplotlib
все установлено.
Попробуем PyCharm.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.