| Автор |
Сообщение |
|
Сообщение создано: 24. 03. 2013 [09:56]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3742
|
"roman" wrote:
DCON через не Serial вижу впервые. :)
Раз так то расширю выбор на все транспорты.
Расширил!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 17. 04. 2013 [15:37]
|
|
Godzilla
Арсен Закоян
Contributor
Зарегистрирован(а) с: 12.02.2013
Сообщения: 123
|
Вместо команд #AA00FF и #AA000F посылаются команды @AA,FF и @AA,F
|
|
Сообщение создано: 17. 04. 2013 [15:55]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Не должно. Вот участок программы - там задано отправлять #
case 704://4DO (#AA000F)
for(unsigned i_n = 0; i_n < 4; i_n++) if(cntr.p_hd[i_p].at().DO[i_n]) code += (1<<i_n);
pdu = TSYS::strMess("#%02X00%02X",cntr.p_hd[i_p].at().mod_addr,code);
do_txterr = cntr.DCONReq(pdu,cntr.p_hd[i_p].at().crc_ctrl,1);
break;
case 708://8DO (#AA00FF)
for(unsigned i_n = 0; i_n < 8; i_n++) if(cntr.p_hd[i_p].at().DO[i_n]) code += (1<<i_n);
pdu = TSYS::strMess("#%02X00%02X",cntr.p_hd[i_p].at().mod_addr,code);
do_txterr = cntr.DCONReq(pdu,cntr.p_hd[i_p].at().crc_ctrl,1);
break;
case 712://12DO (#AA000FFF)
for(unsigned i_n = 0; i_n < 12; i_n++) if(cntr.p_hd[i_p].at().DO[i_n]) code += (1<<i_n);
pdu = TSYS::strMess("#%02X00%04X",cntr.p_hd[i_p].at().mod_addr,code);
do_txterr = cntr.DCONReq(pdu,cntr.p_hd[i_p].at().crc_ctrl,1);
break;
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 17. 04. 2013 [18:49]
|
|
Godzilla
Арсен Закоян
Contributor
Зарегистрирован(а) с: 12.02.2013
Сообщения: 123
|
Даже после выбора из раскрывающегося списка DO метода #AA00FF в этой строке все равно появляется DO метод 8DO(@AA,FF).
У одного меня такая проблема?Собирал из исходников.
|
|
Сообщение создано: 17. 04. 2013 [21:00]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Ошибка в исходный код проскочила. Запятые вместо точек с запятой в 130-ой строчке файла DCON_client.cpp
"0;2;3;4;5;7;8;12;13;16;102;103;202;204;306;402;504;604;608,704,708,712)",
Надо
"0;2;3;4;5;7;8;12;13;16;102;103;202;204;306;402;504;604;608;704;708;712)",
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 18. 04. 2013 [08:12]
|
|
Godzilla
Арсен Закоян
Contributor
Зарегистрирован(а) с: 12.02.2013
Сообщения: 123
|
При выборе команды #AA00FF и включении параметра в атрибутах появляется только 4 DO, а должно быть 8 DO.
А при выборе #AA00FFF появляется 8 DO вместо 12 DO.
[Сообщение редактировалось 1 раз(а), в последний раз 18.04.2013 в 08:17.]
|
|
Сообщение создано: 18. 04. 2013 [08:34]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Ясно. Ещё ошибка. Строки 875 и 876 файла DCON_client.cpp
case 708:itCnt = 4; break; //8DO (#AA00FF)
case 712:itCnt = 8; break; //12DO (#AA000FFF)
Надо
case 708:itCnt = 8; break; //8DO (#AA00FF)
case 712:itCnt = 12; break; //12DO (#AA000FFF)
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 18. 04. 2013 [08:46]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3742
|
Включил эти исправления в рабочую версию.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 20. 04. 2013 [14:53]
|
|
punk
Василий Петров
Зарегистрирован(а) с: 09.05.2011
Сообщения: 57
|
"almaz" wrote:
"punk" wrote:
Собственно вопрос -- планируется ли поддержка протокола DCON на adam-60xx, особенно учитывая что они умеют modbus (у меня в конце концов и он заработал).
ADAM-60xx почти полные аналоги модулей ET-70xx. При наличии нормально работающего MODBUS смысла в поддержке DCON не вижу. Если появятся похожие модули только с DCON или обмен по протоколу DCON окажется чем-то лучше - другое дело.
Все-таки удалось провести некоторое сравнение DCON/ModBUS. Они немного различаются по скорострельности, в пользу DCON. И DCON и ModBUS позволяют уверенно сгенерировать меандр 250Гц (период опроса 0.002), но при генерации 500Гц у DCON появляются пропуски реже 1 в секунду, а у ModBus пропусков сильно больше.
Программа генерации меандра (на всякий случай):
st=!st;
stQ=st;
st - внутренний атрибут, stQ - внешняя связь.
Данные из WorkStation/Задачи:
dcon,0.002s
sub_DAQ.mod_DCON.cntr_Adam_6050 Last: 20-04-2013 14:59:07. Load: 41.6% (0.8361мс from 2.01мс). Lag: 22.78мкс. Cycles lost: 0.
sub_DAQ.mod_LogicLev.cntr_tst0 Last: 20-04-2013 14:59:07. Load: 1.8% (35.59мкс from 2.007мс). Lag: 90.95мкс. Cycles lost: 0.
dcon,0.001s
sub_DAQ.mod_DCON.cntr_Adam_6050 Last: 20-04-2013 15:16:15. Load: 80.9% (0.8084мс from 0.9999мс). Lag: 6.63мкс. Cycles lost: 5.
sub_DAQ.mod_LogicLev.cntr_tst0 Last: 20-04-2013 15:16:15. Load: 2.4% (23.73мкс from 0.9986мс). Lag: 49.7мкс. Cycles lost: 0.
modbus,0.002s
sub_DAQ.mod_LogicLev.cntr_tst0 Last: 20-04-2013 15:20:04. Load: 68.8% (1.35мс from 1.964мс). Lag: 82.08мкс. Cycles lost: 0.
sub_DAQ.mod_ModBus.cntr_Adam_6050 Last: 20-04-2013 15:20:04. Load: 40.2% (0.8027мс from 1.997мс). Lag: 8.685мкс. Cycles lost: 0.
modbus,0.001s
sub_DAQ.mod_LogicLev.cntr_tst0 Last: 20-04-2013 15:23:24. Load: 68.0% (1.379мс from 2.026мс). Lag: 106.8мкс. Cycles lost: 3511.
sub_DAQ.mod_ModBus.cntr_Adam_6050 Last: 20-04-2013 15:23:24. Load: 76.3% (0.7583мс from 0.9935мс). Lag: 5.862мкс. Cycles lost: 11363.
Тестировалось на ноуте lenovo G410,
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 22
model name : Intel(R) Celeron(R) CPU 540 @ 1.86GHz
stepping : 1
microcode : 0x33
cpu MHz : 1861.754
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx lm constant_tsc up arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm
bogomips : 3723.50
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
ядро
Linux debNB 3.2.0-0.bpo.4-rt-686-pae #1 SMP PREEMPT RT Debian 3.2.41-2~bpo60+1 i686 GNU/Linux
max_cstates=1,
OpenSCADA revision 1979
Помимо предоставленных данных, различия очень хорошо видны визуально на подключенном к выходу модуля светодиоде - если в первых случаях он "горит" равномерно, то в последнем постоянно мигает. Более точно пока оценить "кривизну" импульсов не могу - осциллографа под рукой нет.
Еще немного удивила разница в нагрузке на LogicLev, хотя top во всех случаях показывает нагрузку на процессор не более 15%, возможно, во втором случае LogicLev дожидается отправки от ModBUS.
|
|
Сообщение создано: 20. 04. 2013 [20:09]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3742
|
"punk" wrote:
Все-таки удалось провести некоторое сравнение DCON/ModBUS. Они немного различаются по скорострельности, в пользу DCON. И DCON и ModBUS позволяют уверенно сгенерировать меандр 250Гц (период опроса 0.002), но при генерации 500Гц у DCON появляются пропуски реже 1 в секунду, а у ModBus пропусков сильно больше.
Не должно там быть особой разницы поскольку размер пакетов не сильно разнится. ModBus кстати какой: TCP, RTU, ASCII? Если RTU то его время чувствительно сильно к таймауту-времени символа.
"punk" wrote:
sub_DAQ.mod_DCON.cntr_Adam_6050 Last: 20-04-2013 14:59:07. Load: 41.6% (0.8361мс from 2.01мс). Lag: 22.78мкс. Cycles lost: 0.
...
sub_DAQ.mod_ModBus.cntr_Adam_6050 Last: 20-04-2013 15:20:04. Load: 40.2% (0.8027мс from 1.997мс). Lag: 8.685мкс. Cycles lost: 0.
По мне так разницы нет.
"punk" wrote:
sub_DAQ.mod_DCON.cntr_Adam_6050 Last: 20-04-2013 15:16:15. Load: 80.9% (0.8084мс from 0.9999мс). Lag: 6.63мкс. Cycles lost: 5.
sub_DAQ.mod_ModBus.cntr_Adam_6050 Last: 20-04-2013 15:23:24. Load: 76.3% (0.7583мс from 0.9935мс). Lag: 5.862мкс. Cycles lost: 11363.
Скорее всего приоритет задачи sub_DAQ.mod_ModBus.cntr_Adam_6050 низкий, из-за чего и много пропусков.
"punk" wrote:
Еще немного удивила разница в нагрузке на LogicLev, хотя top во всех случаях показывает нагрузку на процессор не более 15%, возможно, во втором случае LogicLev дожидается отправки от ModBUS.
Это нормально, поскольку "Load: 68.8% (1.35мс from 1.964мс)." это не реальная нагрузка на процессор, а то что и написано, т.е. в цикле 1.964 задача исполнялась 1.35мс. Во время 1.35мс включено как часть времени высоко-приоритетных задач, так и время ожидания обмена, не создающего реальной нагрузки на процессор.
Learn, learn and learn better than work, work and work.
|
