| Author |
Message |
|
Written on: 02. 12. 2011 [12:05]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"s-s-n" wrote:
Возникла проблема при записи данных по модбасу.
Настройки хранятся в одном байте, при записи в первый регистр, во втором 0-й байт обнуляется.
Но если записывать число которое там хранится, то и байт во втором не обнуляется.
Контроллер меняет. Есть сомнения открываем отчёт запросов ModBus и контролируем что реально пишется и читается: http://wiki.oscada.org/Doc/ModBus/files?get=modbus_prt_rep.png
P.S. Нужно приводить конфигурацию атрибутов ModBus в OpenSCADA, может Вы определили сборный атрибут из двух регистров, а потом такие вопросы задаёте!
Learn, learn and learn better than work, work and work.
|
|
Written on: 05. 12. 2011 [08:37]
|
|
s-s-n
s-s-n
registered since: 16.08.2011
Posts: 83
|
"roman" wrote:
P.S. Нужно приводить конфигурацию атрибутов ModBus в OpenSCADA, может Вы определили сборный атрибут из двух регистров, а потом такие вопросы задаёте!
Читаю и пишу в эти регистры:
R_i2:61451:rw:R61451:R61451
R_i2:61452:rw:R61452:R61452
R_i2:61453:rw:R61453:R61453
R_i2:61454:rw:R61454:R61454
R_i2:61455:rw:R61455:R61455
Попробовал сформировать запросы на запись и чтение. Сначала ввожу новые данные в 61452, читаю их, потом
новые в 61451 тоже читаю. Потом проверка значений в 61452 и появляется ноль.
wR61452
15 01 00 00 00 09 01 10 f0 0c 00 01 02 32 32
15 01 00 00 00 06 01 10 f0 0c 00 01
rR61452
15 01 00 00 00 09 01 03 f0 0c 00 01 02
15 01 00 00 00 05 01 03 02 32 32
wR61451
15 01 00 00 00 09 01 10 f0 0b 00 01 02 30 30
15 01 00 00 00 06 01 10 f0 0b 00 01
rR61451
15 01 00 00 00 09 01 03 f0 0b 00 01 02
15 01 00 00 00 05 01 03 02 30 30
rR61452
15 01 00 00 00 09 01 03 f0 0c 00 01 02
15 01 00 00 00 05 01 03 02 32 00
Attachment
Снимок-1.png (File type: image/png, Size: 158.84 kilobytes) — 679 downloads
|
|
Written on: 05. 12. 2011 [10:05]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"s-s-n" wrote:
R_i2:61451:rw:R61451:R61451
R_i2:61452:rw:R61452:R61452
R_i2:61453:rw:R61453:R61453
R_i2:61454:rw:R61454:R61454
R_i2:61455:rw:R61455:R61455
Правильно
"s-s-n" wrote:
Попробовал сформировать запросы на запись и чтение. Сначала ввожу новые данные в 61452, читаю их, потом
новые в 61451 тоже читаю. Потом проверка значений в 61452 и появляется ноль.
wR61452
15 01 00 00 00 09 01 10 f0 0c 00 01 02 32 32
15 01 00 00 00 06 01 10 f0 0c 00 01
rR61452
15 01 00 00 00 09 01 03 f0 0c 00 01 02
15 01 00 00 00 05 01 03 02 32 32
wR61451
15 01 00 00 00 09 01 10 f0 0b 00 01 02 30 30
15 01 00 00 00 06 01 10 f0 0b 00 01
rR61451
15 01 00 00 00 09 01 03 f0 0b 00 01 02
15 01 00 00 00 05 01 03 02 30 30
rR61452
15 01 00 00 00 09 01 03 f0 0c 00 01 02
15 01 00 00 00 05 01 03 02 32 00
Из этого я могу заключить, что OpenSCADA всё делает и показывает корректно, а значит сам контроллер обнуляет старший байт регистра rR61452.
Возможно это связанно с некорректной обработкой функции групповой записи в контроллере. Попробуйте отключить параметр объекта контроллера "Использовать функции записи нескольких элементов (15,16)"
Learn, learn and learn better than work, work and work.
|
|
Written on: 10. 12. 2011 [12:37]
|
|
yozhik
Алексей Николаев
registered since: 29.11.2010
Posts: 127
|
Есть устройство, по которому OpenSCADA по Modbus RTU (не от хорошей жизни) синхронизирует время:
req = SYS.XMLNode("RTU");
req.setAttr("id","device").setAttr("reqTm",1000).setAttr("node",node).setText(Special.FLibSYS.strEnc2Bin("03 0b 08 00 04"));
SYS.Transport.Serial.out_terminal.messIO(req,"ModBus");
response = Special.FLibSYS.strDec4Bin(req.text());
//тут пересчет в секунды от лохматого 1970 года из супер нестандартного формата
...
SYS.system( "sudo date --set=\'" + SYS.strftime( timestamp ) + "\'" );
При этом "sudo date" настроено на запуск без ввода пароля. Так вот фишка в том, что если время timestamp превышает текущее, то все нормально. Но если время меньше (примерно на минуту - меньше пока проверить не было возможности), то это при этом выполнение SYS.Transport.Serial.out_terminal.messIO(req,"ModBus") зависает без признаков жизни до таймаута контроллера Javalikecalc. При это остальные контроллеры DAQ.Modbus продолжают работать нормально. Есть здесь что-либо системное? И в общем по мнению гуру линукса как синхронизацию времени по модбас лучше делать? Можно ли переводить время назад командой date при запросах типа SYS.Transport.Serial.out_terminal.messIO(req,"ModBus")?
|
|
Written on: 10. 12. 2011 [13:36]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"yozhik" wrote:
При этом "sudo date" настроено на запуск без ввода пароля. Так вот фишка в том, что если время timestamp превышает текущее, то все нормально. Но если время меньше (примерно на минуту - меньше пока проверить не было возможности), то это при этом выполнение SYS.Transport.Serial.out_terminal.messIO(req,"ModBus") зависает без признаков жизни до таймаута контроллера Javalikecalc.
Не вижу связи между временем в ModBus ответе и зависании именно messIO(). Кроме того, с чего взято, что зависание именно в строке SYS.Transport.Serial.out_terminal.messIO(req,"ModBus")?
Если бы зависание было на одном из внешних вызовов то поток вычисления не прервался никогда! Ищите проблему в своём коде, скрытом за "..."!
P.S. Время от 1970 года как раз самое стандартное, от эпохи UNIX, а всё остальное как раз фигня и обычно желание Microsoft выделиться.
Learn, learn and learn better than work, work and work.
|
|
Written on: 10. 12. 2011 [14:14]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"yozhik" wrote:
И в общем по мнению гуру линукса как синхронизацию времени по модбас лучше делать?
Синхронизировать удалённое устройство, а не сервер.
"yozhik" wrote:
Можно ли переводить время назад командой date при запросах типа SYS.Transport.Serial.out_terminal.messIO(req,"ModBus")?
Скачкообразное изменение времени на системах, работающих с астрономическим временем, вообще черевато. Поэтому используем ntp.
Learn, learn and learn better than work, work and work.
|
|
Written on: 11. 12. 2011 [17:28]
|
|
yozhik
Алексей Николаев
registered since: 29.11.2010
Posts: 127
|
"roman" wrote:
Кроме того, с чего взято, что зависание именно в строке SYS.Transport.Serial.out_terminal.messIO(req,"ModBus")?
Дело в том, что если закомментировать строку SYS.Transport.Serial.out_terminal.messIO(req,"ModBus"), то все замечательно работает. Если закомментировать строку SYS.system( "sudo date --set=\'" + SYS.strftime( timestamp ) + "\'" ), то также все работает. Не работает связка из этих двух строк.
"roman" wrote:
Ищите проблему в своём коде, скрытом за "..."!
P.S. Время от 1970 года как раз самое стандартное, от эпохи UNIX, а всё остальное как раз фигня и обычно желание Microsoft выделиться.
Тут дело в том, что метка времени получается от законченного устройства, в которм оно в отсчетах 1/1200 секунды от 01.01.2000 г. Вот уж ребята покурили чего-то когда это делали. А промежуточный код просто преобразует это к формату в секундах от 1970 г и подсовывает в strftime. Там простая математика и ничего более. То что время от 1970 г самое стандартное никто не спорит, но порой приходится иметь дело и работать с поделками умельцев, которые так не считают. К сожалению ntp тут тоже использовать не получается. Синхронизировать устройство самому тоже никак.
|
|
Written on: 11. 12. 2011 [20:56]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"yozhik" wrote:
"roman" wrote:
Кроме того, с чего взято, что зависание именно в строке SYS.Transport.Serial.out_terminal.messIO(req,"ModBus")?
Дело в том, что если закомментировать строку SYS.Transport.Serial.out_terminal.messIO(req,"ModBus"), то все замечательно работает. Если закомментировать строку SYS.system( "sudo date --set=\'" + SYS.strftime( timestamp ) + "\'" ), то также все работает. Не работает связка из этих двух строк.
Значит эффект скачкообразного изменения времени.
Learn, learn and learn better than work, work and work.
|
|
Written on: 29. 12. 2011 [14:23]
|
|
yozhik
Алексей Николаев
registered since: 29.11.2010
Posts: 127
|
Насколько оправдано в ответе функции messIO текст разбивать на строки по 16 байт? Это, конечно, удобно для восприятия человеком, однако лишь вносит необходимость дополнительно заменять символы "\n" на пробел при разборе пакета в скрипте. Может стоить убрать эту особенность здесь, но сохранить ее при отображении во вкладке Отчеты модуля Transport protocols?
|
|
Written on: 29. 12. 2011 [15:53]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"yozhik" wrote:
Насколько оправдано в ответе функции messIO текст разбивать на строки по 16 байт?
Функция messIO() ничего не разбивает и вообще не работает с запросом в текстовом представлении.
Learn, learn and learn better than work, work and work.
|
