Просмотр полной версии : Modbus TCP опрос устройств последовательный?
Добрый день. Изучая документацию по настройке связи в СПК по Modbus TCP наткнулся на слудующее:
Таймаут ответа – время, которое master дает slave-устройству на ответ. По истечению этого времени, master переходит к опросу следующего slave-устройства
Правильно ли я понимаю, что опрос устройств по TCP/IP производится последовательно? То есть если у меня 20 устройств подключенных через свич к СПК, то опрашиваться они будут последовательно по кругу? О_О Возможно я неуч, но мне кажется, что одно из преимуществ использования TCP/IP - это как раз общение с каждым устройством в сети независимо и асинхронно.
Мне очень важно знать как всё таки в итоге будет работать связь с подчинёнными устройствами. И если да, то существует ли проверенная библиотека, через которую можно работать с каждым устройством независимо?
Если посмотреть на временную диаграмму работы приложения в теории, то можно заметить, что параллельно ничего не работает. Т.е. если, к примеру, у ПЛК несколько RS'ов, то обмен по ним будет последовательный или, на крайний случай, квазипараллельный.
38764
Литература:
1. Coder's Corner: The IEC 61131-3 Software Model (https://www.automation.com/library/articles-white-papers/coder146s-corner-the-iec-61131-3-software-model).
вот эта самая квазипараллельность и интересует. Понятно, что поток выполнения один и процессорное время просто дробиться переключаясь между задачами. Например при работе с файлами заявлена асинхронная работа. Не уверен насколько хорошо оно работает, но по крайней мере оно точно в какой-то степени улучшает отзывчивость программы. Просто я боюсь, что отсутствие асинхронного опроса устройств убьёт выгоду от использования Modbus TCP. Сейчас этот обмен с другими ПЛК происходит посредством UDP через сетевые переменные. Хотим заменить ПЛК100 на СПК207, и заменить подчинённые устройства. Но беспокоит, что быстродействие связи не увеличится относительно сетевых переменных, где устройства как известно нужно разводить по времени опроса.
доплню, касательно документации, данная фраза относится к разделу 4.2. Настройка СПК в режиме Modbus RTU Master
собственно ни какого отношения к ТСР не имеющего
да нет. Как раз к TCP.
п 8.2 Страница 149:
Евгений Кислов
15.09.2018, 19:46
Как было верно замечено - параллельно ничего не работает.
Убедиться в этом несложно:
38767
А почему не рассматриваете вариант продолжить использовать сетевые переменные с СПК?
Что касается родных драйверов Codesys, то, думается мне, там всё последовательно. Когда вы вставляете устройство в дерево оно будет опрашиваться скорее всего последовательно. Если в драйвере есть ожидание таймаута ответа, то все будут этого ответа дожидаться. Поэтому немного есть ПЛК с кучей RS'ов, а также широким набором разнообразных последовательных интерфейсов, которые теоретически могут работать параллельно.
Для "квазипараллельности" нужно написать алгоритм самостоятельно. Я делал подобное для RS'ов, это сложное и неблагодарное занятие.
Как было верно замечено - параллельно ничего не работает.
Убедиться в этом несложно:
38767
А почему не рассматриваете вариант продолжить использовать сетевые переменные с СПК?
потому что планируется серьёзно переработать аппаратную часть системы и "ведомые" устройства будут не Овен
То есть получается в моём случае особого прироста скорости от использования Modbus TCP вместо Modbus RTU по сути не будет? Ведомых устройств порядка 10-15 шт, по каждому из которых нужно гонять туда-сюда порядка 400байт информации (может чуть меньше, но примерно так). Спрашиваю потому что интересно узнать у более опытных коллег практический опыт.
Тут всё зависит от многих факторов. Что считать вообще скоростью работы? Это минимальный цикл между опросами или доля времени обмена в общем цикле приложения? Первое зависит от времени задач приложения, второе в случае TCP явно будет меньше, т.е. TCP обмен на порядки быстрее должно быть. Нужно прикинуть отношение времени задач приложения к времени обмена. Если время задач много больше времени обмена, то уменьшения времени реакции (отклика) можно и не увидеть. Если обмен по времени сравним или больше длительности задач, то можно что-то и получить.
Если есть возможность перехода на TCP при прочих равных, думается, лучше использовать его.
Тут всё зависит от многих факторов. Что считать вообще скоростью работы? Это минимальный цикл между опросами или доля времени обмена в общем цикле приложения? Первое зависит от времени задач приложения, второе в случае TCP явно будет меньше, т.е. TCP обмен на порядки быстрее должно быть. Нужно прикинуть отношение времени задач приложения к времени обмена. Если время задач много больше времени обмена, то уменьшения времени реакции (отклика) можно и не увидеть. Если обмен по времени сравним или больше длительности задач, то можно что-то и получить.
Если есть возможность перехода на TCP при прочих равных, думается, лучше использовать его.
понятно. Спасибо, будем иметь ввиду.
Ответ куда проще, СПК умеет работать в многопоточном режиме как ПК ?
В любом случае интерфейс один и все пакеты будут отправлены по очереди.
Просто на ПК можно отправить кучу запросов и ответы получать не в той же последовательности.
Если СПК можно использовать так же, то прирост получите
Просто на ПК можно отправить кучу запросов и ответы получать не в той же последовательности
вот очень этого не хватает.
в общем очень не хватает в линейке панельного ПК за разумные деньги с ubuntu или Windows IoT Enterprise на борту и с диагональю 10-12" USB, SD и парой RS485/232. Потому что это открывает великолепные возможности в использовании современных языков программирования и фреймворков на их основе, и здесь пропасть на рынке: те панельные ПК которые есть на рынке - стоят как чугунный мост. Что-то плюс-минус отвечающее требованиям, конечно можно притащить из китая, но останавливает отсутствие какой-либо гарантии, непредсказуемость качества и отсутствие поддержки в случае каких-либо проблем.
Пробовали использовать планшеты: не выдерживают эксплаутации 24/7, приходится колхозить какие-то крепления, ну и беда с интерфейсами (хотя появление модулей ввода-вывода с Ethernet - как глоток свежего воздуха в этом консервативном подвале)
Поэтому некоторые встают на путь импортозамещения, но специалистов, способных "поднять" ОС на собственной голой железке, очень мало. Настольная ОС там не нужна, так как её нужно уметь администрировать. Я бы хотел панель, которая может исполнять проекты, разработанные в современных IDE. Только не SCADA, они имеют ограничения. Что-нибудь с Qt или .Net. Codesys, кстати, это скрещенные Qt и .Net, насколько я понимаю. Среда разработки на .Net, а кроссплатформенное исполнение (визуализация) на Qt.
Поэтому некоторые встают на путь импортозамещения, но специалистов, способных "поднять" ОС на собственной голой железке, очень мало. Настольная ОС там не нужна, так как её нужно уметь администрировать. Я бы хотел панель, которая может исполнять проекты, разработанные в современных IDE. Только не SCADA, они имеют ограничения. Что-нибудь с Qt или .Net. Codesys, кстати, это скрещенные Qt и .Net, насколько я понимаю. Среда разработки на .Net, а кроссплатформенное исполнение (визуализация) на Qt.
Настольная нет, но Win 10 IoT Enterprise (бывший win embedded) - вполне себе вариант. По крайней мере для меня .NET-чика. По мере развития .NET Core можно и линух ;);)
В целом же просто хочется иметь все возможности полноценных операционных систем, современных языков и фреймворков.
На самом деле сейчас существует 3 .Net: .Net, .Net Core и .Net Standart. Последний кроссплатформенный. Можно один код запускать на Android, iOS, Linux и Windows. Пока немного сыроват, но работает. Разве что .Net тормознее Qt, но в сопровождении, по-моему, c# много легче C++.
На самом деле сейчас существует 3 .Net: .Net, .Net Core и .Net Standart. Последний кроссплатформенный. Можно один код запускать на Android, iOS, Linux и Windows. Пока немного сыроват, но работает. Разве что .Net тормознее Qt, но в сопровождении, по-моему, c# много легче C++.
Xamarin нормально работает, а совместно с Prism превращается во волне приятное занятие - имею некоторый опыт. Хотя, да, немого сыроват и есть куда расти, особенно по части вечно доставляющего проблемы Linker'a и неудобства с управлением графическими ресурсами. Именно поэтому меня устроит даже Android Things в качестве операционки этой панели-мечты. Касательно кросплатформеных GUI приложений на C# и XAML обратите внимание на проект AvaloniaUI. У меня лично всё никак руки не дойдут попробовать (хотя даже соответствующее дополнение для студии поставил), но то что я видел в их презентациях и статьях выглядит очень впечатляюще и вполне пригодно для небольших коммерческих проектов. Очень надеюсь, что их купит майкрософт и поможет довести идею до конца так чтобы она гармонично встроилась и стала эдаким кросcплатформенным WPF.
Мечты это всё. 3S выделила денег на разработку аналога Delphi (ООП компилятора), а вот с HMI у них очень сыро. Банальные тренды вроде как есть, но просмотр архива сделать нельзя. Компоненты отображения графиков вроде как есть, но их делали люди, далёкие от практики. Страшно представить как они компоненты новые делают, учитывая их двойственность. По одному в год.
Меня бы тоже панелька с Windows Embedded устроила бы.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot