@mark-lazarides @Roald87 @philippleidig @jozefchmelar 여기에서 관례에 대한 논의를 계속합시다... 빠른 채팅을 위한 여유를; 활동을 추적하기 위해 여기에서 토론

• 내 생각에 속성은 "IsEnabled"와 같이 정의되어야 합니다. 이름 자체는 이미 어떤 유형인지 표시해야 합니다.

• 부울로 메서드의 반환 값을 좋아합니다. 더 복잡한 데이터 유형은 외부에서 인스턴스화하거나 참조로 반환되어야 하기 때문에 부적절합니다.

• Inxton 또는 tc.prober를 사용하려면 "fbComponent"의 각 기본 클래스의 상속이 필요합니까?

• 유형 이름 지정과 관련하여 저는 개인적으로 약간 급진적이며 일반적으로 접두사를 생략합니다. 인터페이스, 참조 및 포인터는 제외합니다.
  예

  유형 명명

| 블록형 | 표기 | 접두사 | 예 |
| :---------------- | :------------ | :------------ | :---------------------------------------------------------------- -- |
| FB/클래스 이름 | 파스칼케이스 |아니요 | Cyclinder |
| ENUM 유형 이름 | 파스칼케이스 |아니요 | MachineState.Start |
| 인터페이스 이름 | 파스칼케이스 | I | ICyclinder |
| 기능 이름 | 파스칼케이스 |아니요 | Add() |
| STRUCT 이름 | 파스칼케이스 | 아니오 | Data |
| 유니온 이름 | 파스칼케이스 | 아니오 | Control |

@philippleidig

• 내 생각에 속성은 "IsEnabled"와 같이 정의되어야 합니다. 이름 자체는 이미 어떤 유형인지 표시해야 합니다.

전적으로 동의.

• 부울로 메서드의 반환 값을 좋아합니다. 더 복잡한 데이터 유형은 외부에서 인스턴스화하거나 참조로 반환되어야 하기 때문에 부적절합니다.

구성 요소에 설명된 대로 사용합니다. 시퀀스의 상태를 제어할 때 유용합니다. 대부분의 경우 bool이면 충분합니다. 때로는 메서드의 상태에 대해 더 많은 정보를 알고 싶을 때가 있습니다... 그러나 이것은 더 넓은 논의가 필요할 것입니다(somethig와 같은 유창한 구문일 수 있음)

• Inxton 또는 tc.prober를 사용하려면 "fbComponent"의 각 기본 클래스의 상속이 필요합니까?

아니요. Inxton이나 tc.prober에 대한 특정 요구 사항은 없습니다. 우리는 이것을 이런 식으로 사용합니다. ComponentBase 는 일부 공개 계약(수동 메서드 등)이 있는 추상 클래스이지만 구성 요소에 대한 몇 가지 공통 기능을 구현할 수 있습니다. 나는 상속에 대한 열렬한 팬은 아니지만 (나는 작곡을 선호합니다), 이 경우에는 미래를 위해 몇 가지 옵션을 열고 싶습니다.

inxton에서 컬렉션의 모든 구성 요소를 수집하려면 something is copmonent 에 대한 메커니즘이 있을 때 그렇게 할 수 있습니다.

또 다른 이유가 있습니다. 우리는 요즘 몇 가지 요구 사항이 있는 기본 라이브러리를 공개하는 작업을 하고 있습니다. 다음주에 뭔가 나올 수 있기를 바랍니다. 자세한 내용을 알려드립니다.

• 유형 이름 지정과 관련하여 저는 개인적으로 약간 급진적이며 일반적으로 접두사를 생략합니다. 인터페이스, 참조 및 포인터는 제외합니다.
  예

유형 명명

블록 유형 표기법 접두사 예
FB/CLASS 이름 PascalCase No Cyclinder
ENUM 유형 이름 PascalCase No MachineState.Start
인터페이스 이름 PascalCase I ICyclinder
기능 이름 PascalCase No Add()
STRUCT 이름 PascalCase 아니오 Data
UNION 이름 PascalCase No Control

접두사도 좋아하지 않습니다. 테이블은 우리가 사용하는 접두어 체계와 비슷하지만... 다시 제거하기로 결정하면 저를 기쁘게 할 것입니다.

대부분의 경우 접두사를 사용하면 이점이 없습니다. @philippleidig 의 제안에 동의합니다.

포인터와 참조는 예외라고 말하고 싶습니다.

