Можно ли сделать проще?

[ShveikOff]

Дано:

Есть 6 параметров для работы сушильного шкафа. Также 16 рецептов с конфигурациями этих параметров.

Задача:

Написать макрос, который в зависимости от выбранного рецепта (груши, яблоки, айва и т.д.) будет менять эти параметры...

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\

У меня получилось следующее.

46823
46824
46825

к сожалению открыл для себя ПР200 и OwenLogic относительно недавно, до этого работал в Step7.
Вопрос к знатокам. Можно ли сделать это проще?

[Сергей0308]

Дано:

Есть 6 параметров для работы сушильного шкафа. Также 16 рецептов с конфигурациями этих параметров.

Задача:

Написать макрос, который в зависимости от выбранного рецепта (груши, яблоки, айва и т.д.) будет менять эти параметры...

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\

У меня получилось следующее.

46823
46824
46825

к сожалению открыл для себя ПР200 и OwenLogic относительно недавно, до этого работал в Step7.
Вопрос к знатокам. Можно ли сделать это проще?

Есть же мультиплексоры!

46827

[Серёга Букашкин]

Просто соединяйте средний вход SEL с выходом предыдущего и все ADD исчезнут.

[ShveikOff]

Видел в базе макросов мультиплексеры, но здесь их гораздо больше.
Хм, довольно непростые штуки если внутрь заглядывать. Сложно вообще создавать такие на FBD, по сравнению с каким-нибудь строчным языком?

[ShveikOff]

Да, уже понял, что так разумнее делать))

[Сергей0308]

Видел в базе макросов мультиплексеры, но здесь их гораздо больше.
Хм, довольно непростые штуки если внутрь заглядывать. Сложно вообще создавать такие на FBD, по сравнению с каким-нибудь строчным языком?

Это только первый макрос на 32 входа сделан по другому принципу, остальныые попроще, для понимания работы и это мои, для себя делал(или помогал кому), все с расширением, кроме первого(на 32 входа), поэтому присутствуют настройки в свойствах макроса.

[ShveikOff]

Ясно, спасибо, за макросы. Уже сильно помогут с решением задачи.

[ShveikOff]

Извиняюсь, хочу уточнить. За что отвечает вход IR в макросе MUL16R1?

[Сергей0308]

Извиняюсь, хочу уточнить. За что отвечает вход IR в макросе MUL16R1?

Вход расширения, можно открыть макрос для редактирования и посмотреть, там подписан этот вход и я в проекте расширил количество входов до 32 с помощью двух макросов мультиплексоров по 16 входов, из этого примера тоже понятно для чего вход IR.

[nickbeljaev]

Есть же мультиплексоры!

46827

Предлагаю делать мультиплексоры так
https://drive.google.com/file/d/17aVwHKbiLc_A3jtFqJMbaZ7QtlfogFuf/view?usp=sharing
Не знаю будет ли быстрее или компактнее - надо знать реализацию, но обычно так "правильнее" :)

[Сергей0308]

Предлагаю делать мультиплексоры так
https://drive.google.com/file/d/17aVwHKbiLc_A3jtFqJMbaZ7QtlfogFuf/view?usp=sharing
Не знаю будет ли быстрее или компактнее - надо знать реализацию, но обычно так "правильнее" :)

Ну это Вам не электронная схема, где каждый элемент вносит определённую задержку и в случае цепочки эти задержки суммируются, здесь и так всё "мгновенно" коммутируется, может Вы хотели сказать, меньше ресурсов отъедает?
И хотел сказать у любого варианта есть свои плюсы и минусы, Вы видели мой проект, что я вначале выложил, там я расширил количество входов до 32(можно и более) просто поставив рядом два мультиплексора по 16 входов, теперь попробуйте сделать тоже самое с вашим мультиплексором, который Вы советуете, так вот с вашим такое не пройдёт, потребуется куча дополнительных элементов, боюсь и ваша скорость пострадает, пока не знаю скорость чего Вы имели ввиду, скорость создания проекта уж точно!

[nickbeljaev]

Ну это Вам не электронная схема, где каждый элемент вносит определённую задержку и в случае цепочки эти задержки суммируются, здесь и так всё "мгновенно" коммутируется, может Вы хотели сказать, меньше ресурсов отъедает?
И хотел сказать у любого варианта есть свои плюсы и минусы, Вы видели мой проект, что я вначале выложил, там я расширил количество входов до 32(можно и более) просто поставив рядом два мультиплексора по 16 входов, теперь попробуйте сделать тоже самое с вашим мультиплексором, который Вы советуете, так вот с вашим такое не пройдёт, потребуется куча дополнительных элементов, боюсь и ваша скорость пострадает, пока не знаю скорость чего Вы имели ввиду, скорость создания проекта уж точно!

