Два контроллера Pco5 в одной установке Опции

[liquid_ua]

Доброго времени суток!
Прошу помочь разобраться в некоторых нюансах написания программы для pCO. Постараюсь максимально разложить вопрос.
Имею небольшой опыт программирования контроллеров pCO3 и pCO5. Все проекты имели порядка 10-15 исполнительных механизмов, для этого вполне хватало дискретных выходов одного котроллера.
Сейчас мне необходимо написать программу для гораздо большего количества выходов (порядка 50). Использовать связку контроллер + пачка плат расширения не целесообразно как с финансовой так и практической стороны. Поэтому выбор пал на комбинацию из двух pCO5 Extra large (29 + 29 выходов) и одного дисплея pGD1.
Алгоритм управления оборудованием у меня почти готов, с этим проблем нет.
Вопрос связан с распределением программной части между контроллерами.
Подскажите как правильно поступать в подобной ситуации. Пока вижу 2 варианта:

вариант №1. Распределение выходов между контроллерами решается особой нумерацией этих выходов. В описании блока "Dout" говорится что нумерация дискретных выходов второго контроллера должна быть с приставкой +25. Тоесть, дискретный выход "NO1" второго контроллера должен быть под номером 26 и тд. Вот вроде бы и подсказка, подумал я, но, pCO5 extra large имеет 29 выходов. Что ж получается, 5 выходов на каждом контроллере выпадают с логики? Или тут нумерация сдвигается не на +25 а на +29? Проверить в симуляторе не могу, там симулируется работа только 1 контроллера.
Так как датчики подключаются только к первому контроллеру, это нужно оформить программно (разрешить опрос аналоговых входов только первому контроллеру, второму контроллеру передавать значения с датчиков через pLan links в networkeditor) - подсмотрел в одной из Demo_solution . Также поступить и с остальными входами, влияющими на работу алгоритма.
В данном варианте в каждый контроллер прошивается одинаковая программа, которую они синхронно обрабатывают (с учетом вышеописаных нюансов).

вариант №2. В рамках одной Solution создаю два разных проекта. В первом заложен алгоритм опроса датчиков\входов, а также основная часть всей программы. Во втором проекте почти пустая программа - чтение через pLan links переменных и передача их значений прямо на дискретные выходы. Грубо говоря, в этом варианте второй контроллер будет выполнять функцию платы расширения с доп выходами.

Какой из вышеописанных вариантов является рабочим и правильным?
Какие системные переменные нужно использовать для правильной установки связи между двумя контроллерами?

Оборудование заказано и будет через несколько недель, а чтобы времени не терять пытаюсь разобраться. Но так как это мой первый
опыт связки двух контроллеров в рамках одной промышленной установки, решил обратиться к более опытным автоматчикам, тоесть к Вам!

Сообщение отредактировал liquid_ua - 20.1.2015, 16:53

[liquid_ua]

Доброго времени суток!
Прошу помочь разобраться в некоторых нюансах написания программы для pCO. Постараюсь максимально разложить вопрос.
Имею небольшой опыт программирования контроллеров pCO3 и pCO5. Все проекты имели порядка 10-15 исполнительных механизмов, для этого вполне хватало дискретных выходов одного котроллера.
Сейчас мне необходимо написать программу для гораздо большего количества выходов (порядка 50). Использовать связку контроллер + пачка плат расширения не целесообразно как с финансовой так и практической стороны. Поэтому выбор пал на комбинацию из двух pCO5 Extra large (29 + 29 выходов) и одного дисплея pGD1.
Алгоритм управления оборудованием у меня почти готов, с этим проблем нет.
Вопрос связан с распределением программной части между контроллерами.
Подскажите как правильно поступать в подобной ситуации. Пока вижу 2 варианта:

вариант №1. Распределение выходов между контроллерами решается особой нумерацией этих выходов. В описании блока "Dout" говорится что нумерация дискретных выходов второго контроллера должна быть с приставкой +25. Тоесть, дискретный выход "NO1" второго контроллера должен быть под номером 26 и тд. Вот вроде бы и подсказка, подумал я, но, pCO5 extra large имеет 29 выходов. Что ж получается, 5 выходов на каждом контроллере выпадают с логики? Или тут нумерация сдвигается не на +25 а на +29? Проверить в симуляторе не могу, там симулируется работа только 1 контроллера.
Так как датчики подключаются только к первому контроллеру, это нужно оформить программно (разрешить опрос аналоговых входов только первому контроллеру, второму контроллеру передавать значения с датчиков через pLan links в networkeditor) - подсмотрел в одной из Demo_solution . Также поступить и с остальными входами, влияющими на работу алгоритма.
В данном варианте в каждый контроллер прошивается одинаковая программа, которую они синхронно обрабатывают (с учетом вышеописаных нюансов).

вариант №2. В рамках одной Solution создаю два разных проекта. В первом заложен алгоритм опроса датчиков\входов, а также основная часть всей программы. Во втором проекте почти пустая программа - чтение через pLan links переменных и передача их значений прямо на дискретные выходы. Грубо говоря, в этом варианте второй контроллер будет выполнять функцию платы расширения с доп выходами.

Какой из вышеописанных вариантов является рабочим и правильным?
Какие системные переменные нужно использовать для правильной установки связи между двумя контроллерами?

Оборудование заказано и будет через несколько недель, а чтобы времени не терять пытаюсь разобраться. Но так как это мой первый
опыт связки двух контроллеров в рамках одной промышленной установки, решил обратиться к более опытным автоматчикам, тоесть к Вам!

