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

[Newcomer]

Можно. Сколько это займет человеко-часов?

Смотря кто делать будет. У людей со светлыми головами много времени не займет. ИнСАТ работу заказать, быстро сделают.

[Newcomer]

А исходная мысль была в том, что к p-code можно прикрутить хоть какой язык. Хоть FBD, хоть ST.

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

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

Можно. Сколько это займет человеко-часов?

Основной вопрос не "сколько займёт прикручивание ST к p-code", а "сколько у ОВЕН займёт прикручивание p-code к ОЛ-ПР".
Прикрутить p-code к ОЛ (например, сделать ОЛ-блок с полем ввода IL программы, или ОЛ-блок куда вставляется прямо base64 p-code) и задокументировать не должно быть сложной задачей.

Ну, допустим, программист думает недели полторы над форматом хранения-обмена этим самым p-code.
Потом 3 дня добавляется новый блок с полем ввода для p-code в ОЛ.
Потом неделю делается загрузка из этого формата (распознавание вставленной программы в понятное ОЛ представление)
Потом ещё неделя на запись p-code в *.owl.
Потом ещё неделя на скрещивание нового блока с имеющимся в ОЛ компилятором.
Потом ещё неделя на скрещивание нового блока с имеющейся в ОЛ симуляцией.
Потом документатор документирует. Допустим, это тоже неделя (там писать-то день или два, но попутно будет тратиться время программиста на пояснение, поэтому пишем суммарно неделю).

Итого 7 мифических человеко-недель = 1.5 (формат) + 0.6 (блок) + 1 (чтение) + 1 (запись) + 1 (компилятор) + 1 (симуляция) + 1 (документация)

Без понятия какая компенсация в ОВЕН, но грубо можно оценить как 400 т.р. == 200 т.р. (со всеми налогами) * 2 мес


Прикручивание же ST к p-code можно вообще за пределами ОВЕН делать.
Реальный пример: лично я прикрутил ST к управлению быстрыми входами-выходами ПЛК110. Суммарно работы заняли менее месяца на выходных.

[ASo]

Ну да, ну да....
И что же ОВЕН никак не может прикрутить новые CDS SP к СПК? А Инсат на 2..3 года(!) задержал выход МС4, которая и сейчас "сырая"?

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

Ну да, ну да....

Ну, да.

Hardella работает, а варианта от ОВЕН (или ещё кого-то) на горизонте не видно.

Ещё раз подтверждается факт, что "ну да, ну да..." говорят те, кто не разбираются в предмете.
Можно много чего с умным видом говорить, но Hardella работает, хотя скептики только и делали, что занимались своим скептическим делом.

И что же ОВЕН никак не может прикрутить новые CDS SP к СПК?

А как это относится к ОЛ-ПР?
Как-никак, на КДС ОВЕН вряд ли имеет ощутимое влияние.
Работать же "со своим p-code" должно быть гораздо проще.

А Инсат на 2..3 года(!) задержал выход МС4, которая и сейчас "сырая"?

Так программа МС4 посложнее, чем p-code блок для ОЛ.

[ASo]

Генератор p-code из ST кто напишет?

По поводу альтернативы Харделлы. Видимо, никому не нужны быстрые входы-выходы. Это стандартно. Многие кричат "сделай", как сделают - нужно единицам.

[Newcomer]

Генератор p-code из ST кто напишет?

По поводу альтернативы Харделлы. Видимо, никому не нужны быстрые входы-выходы. Это стандартно. Многие кричат "сделай", как сделают - нужно единицам.

Землекопу точно не надо, а кому-то очень даже надо, например мне. В.Ситников сделал большое и важное дело. Альтернативы Hardella действительно нет.

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

Это просто капец. В ОЛ УЖЕ есть компилятор, потому что ПР200 не исполняет программу в виде квадратиков, но только в виде машинных кодов. А поскольку я не верю, что в ОВЕН писали ОЛ с трансляцией напрямую в машинные коды, то могу предположить что каждому функциональному блоку соответствует подпрограмма в виде текста на С. И вся эта графическая картинка СНАЧАЛА транслируется в С, а ЗАТЕМ, встроенным компилятором, уже в ассемблер и машинные коды.

Ну будут спрашивать и что? Сейчас не спрашивают?

Это не капец, а незнание архитектуры ПО ПР. Нет там никакого транслятора в машинные коды. Добавить макросы на С===переделать ПР полностью, включая и прошивку и среду разработки.

[smk1635]

Пока мы не освоим микропроцессорный язык микроконтроллеров так и будим плестись в хвосте и выискивать баги и ждать новых версий. Как уже сказали выше что ПР200 очень удачное решение но есть ограничение по ОЛ это правда. Нужно открыть второе дыхание популярности, это открыть возможность работы на микроконтроллерном уровне, нужен физический старт а далее пойдет все своим чередом. Линукс тоже делался на энтузиастах.

Угу. А потом, в случае чего, заказчик, да же имея на руках исходный код программы, будет судорожно метаться в поисках кто бы мог разобраться в коде. Попутно твердо уверовав, что ПР200 ни куда не годится.
Вот зачем это Овен?

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

Генератор p-code из ST кто напишет?

А хоть кто.
Вполне возможно, прямо в p-code напишут. Точно так же, как сейчас "из спортивного интереса" рисуют ОЛ картинки на 1000+ элементов.

Ну и диадемовая черепаха, в конце концов, чем плоха?

По поводу альтернативы Харделлы. Видимо, никому не нужны быстрые входы-выходы. Это стандартно. Многие кричат "сделай", как сделают - нужно единицам.

Я пример приводил к тому, что много кто говорил, что "мой подход нерабочий". По факту же, подход оказался рабочий.
Так и тут: много кто говорит, что нужно много миллионов и вообще невозможно, а вариант с p-code может оказаться вполне рабочим. Вариант с C, разумеется, и рассматривать смысла нет.


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

Вот текущая Яндекс Метрика черепахи (19 декабря это дата запуска сайта):
Снимок экрана 2017-04-12 в 21.12.26.png