Ну и вот ещё скрины с плавающей точкой.
Как вариант попробовать сейчас удалить iBus с дискретными входами/выходами и поглядеть что выйдет. У меня подозрения что 2 слейв устройства как-то конфликтуют...возможно..:confused:
Ну и вот ещё скрины с плавающей точкой.
Как вариант попробовать сейчас удалить iBus с дискретными входами/выходами и поглядеть что выйдет. У меня подозрения что 2 слейв устройства как-то конфликтуют...возможно..:confused:
У меня в вашем проекте нет ошибок компиляции.Цитата:
Сообщение от Yakut
Вложение 71403
Если свяжитесь по телеграм (в подписи) и предоставите доступ по AnyDesk - посмотрим, в чем у вас дело.
Похоже для 18 кодесиса union уже не требуется. К сожалению у меня его нет. А когда овен на него перейдёт не известно
Вот я не понимаю, какой смысл переходить на 18 кодесис, если и с 16 и 17 не разобрался ещё?
Он программирует не овен, а там видно требуется.Цитата:
Сообщение от kondor3000
Но я 17 я как бы уже разобрался, того минимума по крайней мере мне хватает для требуемых задач.
Самое прикольное было переделать программу под модбас особенности перестановки регистров в 17 версии. Хорошо, что я это заложил в старой прошивке, изменения заняли пару минут...
CПК 107, библиотека OwenSnmp v3.5.14.2
Ловлю ложноположительную ошибку 61 на старте. В процессе работы не появляется.
Ловлю вот так:
проект прилагаетсяЦитата:
IF fbSNMPagent.eError <> 0 THEN
//записать адрес устройства
sErrorIP := fbSNMPagent.sHost;
//записать код ошибки
usiErrorCode := fbSNMPagent.eError;
//записать индекс переменной с ошибкой
usiErrorIndex := fbSNMPagent.usiErrorIndex;
//записать время ошибки
dtErrorTimestamp := TargetVars.stRtc.dtDateAndTime;
END_IF
Спасибо за информацию. Я завтра попробую воспроизвести эту ситуацию у нас. По результатам отпишусь.Цитата:
Сообщение от xjkpt
Блок работает корректно - вы его вызываете, передавая ему указатель на aPack, а сам aPack заполняете уже после вызова.Цитата:
Сообщение от xjkpt
Перенесите код с заполнением aPack выше вызова блока - тем самым вы устраните причину ошибки.
Здравствуйте, подскажите пожалуйста. Первый проект, Спк 107, написал программу, визуализацию, все работает, начал проверять физически, по модбасу соединил модуль мк110, не работало ничего, ни входа ,ни выхода, выхода заработали путем изменения имени с Q 16.0(не помню точно какие были) на QХ 0.0 ,0.1 и тд. Входа же не работают при таком же методе... При это в онлайне пишет ( в изображении) ,самостоятельно не смог найти проблему. Вложение 72367Первый опыт, подскажите что я не доделал или сделал не так
Добрый день.Цитата:
Сообщение от LANE
Свяжитесь со мной (контакты в подписи) и обеспечьте доступ по AeroAdmin или AnyDesk.
Во первых прочитайте по поводу синих значков M https://owen.ru/forum/showthread.php?t=28167&page=6#52Цитата:
Сообщение от LANE
Во вторых привяжите ко входам переменные, которые будете использовать в программе.
Групповая передача структуры WritePR по модбасу. Канал 0 функция 16 , 20 слов. Ранее все работало в другом проекте. Был вариант просто привязка канала к объявленному имени переменной структуры. Данные в структуру заносятся. Далее надо ее передать по модбасу одной посылкой (для ускорения). Происходит внутренняя сдвижка данных , как будто переменные структуры выстроены не по порядку адресов, не так как объявлено. Смотрю в окне в онлайне "Соотнесение входов/выходов". На скрине показано что с этого момента все сдвигается вниз. Те появился лишний 0. Хотя ранее и работало , сделал по другому , сделал объединение структуры с массивом WORD. Привязываю к каналу теперь переменную массива. Все равно все точно так же. Что не так случилось? Или чего то не вижу или какая опция компилятора. Кстати и SIZEOFF показывает размер WritePR больше на 2 слова, 22 против 20? Скрин + ссылка на тест архив проекта
Спасибо!
https://disk.yandex.ru/d/1HqK4cfaj0D5hA
В объявлении структуры нужно использовать атрибут pack_mode.
В объединении укажите размерность массива [0..19] OF WORD
См. п. 1.1.4 - там объяснение вашей ситуации:
https://ftp.owen.ru/CoDeSys3/98_Book...nipulation.pdf
Спасибо за наводку!
Здравствуйте, имеются модули МВ110 и МУ110 подключенные к контроллеру через преобразователь RTU-TCP(условный MOXA), контроллер программируется через Codesys 3.5 SP16.
Соответственно родные таргеты от Mx110 я использовать не могу, т.к. они работают только в режиме RTU.
Вопрос следующий - Будут ли работать эти модули, если я буду использовать с ними через таргеты от Mx210? Или лучше, в таком случае, использовать их без таргетов?
P.S. Продублировал свой вопрос из раздела по модулям Mx110 т.к. не был уверен, к какому разделу он относится.
Добрый день.Цитата:
Сообщение от Formak21
Шаблоны Mx210 вам не помогут.
Но вы можете использовать шаблоны Mx110.
См. описание принципа в п. 4.13 (рисунок 4.13.2):
https://ftp.owen.ru/CoDeSys3/11_Docu...odbus_v3.2.pdf
Вместо Modbus Slave COM Port вы можете добавить шаблоны Mx110.
Всё понял, огромное спасибо.
Здравствуйте, коллеги!
Подскажите, кто-нибудь имел дело с Драйверами, которые управляются через Modbus и крутят "шаговик" с энкодером(гибрид)?
Есть инструкция (63 стр.), всё на английском, около 8 страниц - одни регистры параметров и настроек.
Собрал стенд на котором пытаюсь "оживить" сие изделие.
Через специализированный китайский софт эл.мотор управляется, не пойму как.
"Фишка" в том, что мотор управляется не по стробам - STEP/DIR, а по команде через Modbus нужное количество импульсов(координата) и возврат "домой"(если нужно).
Пару "веток" видел здесь на форуме поднимали тему, но до реализации - тишина.
Проблема то в чем? Разобраться в модбас и подсказать как подавать команды? Скидывайте документацию...Цитата:
Сообщение от Test_driver
Именно так! Modbus ! Спасибо, Михаил, что откликнулись!Цитата:
Сообщение от МихаилГл
Вам как, срочно?Цитата:
Сообщение от Test_driver
Сами понимаете что наступает...)
Управлять собираетесь с ПЛК с codesys 3.5?
Да, понимаю, подрядные работы и оплата неизбежна. :)Цитата:
Сообщение от МихаилГл
Понимаю, что общение со мной, требует терпения со стороны Мастера(сенсея), требует времени и молока (за вредность, как в СССР) :)
Да, с Codesys 3.5, с СПК.
Время для меня не имеет значения, имеет значение - жизнь!
Ввёл такую структуру, согласно инструкции, мотор ожил, но пока хаотично(прямо в каналах Codesys ввожу Биты)
01 06 62 00 00 01 57 B2 Set PR0 mode to absolute position mode (изменил)
01 06 62 01 00 03 87 B3 Set PR0 position high
01 06 62 02 0D 40 32 D2 Set PR0 position low
01 06 62 03 02 58 66 E8 Set PR0 speed value
01 06 62 04 00 32 56 66 Set PR0 acceleration
01 06 62 05 00 32 07 A6 Set PR0 deceleration velocity
01 06 60 02 00 10 37 C6 Trigger PR0 motion Send when you need to stop:
01 06 60 02 00 40 37 FA Emergency stop
Хотя первая строка другая: 01 06 62 00 00 00 01 57 B2 -здесь контрольный CRC не тот, а вот так правильнее 01 06 62 00 00 01 57 B2 (без октета лишних нулей).
Вопрос: почему в инструкции заведомо неправильно (именно в первой строке много раз в примерах)? Или я что-то упустил? С Modbus`ом знаком как медведь с музыкой.
Да, там много опечаток. И этот косяк мне тоже в глаза бросился.
Тут тоже запятую забыли... Вложение 72668
Да я смотрю вы справляетесь.
Но если подключитесь как к модбас устройству, то достаточно только адресами и тем, что в них пишется, оперировать, остальное (CRC, формирование строки запроса и пр. codesys сам делать должен).
С модбасом все до невозможности просто:
01 06 62 00 00 01 57 B2
01 - адрес железяки
06 - команда записи (на чтение регистров 03)
62 00 - адрес первого регистра, куда писать или с какого читать
00 01 - для команды записи 06 это то число, которое надо записать в регистр 62 00 (0062 если правильно, сначала младший потом старший)
00 01 - для команды чтения 03 это то число читаемых регистров начиная с 62 00
57 B2 - контрольная сумма для модбас протокола
И для вас главное это: 01 06 62 00 00 01 57 B2
В принципе "циферки" я гоняю в канале, мне не понятна сама политика управления, скажем - Homing, у меня мотор ушёл в бесконечное кручение, причём на другой скорости.
В регистре 0x6200 есть тоже бит на Homing, он тоже сработал.
Как понять абсолютное и относительно позиционирование? Как выставить точку Zero?
Энкодер на моторе 1000, в драйвере 4000, но написано в инструкции CPR=4*PPR (нужно ли перезаписывать?) . Проблема с терминологией. Что к чему?
Понял, что там есть Триггеры - заранее указанные координаты, как их "рулить"? Хотя с первым бы разобраться - Path0.
Вопросов много, программная часть на втором плане(сижу в каналах, на экран вывожу пока только контрольные регистры), понять бы принципы, заложенные в "железке".
В регистре 0x6002 ввожу в канале в десятичном виде 64(0x40) - стоп, 16 (0x10) - старт, 32(0x20) - Homing, 33(0x21) - сброс(типа выполнено).
Команды как я понимаю надо выполнять последовательно, это типа G-code, или как там правильно.Цитата:
Сообщение от Test_driver
И если это CNC, то сначала нужно настроить постоянные, координаты дома и пр. Датчики завести... Он у вас ищет дом по концевому или по энкодеру... Это наверное от настроек зависит. Тут надо курить мануал...
Вот, например, настройки дискретных входов: Вложение 72670
Да, ввожу три скорости(старт, крейсерская,стоп), пики(от балды - 0х6202), режим позиционирования (0х6200), пауза между командами и старт по 0х6002 (Ctrl + F7).
Как искать дом по энкодеру? Подскажите? В группе Pr8.xx есть регистры отслеживания пройденных пиков. Как вернуть домой? Не получается, куча режимов и принципов "Домой".
Структуру набивал по Pr9.00, придерживался (картинка)/ CN3(SI1-SI7) не использовал(Pr4).
Если бы я знал... Вам надо сначала все читаемые переменные вывести на отображение в визуализации, и по одной команде проверять. Я с CNC имел дело раз, когда собирал китайский станок 4 года назад из отдельных комплектующих. А тут модбас адаптированная штука, явно рассчитана на профессионалов в создании станков. Там столько настроек, и много взаимосвязанных. Только по одной команде проверять... Больше никак.Цитата:
Сообщение от Test_driver
И команды скорее надо посылать разово, а не сразу все по Ctrl + F7...
Да, сначала записываю по одной, вижу их на экране (считываю), по Ctrl + F7 последняя на 0х6002 для старта.
Ну, что же, придётся стать профессионалом. Буду информировать о продвижении, если не против. Сниму видео и напишу свой мануал, так как вижу, что тема ещё никем толком не освоена. Все крутят "шаговики" Ардуинками и из Math3, домашние варианты. А я сделаю промышленный вариант.
Освоим станкостроение, товарищи! Забыл добавить - c аппаратурой от Owen!
Только благодаря Owen`у я вошёл в этот дивный мир "программирования микроконтроллеров" и этот путь долгий и тернистый!
Пришла мысль, пока сижу на работе.
Моя ошибка, возможно, в Hominge, заключается в том, что я отправляю Домой без изменения направления вращения (0: CW,1: CCW) и мотор начинает "идти Домой" через 65535 (предельная позиция), поэтому кажется, что бесконечно.
Вечером и ночью буду тестить.
Драйвер измеряет напряжение, индуктивность обмоток, пиковые токи и кучу всего интересного можно отобразить.
Здравствуйте, подскажите пожалуйста. Рабочий проект, СПК110, есть исходник. Требуется подключить контролер LMV5х + AZL5хх горелки котла по modbus rtu. Протокол, насколько я понимаю, нестандартный - CRC передаётся младшим байтом вперёд. Вложение 72807. https://pikinno.com/upload/iblock/e3...709c37561c.pdf. Как правильно организовать работу с ним. Может есть отработанные решения? Поиском не удалось ничего найти. В исходнике СПК дописываю третий порт подключаю КТР-121 - всё работает. Самостоятельно победить нестандартный протокол пока не получается.
В Modbus CRC так же передается младшим байтом вперед.
Если примеры запроса и ответа кинуть в парсер, то видно, что в запросе и ответе CRC по разному введено. Ответ сразу парсится как есть. А в запрос парсится если поменять местами байты CRC.
CRC-16/MODBUS 0xA024 - и если вбить запрос без CRC в калькулятор CRC то для Modbus мы получим именно так, а не 24A0 как в примере из доки на прибор
Вот скрин "OPC Server". Вложение 72812 На нём видно что CRC передаётся старшим байтом вперёд =24А0=, а нужно =А024=.
Вот скрин прослушивания линии "Terminal V1.9", Вложение 72813 Здесь видим тоже самое.
В калькуляторе вижу Вложение 72814
А OPC Server передаёт и Terminal V1.9 это подтверждает Вложение 72815
Вопрос: почему в описании протокола и в калькуляторе CRC младшим - байтом вперёд, а в OPC Server - старшим байтом вперёд?
При передаче по Модбас байты и регистры могут меняться местами.Цитата:
Сообщение от Юрий_66
еще раз, в калькулятор и запрос и ответ и вы поймете, что в документации ошибка. ошибка в данных CRC
а потом правильные посылки в парсер Modbus и увидите, что запрос вполне адекватный протоколу.
Я правильно понял, что OPC Server работает не по протоколу?
Можно ли в таком случае заставить его передавать запрос с CRC младшим байтом вперёд?
В ответе так же CRC идёт младшим байтом вперёд. Вложение 72818Цитата:
Сообщение от melky
Предполагаю что это не ошибка, а протокол от "SIEMENS". И для работы с LMV+AZL его надо выполнять.
Если не получается как с модбас работать, то придётся писать общение самостоятельно как работу через сокет и прочее. Если просто считывать данные, то там проблем нет, а хотите полноценное общение со всеми плюсами... То придётся руками всё описывать в программе.Цитата:
Сообщение от Юрий_66
Я при общении с нестандартными протоколами жёстко прописываю посылку с требуемой CRC, а при получении ответа не проверяю на правильность. Иначе это затянется на............
ОРС сервер работает по протоколу, но при передаче по Модбас, не важно куда, байты и регистры могут поменяться местами, для этого и существует перестановка регистров и байтЦитата:
Сообщение от Юрий_66
( как правило этим занимается Мастер сети), а программист настраивает ( программирует) как ему надо.