통신관련입니다

제 경우에는 AB PLC는 사용해 보지 않아서 정확한 해법은 드리기 어려울 것 같습니다.  하지만 아는 범위만큼 알려 드리겠습니다.   우선 PLC를 사용하실 때에는 설계 차원에서 알고 있어야 하는 사항이 있습니다.   1. PLC의 통신 아키텍쳐 모든 PLC 제품이 다 그런 것은 아니지만 대부분의 PLC들은 통신 모듈도 CPU에 종속이 되어 운용됩니다.  즉, 통신 부하가 많으면 CPU가 느려지고, 반대로 CPU의 프로그램이 많으면 통신 속도가 느려집니다.  데이터만 공유를 하고 통신 모듈도 별도의 CPU 칩을 넣어 제작을 하면 CPU 모듈과는 별개로 통신을 할 수는 있지만, 그러면 가격이 올라가기 때문에 PLC는 대부분 그렇게 제작하지 않습니다.  이러한 점은 설계시 중요한 점을 시사하여 줍니다. 그것은 많은 데이터를 처리할 때는 성능까지도 고려해야 한다는 점입니다.  하나의 CPU로 5,000points를 처리하는 것과 20,000points를 처리할 때는 성능의 차이가 나타납니다.  HMI Tag가 24,000개이면 이미 최적화 운용하기에는 용량이 벗어난 것 같습니다.   Siemens PLC의 경우를 예로 들어 드리면, 제 경우에 다음과 같은 통신 성능에 대한 통계를 가지고 설계에 반영을 합니다. - S7-300 PLC : 15 ~ 20 polls/sec - S7-400 PLC : 150 polls/sec 이렇게 Siemens PLC의 경우에는 기종에 따라 통신 성능이 큰 차이가 납니다.  이 통계 데이터를 기준으로 1대의 CPU에서 처리할 수 있는 용량은 얼마인지, 얼마나 빠르게 데이터를 수집할 수 있는지 등을 계산하여 필요한 CPU 노드 수를 산정하기도 합니다.  뿐만 아니라 polling의 최적화를 위해서 데이터 블록 구성하는 것도 PLC 프로그램 설계에서 반드시 반영을 해 줍니다.   AB PLC에 대해서는 AB 측에 알아보셔야 할 것 같습니다.  참고로 통신 할 때와 통신 하지 않을 때 PLC Scan Time의 차이를 말씀하셨는데, 그 이유가 바로 이것 때문입니다.   2. 통신 프로토콜  예전의 PLC5 a모델을 사용할 때는 통신 성능이 무지 빨랐습니다.  1000개의 워드를 읽는데도 20ms가 걸리지 않았던 기억이 있습니다.  그것은 PLC들은 대부분 Polling 방식의 프로토콜을 지원하는데, polling 방식에서 통신을 최적화 할 수 있는 Block 통신이 뛰어났었거든요.  PLC5는 1블록에서 1000개의 워드를 읽을 수가 있었습니다.  아마도 24,000개의 태그 중에는 Digital로 많이 있을 것이므로, 설계만 잘하면 2개의 블록으로 모든 데이터 수집이 가능할 수도 있고, 최적화된 프로그래밍만 한다면 50ms에도 그 많은 데이터를 읽을 수가 있었을 것입니다.  (실제로 대부분의 PLC 엔지니어들은 그러한 설계를 하지 않기 때문에 그런 성능은 나오지 않지만 계산적으로는 그렇습니다.)   그런데 AB가 Control Logix 모델을 발표하면서 상황이 바뀌었습니다.  IEEE 프로그래밍 규약을 지원하면서 Block 통신에는 적합하지 않는 아키텍쳐가 도입이 되어 버린 것입니다.  물론 프로토콜에서는 Block 통신이 가능하도록 설계가 되어있지만 예전과 비교해보면 거의 무용지물이 된 셈입니다.  싸이텍에서는 새로운 Control Logix PLC의 드라이버를 Tag Based Driver라고 부르고 있습니다.  이것은 기준 주소로부터 원하는 데이터 개수 많큼을 수집하는 것이 아니라 Tag 기반으로 개별 인터페이스를 해야 한다는 것을 의미합니다.  이러한 변경 때문에 Control Logix 사용하시는 분들은 성능에 더욱 신경을 쓰셔야 할 것 같습니다.   위의 두 가지 내용을 미리 알고 계셔야 아래 설명들이 최적화를 위해서 왜 필요한 것인지 이해하실 수가 있을 것 같습니다.  (참고로 서두에서도 이야기 했지만 AB PLC를 사용해 본 경험이 없어서 CPU 성능을 향상시킬 수 있는 직접적인 방법은 모릅니다.  다만 통신 성능 향상을 위한 방법을 알려 드리오니 참조하시기 바랍니다. 통신을 최적화 하면 어느 정도 CPU에 도움은 되겠지만 근본적인 원인 해결은 되지 않을 것 입니다.  제가 볼 때는 PLC Station을 최소 4~5개로는 분리를 해야 할 것으로 보입니다.  또는 AB에 문의를 해 보시면 좋은 방법이 있을 수도 있습니다.  어차피 CPU 성능은 PLC 업체가 해결할 부분이니까요.)   통신 최적화에 앞서 몇 가지 문의 내용을 정리하고자 합니다.  첫째는 Advanced에서 System Overhead Time을 조정하는 것은 아마도 CPU의 과부하를 의도적으로 막는 기능인 것 같습니다.(자세한 내용은 AB 도움말을 참조하시기 바랍니다.  저는 그냥 항목 이름만 가지고 예상을 한 것입니다.)  그런데 그 설정이 60% 이하가 되면 통신이 안된다는 것은 지금 CPU의 부하가 높다는 것을 의미하는 것입니다.  컴퓨터도 어떤 프로그램을 제공할 때 항시 60% 이상이 되는 시스템이라면 그건 뭔가 설계가 잘못된 시스템이라고 할 수 있습니다.  특히나 PLC의 경우에는 주어진 태스크 이외에는 다른 것은 하지 않기 때문에 그렇게 높을 이유가 없습니다.  단지 지금은 규모가 상당히 큰 이유로 CPU 부하가 높을 수는 있습니다.  그래서 의도적으로 CPU의 부하를 줄여버리면 그만큼 성능이 낮아지거나 또는 덜 중요한 프로세스가 스케쥴링에서 빠져 버리겠지요.  아마도 그러한 이유로 통신이 되지 않은 것 같습니다.  이럴 때는 CPU를 증설하셔서 CPU의 부하를 낮추시는 것이 중요합니다.   두번째는 Page Scan Time을 조정해 보셨는데, 이는 별 도움이 되지 않습니다.  나중에 설명하겠지만 통신의 Scan Time은 드라이버 파라미터에서 설정을 합니다.    그럼 통신을 최적화 할 수 있는 방법을 하나씩 알아보도록 하겠습니다.   Step1. PLC의 System Overhead Time Slice를 더 높은 값으로 설정합니다. 이 부분은 정남이 님께서 생각하신 것과는 반대로 적용해야 합니다.  지금 CPU가 할 일이 많기 때문에 System Overhead Time Slice 값은 최대로 주셔야 합니다.  물론 이런 경우 PLC의 수명은 단축될 수는 있겠지만 지금 당장은 CPU로 하여금 최대로 동작하도록 설정해야 합니다.(Controllogix programming software > controller 우클릭 > Controller Properties > Advanced tab 에서 설정)   Step2. Variable.dbf를 IODevice, Data Type 순으로 소팅을 합니다. Tag 기반의 통신 시스템에서는 항상 권장되는 방법입니다.  PLC 장치 별로, 그리고 PLC에 대해서도 데이터 타입별로 소팅을 함으로써 PLC와 어느정도 블록 통신이 가능하게 됩니다.   Step3. BAD Tag는 없도록 합니다. IOServer 커널에서는 드라이버 페이지에서 ABCLX 드라이버로 이동한 다음 "v"(verbose) 키를 눌러 "Bad Tag"가 있는지 확인할 수 있습니다.  만약 Bad Tag가 있다면 ABCLX 드라이버의 로깅 파라미터를 사용하여 그 태그를 찾으시면 됩니다.  드라이버 저옵 로깅하는 방법은 ABCLX 도움말을 참조하시기 바랍니다. (유용한 내용이 많으므로 꼭 드라이버 도움말을 모두 읽어 보실 것도 권장하여 드립니다.)  참고로 파라미터 설정하는 방법은 citect.ini 파일에    [ABCLX]    DebugLevel=WARN|ERROR|TRACE    DebugCategory=ALL 이라고 입력하고 런타임을 기동하시면 됩니다.  이렇게 해서 "Bad Tag" 및 "Tag Config Warnings"를 완전히 없애셔야 합니다.   Step4. 드라이버 Scan Time을 조정합니다. citect.ini 파일에서 [ABCLX]ScanRate=500 파라미터의 값을 조정합니다.  디폴트는 500ms로 되어 있는데 최소 100ms까지 줄일 수 있으며, 반대로 최대 30000ms까지 늘릴 수 있습니다.  빠른 통신 성능을 원할 때는 줄여야 겠지만 CPU의 성능을 고려할 때는 이 값을 늘려야 합니다.  대신 데이터 업데이트 속도는 느려지겠지요.  통신 파라미터를 조정하실 때는 Timeout, Retry 등도 고려하셔야 하므로 ABCLX 도움말을 읽어 보신 후 조정하시기 바랍니다.  테스트하실 때는 2배씩 늘려보셔도 될 것 같습니다.   Step5. Polling 상태의 확인 위에서 통신 파라미터도 조정하였고, Bad Tag및 Warning Tag들을 모두 제거하였기 때문에 Polling이 제대로 되고 있는지 확인할 필요가 있습니다.  이것은 IOServer 커널에서 Driver 창에서 "v"를 눌러 Verbose모드로 보면 아래의 값들이 표시되는데 아래의 값들로 표시되는지를 확인하시면 됩니다.    Session Thread State = 2    Session State = 4    Socket Thread State = 2   Step6. [ABCLX]ForwardOpenPoolSize 파라미터 값 조정 이 파라미터의 기본 값은 4인데 조금씩 늘려 보시기 바랍니다  이값을 늘리면서 Group Average Poll Time도 같이 확인하셔야 합니다.  이 파라미터의 값을 늘리면 Group Average Poll Time 값이 조금씩 줄어들 수 있는데, 그 줄어드는 영향이 크지 않을 때가지 조정하는 것입니다.   Step7. 모든 Bit를 사용하도록 설계 Allen Bradley protocol은 1개의 비트도 바이트 단위로 처리하도록 되어 있습니다.  그래서 PLC에서 digital들을 분산시켜 놓으면 많은 데이터 통신 부하를 초래하게 됩니다.  반면에 바이트의 모든 비트를 HMI Tag로 사용하면 그만큼 통신 향상에 도움을 줄 것입니다.    예)   PLC Tag Alias Name          Address         Type           Tag1_Bit0                           Tag1/0           Digital           Tag1_Bit1                           Tag1/1           Digital           Tag1_Bit2                           Tag1/2           Digital           Tag1_Bit3                           Tag1/3           Digital           Tag1_Bit4                           Tag1/4           Digital           Tag1_Bit5                           Tag1/5           Digital           Tag1_Bit6                           Tag1/6           Digital           Tag1_Bit7                           Tag1/7           Digital   Step8. 최적화 프로그래밍 기술 적용하기 AB의 KnowledgeBase 글 중에 'A54732518 - Optimizing a ControlLogix redundancy System, Programming Guidelines and Case Study'를 보시면 잘 나와 있는데, 이 글을 보면 다른 최적화 프로그래밍 기술 글들도 있는 것 같습니다.  이와 관련된 내용들은 AB에 요청하시면 받으실 수 있을 것입니다.  이 글을 요약하면 데이터 타입 정렬하는 방법을 타입별로 하라는 것입니다.  예를 들어 아래와 같은 데이터 타입 정의는 좋지 못합니다.    DATATYPE Sample1       BOOL Bit1;       SINT Tiny_Value;       BOOL Bit2;       INT Small_Value;       DINT Big_Value;       REAL Float_Value;    END_TYPE   보시면 정의 자체는 문제가 없지만 타입별로 정리가 안되어 있습니다.  이를 타입별로 정리하면 다음과 같이 됩니다.    DATATYPE Sample1       BOOL Bit1;       BOOL Bit2;       SINT Tiny_Value;       INT Small_Value;       DINT Big_Value;       REAL Float_Value;    END_TYPE   너무나도 간단하고 별로 중요한 것 같지는 않아 보이지만 사실은 아주 중요한 내용입니다.  왜냐하면 아주 사소한 것이라도 누적이 되면 아주 크기 때문입니다.  한 라인 한 라인이 100% 최적화된 프로그래밍을 할 수 있도록 노력해야 합니다. 만약 99%로 최적화된 라인을 100줄 작성하면 (0.99 * 0.99 * 100번 = 1.99^100 = 0.366 = 36.6%) 36.6%의 효율밖에 발휘하지 못하게 되기 때문입니다.   일단 가능한 방법은 모두 설명 드렸습니다.  이걸로 얼마나 최적화 시킬 수 있을 지는 모르겠습니다.  제 경험상 90년대 초 Ethernet 통신이 지원되지 않을 시절, RS-232C(19,200bps) 1개의 포트로 3,000개의 태그를 1초 업데이트를 성공한 적이 있었습니다.  일반적으로는, 아니 계산적으로도 도저히 나올 수 없는 성능이었지만 무진장 최적화를 하다 보니까 가능하더라구요.  하지만 이것은 결코 좋은 방법은 아닙니다.  초기 PLC와 PC 통신 설계부터가 잘못되어 있던 것이기 때문에 이것을 바로잡아야 했었습니다.  잘못된 설계 때문에 개발자만 엄청 고생하거든요.  아무튼 어려운 일인 것 같습니다.  혹시 잘 해결되시면 그 과정과 해결 방법도 공유해 주시면 감사하겠습니다.