Да никакой там ток не течет, если транзистор закрыт. Резистор является нагрузкой для ПЛК и включен он параллельно оптрону. А вот форма импульсов улучшилась кардинально. 2кОм можно поставить, не спорю. Хотя и при 1 нагрузка на выход ПЛК 25 мА. (допустимая 400 мА).
Перестают управляться 2 быстрых (ПЛК-110.32) и первые 2 простых входов. Входы.jpgСообщение от capzap
Не заливать, конечно можно, но и генерировать нечем будет. Нафига тогда эти PRU предложили?
Последний раз редактировалось dima64; 04.10.2016 в 14:24.
Это проблемы роста.
Да как он там течет? Я не схемотехник, нарисуй картинку.
Вердикт: эксперимент показывает, что регистры _не_ переиспользуются. Тут всё ровно так, как и говорил Владислав.
Дмитрий, я требую извинений.
Вот пример: test_add.zip, pru_register_reuse.png
Видно, что после того, как первые AND'ы отрабатывают, то регистры можно и переиспользовать для следующих AND'ов.
Компилируем и видим такое (в конце):
Видно, что номера регистров только растут. Т.е. регистры с меньшими номерами не переиспользуются.Код:#defFB PRU_AND2_64 PRU_AND2 R8.b2 R8.b3 R9.b0 #defFB PRU_AND2_59 PRU_AND2 R7.b1 R9.b0 R9.b1 #defFB PRU_AND2_65 PRU_AND2 R5.b2 R9.b1 R9.b2
Пойдём в target.trg файл, и уменьшим значение REG_END=28 до 8-и. Ну, сделаем вид, что в нашем PRU всего-навсего 8 регистров.
Что нам скажет компилятор?
Он нам скажет "unknown ID 0 in element", и вообще не сможет скомпилировать такое FBD.
Т.е. по факту, компилятору не хватило R2..R8 регистров (7 штук по 4 байта каждый, т.е. 28 байт!).
А по факту, видно, что регистры для "AND" блоков очень быстро становятся ненужными.
По факту, тут 4 "FROM_HOST" блока. Да, 16 байт действительно нужно постоянно хранить (информация с HOST'а обновляется далеко не в каждом PRU цикле). Но остаётся целых 12 байт == 28-16, и линкер всё равно не смог выполнить несколько AND'ов? Что за ерунда?
Поэтому я и говорю, что мой подход и подход ОВЕН в части компиляции существенно отличаются.
Ну это я к чему, не к тому, что "инструмент beta PRU плохой", а к тому, что это моя аргументация почему я не могу просто взять и оформить свою ШД программу "по правилам ОВЕН". Тут не только моё субъективное "не хочу тратить время", но и вполне конкретная техническая проблема.
Последний раз редактировалось Владимир Ситников; 04.10.2016 в 16:15.
Откуда тут земля нарисовалась? Посмотри картинку PRONET1.
Я ошибся. при закрытом транзисторе ток через светодиод вообще не течет.
Последний раз редактировалось Newcomer; 04.10.2016 в 16:13.
На этот вопрос (можно ли выводить результаты PRU программы в "plc configuration") тов. Филоненко говорит решительное нет. Ну, что, якобы, адреса памяти КДС назначает произвольно, что это в концепцию ПЛК110 не укладывается и т.п.
С моей точки зрения, звучит, конечно, неубедительно. Свои fast encoder/fast counter программы в ОВЕН как-то сделали и в конфигуратор сумели вывести? Значит и для PRU программ такая возможность может быть. Да, возможно, это потребует доработку прошивки, но fast encoder же как-то сделали модулем в plc configuration?
Тем не менее, над конкретно этим вопросом предлагаю не заострять внимание, а воспринимать его как "данность свыше".
Обмен только через pruaccesslib.lib? Ну, ок.
Конечно, и в части "обмена host-pru" можно сделать более удобные механизмы, но нет никакого смысла тратить время и силы на обсуждение механизмов обмена данными и plc configuration, если ОВЕН молчит про саму возможность составлять PRU программы.
нет,я не про это, протестил конечный пользователь работу пру и перешел к повседневным делам. как ему вернуть контроль, если залитая программа в пру до сих пор крутится, как от нее избавиться?
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Отступать нельзя -- позади Москва.
Можно залить пустой файл -- тогда всё вренётся к обычному режиму.
Ваши права
Ответить с цитированием