PR #5에서 내 컨벤션을 제안했습니다.

멤버 네이밍 & 타입 네이밍

접두사를 사용하면 이점이 없습니다. 그것은 어떤 식 으로든 나에게 도움이되지 않습니다.

멤버 변수

클래스(FB) 멤버 변수는 숨겨지고 작은 이름으로 시작해야 합니다.
~파스칼VAR{속성 '숨기기'}트리거: BOOL;{속성 '숨기기'}카운터 : INT;{속성 '숨기기'}아날로그 상태: 아날로그 상태;END_VAR~

@jozefchmelar

대부분의 경우 접두사를 사용하면 이점이 없습니다. @philippleidig 의 제안에 동의합니다.

포인터와 참조는 예외라고 말하고 싶습니다.
👍
PR #5에서 내 컨벤션을 제안했습니다.

멤버 네이밍 & 타입 네이밍

접두사를 사용하면 이점이 없습니다. 그것은 어떤 식 으로든 나에게 도움이되지 않습니다.
👍👍

멤버 변수

클래스(FB) 멤버 변수는 숨겨지고 작은 이름으로 시작해야 합니다.

    VAR
        {attribute 'hide'}
        trigger : BOOL;
        {attribute 'hide'}
        counter : INT;
        {attribute 'hide'}
        analogStatus : AnalogStatus;
    END_VAR

• 숨겨진 변수는 광고 위에 표시되지 않으므로 HMI에서 필요하지 않은 경우 숨길 수 있습니다. 그러나 HMI에서 볼 필요가 있는 경우 'hide' 속성을 사용하지 않아야 합니다.
• Tc3은 대소문자를 구분하지 않으므로 trigger (변수 이름) 및 Trigger (속성 이름)이 충돌합니다. 제안된 대로 _ 접두사를 붙여야 합니다.

완전 공감 👍

"conditionalshow" 속성도 있습니다. 그러나 이것은 컴파일된 라이브러리와 함께만 사용할 수 있습니다.
https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/8095402123.html &id=7685156034373049758
나는 우리가 개방형 라이브러리를 제공할 것이라고 가정하기 때문에 이것은 제한된 의미만 있을 것입니다.

@PTKu 가 말했듯이 멤버 변수의 접두사로 _ 가 필요합니다.

나는 일반적으로 C#의 명명 규칙과 이름 선택을 고수하는 것을 좋아합니다.

부울로 메서드의 반환 값을 좋아합니다. 더 복잡한 데이터 유형은 외부에서 인스턴스화하거나 참조로 반환되어야 하기 때문에 부적절합니다.

@philippleidig 반환 값은 무엇을 의미합니까? 이 경우 오류 검사로 사용됩니까? 일반적으로 반환 값은 메서드에 따라 다릅니다. CalculcateArea 는 REAL `LREAL`을 반환합니다.

제안된 변수 이름에 전적으로 동의합니다!

부울로 메서드의 반환 값을 좋아합니다. 더 복잡한 데이터 유형은 외부에서 인스턴스화하거나 참조로 반환되어야 하기 때문에 부적절합니다.

@philippleidig 반환 값은 무엇을 의미합니까? 이 경우 오류 검사로 사용됩니까? 일반적으로 반환 값은 메서드에 따라 다릅니다. CalculcateArea 는 REAL``LREAL 를 반환합니다.

@Roald87 아이디어는 작업을 수행하는 구성 요소의 메서드가 작업이 완료되면 'true'를 반환한다는 것입니다(홈 센서/위치에 도달하면 MoveToHome()). 이것은 필요할 때 다른 반환 유형을 방지하지 않습니다.

제안된 변수 이름에 전적으로 동의합니다!

배열에 대한 제안이 있습니다. 0을 기반으로 하는 배열만 트랜스-파일링하는 inxton 컴파일러에 대한 공식적인 요구 사항이 있습니다. 그 이유는 C#에서 사용할 때 혼동을 방지하기 위함입니다.

_array : ARRAY[0..10] OF BOOL; // 트랜스 파일
동안
_array : ARRAY[1..10] OF BOOL; // 트랜스파일을 하지 않는다

이에 대한 의견이 있으십니까?

TwinCAT HMI(TE2000)와 동일

TwinCAT HMI(TE2000)와 동일

HMI와 동기화된 어레이가 있으면 매우 편리할 것입니다!

