ПР200

[rovki]

Абстрактные хотелки все это для пр200 .Соединить последовательно макросы из 8(16,32) селов не представляет сложности .Если не будет связи ,то выход висящего макроса не будет активен ...О тех ошибках ,что вы говорите вообще ни кто не париться ...исправляются и находятся на раз ...Вроде умный человек ,а вьехать не можете ,что у схемотехников восприятие другое .Если на картине нарисованы 3 кита ,то он и видит три , и ему не надо читать книгу об этом ,где написано ТРИ, да еще на иностранном языке часто .

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

у схемотехников восприятие другое

Полюбуйтесь на перечень доработок в ОЛ 1.9: http://www.owen.ru/forum/showthread.php?t=25870
То, что я предлагаю идёт в работу. Можно сколько угодно с пеной у рта говорить, что "fSEL не нужно", и про "отличия прямых и обратных связей", но против факта не попрёшь. В ОЛ 1.9 добавили встроенный fSEL, и переименовали обратные связи в линии задержки.


Разумеется, массивы в ОЛ 1.9 не попадут, но это не значит, что они "никому не нужны".
С текущими темпами развития, массивы появятся в ОЛ 2.2 (года через 3).

Поймите же, наконец, отличие фраз "никому не нужно" и "не реализовано в ОЛ".

Если на картине нарисованы 3 кита

Детский сад какой-то. 3 блока AND это 3 блока AND.

А вот очередь задержки на 400 элементов невозможно окинуть одним взглядом и сказать, что это реально очередь и реально 400, а не 402.
Да и нарисовать/протестировать очередь на 400 элементов за 15 минут не получится.

Была куча исследований на тему того, сколько предметов мозг человека/муравья/обезьяны способен обрабатывать одновременно. Не надо приплетать всякое левое "у электронщиков мозг способен помнить про каждый из 500 элементов". Очевидно, что большинство людей так не может. В том числе, большинство тех, кто по долгу службы работает с ОЛ.

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

Можно сколько угодно с пеной у рта говорить, что "fSEL не нужно", и про "отличия прямых и обратных связей", но против факта не попрёшь. В ОЛ 1.9 добавили встроенный fSEL, и переименовали обратные связи в линии задержки.

fSEL просили включить в ОЛ ещё тогда, когда вы об этом форуме и не подозревали.
Я же считаю, что нужно ещё сделать ФБ fMEMR, т.к. примерно в 70-85% случаев макрос fSEL используется как ячейка памяти.
Да и ФБ MEMR не повредит, для целочисленных переменных.
http://www.owen.ru/forum/showthread....l=1#post229971

А вот очередь задержки на 400 элементов невозможно окинуть одним взглядом и сказать, что это реально очередь и реально 400, а не 402.
Да и нарисовать/протестировать очередь на 400 элементов за 15 минут не получится.

Сваял макрос на 32 элемента, оттестил его, воткнул в программу, соединил последовательно N макросов... В чём проблема?
Монитора с разрешением 100500х100500 нет? Так он и не нужен...

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

fSEL просили включить в ОЛ ещё тогда, когда вы об этом форуме и не подозревали.

Если wal79 скажет, что "рассмотрение fSEL началось с темы 'fSEL, ты где?' ", тоже не поверите ему?


Цитирую (ответ программиста ОЛ на моё предолжение добавить блок fSEL в ОЛ):

Добавление fSel как блока будет рассмотрено.

fSEL просили включить в ОЛ ещё тогда, когда вы об этом форуме и не подозревали.

Про "линию задержки" все скромно умалчивают? Или у какого-нибудь электронщика хватит смелости заявить, что переименовать "обратную связь" в линию задержки просили до того, как это сделал я?

Да и ФБ MEMR не повредит, для целочисленных переменных.

Лучше уж сразу сделать поддержку массива. "одна ячейка" это частный случай массива длины 1.

Сваял макрос на 32 элемента, оттестил его, воткнул в программу, соединил последовательно N макросов... В чём проблема?

Повторяю по буквам:
1) Запросто может оказаться, что какая-нибудь связь пошла не туда, не подключилась, или лишняя связь.
2) В ОЛ отсутствует понятие автоматических тестов. Т.е. пощёлкать на 2-3-4 элемента ещё можно, а вот найти ошибку, что "30 и 31ый элементы перепутаны" крайне затруднительно.
3) Потребление ресурсов ПР будет чрезмерным. Например, линия задержки из 400 SEL'ов будет выполнять как минимум 400 операций в каждом цикле ПР. Каждая SEL ячейка будет "пересохранять значение". В случае же массива, добавление/чтение записи это лишь пара целочисленных операций с индексами. Т.е. не 400 операций, а 3-4.

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

Те, кто, якобы, сходу замечают неправильную связь в пауке из 32 элементов пусть сначала обыграют мартышку тут: https://www.youtube.com/watch?v=n_tJoW2hctM

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

