 | |
Предыдущие результаты
 Мне надо изменить размер шрифта в Controller organizer, также заблокировано изменение шрифтов в SFC и FBD редакторах.
|
Проблема: Allen-Bradley -> Profibus -> Siemens?
Я программирую передачу данных в контроллеры Allen-Bardley
(серия ControlLogix) из контроллеров Siemens (серия S7-300) и
обратно по протоколу Profibus. Со cтороны Allen-Bradley для связи
по Profibus используется модуль 1756-MVI56-PDPMV1,
т.е. Profibus DPV1 Master Communication Module (в сети он Master),
со стороны Siemens - CP 3425 DP (в сети он Slave).
Со стороны Siemens все хорошо. Gsd-файл модуля нормально
загружается в 1756-MVI56-PDPMV1, параметры передачи (кол-во передаваемых,
получаемых байт) заданы одинакого и со стороны Siemens,
и со стороны Allen-Bradley. При просмотре сети Profibus в On-line режиме
с помощью утилиты Prosoft Configuration Builder 2.0.2 (PCB) тоже все нормально
(On-Line параметры диагностики модуля Siemens в PCP говорят Slave Ok).
Сеть выстроена правильно и по данным и по индикации как со стороны Allen-Bradley,
так и состороны Siemens.
Теперь самое главное - передача данных в циклическом режиме в RSLogix
осуществляется с помощью структур:
MVI56PDPMV1.Input[0..1535] - для входных данных.
MVI56PDPMV1.Output[0..1535] - для выходных данных.
При передачи через MVI56PDPMV1.Output Siemens получает данные.
Но при посылке данных Siemens-ом массив MVI56PDPMV1.Input
остается заполнен нулями, несмотря на то, что в PCB приходящие данные видны
(в выделенных им структурах). Т.е. модуль 1756-MVI56-PDPMV1 данные получает.
Это также видно и в On-Line параметрах master-a из PCB.
Но буфер MVI56PDPMV1.Input[0..1535] остается пуст
(длина его задана нормально в конфигурации PCB).
Программа логики Allen-Bradley скачана с официального сайта Prosoft.
Входной буфер можно просматривать и из PCB через Diagnostics модуля,
но там тоже нули. Анализ приходящих данных в контроллере показывает,
что ошибок нет, обмен идет нормально. #-ра блоков тоже отлично передаются
модулю и принимаются. Но при чтении регистров (#блоков 1-3) они остаются
заполнены нулями. Не понимаю, почему приходящие данные отлично отображаются
в PCB (Prosoft Configuration Builder), но в структуры RSLogix-a (MVI56PDPMV1.Input)
передаваться упорно не хотят?
Буду очень признателен за помощь.
[/b]
|
И еще интересная информация на тему записи строк.
Испытания записи русских строк продолжили с изменениями в полигоне: вместо RSView32 использована среда RSView Studio версии 3.20. Результаты таковы:
Если использовать прямое подключение к контроллеру ControlLogix с использованием RSLinx Enterprise, то проблема остается нерешенной, также идет некорректная запись символов и считывания не происходит. Но, если в качестве связи с PLC использовать RSLinx OPC Server (RSLinx Professional), то и запись и чтение тэгов происходит успешно, т.е. в контроллер попадают символы русской кодировки (можно их проанализировать в 16-ти ричном коде). Вот такая чушь...
Хотя я так подозреваю, что преимущественней в случае RSView Studio использовать коммуникации через RSLinx Enterprise, а RSLinx классик совсем не устанавливать?
С уважением,
Vitaliy D. Burtsev
|
Проблема: Allen-Bradley -> Profibus -> Siemens?
Я программирую передачу данных в контроллеры Allen-Bardley
(серия ControlLogix) из контроллеров Siemens (серия S7-300) и
обратно по протоколу Profibus. Со cтороны Allen-Bradley для связи
по Profibus используется модуль 1756-MVI56-PDPMV1, т.е. Profibus
DPV1 Master Communication Module (в сети он Master), со стороны
Siemens - CP 3425 DP (в сети он Slave). Со стороны Siemens все
хорошо. Gsd-файл модуля нормально загружается в 1756-MVI56-
PDPMV1, параметры передачи (кол-во передаваемых, получаемых
байт и шинные параметры) заданы одинакого и со стороны Siemens,
и со стороны Allen-Bradley. При просмотре сети Profibus в On-line
режиме с помощью утилиты Prosoft Configuration Builder 2.0.2 (PCB)
тоже все нормально (On-Line параметры диагностики модуля Siemens
в PCP говорят Slave Ok). Сеть выстроена правильно и по данным и
по индикации как со стороны Allen-Bradley, так и состороны Siemens.
Теперь самое главное - передача данных в циклическом режиме в
RSLogix осуществляется с помощью структур:
MVI56PDPMV1.Input[0..1535] - для входных данных.
MVI56PDPMV1.Output[0..1535] - для выходных данных.
При передачи через MVI56PDPMV1.Output Siemens получает данные.
Но при посылке данных Siemens-ом массив MVI56PDPMV1.Input
остается заполнен нулями, несмотря на то, что в Prosoft Configuration
Builder, приходящие данные видны в выделенных им структурах.
Т.е. модуль 1756-MVI56-PDPMV1 данные получает. Это также видно и
в On-Line параметрах master-a и slave-a из PCB. Но буфер
MVI56PDPMV1.Input[0..1535] остается пуст (длина его задана
нормально в конфигурации PCB). Программа логики для контроллера
Allen-Bradley скачана с официального сайта. Входной буфер (Input)
можно просматривать и из PCB через Diagnostics модуля, но там тоже
нули.
Не понимаю, почему приходящие данные отлично отображаются в
PCB (Prosoft Configuration Builder), но в структуры RSLogix-a
(MVI56PDPMV1.Input) передаваться упорно не хотят?
Буду очень признателен за помощь...
|
[color=blue:3b0ea881a3]Может, немного не в тему, но мы на Дельфях делали ввод/вывод на форму стринги, в том числе и кириллицу. Тип данных в каонтроллере - String. L32E, RSLogix5000 v.15, RSLinxPro 2.5. Без проблем.[/color:3b0ea881a3]
У меня такое подозрение, что некорректно работает RSView32 v.7.00. Она не только не умеет прочитать записанные в ControlLogix строковые теги, но и пишет их туда неправильно. RSLinx у меня версии 2.42.
Если использовать практически любого другого OPC клиента к RSLinx, то получается и записать, и прочитать. Строка кладется с нормальными 16-ти ричными кодами русских символов и без проблем считывается в этот же клиент. А нужно именно использовать в качестве клиента RSView32.
С уважением,
Vitaliy D. Burtsev
|
[quote:48d8f9f4f7="Mr_Wasp"]Спасибо, конечно, за ответы, но я так и не понял: можно ли как-нибудь записать в ControlLogix именно РУССКУЮ строку, а затем ее прочитать?
Skip
[/quote:48d8f9f4f7]
Можно. И никаких "Васиков" не надо.
Описываешь в RSLogix 5K тег как String, например имя "Text"
В RSView32 в поле Adress также пишешь "Text", тип данных String.
Не используй "Text.data[*]".
|
Спасибо, конечно, за ответы, но я так и не понял: можно ли как-нибудь записать в ControlLogix именно РУССКУЮ строку, а затем ее прочитать?
Я знаю, что коды русских букв выходят за пределы стандартной ASCII таблицы и имеют значение большее 127 (десятичное), даже более того: если создать самому массив INTов и попытаться записать в него русские символы, то коды символов правильно раскладываются в шестнадцетиричном коде. Однако никто не может их считать: ни RSView32, ни OPCTestClient (RSLinx Tools), ни другие клиенты.
Неужели придется этот массив на ВАСИКе разбирать? Типа загружаем нулевой элемент массива: старший байт преобразуем, записываем в первый символ строки, младший байт преобразуем - записываем во второй символ строки; затем берем следующий INT и т.д. Честно говоря, по ощущениям выглядит не очень...
Vitaliy D. Burtsev
|
Здравствуйте, коллеги!
Никто не сталкивался с проблемой записи в строковые теги ControlLogix и чтения из них строк на русском языке? Есть такая необходимость, чтобы одно приложение по OPC записало в контроллер строку на русском языке, другое - прочитало.
Я так понимаю, что стандартный тип String в Logix не катит по причине того, что каждый символ в строке имеет тип ShortInt (SINT). Но есть якобы вариант с использованием массива INTов, к которым нужно лишь своеобразно обратиться: например, из RSView32 указать примерно следующее [LINX_TOPIC]int_str[0],SCxx. В этом случае получается забрать символы в латинской кодировке (опять с кодом от 0 до 127 десятичн.), но с кодом от 128 до 255 никак, точнее они отображаются не по-русски в любом случае.
Если есть решение, то буду рад за помощь.
С уважением,
Vitaliy D. Burtsev
|
Я делал управление газотурбинными компрессорами ГТТ-3М на агрегатах производства азотной кислоты серии УКЛ. ControlLogix отлично справился с поставленной задачей. Для реализации ППЗ нужно было раскошелиться на достойные клапана - руководство зажало... И вообще нужен был толковый технолог, который рассказал толково собственно алгоритм защиты, а со стороны АВ - проблем -никаких.
|
[quote:0dbad7c0a3]Я бы попробовал запитать от другого источника питания.[/quote:0dbad7c0a3]
Источников питания у нас несколько, все от Бредли. Там проблем нет, контроллеры работали на разных источниках _PS3) тоже новый).
[quote:0dbad7c0a3]то на начнём с вопроса - вы в новый контроллер "залили " ту же программу что и на объекте? Если да, то есть ли пример успешной работы данной программы ? Если да, то всё таки проверьте ваш БП. Если нет, то может разберёмся с программой?[/quote:0dbad7c0a3]
Данная прога сейчас работает на заводе. Проблема была в логике алгоритма и защите от дурака. Инструкции input/output используются только для игнорирования связи с модулями (выполняются один раз при установки метки). Ошибок стандартных при выполнении задач не отмечал, прескан тоже проходит нормально. Память пользователя занята процентов на 20. Вообще, это моя первая прога на Лоджике, но работает. Да и какие в конце-кнцов могут быть ошибки кода, которые приводят к неустранимой ошибке. При всем при том, что на этот раз код выполнялся процентов на 20, потому, что ни одной стандартной задачи алгоритма техпроцесса не было задано, т.е. условный переход в основные рутины из главной рутины не выполнялся. Ошибки прескана исключены, контроллер нормально вошел в работу. Сторожевые таймеры задач установлены на 500, циклов не задано вообще. В ControllerFault тупо прописано снимать любую ошибку вне зависимости от типа, программные обработчики Fault вообще не прописаны. Вся прога написана на LD. Одна задача фоновая, и одна периодическая.
|
Предыдущие результаты
Ещё результаты |
|
| |
|