@philippleidig || @Roald87 은 배열에 대한 PR 규칙 중 하나라면 pls... 리포지토리에서 더 많은 기여자를 보고 싶습니다. :).

배열에 대한 제안이 있습니다. 0을 기반으로 하는 배열만 트랜스-파일링하는 inxton 컴파일러에 대한 공식적인 요구 사항이 있습니다. 그 이유는 C#에서 사용할 때 혼동을 방지하기 위함입니다.

_array : ARRAY[0..10] OF BOOL; // 트랜스 파일
동안
_array : ARRAY[1..10] OF BOOL; // 트랜스파일을 하지 않는다

이에 대한 의견이 있으십니까?

구조화된 텍스트 루핑이 작동하는 방식 때문에 저는 PLC 어레이의 치수를 1..X로 유지하는 것을 선호합니다. 결과적으로 코드는 PLC의 모든 곳에서 읽기 쉽습니다. PLC에서 항상 매력적이고 유지 관리 가능한 코드를 작성해야 한다고 생각합니다. 타사 코드에서 더 잘 작동하도록 shim이 필요한 경우 별도로 관리할 수 있습니다.

// Declaration
NUMBER_OF_DRIVES : INT := 10;
drives  : ARRAY[1..NUMBER_OF_DRIVES] OF I_Drive;

// now in the code
FOR i := 1 to NUMBER_OF_DRIVES DO
   drives[i].SomethingCool();
END_FOR

// Compared to

// Declaration
drives : ARRAY[0..(NUMBER_OF_DRIVES -1) ] OF I_Drive;
// Code
FOR i := 0 to (NUMBER_OF_DRIVES -1) DO
   drives[i].SomethingCool();
END_FOR

부울로 메서드의 반환 값을 좋아합니다. 더 복잡한 데이터 유형은 외부에서 인스턴스화하거나 참조로 반환되어야 하기 때문에 부적절합니다.

메서드는 메서드에 대해 합리적인 것을 반환해야 한다고 생각합니다. 메소드의 이름은 이를 이해하는 데 도움이 됩니다.

즉

IF NOT piece.PassesValidation() THEN
 LogError('Piece does not pass validation');
END_IF

// OR

IF sequence.Finished THEN
  axis.Disable(); // No return type necessary.
  state := WaitForAxisDisabled;
END_IF

@Roald87 아이디어는 작업을 수행하는 구성 요소의 메서드가 작업이 완료되면 'true'를 반환한다는 것입니다(홈 센서/위치에 도달하면 MoveToHome()). 이것은 필요할 때 다른 반환 유형을 방지하지 않습니다.

나는 public 메소드를 반복적으로 호출하는 접근 방식을 정말로 좋아하지 않습니다. 여기서 메소드는 올바른 결과를 반환할 때까지 기능을 반복적으로 실행합니다. 내가 생각하기에 받아들일 수 있는 한 가지 경우가 있습니다(인터페이스에 "실행" 유형 메소드가 있지만 작동하는 더 나은 방법도 있다고 생각합니다).

그것의 문제점;

• 동시에 호출할 수 있는 클래스에서 실행 경로를 생성할 수 있습니다. 즉

atEnd :=  axis.GoToEnd();
atBeginning := axis.GoToBeginning();

• 클래스는 내부적으로 상태를 관리해야 합니다. 메서드를 사용하여 해당 상태를 요청하고 수정할 수 있으며 속성을 사용하여 상태에 액세스하거나 간단한 상태를 설정할 수도 있습니다.
• 어떻게 그리고 왜 그런 식으로 사용되는지 명확하도록 메서드의 이름을 어떻게 지정합니까? axis.GoToEndTrueWhenComplete()?
• 호출이 실행되는 방식을 수정하는 방식으로 클래스의 기본 상태가 변경되면 어떻게 될까요?
• 경쟁 조건을 더 쉽게 생성할 수 있습니다. 무언가에 대해 .Enable()을 반복적으로 호출하지만 단일 스캔에 대해 오류가 발생하면 .Enable()은 "완료될 때까지 계속 호출" 접근 방식을 사용하여 어쨌든 활성화할 수 있습니다. 이는 대신 .RequestEnable : BOOL이어야 합니다. 이는 요청 지점의 기본 조건이 올바른지 여부를 나타냅니다(호출 코드가 해당 지점에서 정상적으로 폴백되도록 허용). 요청이 이루어질 수 있으면 호출 코드는 완료를 위해 .IsEnabled 및 .InError를 모니터링할 수 있습니다.

