Там действительно всё сложно, скажу конкретно за связь: в модулях автоматики есть прям конкретные настройки на случай обрыва соединения - установка сигнала на выходе + с какой скоростью сигнал будет формироваться если он аналоговый.
При выходе из строя модуля, даже без резерва по сети, при правильной настройке, например манипулятор не уронит груз на пол, а пойдёт в исходное положение.
Если модуль изначально бракованный его найдут ещё при наладке, а вообще сейчас принято делать модули, выставляющие значение по умолчанию в случае аварии, то бишь выводящие систему в безопасное состояние.
Ethernet подразумевает механизм контроля несущей, то есть ожидание своей очереди заговорить, EtherCAT ожидает одного единственного на всех фрейма, Ethernet подразумевает прием и передачу данных как два отдельных действия (и фрейма соответственно), у EtherCATа фрейм один на всех, и операции чтения/записи идут в один фрейм, без буферизации и ожидания, на лету. Передача данных по Ethernet подразумевает установку канала связи, EtherCAT канал связи не нужен, поэтому а его модели уровень только один - физический.
П.С. к слову: тот же ProfiNET то же вроде Ethernet, но не Ethernet - у него тоже нет контроля несущей, как у него коллизии разрешаются я не знаю, ибо это походу секрет фирмы.
Пример конечно за уши притянутый: где вы видели программы из одной линии LD, плюс у вас чистая релейка без матеши и вызова функций.
Мой посыл бы в том что сложные проекты при большом объеме кода с вычислениями, вызовами, преобразованиями, адресной арифметикой начинают растекаться по странице.
Попробуйте просто разделить два числа и привести их к целому при условии достижения счётчика определенного значения. LD сразу становится громоздким, даже в одну строчку.
Вы не совсем уловили суть: на ведомых устройствах специальный контроллер сети, работа исключительно на 1 уровне OSI, что и позволяет читать/писать данные на лету, без всяких там запросов-ответов и TCPшных рукопожатий, а то что EtherCat может работать поверх Ethernet не обращая на него внимания - это фича.
Нет, не миллисекунды, имел опыт с промышленным Ethernet/IP, передача данных от камеры технического зрения до TCP сервера на контроллере, время отклика с обработкой больше секунды (в среднем, потому что от раза к разу менялось).
Вообще TCP негоден для автоматизации из-за неопределенного времени доставки... но это отдельная история.
LD плох загромождением рабочего пространства: там где программу можно реализовать в три строки на ST, десять строк на IL, у LD уйдет пара экранов.
При большом объеме кода сложно в этой лапше ориентироваться. Хотя может это и дело вкуса.
П.С. программа с двенадцатью реле времени на программируемом реле - такой себе показатель, хотя это уже на пару порядков удобнее чем собирать шкаф автоматики с двенадцатью физическими реле времени.
Кто работал в АСУ тот поймет, что подключить два провода - не такая уж и тривиальная задача, какой интерфейс передачи данных может за ними скрываться: симплекс RS232, RS485, CAN, Hurt, а может токовая петля?
И таки да, например EtherCat'у с его чтением/записью в "пролетающий мимо" по сети фрейм аналогов в мире IT нет (я по крайней мере не встречал), так что я небыл бы столь категоричен называя промышленную автоматизацию отсталой.
А я подростковом возрасте мечтал стать разработчиком процессоров, однако такой возможности мне не предоставилось и не предоставится.
-"Товарищ генерал табе пакет!"
- "Не табе, а Вам!"
- "Нам он на хрен не нужен! Он табе."
- "Вот дурень, где такого нашли? Не могли нормального послать?"
- "Нормальных к нормальным послали, а меня к Табе!!!"
Коаксиалка ловит помехи прям на ровном месте, скорость низкая.
EthercCAT это скорее про робототехнику: чтобы быстро, точно и в срок.
Идея не нова, Нова реализация.
Есть такое понятие как инерция, сразу не встанет, но будет неуклонно хиреть.
ST выглядит как Pascal.
Там действительно всё сложно, скажу конкретно за связь: в модулях автоматики есть прям конкретные настройки на случай обрыва соединения - установка сигнала на выходе + с какой скоростью сигнал будет формироваться если он аналоговый.
При выходе из строя модуля, даже без резерва по сети, при правильной настройке, например манипулятор не уронит груз на пол, а пойдёт в исходное положение.
Обидно, досадно, но ладно - штатная ситуация.
Если модуль изначально бракованный его найдут ещё при наладке, а вообще сейчас принято делать модули, выставляющие значение по умолчанию в случае аварии, то бишь выводящие систему в безопасное состояние.
То же такая мысль в голову приходила.
А вот запись может идти только во фрейм, а фрейм формирует только ведущее устройство!
Ну как то так )
Про Token ring - и правда очень похоже, возможно даже идею из него почерпнули, но, как говорится, все новое - это хорошо забытое старое.
П.С. упс, не про то ответил )
А вот это уже совсем другая тема, датчики нужно периодически менять в рамках планово-профилактических работ, и тогда отказов не будет.
Ethernet подразумевает механизм контроля несущей, то есть ожидание своей очереди заговорить, EtherCAT ожидает одного единственного на всех фрейма, Ethernet подразумевает прием и передачу данных как два отдельных действия (и фрейма соответственно), у EtherCATа фрейм один на всех, и операции чтения/записи идут в один фрейм, без буферизации и ожидания, на лету. Передача данных по Ethernet подразумевает установку канала связи, EtherCAT канал связи не нужен, поэтому а его модели уровень только один - физический.
П.С. к слову: тот же ProfiNET то же вроде Ethernet, но не Ethernet - у него тоже нет контроля несущей, как у него коллизии разрешаются я не знаю, ибо это походу секрет фирмы.
Пример конечно за уши притянутый: где вы видели программы из одной линии LD, плюс у вас чистая релейка без матеши и вызова функций.
Мой посыл бы в том что сложные проекты при большом объеме кода с вычислениями, вызовами, преобразованиями, адресной арифметикой начинают растекаться по странице.
Попробуйте просто разделить два числа и привести их к целому при условии достижения счётчика определенного значения. LD сразу становится громоздким, даже в одну строчку.
Вы не совсем уловили суть: на ведомых устройствах специальный контроллер сети, работа исключительно на 1 уровне OSI, что и позволяет читать/писать данные на лету, без всяких там запросов-ответов и TCPшных рукопожатий, а то что EtherCat может работать поверх Ethernet не обращая на него внимания - это фича.
Нет, не миллисекунды, имел опыт с промышленным Ethernet/IP, передача данных от камеры технического зрения до TCP сервера на контроллере, время отклика с обработкой больше секунды (в среднем, потому что от раза к разу менялось).
Вообще TCP негоден для автоматизации из-за неопределенного времени доставки... но это отдельная история.
Ну что вы, сударь! EtherCat это новейшая технология - появился в 2003.
Гигабитные скорости, кабель только F/FTP, гарантированное время доставки, поддержка резервированных каналов связи.
https://ipc2u.ru/articles/prostye-resheniya/obzor-protokola-ethercat-i-ustroystv-na-ego-osnove/
Некоторые через чур злоупотребляют макросами.
LD плох загромождением рабочего пространства: там где программу можно реализовать в три строки на ST, десять строк на IL, у LD уйдет пара экранов.
При большом объеме кода сложно в этой лапше ориентироваться. Хотя может это и дело вкуса.
П.С. программа с двенадцатью реле времени на программируемом реле - такой себе показатель, хотя это уже на пару порядков удобнее чем собирать шкаф автоматики с двенадцатью физическими реле времени.
Кто работал в АСУ тот поймет, что подключить два провода - не такая уж и тривиальная задача, какой интерфейс передачи данных может за ними скрываться: симплекс RS232, RS485, CAN, Hurt, а может токовая петля?
И таки да, например EtherCat'у с его чтением/записью в "пролетающий мимо" по сети фрейм аналогов в мире IT нет (я по крайней мере не встречал), так что я небыл бы столь категоричен называя промышленную автоматизацию отсталой.
Вот и я про то же: FOiL не понимает о чем говорит.
Ассемблероподобный STL - детский кубик?
Что то вы сударь не договариваете!
Как показывает практика - не готовы.