ПЛК (Arduino Mega 2560 + W5100)

[cg_shura]

Так весь смысл скриптового языка - это манипуляция ресурсами системы (порты, файловая система и т.д.). А если оно только printf может вывести, то какой смылс в этом скриптовом языке.

В avr работа со всей архитектурой идёт через ОЗУ. Вы можете объявить идентификаторы для каждого конфигурационного регистра и по особому их обрабатывать. Получится работа со всей периферий напрямую. Что касается работы с файлами, то это тоже можно сделать, просто немного сложнее, учитывая ограничения используемого драйвера. FatFs я ещё не подключил.

В любом МК работа идет через ОЗУ. Если в этом picoc нельзя подключить внешние библиотеки и использовать их API, то толку от такого скриптового языка.[/quote]

Да, память дорогая, но в результате всё равно будет дешевле, если бы я себе покупал несколько ПЛК, модулей, шлюзов. Вообще, я бы купил сторонний ПЛК, но они очень дороги и все кроме того ограничены в ПО. Те, кто продают ПЛК, берут деньги со всего, что можно монетизировать: ограничивают интерфейсы, входы/выходы, память для программ и пр.

А есть и другая сторона вопроса. ПЛК стандартизованы и их можно будет заменить. А чем можно будети заменить ваши разработки если вы прекратите деятельность? Вопрос скорее не от меня, сам занимаюсь разработкой, но такие каверзные вопросы часто задают разработчикам "нестандартного" железа.

[uni]

Наши заказчики просят все исходники проекта с тем же посылом, мол, а что если? Естественно мы не даём ни каких исходников. Хотя бы потому, что они требуют КБ программистов, чтобы их поддерживать. Хотите исходники - пишите сами, ПЛК и SDK есть.
Мы тоже хотим исходники CoDeSys'а, так как разрабатываем драйвера для нашего ПЛК, которые будут использоваться совместно. Дадут нам их? Даже не продадут.

Если вы по поводу open source портирования picoc. На avr это по-моему бессмысленно из-за отсутствия нормального отладчика и среды. Он очень дорогой, среда разработки не стабильная. Вот для stm это больше имеет смысл, у меня и отладчик есть, но никакой платы для проверки нету. Без реального железа колупаться нет смысла.

По поводу всех мк я не уверен, я просто показал, что вы можете работать с периферией на скрипте точно также как на си обычном. За исключением обработки прерываний и прочих подобных вещей. Я в принципе могу назначить на обработчики прерывания функцию внутри скрипта, но сделаю наверное это по-другому. Вообще, если вы хотите работать с периферией напрямую, то зачем вам интерпретатор? Работайте напрямую вообще. Скрипт должен поддерживать периферию как некие объекты с набором свойств и методов, а реализовывать модбас самому на скрипте нет никакого смысла. То же касается всего остального.

По поводу внешних библиотек я не понял вопроса. Вы можете отобразить любые функции из своих библиотек на внутренние (в скрипте) и дать им такое же имя. На самом деле так подключены все стандартные библиотеки. Для каждой такой функции нужно объявить обёртку, которая описывает её полностью.

Если посмотреть на исходники, а их можно собрать в Visual Studio (там есть проект, но я не собирал), то можно увидеть, что вы можете подгрузить столько скриптов, сколько памяти хватит. Я лично не планировал такого использования, так как мне памяти точно не будет хватать. Мне достаточно 31 параллельной задачи и набора библиотек, реализующих драйвера и протоколы для частых применений.

Как правило для пользователя ПЛК требуется только написать алгоритм работы, который должен только манипулировать тегами. Теги появляются от модбаса (входы/выходы у самого ПЛК - ещё проще), который знает как их читать и писать. Ещё нужно меню для настройки, ввода коэффициентов и прочего, я это обязательно добавлю. Ещё мне нравятся графические экраны, я добавлю работу с графикой. Вот в общем и всё. Это даже не типовое применение, так как экранов обычно нет и кнопок. Ещё можно добавить возможность реализации произвольного протокола. Это тоже можно сделать.
Забыл про работу с файлами.

По поводу стандартизации ПЛК не соглашусь. Все они разные, то есть вы не сможете взять одну мэковскую программу и записать её в другой ПЛК, если только они не одного семейства. Можете попробовать. Я пишу драйвера для нашего ПЛК, на котором стоит CoDeSys, так вот заменить вы его не сможете, так как нет таких же ПЛК с экраном и кнопками. А если что-то и найдётся, то наши API будут несовместимы. Проще будет написать заново. Вы сможете заменить только на очень похожий ПЛК той же фирмы с тем же runtime'ом.
Кроме того, не все мэковские языки одинаково реализованы. В апреле вступит в силу новый отечественный стандарт на языки, там есть поддержка ООП. Это копия импортного. Так вот я пишу драйвера с использованием ООП на ST. Не много найдётся софтин, на котором это будет работать.

[cg_shura]

Мы тоже хотим исходники CoDeSys'а, так как разрабатываем драйвера для нашего ПЛК, которые будут использоваться совместно. Дадут нам их? Даже не продадут.

Для разработки нового ПЛК нет необходимости в исходниках CoDeSys'а или любой другой среды с языками МЭК.

По поводу внешних библиотек я не понял вопроса. Вы можете отобразить любые функции из своих библиотек на внутренние (в скрипте) и дать им такое же имя. На самом деле так подключены все стандартные библиотеки. Для каждой такой функции нужно объявить обёртку, которая описывает её полностью.

