CANOpen -> Profibus

[keysansa]

Доброго времени.
Возникла непонятка. Может кто-то подскажет?

Исходные:
1. Энкодеры Baumer, с интерфейсом CANOpen (BMMH серия)
2. CP 4xx Siemens.

Появилась необходимость эти два устройства связать. Энкодеры давно сняты с производства, да и контроллер, который их обрабатывал, тоже (сейчас эта фирма уже не работает в принципе). Ну и их контроллер у нас так же, приказал долго жить.
Математика там простая, решили перенести ее на головной 414 S7. Для получения данных с энкодеров, был приобретен Anybus X-Gateway Can Master.

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

Однако, транслировать их в Profibus (GDS файл именно для этого коммуникатора, в Hardware именно он) - не получается. 2 телеграммы 32UINT - показывают не то, что в первых двух ячейках 2120 массива (Long). Других регистров нет в PDO.

Как связаны регистры CAN и регистры Profibus в данном устройстве? В мануале на устройство - написано: "прозрачно".

PS. ЗЫ. Может, кто еще прояснит, про идентификацию Anybus устройства CAN по EDS файлу? Энкодеры у меня красными в конфигураторе обрамлены (это означает, что данные устройства и EDS файла - отличаются).
Я просмотрел с помощью CAN Terminal все значения регистров 10ХХ энкодера и сравнил их с EDS файлом, убрал те, что энкодер не может предоставить, добавил значения, что не было в EDS - и все равно пишет ошибку, мол устройство не соответствует EDS файлу (однако значения с 6004 регистра энкодеров приходят в регистры 2120 коммуникатора, что настроено в таблице связей, проверял онлайн опросом).
А в регистрах Profibus - какая-то фигня...

ЗЫЫ. Может прояснит ситуацию.
В документации, указано, что посылки 180+NodeID и 280+NodeID содержат "текущую позицию в инкрементах". Я эти посылки наблюдаю в CAN терминале и они соответствуют значениям 6004 регистров обоих энкодеров (соответственно). А так же 2120 регистрам X-Gateway.

[VADR]

Очерёдность байтов проверяли?

[keysansa]

Очерёдность байтов проверяли?

Совершенно верно, спасибо огромное!
Мой сменщик отзвонился, сказал, что решил.
Итак:
1. Очередность байт - "имеет значение"
2. В CAN массиве регистров, первые 1-2 байта - сервисные. Их тоже надо учитывать, и читать.
ЗЫ. В четверг буду на работе, если интересно, отпишу полное решение.

ЗЫЫ. Меня так и гложет несоответствие устройства и EDS файла. Но это проще, там пока понятно куда копать. В 10хх регистры.

[keysansa]

Отписываюсь, прошу прощение за задержку.
Так и есть, байты помешать, не забыть прочитать первый, статус.
Соответствие устройства EDS файлу, отложено, ввиду более приоритетных задач (перетягивание ссылки EDS файла на устройство хоть и не избавляет от проблем с обнаружением, но позволяет работать с устройством так как нам нужно, при условии, что проблема именно в определении устройства).

ЗЫ. Но в целом была проблема в моем тупизме при конфигурировании Hadware 4хх. Я импортировал GDS файл, и перетянул "ввод/вывод" строчку "32 Word". И тупил.
Сменщик это заметил, поправил и потом боролся с порядком байт и нулевым регистром.