@philippleidig 는 TwinCAT HMI에 익숙하지 않습니다. 0이 아닌 기반 배열은 어떻게 처리됩니까?

@mark-lazarides

메서드는 메서드에 대해 합리적인 것을 반환해야 한다고 생각합니다. 메소드의 이름은 이를 이해하는 데 도움이 됩니다.
👍

동시성 및 경쟁 조건은 모두 합리적인 문제입니다. IMHO 이러한 문제는 구성 요소 수준에서 가능한 한 많이 해결되어야 하지만 구성 요소를 소비할 때 조정 수준에서 더 중요합니다. 구성 요소 메서드는 구성 요소의 동일한 인스턴스에서 충돌하는 메서드의 동시 호출을 방지하는 적절하게 구현된 상태 컨트롤러와 유사한 기본 요소(단순한 CASE, IF, ELSIF 또는 더 복잡한 시퀀서/선택기/반복자) 내에서 호출되어야 합니다. .

구성 요소의 소비자 코드에서 이와 같은 것을 방지해야 합니다.
~atEnd := axis.GoToEnd();atBeginning := axis.GoToBeginning();~

executing methods 완료 시 true $를 반환하면 깨끗한 선언적 사용이 가능합니다.

내가 염두에 둔 것은 다음과 같습니다.

~~~
VAR
_상태 : INT;

END_VAR

CASE _상태
0:
IF(axis.MoveAbsolute(위치: 100.0)) THEN
_상태 := 1;
END_IF;
1:
IF(axis.MoveRelative(위치: 100.0)) THEN
_상태 := 2;
END_IF;
2:
IF(axis.MoveAbsolute(위치: 300.0)) THEN
_상태 := 3;
END_IF;
삼:
_상태 := 0;
END_CASE
~~~

이것은 다음으로 줄일 수 있습니다.

~~~
VAR
_상태 : INT;

END_VAR

CASE _상태
0:
Await(axis.MoveAbsolute(위치: 100.0),1);
1:
대기(axis.MoveRelative(위치: 100.0),2);
2:
Await(axis.MoveAbsolute(위치: 300.0),3);
삼:
대기(참, 0);

END_CASE

=====================================

방법 대기
VAR_INPUT
완료 : BOOL
다음 상태: INT;
END_VAR
IF (완료) THEN
_state := 다음 상태;

END_IF;

~~~
편집: 구성 요소가 단일 PLC 작업에서 사용된다고 가정합니다.