Да не, в "правильном" варианте в муксе на 4 входа 5 блоков, на 8 входов 10 блоков, на 16 входов 1+2+4+8+4 = 19 блоков, на 32 входа 1+2+4+8+16+5 = 36 блоков итд, а сколько блоков в "неправильном" муксе на 32 входа? не 64 часом? Вероятность того что "правильный" мукс еще и будет жрать меньше тиков крайне высока, особенно если каждый блок в любом случае выполняется. И еще "битовый" мус позволяет использовать цикличность то есть если на него подавать выход счетчика он будет перебирать значения по циклу, в ФБД это очень полезное свойство, например потактовые циклы так делают.
Вообще в программировании очень не хорошо изобретать велосипеды, обычно все задачи уже решены до нас и гораздо лучше чем мы сами это сможем, поэтому везде где можно надо изучать источники - экономит много времени и человеческого и машинного. Я этот мукс естественно не сам придумал - он стандартный, я еще не родился когда такая схема работала, просто надо все время учится у предшественников - это окупается.

[Серёга Букашкин]

Правильно то что экономичнее для конкретной функции. Есть много вариантов решения мультиплексирования. Чаще полезнее использовать в качестве задатчика канала не целочисленное значение, а сразу бегущие битовые стробы. Потом по ним селами выбираются входные данные, и сел-защёлками фиксируются результаты пока обрабатываются другие.

[nickbeljaev]

Правильно то что экономичнее для конкретной функции. Есть много вариантов решения мультиплексирования. Чаще полезнее использовать в качестве задатчика канала не целочисленное значение, а сразу бегущие битовые стробы. Потом по ним селами выбираются входные данные, и сел-защёлками фиксируются результаты пока обрабатываются другие.

Да, интересная конструкция, а ОЛ позволяет входа оставлять пустыми? В прочих ФБД это очень запрещено однако. Я тоже думал про кольцевой буфер на задержках, задержки вообще очень сильный инструмент, интересно как реализованы только, хотелось бы посмотреть.

[Сергей0308]

Да не, в "правильном" варианте в муксе на 4 входа 5 блоков, на 8 входов 10 блоков, на 16 входов 1+2+4+8+4 = 19 блоков, на 32 входа 1+2+4+8+16+5 = 36 блоков итд, а сколько блоков в "неправильном" муксе на 32 входа? не 64 часом? Вероятность того что "правильный" мукс еще и будет жрать меньше тиков крайне высока, особенно если каждый блок в любом случае выполняется. И еще "битовый" мус позволяет использовать цикличность то есть если на него подавать выход счетчика он будет перебирать значения по циклу, в ФБД это очень полезное свойство, например потактовые циклы так делают.
Вообще в программировании очень не хорошо изобретать велосипеды, обычно все задачи уже решены до нас и гораздо лучше чем мы сами это сможем, поэтому везде где можно надо изучать источники - экономит много времени и человеческого и машинного. Я этот мукс естественно не сам придумал - он стандартный, я еще не родился когда такая схема работала, просто надо все время учится у предшественников - это окупается.

Желаю Вам успехов в изучении достижений предков и их повторении, надеюсь, когда это окупится и начнёт приносить прибыль, поделитесь с окружающими?!
Вот у меня ещё имеются булевы мультиплексор и демультиплексор, можете пользоваться, пока Вы у предшественников ничему не научились(имею ввиду, как правильно делать):

46855

[nickbeljaev]

Желаю Вам успехов в изучении достижений предков и их повторении, надеюсь, когда это окупится и начнёт приносить прибыль, поделитесь с окружающими?!
Вот у меня ещё имеются булевы мультиплексор и демультиплексор, можете пользоваться, пока Вы у предшественников ничему не научились(имею ввиду, как правильно делать):

46855

Сергей, слышали такое "Платон мне друг но истина дороже", я когда вижу недостаток у решения я иногда не молчу (если настроение хорошее). И ваши макросы я с интересом рассматриваю, и разбираюсь как они работают, и это очень правильная у вас позиция - делится кодом и выносить его на обсуждение, вы слышали, конечно, про GNU Project - он такой огромный и могучий как раз потому что люди в нем все между собой обсуждают и свой код выкладывают на всеобщее обозрение - и если кто то предлагает объективно код улучшить - сделать компактнее, быстрее, то это обсуждается и проверяется, и ежели действительно так то автор исходного варианта принимает изменения и говорит "мерси", а не посылает предлагающего "жену учить щи варить". Поэтому я вам предлагаю тот вариант как нибудь проверить на практике при случае, и если оно действительно занимает меньше памяти и быстрее работает то в дальнейшем использовать, потому что если каждый будет отчаянно целятся за "свой" вариант то далеко мы как сообщество не уйдем, а хотелось бы. И я специально обозвал эти варианты "правильный" и "неправильный", а не "мой" и "ваш", потому что он не мой нифига, так же как и ваш не ваш, он принадлежит нашему сообществу, так же как логика, так же как арифметика, так же как язык на котором мы общаемся. Если сейчас все это раздражает, то не обращайте плз. внимания, кто много работает и решает все более сложные задачи - обязательно к этому приходит.