Сообщение отредактировал liquid_ua - 20.1.2015, 16:53

[Igorchello]

Доброго времени суток!
Прошу помочь разобраться в некоторых нюансах написания программы для pCO. Постараюсь максимально разложить вопрос.
Имею небольшой опыт программирования контроллеров pCO3 и pCO5. Все проекты имели порядка 10-15 исполнительных механизмов, для этого вполне хватало дискретных выходов одного котроллера.
Сейчас мне необходимо написать программу для гораздо большего количества выходов (порядка 50). Использовать связку контроллер + пачка плат расширения не целесообразно как с финансовой так и практической стороны. Поэтому выбор пал на комбинацию из двух pCO5 Extra large (29 + 29 выходов) и одного дисплея pGD1.
Алгоритм управления оборудованием у меня почти готов, с этим проблем нет.
Вопрос связан с распределением программной части между контроллерами.
Подскажите как правильно поступать в подобной ситуации. Пока вижу 2 варианта:

вариант №1. Распределение выходов между контроллерами решается особой нумерацией этих выходов. В описании блока "Dout" говорится что нумерация дискретных выходов второго контроллера должна быть с приставкой +25. Тоесть, дискретный выход "NO1" второго контроллера должен быть под номером 26 и тд. Вот вроде бы и подсказка, подумал я, но, pCO5 extra large имеет 29 выходов. Что ж получается, 5 выходов на каждом контроллере выпадают с логики? Или тут нумерация сдвигается не на +25 а на +29? Проверить в симуляторе не могу, там симулируется работа только 1 контроллера.
Так как датчики подключаются только к первому контроллеру, это нужно оформить программно (разрешить опрос аналоговых входов только первому контроллеру, второму контроллеру передавать значения с датчиков через pLan links в networkeditor) - подсмотрел в одной из Demo_solution . Также поступить и с остальными входами, влияющими на работу алгоритма.
В данном варианте в каждый контроллер прошивается одинаковая программа, которую они синхронно обрабатывают (с учетом вышеописаных нюансов).

вариант №2. В рамках одной Solution создаю два разных проекта. В первом заложен алгоритм опроса датчиков\входов, а также основная часть всей программы. Во втором проекте почти пустая программа - чтение через pLan links переменных и передача их значений прямо на дискретные выходы. Грубо говоря, в этом варианте второй контроллер будет выполнять функцию платы расширения с доп выходами.

Какой из вышеописанных вариантов является рабочим и правильным?
Какие системные переменные нужно использовать для правильной установки связи между двумя контроллерами?

Оборудование заказано и будет через несколько недель, а чтобы времени не терять пытаюсь разобраться. Но так как это мой первый
опыт связки двух контроллеров в рамках одной промышленной установки, решил обратиться к более опытным автоматчикам, тоесть к Вам!

Используйте 2 вариант. Так гораздо проще.

[liquid_ua]

Используйте 2 вариант. Так гораздо проще.

Спасибо! А как насчет системных переменных, есть какие нюансы или подводные камни?

[Igorchello]

Спасибо! А как насчет системных переменных, есть какие нюансы или подводные камни?

Есть системные переменные PLAN_ADRESS_SW. C помощью нее можете заранее выставить адрес pLan. Чтобы вручную потом не настраивать.
Еще переменные PLAN_INFO и PLAN_STATUS_01_16. С их помощью можно сделать аварию об отсутствии связи по pLan.

А так вроде все. Сложностей никаких нет.

[liquid_ua]

Хорошо. Идея оповещать об обрыве связи pLan правильная, спасибо!
Скажите, нужно ли мне использовать атомы RA_In_T, RA_Out, RD_Out? Или они нужны только в случае отправки переменных в скаду?

Есть вероятность что потребуется установить плату pCOWeb и отображать параметры установки на удаленном компьютере. Без красивых визуальных эффектов и анимаций, лишь табличное отображение температур. Думаю с простенькой страничкой html из скачанного примера я справлюсь, с настройкой переменных COM_BAUDRATE_BMS, и тд. тоже, а вот нужно ли использовать макроблок Carel_Protocol_Mng? а RA_In_T, RA_Out, RD_Out?

[Igorchello]

Хорошо. Идея оповещать об обрыве связи pLan правильная, спасибо!
Скажите, нужно ли мне использовать атомы RA_In_T, RA_Out, RD_Out? Или они нужны только в случае отправки переменных в скаду?

Есть вероятность что потребуется установить плату pCOWeb и отображать параметры установки на удаленном компьютере. Без красивых визуальных эффектов и анимаций, лишь табличное отображение температур. Думаю с простенькой страничкой html из скачанного примера я справлюсь, с настройкой переменных COM_BAUDRATE_BMS, и тд. тоже, а вот нужно ли использовать макроблок Carel_Protocol_Mng? а RA_In_T, RA_Out, RD_Out?

RA_In_T, RA_Out, RD_Out предназначены для отправки переменных в SCADA. Но это устаревшие модули, ими пользоваться не обязательно. Настройку передачи переменных в BMS удобнее производить в Variable Wizard на вкладке Network.

Макроблок Carel_Protocol_Mng предназначен для протокола Carel Master, т.е. для считывания переменных с Carel- устройств. Это не Ваш случай.

[liquid_ua]

Igorchello, большое Вам спасибо!