코드 소비에 제약을 가합니다. 소비자가 잘못된 순서로 구성 요소를 사용하는 경우 당사 구성 요소는 오류에 대한 책임을 지지 않습니다. 그들은 모든 상호 작용에 잘 반응해야 합니다. 그것들은 반드시 "작동"하지 않을 것입니다(즉, $#$ axis.Enable() res := axis.MoveTo(Position:=100); 를 호출하면 작동하지 않을 것입니다). 그러나 소비하는 코드에는 문제가 발생한 위치를 이해하기 위해 모든 지점에서 충분한 정보가 제공되어야 합니다.

나에게도 여전히 잘 읽히지 않는다. axis.MoveAbsolute(syx)를 읽을 수 없으며 주기적으로 호출해야 함을 이해합니다. 우리의 관용적 스타일이 당신에게 필요하다는 것을 알고 그 시점에서 우리가 매우 유용한 것을 만드는 데 실패했다고 생각하는 경우에만 이해하실 것입니다.

나는 또한 오류를 제외할 수 있는지 여부에 관계없이 오류가 발생할 가능성이 더 높다고 말하고 싶습니다. 순환 메서드 호출 접근 방식을 사용하면 객체의 상태를 호출할 준비가 되었는지 확인하는 메서드를 만든 다음 순환 메서드를 호출한 다음 객체의 다른 상태를 모니터링하여 중간에 아무 일도 일어나지 않았는지 확인할 수 있습니다. 또는 성공 여부를 알려주는 요청을 만든 다음 완료 상태를 모니터링합니다. 원하는 경우 요청의 일부로 이에 대한 콜백을 등록할 수 있습니다. 이는 이에 대한 적절한 OO 접근 방식이며 주기적으로 더 많은 호출/질문을 줄이는 것입니다.

@mark-lazarides 맞습니다! 나는 execute methods (이런 식으로 부르자) 순환 논리를 구현해서는 안됩니다. 이전에 논의한 내용을 순환 방식으로 실행해야 하는 항목이 FB의 본문이나 Cyclic 메서드에 배치되도록 보장한다고 가정했습니다. 소비자 프로그램의 적절한 위치에서 호출되어야 합니다.

좋아요. 그렇다면 왜 우리는 주기적으로 메서드를 호출할까요? 나는 여전히 원래의 주장이 유효하다고 생각합니다. 메서드는 하나의 작업을 수행해야 합니다. 무언가를 시작하거나(따라서 그 성공을 보고하거나) 무언가를 얻고 반환합니다.

좋아요. 그렇다면 왜 우리는 주기적으로 메서드를 호출할까요? 나는 여전히 원래의 주장이 유효하다고 생각합니다. 메서드는 하나의 작업을 수행해야 합니다. 무언가를 시작하거나(따라서 그 성공을 보고하거나) 무언가를 얻고 반환합니다.

이의 없음 마크, 실행 메서드를 주기적으로 호출할 필요는 없지만 그렇게 하면 문제가 되지 않습니다.

메서드가 작업 결과를 반환할 수 없는 이유를 알 수 없습니다.

좀 더 복잡한 구성 요소를 생각해내고 이러한 아이디어의 프로토타입을 만들어야 한다고 생각합니다(공압 피스톤은 이 논의에서 충분히 복잡하지 않습니다). 구동/축으로 시작할 수 있다고 생각합니다.

동의합니다, 피터.

스레드 이름 때문에 이것을 컨벤션으로 노리고 있다고 생각했습니다! 제가 잘못 이해했다면 사과드립니다.

Chris는 현재 PR로 기본 축 블록을 가지고 있습니다. 이에 대해 언급했지만 더 많은 관심이 필요합니다.

@mark-lazarides 사과 필요없어요 마크, 자유롭게 토론하러 왔어요, 내일 홍보 좀 할게요...

@philippleidig @Roald87 @dhullett08 부품 설계에 대한 논의도 여기에서

PLCopen 문서에서 가져온 몇 가지 무작위 제안.

plcopen_coding_guidelines_version_1.0.pdf

상수
쉽게 식별할 수 있도록 ALLCAPS로 작성해야 합니다.

허용되는 이름 길이
최소 4자 최대 24자?

PLCopen 문서에서 가져온 몇 가지 무작위 제안.

plcopen_coding_guidelines_version_1.0.pdf

링크 주셔서 감사합니다

상수
쉽게 식별할 수 있도록 ALLCAPS로 작성해야 합니다.

👍

허용되는 이름 길이
최소 4자 최대 24자?

더 긴 이름은 의도를 표현할 때까지 문제가 되지 않아야 하며 24자로 충분해야 하지만 최대 제한은 두지 않습니다. 문자. 너무 짧은 이름은 실제로 의심스럽습니다. 4자 이상이어야 합니다.

@Seversonic 귀하의 의견이 문서에 추가되었습니다...

토론 계속 여기 #11

나는 당신의 컨벤션이 정말 마음에 들지 않지만 당신의 프로젝트는 꽤 흥미롭다고 생각합니다!
개인적으로 나는 더 고전적인 방법을 선호합니다
FB_ fb 기능 블록
M_Add() 메서드
P_Parameter 소품

안녕하세요, @PeterZerlauth 와 감사합니다. 우리는 PLC와 고전적인 소프트웨어 엔지니어링의 중간 단계에 있기 때문에 규칙에 동의하는 것은 약간 힘든 일입니다.

토론 초기에 실시한 설문조사는 다음과 같습니다.

TcOpen.Survey.Result.pdf

그 외에도 여기와 Slack 채널에서 토론이 있었고 @dhullett08 TcOpen repo에도 뭔가 있을 수 있습니다.

접두사가 유용한 정보를 제공하지 않거나 현대 IDE가 과거 접두사로 전달했던 정보를 제공하는 경우 접두사를 포기해야 한다는 일반적인 느낌이 있었습니다(또는 적어도 저는 그렇게 해석합니다).

나는 이것이 개인적인 취향에 관한 것이며 실제로 옳고 그른 방법이 없다는 것을 이해합니다. 다만 우리는 무언가에 동의해야 합니다.

여기에서 토론을 마치며 여기에서 계속됩니다: https://github.com/TcOpenGroup/TcOpen/discussions/11