Просмотр полной версии : Библиотека ModBus Slave
Кто нибудь встречал библиотеку ModBus Slave для CDS 2.3?
Что то я не нашел.
ModBus Slave RTU реализовать неполучицо в виду устройства протокола, а вот ModBus Slave ASCII можно запилить на библиотеке ModBus.lib c помощью входящих в нее функций MB_ASCII_RX и MB_ASCII_TX.
не знаю что там может не получиться с рту, но такой бибки официально не существует, её придется самостоятельно написать
ModBus Slave RTU реализовать неполучицо в виду устройства протокола, а вот ModBus Slave ASCII можно запилить на библиотеке ModBus.lib c помощью входящих в нее функций MB_ASCII_RX и MB_ASCII_TX.
Интересно почему Modbus Slave TCP можно реализовать, а ModBus Slave RTU нет?
не знаю что там может не получиться с рту
проблемы с определением начала и конца пакетов. работать будет только если в сети один слейв и то нестабильно.
проблемы с определением начала и конца пакетовА ещё подробнее можно?
проблемы с определением начала и конца пакетов. работать будет только если в сети один слейв и то нестабильно.
любой слейв должен читать что приходит по интерфейсу и найдя знакомые "буквы", то бишь свой адрес готовится к отправке ответки, соблюдая правила протокола, для этого нужно знать всего навсего этот протокол
и найдя знакомые "буквы"
У протокола несколько уровней. прикладной, канальный и физический. На канальном уровне признаком конца/начала пакета(кадра) считается пауза или тишина продолжительностью не менее 3,5 шестнадцатеричных символов (14 бит). Знакомые буквы находятся уровнем выше который собственно и доступен программисту ПЛК. Если есть возможность распознавать кадры по паузе из пользовательской программы с удовольствием выслушаю )
я собственно делал слейв модбас рту, всё работало, бибку не выкладывал ни где. У Вас очень много теории и это Вам мешает понять, что слейв не инициирует обмен, пауза не пауза его не волнует, его интересует любой принятый байт, если он принял некий байт похожий на его адрес он переходит к последующему байту, тогда он узнает либо сразу размер всего пакета по номеру функции, либо потребуется прочесть еще один байт, после принятия нужного количества он приступает к анализу контрольной суммы пришедьшей и того что принял, после сравнения приходит к выводу какой ответ послать или не послать
мне просто интересно для трмок кто по Вашему слейвы написал люди или боги?
Точно так же как и мастер определяет пакет. Или предполагаете что он каким-то другим волшебным образом вычленяет пакеты ?
слейв не инициирует обмен
В этом как раз вся собака и зарыта )
Я думаю если б все было так просто то в существующей бибке слейв был бы реализован. Я тож писал слейв рту, и он тож "работал", но при определенных условиях. и как только в сети появлялись еще слейвы начиналась жопа (для программирования). Я спорить особо не хочу на эту тему и идею со слейвом рту забросил так как в нем нет особой нужды, точнее гемор при написании кода гораздо больше профита )
Точно так же как и мастер определяет пакет. Или предполагаете что он каким-то другим волшебным образом вычленяет пакеты ?
мастер шлет запрос и получает один ответ (может быть в несколько приемов чтения порта) но с начала и целиком. только это и позволило реализоваь модбас на бибке юзающей пользовательский уровень протокола.
я так думаю )
В этом как раз вся собака и зарыта )
Я думаю если б все было так просто то в существующей бибке слейв был бы реализован. Я тож писал слейв рту, и он тож "работал", но при определенных условиях. и как только в сети появлялись еще слейвы начиналась жопа (для программирования). Я спорить особо не хочу на эту тему и идею со слейвом рту забросил так как в нем нет особой нужды, точнее гемор при написании кода гораздо больше профита )
разбирать приходящие запросы и анализировать послать ответ или нет и еще дополнительно подготовить данные требуется как можно быстрее, чтоб мастер не устал ждать и переходить к другим устройствам, в мастере тоже требовалось произвести настройки, чтоб слейвы др.друга не затыкали
мастер шлет запрос и получает один ответ (может быть в несколько приемов чтения порта) но с начала и целиком. только это и позволило реализоваь модбас на бибке юзающей пользовательский уровень протокола.
Мастер после отправки запроса слушает эфир, выцепляет кусок мусора который почему-то закончился подходящим интервалом и после этого начинает проверку этого мусора на предмет похожести на нужный ответ.
Слейв постоянно слушает эфир, выцепляет кусок мусора который почему-то закончился подходящим интервалом и после этого начинает проверку этого мусора на предмет похожести на нужный запрос
Найдите хоть одно отличие в выделенном
Код в студию как говорицо. как корабли бороздят пространства окиянов мы все и так знаем )
..больше профита ..
Как направление - исходник модбас.либ для ознакомления.
Кстати библиотека Modbus RTU slave есть для контроллеров Beckhoff. Правда не знаю, насколько она закрытая и плюс она может еще использовать какие-то нюансы их контроллеров на предмет в ней покопаться.
Код в студию как говорицо. как корабли бороздят пространства окиянов мы все и так знаем )
http://www.hmisys.com/downloads/PeakHMIDemoInstaller.exe
Вот бибку от Beckhoff глянул бы...
а в Modbus.lib никто "в мусоре" ничего не ищет. пакет от слейва появляецо после запроса и кончаецо потому что в линии кроме ответа от одного слейва больше ничего быть не может и мастер это знает. проверяецо CRC И если все гуд сверяюцо первые байты принятого пакета. адрес там... колво байт... и все. а вот у слейва в линии все что угодно может быть. и обрывки пакетов от мастера и обрывки пакетов от других слейвов (т.к. включицо он может позже чем мастер) ну и энти пакеты целиком где конец одного и начало другого он не знает и иксать в этом свой адрес потом команду и прочее... ну-ну )
...где конец одного и начало другого он не знает и иксать в этом свой адрес потом команду и прочее... ну-ну )
вот с таким отношением у Вас работа дальше одного слейва и не пошла
Синхронизироваться можно по байту с взведенным девятым битом.
murdemon
05.11.2015, 17:21
:D да еще в modbus RTU нет рукопожатий и подтверждений от центра выдачи времных ключей в том чтобы убедиться что ответил нам именно вот тот частотник а не злоумышленник (Петька с modbus slave софтом) У всех все работает - это протокол мастер слейв ... 1 мастер много слейвов ... и да 1 сломанный слейв может повесить всю шину.
вот с таким отношением у Вас работа дальше одного слейва и не пошла
У всех все работает
я все еще жду хотя бы отрывки кода )
так и Вы хвастались что что то делали и где этот код? Почему мы должны показывать первые
murdemon
05.11.2015, 18:39
берешь твинкат ставишь, бибку ModbusRTU.lib там есть слейв... для ПК в том числе который работает через обычный UART (те через SysComLib)... если не разберешься готов помочь (стучи в личку)
Ну понятно, берешь... ставишь...
Тож хочу предложить домашнее задание из разряда сказок. Составить такой пакет, легальный ответ какого нибудь слейва, который будучи принятым другим слейвом не сначала (в виду того, что он включился на несколько миллисекунд позже чем другие участники обмена) будет расценен им как команду на запись какого-либо числа (например ноля) в какойнить свой регистр. Для того чтобы главной новостью утренних газет стало: "Деление на ноль убило человека" ;)
Например библиотеки Modbus от ABB запаролены, возможно тоже и с TwinCat. Нету под рукой чтобы ставить и смотреть, да и не надо.
В 3-м CDS есть библиотеки Modbus как мастер так и слейв.
Ну понятно, берешь... ставишь...
Тож хочу предложить домашнее задание из разряда сказок. Составить такой пакет, легальный ответ какого нибудь слейва, который будучи принятым другим слейвом не сначала (в виду того, что он включился на несколько миллисекунд позже чем другие участники обмена) будет расценен им как команду на запись какого-либо числа (например ноля) в какойнить свой регистр. Для того чтобы главной новостью утренних газет стало: "Деление на ноль убило человека" ;)
Ну и к чему это ? Составьте такой пакет. Посмотрим. Думаете что тут будут бить себя ногой в грудь и кричать что невозможно ? Возможно.
Возможно вообще всё. Или до сих пор верите в существование некоего мифического абсолютно защищенного от ошибок протокола ?
murdemon
06.11.2015, 17:55
Например библиотеки Modbus от ABB запаролены, возможно тоже и с TwinCat. Нету под рукой чтобы ставить и смотреть, да и не надо.
В 3-м CDS есть библиотеки Modbus как мастер так и слейв.
на счет АВВ (если там 2 codesys) и TwinCat2 - есть магический способ как знать заветные цифры
murdemon
06.11.2015, 18:02
обычно ловится в принимаемом потоке адрес (за ним все по протоколу и проверяем контрольную сумму, если не совпало ищем следующий адрес как у устройств (в потоке и тд) и все работает.. (в некоторых протоколах есть и разделитель фреймов каконить заданный символ, но тут такая же ситуация что и с адресом в самих данных может быть и символ разделитель фреймов :) )
а если надо бьютефул пользуй Profibus - там все вплоть до коннекторов и проводов стандартизировано и все всегда работает. (и на вопрос я взял штекер не стандартный а самодельный и у меня не чего не работает - тебе даже отвечать не кто не будет)
Ну если хочешь из модбаса сделать бьютифул - копай либы, доки, экспериментируй.. . Сам.
Тогда и никаких супер коннектеров и проводов не потребуется. Легко соединишься и простым пвс-ом.
murdemon поделитесь заветными цифрами и как именно открыть код, опробую в понедельник.
murdemon
07.11.2015, 12:21
скинь бибку сюда... или в скайпе... там просто в открытом виде по определенному смещению нумберок :)
Проще было смещение указать. Гляньте, откроется, нет ?
Судя по размеру это пустышка, от которой толк будет только на родном для неё контроллере.
murdemon
09.11.2015, 11:32
SST_TS_KB2 , но в этой бибки от абб все реализовано либо на уровне ОС либо на железном уровне (там протокол не расписан)... у ваги точно для SysLibCom.. такая же бибка
murdemon
09.11.2015, 11:35
вот для бекова тож для SysLibCom TS6255-PLC-Modbus-RTU.exe (я бы даже поставил бы TwinCat2 но он Codesys2 ломает... так что только по спец запросу :))
Там у АББ несколько бибок связанных с Modbus, я только одну выложил.
Объясните, как вы нашли код, что-то не могу найти его в файле.
murdemon
09.11.2015, 11:55
это магия... не какого мошенничества :D
Ну тогда тексты библиотек так же останутся магией...
это магия... не какого мошенничества :D
Кончай понты кидать, "маг" хренов.
murdemon
09.11.2015, 13:07
штаны превращаются .. превращаются в элегантные шорты .. (PS надо денег - готоф за денег запилить супер пупер бибку для modbus rtu slave для codesys 2) ну или есть бесплатный вариант позвонить и поинтересоваться в поддержке ОВЕН (это же их железо и они профит с него получают)
"Работать ради денег - это нормально.." - (С) Машков где-то на подработках.
Народ столько энергии проявляет чтоб взломать, найти..
Хотя вопрос в 1 дне, 5 строках для выделения фрейма, и 2-4х десятках строк для его разбора. Мд-я-я-я..
Хотя вопрос в 1 дне, 5 строках для выделения фрейма, и 2-4х десятках строк для его разбора
такой алгоритм позволяет находить несуществующие фреймы, дык еще ответственность за это возлогаецо на протокол а не на алгоритм )
Если фрейм нашли - это как он не существует ? Вы их сами придумываете или из порта берете ?
А ответственность - на разработчике алгоритма, который учитывает протокол.
murdemon
09.11.2015, 15:48
А зачем она вообще нужна почему не воспользоваться встроенными в Codesys2 средствами для настройки Modbus RTU Slave?
Если фрейм нашли - это как он не существует ?
Он может находицо внутри другого фрейма например в ответе другого слейва, вы же не знаете где в потоке данных из порта конец одного пакета и начало другого. регистры одного из слейвов например могут совпасть адрес команда црц итд. да это маловероятно но возможно. и отличить в потоке регистры это другого слейва или запрос мастера на запись (например) никак нельзя. сумбурно мож и непонятно но как то так.
В бибке для мастера такого быть не может потому что в линии никаких данных нет пакеты для мастера появляюцо после его запроса и он их принимает сначала и целиком. на один запрос - один ответ. и различать где начало пакета не надо. он и так сначала и он один. дальше да црц и прочие дела.
(нормальный) слейв принимает все пакеты и начинает их "разбирать" только после того как пакет закончицо то есть возникнет пауза в передаче. после этого он уже проверяет црц и прочее. только после паузы. ели есть возможность каким то образом различать пакеты по паузе - да, работать будет. но как это сделать?... ) так же возможно написать слейв рту для какой то конфигурации где известно заранее что будут спрашивать итд. но это не будет универсальной бибкой.
в modbus ascii есть спецсимволы начала и конца пакетов поэтому слейв реализуем уже на существующей бибке.
Вроде как в ответе слейва тоже должен фигурировать адрес устройства, нет ? И в конце CRC.
Так же как и в запросе от мастера фигурирует номер от какого слейва ждем ответ. Если запрос не нам (другому слейву) то нафига его вообще разбирать ?
Вроде как в ответе слейва тоже должен фигурировать адрес устройства, нет ? И в конце CRC. ?
слейв знает только свой адрес и ничего о других слейвах. и начало пакета предпологаецо искать по его адресу (или по чьему?). у вас нет пакетов у вас есть поток данных из порта. ответы других слейвов вам тоже придецо разбирать как то. как? только искать в этой мешанине запрос мастера и он может найтись хотя его и не было. )
lazy, там из разбирательства только адрес. Определили, что не наш и очистили буфер.
там из разбирательства только адрес.
Допустим слейв включился чуть позже чем остальные слейвы и мастер и уже идет обмен. в порту какие то данные, что искать, чей адрес? нет гарантий в том что вы примите чей то пакет сначала.
А зачем она вообще нужна почему не воспользоваться встроенными в Codesys2 средствами для настройки Modbus RTU Slave?
ТС нужно. А так - да. Слейв замечательный (о мастере - не скажу ))
Он может находицо внутри другого фрейма например в ответе другого слейва, вы же не знаете где в потоке данных из порта конец одного пакета и начало другого...
Знаю. Поэтому не понимаю сути проблемы
Допустим слейв включился чуть позже чем остальные слейвы и мастер и уже идет обмен. в порту какие то данные, что искать, чей адрес? нет гарантий в том что вы примите чей то пакет сначала.
запросы на чтение имеют определенную размерность байт, запросы на запись содержат двойное указание сколько байт всего в запросе, чё Вы пытаетесь со всеми спорить то. Программисты всех устройств и направлений делают слейвы, ни чего в этом нет сложного
Тм чтобы принять лажовый запрос надо сильно постораться, вероятность совпадения мизерная, если вобще не равна нулю
murdemon
09.11.2015, 19:39
это у меня был знакомый он с Java в преобразователь Ethernet/485 писал и не дожидаясь ответ писал и читал по всем адресам (устройствам которых было много) на 485 шине (modbus) .. а потом не понимал почему какие то странные ответы приходят. На вопрос что 485 это полудуплекс и мастер-слейв ... он четко говорил мне все равно я по Ethernet работаю и долго звонил в MOXA устраивал разбирательства почему их устройства такие дорогие и так плохо работают. :)
lazy объясните дураку, как можно начать принимать запрос с середины пакета, если в начале любого пакета данных должна быть пауза а ее тупо нет ?
Зачем что-то читать вообще, если видно что это не начало пакета ? Ну включился слейв позже и что ? программа обработчик должна дождаться начало следующего пакета и только тогда начинать их проверять, ему прислали или не ему.
Дык-ж периодически на Землю прилетает метеорит и гасит почти все живое. Последний раз запортил все настройки у завров. Вот lazy и хочет защиту от этого поставить. Видимо у заказчика на это монет взял.
Lazy ! Тут защита простая - нужно применить функцию nauchitoslachitat() из hodjanasreddin.lib
ModBus Slave RTU реализовать неполучицо в виду устройства протокола
WTF? :eek:
И Мастер и Слейв и RTU и TCP прекрасно реализовываются, причём на базе стандартных библиотек codesys.
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot