Здравствуйте. Проблема такая. Узел RTM. Связь аргументов программы и экрана через байты числового канала.
СALL.Program через аргумент Q_0 (типа OUT) передает значение в байт_0 канала HEX32 (или HEX16), через аргумент Q_1 -- в байт_1 того же канала НEX32 и т.д. С другой стороны CALL.Screen в свой байтовый аргумент ARG_0 (тип IN), соответственно, тянет байт_0 означенного канала, в аргумент ARG_1 -- байт_1 и т.д. В узле RTM такая схема работает прекрасно. Но стоит мне попытаться вытянуть байт этого числового канала тем же образом из консоли -- получается это только в момент старта консоли, а потом значения не обновляются. При этом, если программа будет передавать значения своих выходных аргументов не в байты одного и того же канала, а в четыре разных канала HEX16, то схема работает.
Пробовал играться с типом данных принимающих аргументов экрана, с направлением числового канала (In/Out) -- безуспешно. В экране к этим аргументам привязаны координаты перемещения графических объектов (в одном случае), а также видимость ГЭ. Атрибут привязки ГО и ГЭ -1 (т.е. байт прописан в строке привязки аргумента, как и подобает). Сам канал вызова программы находится в узле RTM, он один. А каналы вызова экрана -- в узлах RTM и NLL.
На мой взгляд не рационально городить 4 канала, когда можно обойтись байтами одного. К тому же большая работа проделана именно с этим подходом, а в консоли, как оказалось результата нет. Причем я вижу, что принципиально это возможно, ведь в начальный момент консоль считывает байты. Мне кажется, я что-то не учел или не до конца понимаю. Надеюсь на вашу помощь.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Такие ограничения в настоящее время имеют место.
В зависимости от способа отображения 4-х байтов одного канала можно использовать 1 из двух механизмов.
1. Если каждый байт в отдельности с консоли используется только для индикации, то можно запросить значение канала HEX32 аргументом экрана консоли и построить индикацию путем маскирования полученного значения.
2. Если байты используются в консоли для числового отображения, можно - создать в консоли программу, - запросить в аргумент программы значение канала HEX32, - распаковать запрошенное значение в аргументы программы и - привязать аргументы экрана к соответствующим аргументам программы.
3. В исходной программе сервера не упаковывайте байты в число UDINT. Выдайте каждый байт в свой аргумент программы, но так, чтобы ID этих аргументов не превышали 46.
Согласно документации, аргументы также являются атрибутами канала, их индексация начинается со 140. В ИС 47 аргументов канала (ID аргументов равны 0-46) доступны для привязки через атрибуты 140-186 (привязка к атрибуту 140 в ИС равнозначна привязке к аргументу с ID=0).
Привяжите аргументы экрана к нужным атрибутам программы.
Posted by Alexander_ (Участник № / Member № 7778) on :
Спасибо. В моём случае уместен третий способ.
Уточню: упаковка байтов у меня происходит не в исходной программе сервера, а на уровне числового канала, в байты которого программа шлет свои выходные аргументы. Такое решение как раз и было обусловлено необходимостью работы канала вызова программы из сервера "на консоль". Однако оказалось, что из консоли нельзя привязываться к аргументам серверного канала, лишь как к собственно аргументам, в то же время можно привязаться к ним как к атрибутам этого канала (вкладка "Атрибуты", в пределах 47 аргов).
По этому случаю и другим постам раздела вижу, что модули консолей имеют ряд специфических ограничений, о которых, в общем-то, не упомянуто ни в сопроводительной документации, ни на оф. сайте. Можно ли где-нибудь найти исчерпывающую информацию касательно возможностей модуля NLL, чтобы не плодить подобных вопросов и не простаивать в работе? Наверняка, и с полубайтами та же фигня? А еще заметил, что указание атрибута привязки в настройках ГЭ (в редакторе аргументов, открывающемся при задании динамизации ГЭ) в консоли тоже не работает: получается для различных атрибутов одного и того же канала в экране, вызываемом из консоли, должны быть созданы различные аргументы.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