[capzap]

Можно ли сделать это проще?смотря что считать простотой, выкладываю "монстра", ни каких ретайнов, ни какого построение логических схем, для таблички рецептов сгенерированной случайным образом
[21. 24. 30. 36. 41. 44. 1.]
[21. 26. 29. 35. 40. 46. 2.]
[20. 25. 31. 35. 40. 45. 3.]
[21. 26. 29. 33. 40. 44. 4.]
[19. 25. 32. 35. 43. 44. 5.]
[22. 26. 29. 35. 39. 44. 6.]
[21. 26. 30. 35. 41. 44. 7.]
[20. 23. 31. 36. 40. 46. 8.]
[19. 25. 29. 35. 40. 45. 9.]
[21. 25. 32. 36. 40. 44. 10.]
[19. 26. 30. 35. 40. 46. 11.]
[19. 25. 31. 34. 40. 46. 12.]
[20. 25. 31. 35. 40. 45. 13.]
[22. 24. 30. 37. 40. 46. 14.]
[20. 23. 30. 35. 42. 46. 15.]
[21. 24. 29. 34. 41. 45. 16.]
последняя колонка это номер рецепта
займет некоторое время получение коэффициентов и в проект просто ввод этих значений

[Сергей0308]

Сергей, слышали такое "Платон мне друг но истина дороже", я когда вижу недостаток у решения я иногда не молчу (если настроение хорошее). И ваши макросы я с интересом рассматриваю, и разбираюсь как они работают, и это очень правильная у вас позиция - делится кодом и выносить его на обсуждение, вы слышали, конечно, про GNU Project - он такой огромный и могучий как раз потому что люди в нем все между собой обсуждают и свой код выкладывают на всеобщее обозрение - и если кто то предлагает объективно код улучшить - сделать компактнее, быстрее, то это обсуждается и проверяется, и ежели действительно так то автор исходного варианта принимает изменения и говорит "мерси", а не посылает предлагающего "жену учить щи варить". Поэтому я вам предлагаю тот вариант как нибудь проверить на практике при случае, и если оно действительно занимает меньше памяти и быстрее работает то в дальнейшем использовать, потому что если каждый будет отчаянно целятся за "свой" вариант то далеко мы как сообщество не уйдем, а хотелось бы. И я специально обозвал эти варианты "правильный" и "неправильный", а не "мой" и "ваш", потому что он не мой нифига, так же как и ваш не ваш, он принадлежит нашему сообществу, так же как логика, так же как арифметика, так же как язык на котором мы общаемся. Если сейчас все это раздражает, то не обращайте плз. внимания, кто много работает и решает все более сложные задачи - обязательно к этому приходит.

По "вашему" принципу оптимальным получится только для количества входов 2 в степени 1 и более, то есть для большинства случаев будет неоптимальным, если рассматривать все возможные варианты, "наш" вариант можно легко обрезать до необходимого количества входов, например до 18, и Вы наверно невнимательно прочитали мой 11 пост.
Вы слышали такое: "Гладко было на бумаге, да забыли про овраги", я тоже когда вижу недостатки в вашем решении могу не промолчать!
Так что придумывайте сразу нормальные элементы(макросы), которые будут иметь преимущества не в теории, а на практике, то есть на 4, 8, 16, 32 входа и все(можно за исключением последнего) с расширением(без применения дополнительных элементов), пока на практике не вижу преимущества, даже наоборот, надеюсь понятно объяснил?!

[nickbeljaev]

По "вашему" принципу оптимальным получится только для количества входов 2 в степени 1 и более, то есть для большинства случаев будет неоптимальным, если рассматривать все возможные варианты, "наш" вариант можно легко обрезать до необходимого количества входов, например до 18, и Вы наверно невнимательно прочитали мой 11 пост.
Вы слышали такое: "Гладко было на бумаге, да забыли про овраги", я тоже когда вижу недостатки в вашем решении могу не промолчать!
Так что придумывайте сразу нормальные элементы(макросы), которые будут иметь преимущества не в теории, а на практике, то есть на 4, 8, 16, 32 входа и все(можно за исключением последнего) с расширением(без применения дополнительных элементов), пока на практике не вижу преимущества, даже наоборот, надеюсь понятно объяснил?!

Если все блоки выполняются то 17 и 18 будет быстрее, тут я не спорю.