Возможность программирования на более низком, чем ОЛ схемы уровне

[melky]

rwg что-то вы погорячились с 1 мс, у меня программа 5 мс по времени работает если верить индикатору ПР200.
я за то, чтобы сами макросы для ОЛ можно было бы писать на С# и подключать их к базе макросов.
мечты, мечты.....

[Филоненко Владислав]

Овен Лоджик работает как работает. P-code, о котором Вы так мечтаете - это те же квадратики, но в виде потока байт. За счёт супероптимизации процентов 10, наверное, выжать удастся по производительности.
У нас и так самый быстрый ПР среди конкурентов.

А шаг ниже - это писать свою программу на С и ASM и прошивать её в STM-ю отладку.

Никаких коварно скрываемых от общественности суперформатов загрузки не существует.

[Владимир Ситников]

А шаг ниже - это писать свою программу на С и ASM и прошивать её в STM-ю отладку.

По-моему, вы смотрите со стороны разрабочика ОЛ. Да, для разработчика ОЛ шаг ниже это C или бинарный код STM.
Но для общественности доступны лишь "квадратики ОЛ, которые нужно таскать мышкой".
Для общественности, p-code это и есть тот самый нужный "шаг ниже". Большинству этого самого p-code должно хватить.


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

Понятно, что соединить вход с выходом в ОЛ проблем не составляет. А, например, записать формулу уже непросто.

Никаких коварно скрываемых от общественности суперформатов загрузки не существует.

О, где можно почитать/попробовать ОЛ p-code?

[Алексей Геннадьевич]

Овен Лоджик работает как работает. P-code, о котором Вы так мечтаете - это те же квадратики, но в виде потока байт. За счёт супероптимизации процентов 10, наверное, выжать удастся по производительности.

Смысл не в "супероптимизации производительности", а в том, чтобы просто иметь возможность генерировать программы для ПР в сторонних редакторах.
Понятно, что соединить вход с выходом в ОЛ проблем не составляет. А, например, записать формулу уже непросто.

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

[AlexP]

Согласен с автором темы относительно вставки макросов, написанных на ST (или на С). Более-менее серьезные проекты на ПЛК у меня ну никак не обходятся без ST, - те же формулы, или мозго-выносящие ветвистые условия. Просто, в данной ситуации написать пару-тройку строк кода гораздо менее трудоемко, чем воротить все это на FBD. Планировал серьезно применять ПР200 в вентиляции и кондиционировании - платформа и возможности довольно серьезны для этого, НО. Написать что-то стоящее в ОЛ в данном случае, конечно, можно, но человеко-часов я на это затрачу просто уйму! И это не допустимо, потому что, в основном, все решает время. Да-да, последний пример: срочно сделать штучный заказ для нестандартной приточной установки. Если бы в ОЛ была возможность вставки хоть примитивного ST, как, например, в 1Tool у Carel, не задумываясь бы взял ПР200 (очень нравится). А так, заказал pCOxs с панелькой за 38k. И только из-за отсутствия ST в Лоджике, и отсутствия времени у меня.
Конечно, я понимаю, реализация ST тянет за собой серьезные вложения в разработку IDE Лождик, но в этом случае ПР200 добавил бы себе еще какое-то количество потребителей, это уж точно.

[rovki]

Написать что-то стоящее в ОЛ в данном случае, конечно, можно, но человеко-часов я на это затрачу просто уйму! И это не допустимо, потому что, в основном, все решает время. .

Так это не проблема ОЛ ,скорее ваша ,потому как ОЛ делался для электрошиков ,для которых ваши проблемы вообще не проблемы .Кто на что учился .А так берите ПЛК 63 и все (не считая цены,но ОЛ в этом не виноват) будет быстро у вас .

[Вольд]

Конечно, я понимаю, реализация ST тянет за собой серьезные вложения в разработку IDE Лождик, но в этом случае ПР200 добавил бы себе еще какое-то количество потребителей, это уж точно.

Вода камень точит. Кончится тем, что появится возможность программировать ПР "ОВЕН" и на ST. rovki и "электронщики" буду продолжать программировать в ОЛ, а у более продвинутых пользователей появятся альтернативные возможности. Дали бы волю В.Ситникову все бы давно было сделано.

[Владимир Ситников]

Вот как раз это и интересует гурманов как Владимир да и других

Интегрировать C и ОЛ намного сложнее, чем какой-нибудь p-code / IL и ОЛ.
Программировать ПР/ПЛК на C вряд ли будет много желающих.
И уж вряд ли будут желающие вообще весь стек с нуля создавать (ну, на C писать работу с 485, симулятор, online, загрузку программы и т.п.)

Сколько тут умельцев, способных и желающих написать свою прошивку для ПР? Ни-ко-го.
Разве что ради развлечения/хобби.

Поэтому я и говорю, что нужно не STM-32 на C программировать, а делать так, чтобы в ОЛ можно было добавлять программы-макросы, написанные на p-code / IL.
Разумеется, IL программы не вручную писать, а каким-нибудь генератором (компилятором). Например, пишем на ST -- получаем IL, вставляем IL в ОЛ.

[rovki]

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

Для кучки продвинутых ,которым не хватает денег купить плк63 (12тр) и которые хотят получить альтернативные возможности -то же самое за 6тр ,следует знать что все дополнительные затраты (при бесплатности ОЛ) лягут на цену ПР200 или размажутся на все изделия (скорее всего) ...Халявы бесплатной нет уже давно и это следует знать продвинутым в этой области пользователям.При скрещивании божей коровки и мухомора(внешне похожи) не следует надеятся на здоровое потомство.

[Алексей Геннадьевич]

Сколько тут умельцев, способных и желающих написать свою прошивку для ПР? Ни-ко-го.
Разве что ради развлечения/хобби.

Вопрос неправильно поставлен.
Правильный вопрос - нафига?
1)Приключений себе на задницу найти можно и более простыми способами.
А если так припекло, то:
2)Сравниваем цену на отладочную плату STM и ПР-200.
3) в промышленности "самопал" недопустим.