Вообще-то с этой карты надо начинать программировать. Если это будет в конце, то всё переменные будут не пойми в какой последовательности.Сообщение от nicton
Вообще-то с этой карты надо начинать программировать. Если это будет в конце, то всё переменные будут не пойми в какой последовательности.
нет. Ваше желание менеджера всё заадминистрировать "на берегу" а потом якобы только сидеть и ничего не надо будет делать, исходит из непонимания "технологического" процесса проектирования и программирования. Ну и последующей наладки. Написание "жосского" ТЗ не равносильно грамотному управлению проектомНу а выбор Ethernet в качестве транспорта разве не решает всех этих проблем?
А можно узнать почему не решит? Вот отрывок из описания CODESYS V3.5 "Альтернативный вариант – организовать обмен по Modbus TCP. В данном случае пользователь
должен добавлять в проект соответствующие компоненты (Ethernet, Modbus TCP Master, Modbus TCP
Slave), настраивать их, разбираться в используемых функциях и адресации регистров.
Преимуществом использования сетевых переменных является простота их настройки – достаточно
создать на одном устройстве список читаемых/записываемых переменных и импортировать его на
другом." Вроде как обозначена моя проблема и пути ее решения.
А Вы её заранее выдайте. Хотя бы в диапазонах адресов. Хороший программист - ленивый (в хорошем смысле) программист- что однажды где-то реализовал, будет пихать повсюду.
Нет. А должно? С чего бы? Вы, как я понимаю, совсем не в теме.
Раз никто не знает, пришлось самому разбираться: кодесис поднимает имена переменных из соседнего контроллера (видел это на видео), но эта история про ПЛК. Овен конфигуратор поднимает имена из ПР103 (тоже видел на видео), возможно кодесис может поднять имена из овен логик. Т.е. имеет смысл использовать ПЛК вместо ПР (в голову так и так ПЛК ставить, у ПР мало сетевых переменных), т.е. укрупнять кластеры, в тех же местах где ПЛК откровенное излишество ставить ПР103, хотя бы есть вариант верифицировать номера регистров через конфигуратор.
Последний раз редактировалось nicton; 11.03.2024 в 19:40.
а причём здесь КДС 3,5? и как это избавит ваш проект от ошибок
?если программист исполнительного блока что то не правильно укажет в таблице регистров или программист головного блока ошибется
каким волшебным образом Модбас ТСР вылечит кривые руки программиста?
это вообще элементарно так-то, и профилактика и диагностика этого также элементарная, и проверка сделанного также элементарная., то это очень трудно выявить
чисто вот по-менеджерски - вы полезли регулировать и администрировать туда, где ничего не понимаете, причём даже не в модбасе, и даже не в овен лоджике, а в общем процессе проектирования в общем и асу в частности
вам не в модбас втыкать надо, оставьте это исполнителям, это их проблемы и это их работа
любой проект начинается с системы кодирования. почитайте что такое KKS, это база, если поймёте, дальше будет полегче
Отрывок из описания был не полный, вот как там написано: "Сетевые переменные позволяют организовать обмен между несколькими контроллерами,
программируемыми в CODESYS V3.5 (и CoDeSys V2.3), по протоколу UDP, который работает поверх
Ethernet. Соответственно, все контроллеры, участвующие в обмене, должны находиться в одной
локальной сети. В настройках сетевого оборудования должна быть отключена блокировка UDPпакетов.
Альтернативный вариант – организовать обмен по Modbus TCP. В данном случае пользователь
должен добавлять в проект соответствующие компоненты (Ethernet, Modbus TCP Master, Modbus TCP
Slave), настраивать их, разбираться в используемых функциях и адресации регистров. Преимуществом
использования сетевых переменных является простота их настройки – достаточно создать в одном
устройстве список читаемых/записываемых переменных и импортировать его в другом."
Последнее предложение - это и есть решение моей "озабоченности", хотя бы тот факт что этот функционал имеет место быть в природе говорит о востребованности рынком, т.е. не я один такой "умный".
КДС 3,5 здесь при том, что я могу и на ПЛК сделать систему.
Вы в своем первом посте задали вопрос, Вам многие люди дали конкретные и правильные рекомендации, начать с карты регистров, задокументировать это. Вопрос простой и ответ очевиден, особенно если во всех 20 - и пр 100 однотипная программа.
Даже если и различные, отдали эти задания программистам и пусть делают, каждый свою задачу, в чем проблема? Вся это ваша идея по автоматической верификации, только необоснованно усложнит все, в итоге путаница будет ещё та.
Да везде документация ВАЖНА. Тот, кто работает без документации - это не АСУТПшник, а наколенный ларёчник.
Меня поражает даже то, как люди (в том числе и автор темы) не удосужатся почитать чужую документацию (протокол Modbus) и думают что в нём есть передача имён переменных, просто надо хорошо поискать и додолбаться до людей, которые секрет не хотят говорить!!!
Это всё так же грустно, как целый слой мутного народа, который на каждом ОВЕНском вебинаре про ПРки спрашивает, когда в ПРках будет Pyhton.
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте. © Steve McConnell
Мой рабочий блог со статьями про щиты и автоматику ОВЕН - Cs-Cs.Net | Почта: Info@Cs-Cs.Net
вы цитируете документацию, ничего в этом не понимая
"что за бред вы несёте? жпг"Последнее предложение - это и есть решение моей "озабоченности", хотя бы тот факт что этот функционал имеет место быть в природе говорит о востребованности рынком, т.е. не я один такой "умный".
какая востребованность рынком...таких "умных" по рынку вот именно - бегает толпами, только вот исполнителей, которых вы пытаетесь научить жить, гораздо меньше
вы уже поменяли свои же условия, не прошло и пары днейКДС 3,5 здесь при том, что я могу и на ПЛК сделать систему.
делайте, удачи
Ваши права
Ответить с цитированием