Я как раз и говорил о работе с абстракциями из скрипта. Работать с периферией из скрипта нет никакого смысла.

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

Это само собой разумеется. Вопрос в том сколько памяти занимает один минимальный скрипт плюс рантайм picoc.

По поводу стандартизации ПЛК не соглашусь. Все они разные, то есть вы не сможете взять одну мэковскую программу и записать её в другой ПЛК, если только они не одного семейства. Можете попробовать.

Опять выступлю в роли адвоката дьявола, вы уж простите. Ответят что да, это так. Но специалисты АСУТП быстро разберутся в особенностях и разнице ПЛК. А ваше изделие в этом плане уникально, аналогов нет. Нет сообщества пользователей. Потому при неудаче в поиске пропавшего разработчика будет нанят АСУТП'шник который сменит все на знакомый ему ПЛК (на что учился).

[uni]

Я автоматчик и специалист по разработке автоматики в одном лице. Расскажу один случай, на который до сих пор ни ответа, ни привета от разработчиков CoDeSys. Вообще, мне жалко людей, которые пишут на мэковских языках и это одна из причин почему я хочу скрипт на Си.

Так вот, пишу я библиотеку поддержки, которую должны использовать автоматчики в асу отделах потом, чтобы заставить ПЛК делать что нужно. Столкнулся со следующей проблемой. В нашем ПЛК некоторая периферия представлена в Linux через event'ы. Буквально кнопки на них сидят. Пробую я разными способами читать из /dev/input/event. Мне нужно неблокирующее чтение. В CoDeSys есть специальные для этого функции чтения, но когда я пытаюсь их использовать, то теряется связь с runtime'ом из-за чего я не могу нормально отлаживать проект, мне приходится перезагружать ПЛК. Так вот обратились мы к фирме посреднику, что нам кодесис адаптировала, они проблему признали и всё. Написал я на форуме кодесиса... тишина. Взял проверил проблему на другой их сборке на Raspberry - то же самое. Среда разработки теряет связь. Я видео снял и поместил на форуме... никому это не интересно. Техподдержка равна нулю. За что мы заплатили?

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

Не знаю откуда у вас такая вера к этим системам. Мне китайцы из Wecon даже прошивку своего ПЛК давали, чтобы перешить его, когда я у них глюк обнаружил и ПЛК с катушек съехал. Вот это поддержка, но больше они так не делают.

Минимальный скрипт занимает один нулевой байт, я думаю, то есть пустой. Что касается памяти, то это где-то 70-80 Кб флеша и в районе 8 Кб ОЗУ для runtime, без драйвера файловой системы.

[cg_shura]

Не знаю откуда у вас такая вера к этим системам.

Я же писал что выступаю в роли "адвоката дьявола" Сам не сторонник ПЛК. Видел как народ с ними мучается. Но тем не менее все твердят про промышленные стандарты и языки МЭК.

[alexsis_76]

И все таки мне кажется что на avr будет очень медленно,низкая тактовая частота, отсутствие dma,плюс не очень вменяемая отладка,может пока не зашло слишком далеко выбрать какой нибудь из армов или пиков,кстати pic24 при небольшой цене очень даже не плох,куча библиотек,без проблем стыкуется c w5100, есть хороший wifi модуль,сертифицированный, работает отлично(сам пробовал),хороший отладчик, среда разработки.

[DimSun75]

Соглашусь с предыдущим оратором. avr все-таки слабоват для таких задач. А вообще проект интересный. Мне конечно полноценный ПЛК не нужен, а вот использование скриптов для минимальной автономии очень даже.

Отправлено с моего SM-A520F через Tapatalk

[uni]

У меня скоро будет простая демо прошивка для Arduino Mega2560 с подключенной по SPI карточкой (Ethernet шилд с W5100). Можно будет короткий скрипт потестить, скажем, длиной в 512 байт. Туда можно будет цикл вставить и printf(), который будет писать в терминал. Каждая строчка вывода будет сопровождаться временем с точностью до мсек. Вот можно будет типовой пример запустить с простым циклом на 1000 итераций и засечь время его исполнения. Правда это будет не совсем честно, т.к. не будет учитываться время работы с файлом. Может быть лучше тогда немного подождать, когда я сделаю специальный указатель, который позволит использовать файл любого размера, поддерживаемый драйвером файловой системы. Тогда скрипт можно будет заполнить кучей комментариев и между ними вставить кусочки кода. Это чуть ближе к реальности, но тоже не совсем хорошо.

Да, кстати, конкретно этот вариант прошивки можно будет протестировать в Proteus. В реальном времени на 16 МГц вряд ли комп потянет, но вот анализ на графиках можно использовать. Если я добавлю поддержу работы с портами, то можно просто "дёргать ножкой" в цикле и сравнить время с таким же циклом без интерпретации. Получим коэффициент замедления для моей реализации.

[cg_shura]

кстати pic24 при небольшой цене очень даже не плох,куча библиотек,без проблем стыкуется c w5100, есть хороший wifi модуль,сертифицированный, работает отлично(сам пробовал)

Только стоит этот wifi модуль как самолет по сравнению с тем же ESP8266.

[DimSun75]

printf бесполезный пример. Гораздо интереснее ножкой подрыгать и посмотреть осциллографом. А еще интереснее добавить ветвлений.

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

Отправлено с моего SM-A520F через Tapatalk