Если wal79 скажет, что "рассмотрение fSEL началось с темы 'fSEL, ты где?' ", тоже не поверите ему?

Ну почему не поверю? Или у него есть время перечитывать все посты в разделе ПР за последние 4 года?

Про "линию задержки" все скромно умалчивают? Или у какого-нибудь электронщика хватит смелости заявить, что переименовать "обратную связь" в линию задержки просили до того, как это сделал я?

У 100% новичков от этой формулировки пердак подгорает.

Лучше уж сразу сделать поддержку массива. "одна ячейка" это частный случай массива длины 1.

Вообще-то для таких задач контроллер лучше подходит.
Особенно когда делаешь единичный проект.

Повторяю по буквам:
1) Запросто может оказаться, что какая-нибудь связь пошла не туда, не подключилась, или лишняя связь.
2) В ОЛ отсутствует понятие автоматических тестов. Т.е. пощёлкать на 2-3-4 элемента ещё можно, а вот найти ошибку, что "30 и 31ый элементы перепутаны" крайне затруднительно.
3) Потребление ресурсов ПР будет чрезмерным. Например, линия задержки из 400 SEL'ов будет выполнять как минимум 400 операций в каждом цикле ПР. Каждая SEL ячейка будет "пересохранять значение". В случае же массива, добавление/чтение записи это лишь пара целочисленных операций с индексами. Т.е. не 400 операций, а 3-4.

1) Не нужно пить на рабочем месте.
2) Автотест это конечно интересно, но сколько усилий уйдёт на создание образа? И насколько уменьшим время поиска ошибки? (это при условии, что образ для автотеста написан правильно)
3) да двигай адреса вкруговую, и не надо ничего смещать-перезаписывать, те-же 3-4 операции... кто запрещает? религия?

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

16 mhZ. Офигительно крутая "моща"...

Те, кто, якобы, сходу замечают неправильную связь в пауке из 32 элементов пусть сначала обыграют мартышку тут: https://www.youtube.com/watch?v=n_tJoW2hctM

Сам-то осилишь ? У неё кратковременная память - фотографическая.

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

Хорош прибедняться. Прямо как в басне Крылова про лису и виноград... Купит вам директор контроллер, если хорошо попросите и обоснуете.
ОЛ для относительно простых задач.
Кстати, как ваша система из 4Х32 входных модулей + 2 х 32 выходных + ИП320 + аналоговый ввод + МДВВ работает?
Я такого монстра на ПР200 точно собирать не стану... Мозг вывихнешь на отладке... Только на ПЛК.

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

3) да двигай адреса вкруговую, и не надо ничего смещать-перезаписывать, те-же 3-4 операции... кто запрещает? религия?

Объясняю ещё раз: ОЛ не может "не выполнять" код. Если создано 400 SEL ячеек памяти с линиями задержки, то на каждый такт ПР оно будет брать значения с линии задержки, подавать на вход каждого SEL, и сохранять результат "в линию задержки". Сколько команд выполняется реально я не знаю, но уж совершенно точно не меньше одной на каждый SEL.

Вот как предлагаете "двигать адреса вкруговую"?
Моё утверждение в том, что каждый элемент на схеме ОЛ это как минимум одна команда при выполнении.
Для "очереди на 400 ячеек" по-любому потребуется 400 элементов (явно больше, но 400 это минимум). И это вообще не зависит от того, как элементы связаны между собой.


Кстати, ещё момент вспомнил: даже если проект на 400 ячеек и получится создать, отладить, то всё равно ОЛ будет тормозить при большом количестве связей/блоков на одном экране. По-любому будут проблемы с проведением связей и т.п.
В этом плане наличие одного блока с массивом упростит саму схему, и, соответственно, снимет необходимость оптимизировать ОЛ под несусветное количество элементов на схеме (в макросе и т.п.)

16 mhZ. Офигительно крутая "моща"...

У ПР200 процессор на 72МГц (см http://www.owen.ru/catalog/programmi...pr200/50431885 )

Сам-то осилишь ? У неё кратковременная память - фотографическая.

Разумеется, нет. Это же мой аргумент к тому, что одним взглядом средний человек не осилит и 10 квадратиков.
Я где-то до 4го успеваю запомнить.

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

Объясняю ещё раз: ОЛ не может "не выполнять" код.
Кстати, ещё момент вспомнил: даже если проект на 400 ячеек и получится создать, отладить, то всё равно ОЛ будет тормозить при большом количестве связей/блоков на одном экране.

Согласен.

У ПР200 процессор на 72МГц (см http://www.owen.ru/catalog/programmi...pr200/50431885 )

Правда? Даташит на проц почитай. (Заодно проникнешься какую мощность проц рассеивает на 72 Mhz в активном режиме.)
Я ПР200 разбирал, и на тактирование применён кварц 16Mhz.