Когда все будет готово окончательно ?
Вид для печати
Когда все будет готово окончательно ?
"Всё" это понятие растяжимое. Если туда включать online отладку, симуляцию из самой среды, точки останова, автотесты из среды, то это "всё" одним наскоком не сделатьЦитата:
Сообщение от Вольд
А тестировать Hardella -> pru0 будем недели через две.
При этом, смена программы даже перезапуск плк не потребует. Можно будет как на марсоходе программу на ходу менять.
Чего же? Все по делу. Если честно, я не думал, что на ходу программу менять можно. Смысла, наверное, не так много (ведь, контакты кто на ходу будет переключать), но возможность сменить программу может пригодиться. Не только для вируса, а, например, для повышения точности.
Или, например, для online обновления программы.
Так тут вопрос не в "российских компаниях", а в КДС. Указатели есть, защищенного режима нет - кто угодно может работать с какой угодно памятью.
ну КДСовский протокол при чрезмерной активности "подвешивается" так, что из вариантов только перегрузка, с пру конечно тоже есть ограничения, но и обычно первые входы/выходы у пользователей как раз и задействованы впервую очередь, соответственно нет ни каких проблем захватить их
Возник такой вопрос: можно ли как-то из КДС кода узнать название текущего ПЛК?
Мне это нужно для того, чтобы библиотека не падала в режиме симуляции, и чтобы не приходилось комментировать-раскомментировать постоянно.
Вроде, можно через PRU_FB_GetParameter(pru_num:=0, index:=100500, value:=0) отличить симуляцию от работы, но, может, есть ещё какой-нибудь способ?
Сделал новым подходом программу, мигающую двумя выходами, залил в ПЛК -- работает.
Надо будет проверить обмен данными, входы и можно выпускать обновление Hardella.
Hardella рулит. ;)Цитата:
Сообщение от Владимир Ситников
Зачем нужен этот костыль ? Сделайте нормальный источник питания.Цитата:
Сообщение от Филоненко Владислав
Почему же нельзя? Если что, то PRU у меня работает только со своей памятью. Т.е. local dram, которая за пару тактов доступна.Цитата:
Сообщение от Филоненко Владислав
потому что выше у вас написано >>>> "PRU берёт BOOL из основной программы и записывает его в другую переменную."Цитата:
Сообщение от Владимир Ситников
но смысл поста Владислава в том, что нужно, как минимум понимать, что будет с алгоритмом, если ему из другого потока значение переменных менять, а в общем случае - проклясть и не использовать сей "метод"
Вот вот, данных нет, но я решил, что...
Нельзя так сделать.
Идея всей программы PRU как одного куска на С-подобном языке мне не нравилась из-за проблем с тестированием кода. Но это цветочки по сравнению с прямым доступом к ОЗУ (да ещё и "скрытым от пользователя").
И если подход с компиляцией непонятно чем программы из С-языка я ещё могу понять, то
Как разработчик системы ПЛК ответственно заявляю:
Прямой доступ из PRU к ОЗУ за пределами PRU, либо из основного цикла ПЛК к PRU по указателю является опасным и при таком доступе не гарантируется соблюдение алгоритма работы PRU, цикла PRU, либо правильность получения в PRU/из PRU данных.
гм, при 16-битной шине и наличии в системе нескольких DMA контроллеров, которые использует ОС ПЛК по своим неизвестным нам приоритетам... ну - нуЦитата:
Т.е. мой подход опирается на следующее:
1) Чтение/запись DWORD атомарны (всегда читается/записывается полное значение)
а идея, под которую затачивались ПРУ ядра - это остановить ядро, загрузить блок данных, запустить ядро на обработку и по завершении - остановить вычисления и выгрузить результат
И учитывая, что у PRU только побайтное чтение/запись. Ню-ню.Цитата:
Сообщение от Дмитрий Артюховский
Короче - без знания железа и внутренних потрахов лезть туда не безопасно чистым программистам или нужно все согласовывать и работать по ТЗ.Что бы ню-ню не превратилось в ба- бах ;)
вывод не совсем правильный ))) разговор о том, что нужно хорошо понимать что именно собираешься сделать....Цитата:
Сообщение от rovki
концепция "овена" - конструкции из проверенных "атомарных" блоков с прозрачным и однозначным функционированием, и поскольку библиотеку будет распространять овен - то и нести некую ответственность за конечную работоспособность системы
господин Ситников продвигает свою среду разработки - презентуя ее в стиле - каждый станет богом программирования с этой волшебной оболочкой ))) как он ее будет поддерживать, и будет ли "диктовать бабушкам емейлы" - большой вопрос, и скорее похоже на желание продать этого "слона" овену (возможно вместе с собой!)
лично мне больше всего импонирует концепция ассемблерных модулей - все едино они там не большие получаются - отлаживать не сложно, зато свободными от окружающей шелухи - различных оберток... и собственно это натуральная среда, предполагавшаяся разработчиками чипа, позволяющая использовать все возможности ( и кстати, выйти за ограничения кодесиса, ибо ядра ПРУ имеют доступ ко всей памяти и ко всем периферийным устройствам - гы - поставить в основном цикле холостой оператор и выполнить весь функционал на "чердаке"!!! - это конечно смешно, но вполне возможно (правда 2к команд) )
Значит не в среде разработки дело, а в правильном подходе к PRU - программированию.Цитата:
Сообщение от Дмитрий Артюховский
не обязательно... как я понял, заложенный механизм работает следующим образом: когда PRU что-нить нужно - оно генерит прерывание, сообщающее ЦП о желании пообщаться и ЦП освобождает шину, занимаясь другими проблемами - при кеше ядра в 16к вполне есть чего поделать... и это нормально, потому что одно из назначений PRU первичная обработка получаемых с интерфейсов данных..Цитата:
Вся красота разбивается о суровую реальность: задержка доступа к основной памяти запросто может быть 50 тактов, т.е. тупо ждём по 0.25мкс на каждое обращение к памяти. Беда-печаль.
не, конечно нас не пустят в прерывания ЦП, но суть в том что ожидание: 1. совсем необязательно будет, все таки в ПЛК нет обмена видео и аудио потоками и 2. ПРУ имеет высокий приоритет на доступ к шине
но учитывать возможность в задержках и разрыве потока байтов обязательно ))) .... буфера обмена и флаги !!!!
Понимание возникает (или нет) от знания ,а не наоборот .Цитата:
Сообщение от Дмитрий Артюховский
нравится Хардела - используйте её, чего тут агитировать за всё хорошее.
Как по мне не хватает простых примеров.
Взять что даёт codesys по умолчанию, что даёт ОВЕН (удобство) и вашу работу и сравнить хоть в видео, хоть в таблице, плюсы минусы и аргументы.
а Вы видимо распробовали, теперь проекты пишите только там?Цитата:
Сообщение от Вольд
Добрый день.
Прошу помощи в подборе контроллера.
Имеются два ШД (FL86STH65) и два драйвера (PLD441) для них (Step/DIR/Enable). Контроллеры какой линейки подойдут для их управления?
Смотрела на сайте, там указано, что и ПЛК 100 имеет ШИМ, и ПЛК 150 линейки тоже, и ПЛК 110. Но только в характеристиках последнего указано наличие быстрых выходов. А у первых двух про это ни слова.
Кроме ШД имеются: аналоговый датчик температуры, 8 клапанов НЗ, каждый управляется одним дискретным сигналом; насос, управляемый также одним дискретным сигналом; входных сигналов дискретных нет.
Заранее благодарю за помощь.
Про ПЛК100, 150 точно можно забыть...
Какая скорость (частота импульсов) и точность (через ШИМ будет погрешность) ШД нужна?
Если "управлять выходами STEP/DIR напрямую с ПЛК" И "нужна частота STEP больше 500Гц" И "нужно точное позиционирование" то ПЛК110 М02.
Управление ШД на ПЛК110 М02 обсуждается тут и тут.
Либо нужен какой-то другой драйвер ШД (с управлением не STEP/DIR, а прямо нормальными командами).
а на 110-ом есть аналоговые входа?
Аналоговый датчик придется опрашивать через последовательный порт.Цитата:
Сообщение от capzap
Управлять нужно напрямую с ПЛК, точного позиционирования, вроде, не нужно. Частота требуется больше 500 Гц, но не Мегагерцовая. По характеристикам ПЛК 110 (не M02, а предыдущей линейки), имеет высокочастотный таймер на 20 мкс. В этом случае можно ли использовать старую линейку 110-ых?Цитата:
Сообщение от Владимир Ситников
В общей сложности потребуется где-то 16 DO сигналов (в том числе и для управления ШД) и 1 AI. В составе ни одного ПЛК нет требуемого кол-ва. Поэтому, думаю, придется ещё аналоговым модулем укомплектоваться.Цитата:
Сообщение от capzap
Старую линейку лучше не использовать.Цитата:
Сообщение от yulya.aniskina2010
Высокочастотный таймер тоже лучше не использовать (правильно его готовить могут только разработчики самого ПЛК110)
20мкс на таймере вы не получите. В лучшем случае 40 или 60мкс (иначе будут проблемы с основным циклом, сетевым обменом и тому подобным)
На М02 можно управлять быстрыми входами выходами без всяких 20мкс таймеров.
500кГц ШД (на самом деле серво) без таймеров можно вполне сделать на М02.
Если точность не нужна, то можно, конечно, попробовать управлять ШД через ШИМ, но, на мой взгляд, это стрёмный путь.
Прежде чем покупать старый ПЛК110, прочтите это http://www.owen.ru/forum/showthread....l=1#post226391Цитата:
Сообщение от yulya.aniskina2010
плк160 имеет на борту и быстрые выхода и аналоговые входа,их же можго использовать как и дискретныеЦитата:
Сообщение от yulya.aniskina2010
О, да, быстрые релейные выхода. Управление ШД через релейные выхода это передовое слово в развитии ПЛК.Цитата:
Сообщение от capzap
Если что, то ПЛК160 с транзисторными выходами не бывает.
хмм...Цитата:
Сообщение от capzap
интересно что там за быстрые выхода??
ой блин поймали, я не пользуюсь ни входами ни выходами, а из доков читал только http://www.owen.ru/uploads/rp_plk110.160.pdf.
Да что вы такое пишите. Вы РЭ на ПЛК110 почитайте.Цитата:
Сообщение от yulya.aniskina2010
А что не так?Цитата:
Сообщение от Вольд
AI в ПЛК110 нет.
Т.е. рабочая комбинация -- ПЛК110М02 + нужный модуль для AI.
Либо "любой ПЛК" + драйвер ШД (который умеет команды обрабатывать)
Под словами "любой ПЛК" стоит понимать ПЛК110 М02 (т.к. с ПЛК160, ПЛК110 M01 проблемы, которые описал Scream)
Автор темы пишет, что ей в ПЛК не хватает выходов. Вот это и не так.Цитата:
Сообщение от Владимир Ситников
Вы меня неверно поняли или я непонятно выразилась. Имела ввиду, что нет контроллера, на борту которого имеются необходимое кол-во дискретных выходов, включая быстрые, и аналоговых входов. Поэтому, тоже склоняюсь к комбинации ПЛК110 М02 и модуль AI.Цитата:
Сообщение от Вольд
И хочу поблагодарить за помощь всех откликнувшихся. Спасибо вам :)
Именно про это я и говорю: "надо подумать как это органично встроить"Цитата:
Сообщение от murdemon