Jump to content
    

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

 

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

 

А это не Вы, тот самый Paul, что выложил ссылку в майлинг листе на свой git-репозитарий? (была неверная ссылка, отредактировал)

Share this post


Link to post
Share on other sites

А это не Вы, тот самый Paul, что выложил ссылку в майлинг листе на свой git-репозитарий? (была неверная ссылка, отредактировал)

 

Да, это я.

 

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

 

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

 

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

 

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

 

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

 

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

 

Соответственно если что-то делать нужны:

а) тестовые файлы (для регрессионного тестирования)

б) кто-то, кто сможет проконсультировать по МЭКовским языкам.

в) время, которого мало, ибо мне надо писать прошивки для трёх приборов...

г) специалист по питону, ибо в)

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

Только пошаговой отладки (в смысле прошагивание инструкций) там нет, есть просмотр переменных и лога,

насколько я понял, в Beremiz всё этим и ограничивается, я не видел там свидетельств возможность "шагать", как в том же Си.

 

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

 

 

 

 

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

 

 

Кстати, а тот код пробовали обрабаывать с помощью iec2iec? Что генерируется в этом случае?

Share this post


Link to post
Share on other sites

Кстати, а тот код пробовали обрабаывать с помощью iec2iec? Что генерируется в этом случае?

 

Я если честно не совсем понимаю что делает iec2iec, поэтому и не пробовал. Если не затруднит растолкуйте для чего он? Я пробовал через консоль отправлять тот код в iec2c.exe, в генерированном им коде и была та злосчастная ошибка.

Share this post


Link to post
Share on other sites

Я если честно не совсем понимаю что делает iec2iec, поэтому и не пробовал. Если не затруднит растолкуйте для чего он? Я пробовал через консоль отправлять тот код в iec2c.exe, в генерированном им коде и была та злосчастная ошибка.

 

 

По задумке автора, он нужен для контроля корректности работы парсера (как раз той самой части, которая на bison и yacc/flex ):

берем исходник на ST/LD/SFC, преобразуем в ST, сравниваем с оригиналом, если парсер отработал корректно, - должен получиться оригинал, или что-то близкое к нему.

 

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

 

Такой подход позволяет отделить баги прасера и баги кодогенератора.

Edited by paulbell

Share this post


Link to post
Share on other sites

Только что сделал следующее:

 

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

 

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

 

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 оказало дофига отладочной информации, но в самом конце было следующее:

 

{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

 

Смею предположить, что парсер отработал все верно.

Share this post


Link to post
Share on other sites

Смею предположить, что парсер отработал все верно.

 

 

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

 

 

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

 

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

 

 

 

Только что сделал следующее:

 

..\..\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?

Edited by paulbell

Share this post


Link to post
Share on other sites

iec2iec.exe -v
matiec version 0.1
changeset id: 7518955c875a

 

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

 

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

Share this post


Link to post
Share on other sites

iec2iec.exe -v
matiec version 0.1
changeset id: 7518955c875a

 

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

 

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

 

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

 

 

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

 

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

 

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

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

 

А какие там ещё баги? Ну которые мешают переносу проектов?

Share this post


Link to post
Share on other sites

Был еще один баг, но мы его исправили самостоятельно: было невозможно вызывать глобальный функциональный блок из простого экземпляра функционального блока. Я вот сейчас смотрю и не уверен исправлял ли этот баг сам Марио. К сожалению мы поторопились и коментарий к комиту написали по-русски. Поэтому сделать запрос на пуш в оффициальный репозитарий думаю пока не получится, но если надо можем просто открыть свой.

Share this post


Link to post
Share on other sites

Был еще один баг, но мы его исправили самостоятельно: было невозможно вызывать глобальный функциональный блок из простого экземпляра функционального блока. Я вот сейчас смотрю и не уверен исправлял ли этот баг сам Марио. К сожалению мы поторопились и коментарий к комиту написали по-русски. Поэтому сделать запрос на пуш в оффициальный репозитарий думаю пока не получится, но если надо можем просто открыть свой.

 

 

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

 

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

по результатам создать все issue, где будут только актуальные баги.

 

Кстати, я смотрю тут уже есть три организации, заинтересованные в развитии Beremiz/matiec, может объединить усилия?

Share this post


Link to post
Share on other sites

Я добавлю issue и патч на днях; и по-поводу "незакрытых" баг - согласен.

 

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...