Добрый день товарищи.
Прочитал что СХ-Протокол предназначен для формирования протокола обмена с любым устройством. Это что ли получается если подключить к CJ по последовательному порту некое устройство с своим закрытым протоколом и запустить СХ-Протокол то он анализирует посылки от этого устройства, и в конце концов создает протокол обмена для этого устройства, так что ли?
Что то меня сомнения берут что такое возможно в чистом виде сдалать.

Размечтался... Такое автоматом невозможно, только ручками с использованием всяких прог мониторов портов.

CX-Protocol нужен чтобы составить программу для модуля SCU по известному протоколу, т.е. нужно описание протокола на устройство с которым нужно связатся. устройство цепляют не к порту контроллера, а к портам модуля SCU, намного проще и удобнее чем описывать обмен полностью в контроллере, ну и память контроллера существенно экономится. В SCU уже забито десяток протоколов под обмен с разными омроновскими устройствами.

ну я не размечтался, я и усомнился в этом сразуже, просто прочитав рекламку не совсем понял что к чему.
Кстати работа с SCU тоже не плохо, а где можно почитать про него (желательно на русском), я например в проекты его не закладываю, думаю обойдусь встроенным портом ПЛК, ведь наверняка есть у ОМРОНА готовые функц. блоки или библиотеки для последовательного порта, и библиотеки для разных протоколов, неужели самомоу организовывать обмен?
А с модулем SCU получается просто кидаешь в него данные и все он сам дальше посылает их в сеть, так?

мануал на русском W336-RU2-04+CS1W-SCB+SCU+OM.pdf

FB для обмена через порт есть, какие именно можно посмотреть в хелпе программера.
SCU примерно так и работает, в нем описываются последовательности на передачу и приём. откуда брать данные и куда их подставлять в протоколе, что именно брать из полученного и куда писать в контроллере, заодно он конвертирует данные из одного формата в другой, например можно получить из порта ASCII а в контроллер записать Hex, считает контрольные суммы, делает трассировку чтобы при отладке протокола можно было посмотреть что в порту делется.

SCU штука довольно удобная, пожалуй недостатков всего два, в режиме макропротокола не может работать на скорости выше 57,6 и нет возможности вставить алгоритм на расчёт нестандартной контрольной суммы.
Иногда он и деньги экономит, например проще и дешевле управлять скоростью инверторов и читать их состояние по связи, чем использовать аналоговые и дискретные входа/выхода (можно кстати в этом случае использовать свободные входа/выхода инвертора для подключения каких либо датчиков)

скорость 57 это в наше время мало, жаль.
А управлять инверторами конечно удобней по сети, я так и рассматриваю в проектах, но опять же не напороться бы из-за ограничений по скорости.
все ясно спасибо.

Вперёд назад по проводам, задание частоты по связи в параметр многоступенчатой скорости, если очень быстро менять скорость нужно одновременно только у одного инвертора, можно прервать связь и выполнить команду только на этот инвертор. одной командой из контроллера можно писать частоту и читать всё состояние инвертора.

ограничения по скорости, всё зависит от объекта, иногда изменения скорости с запаздыванием на пару секунд не критично, например для вентилятора, насоса.

Какраз сейчас рассматриваю задачку управлять инвертором по сети. Меня смутила фраза "параметр многоступенчатой скорости", а просто в регистр задания чатоты нельзя? До этого работал с "веспером", там делал именно так.

Можно и стандартным способом, но для меня удобнее именно так, даёт некоторые преимущества, например на V7 так было проще сделать переключение с местного на дистанционный. да и получается более надёжно.

кстати когда инвертором управляют через CX-Drive, задание частоты именно в этот параметр и пишется.

Олег, можешь дать конкретную ссылку на этот мануал?