Эти КИТы были на базе PIC18 (ПР110) , с очень ограниченным функционалом .А вот другие КИТы очень даже имеют спрос -ардуино ,например .
электронщик до мозга костей и не только
Между PIC18 и STM32 разница в популярности. Если предлагать PIC18, то его будут брать очень мало,или никто. А если предлагать STM32, да еще сделать его совместимым с Arduino (уже есть платы на STM32 совместимые с Arduino), то можно предсказать больший интерес покупателей - все те, кто сейчас пытается "приколхозить" на проводках ардуиновксие платы для "дома и семьи" - будут иметь возможность купить нормальный прибор. Т.е. люди освоившие автоматику через Arduino - смогут получить возможность развития. Купить ПР200 можно и сейчас, но немалое количество пользователей не знает зачем он им и не знает языков ПЛК.
Молодца. Всё именно так.
А почему IL:
- переносимость (Ядро не правилось уже десяток лет, несмотря на кучу платформ)
- расширяемость (float-ы и доп. ФБ добавились без вреда для остального кода) И др. ФБ вставятся так же.
- стабильность и предсказуемость - ФБ протестировать легко, ФБ друг на друга не влияют, время выполнения и ресурсы константны.
А С никому не интересен, кроме гиков и ОЧЕНЬ крупных системных интераторов. Сложный язык с кучей side effect, крутой кривой обучения, затрудненной отладкой, проблемами с симуляцией на кросплатформенных приложениях, БОЛЬШИМИ проблемами с совместимостью кода на разных платформах и слабой (для непрофессионала) переносимостью.
А тут квадратиков накидал, в симуляции проверил и вперед.
Приборы с программированием на С у нас продаются, ПЛК100, 110, 304-323 - можно купить с Линукс. И кодь себе до посинения. Покупают КРУПНЫЕ интеграторы, к-е знают зачем и как применить.
Тролль-наседка, добрый, нежный и ласковый
По ценам промолчу, но с чего бы им быть дороже? А что не рекламируем - да никому не нужны с улицы. А так - 100, 323 ЛЕГКО купить. 110 - немного сложнее, но некритично. Обращайтесь. При 1000+ в год - большие скидки.
Тролль-наседка, добрый, нежный и ласковый
Сделать блок, который будет в себе содержать пользовательский код?
Мы это уже проходили с ПРУ - вся программа вырождается в 1 блок, потом все бегают по кругу - а почему у меня при ХХХ YYY работает не так. Оттестировать "суперблок" невозможно в принципе.
время выполнения скачет как кенгуру, ОВЕН, спасите, проект горит.
Зачем такие сложности?
Тролль-наседка, добрый, нежный и ласковый
Ну, да, пользовательский код.
Вот сейчас в ОЛ есть такая штука как макрос. Там содержится пользовательский код.
И ничего, многим нравится. Многих выручает.
Какая-то проблема с этим?
Повторюсь, код не бинарный, а p-code.
А что называется словом "оттестировать"?
Вот "макрос ОЛ" можно оттестировать?
Если можно, то и "p-code блок" тоже можно оттестировать.
Суперблок это будет или нет зависит от того, будет ли в p-code инструкция "CALL macro".
Надеюсь, если не в первой версии p-code блока, то следующих эта инструкция появится (ну, чтобы можно было вызывать проектные макросы).
А значит, можно будет вызывать и один p-code блок из другого.
А значит, "оттестирование" p-code блока будет несильно сложнее, чем "оттестирование обычного ОЛ макроса".
Можно же сложные p-code блоки составлять из более простых. Всё в порядке. Где "невозможность в принципе"?
Про возможность тестирования p-code за пределами ОЛ я пока не буду распространяться.
Тестирование PRU блока вполне возможно (pru-emulator прекрасно работает).
Есть реальные примеры, когда пользователи берут и раскручивают ШД на ПЛК110 буквально за день. С разгоном и торможением, без мутоты с прерываниями.
Сами качают среду, заливают PRU0.prg и всё такое.
И никто не бегает как кенгуру. Оно просто работает.
Наоборот, кто-то вообще взял и с нуля сделал свою PRU программу на ST. Да, с точки зрения КДС это получился "один блок", но с точки зрения пользователя это нормальные ФБ и понятный ST код.
В этом плане p-code блок в ОЛ будет смотреться гораздо более органично, ведь по сути он не будет отличаться от имеющихся макросов. А PRU программа хочешь-не-хочешь выполняется на другом ядре процессора, и там даже передача данных это непростая задача.
Последний раз редактировалось Владимир Ситников; 21.04.2017 в 11:04.
Не знаю как в ПР, но в PRU программах, которые создаёт Hardella, время выполнения не скачет. Там есть погрешность в 5-10 наносекунд, но называть это "скачет как кенгуру" явное лукавство.
Если у вас есть достаточно точный осциллограф -- можете взять и убедиться.
Вернее даже наоборот: если пользовательский код заканчивается раньше, то больше времени остаётся на служебные задачи (RS-485, экран и т.п.).
Макрос легко отлаживается за счет его опять-же, "чистоты".
Каждый макрос тестируется подачей на него тестовых последовательностей входов. Если он на все тестовые последовательности отвечает правильным выводом, вы можете вставлять макрос куда угодно и будете на 100% уверены, что он будет работать.
Если же добавить туда возможность доступа к любым внешним сущностям, вот тогда и начнется "спасите, ничего не работает"=)
Таким образом всё будет зависеть от того, какой доступ будет предоставляться пользовательскому коду.