@ mark-lazarides @ Roald87@ philippleidig @ jozefchmelarここでコンベンションについての議論を続けましょう...簡単なチャットのためのたるみ。 活動を追跡するためのここでの議論

• 私の意見では、プロパティは次のように定義する必要があります「IsEnabled」。 名前自体は、それがどのタイプであるかをすでに示しているはずです。

• メソッドの戻り値はブール値として気に入っています。 より複雑なデータ型は、外部でインスタンス化するか、参照によって返す必要があるため、不適切だと思います。

• Inxtonまたはtc.proberを使用するには、「fbComponent」の各基本クラスの継承が必要ですか？

• タイプの命名に関しては、私は個人的に少し過激で、一般的にプレフィックスを省略しています。 インターフェイス、参照、およびポインタを除きます。
  例えば

  タイプネーミング

| ブロックタイプ| 表記| プレフィックス| 例|
| ：------------- | ：--------- | ：------------ | ：------------------------------------------------- -|
| FB/CLASS名| PascalCase|いいえ| Cyclinder |
| ENUMタイプ名| PascalCase|いいえ| MachineState.Start |
| インターフェース名| PascalCase | I | ICyclinder |
| 関数名| PascalCase|いいえ| Add() |
| STRUCT名| PascalCase | いいえ| Data |
| UNION名| PascalCase | いいえ| Control |

@philippleidig

• 私の意見では、プロパティは次のように定義する必要があります「IsEnabled」。 名前自体は、それがどのタイプであるかをすでに示しているはずです。

完全に同意します。

• メソッドの戻り値はブール値として気に入っています。 より複雑なデータ型は、外部でインスタンス化するか、参照によって返す必要があるため、不適切だと思います。

コンポーネントで説明したように使用します。 シーケンスの状態を制御するときに便利です。 ほとんどの場合、ブール値で十分です。 メソッドの状態についてより多くの情報があればいい場合もあります...しかし、これにはより広い議論が必要になります（多分流暢-何かのような構文）

• Inxtonまたはtc.proberを使用するには、「fbComponent」の各基本クラスの継承が必要ですか？

いいえ。そのための特定の要件も、Inxtonもtc.proberもありません。 このように使用します。 ComponentBaseは、いくつかのパブリックコントラクト（手動メソッドなど）を持つ抽象クラスですが、コンポーネントにいくつかの一般的な機能を実装できます。 私は継承の大ファンではありませんが（私は作曲が好きです）、この場合、将来のためにいくつかのオプションを開いてもらいたいと思います。

inxtonでは、コレクション内のすべてのコンポーネントを収集する場合、 something is copmonentにそのためのメカニズムがあるときにそれを行うことができます。

それには別の理由もあります。 私たちは今日、いくつかの要件があるベースライブラリのオープンソーシングに取り組んでいます。 来週何かを思いつくことができるといいのですが。 詳細をお知らせします。

• タイプの命名に関しては、私は個人的に少し過激で、一般的にプレフィックスを省略しています。 インターフェイス、参照、およびポインタを除きます。
  例えば

タイプネーミング

ブロックタイプ表記プレフィックスの例
FB /CLASS名PascalCaseいいえCyclinder
ENUMタイプ名PascalCaseいいえMachineState.Start
インターフェース名PascalCase I ICyclinder
関数名PascalCaseいいえAdd()
構造体名PascalCaseいいえData
UNION名PascalCaseいいえControl

プレフィックスのファンでもありません。 この表は、私たちが使用しているプレフィックスのシステムに似ています...しかし、それを取り除くことにした場合、私はただ幸せになります。

ほとんどの場合、プレフィックスを使用してもメリットはありません。 @philippleidigの提案に同意します。

ここでは、ポインタと参照は例外だと思います。

私はPR＃5で自分の大会を提案しました

メンバーの命名とタイプの命名

プレフィックスを使用してもメリットはありません。 それは私には何の助けにもなりません。

メンバー変数

クラス（FB）メンバー変数は非表示にし、小さい名前で始める必要があります
〜パスカルVAR{属性'非表示'}トリガー：BOOL;{属性'非表示'}カウンター：INT;{属性'非表示'}analogStatus：AnalogStatus;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は配列とplsについてのPRコンベンションのいずれかです...私はちょうどリポジトリでより多くの貢献者を見るのが好きです:)。

配列についての提案があります。 0ベースの配列のみをトランスパイルするinxtonコンパイラの正式な要件があります。 その理由は、C＃で使用する場合の混乱を防ぐためです。

_array：ARRAY [0..10] OF BOOL; //トランスパイル
その間
_array：ARRAY [1..10] OF BOOL; //トランスパイルしません

これについて何かコメントはありますか？

構造化テキストのループが機能する方法のために、私はPLC配列の寸法を1..Xに保つことを好みます。 その結果、コードはPLCのどこでも読みやすくなります。 PLC上で常に魅力的で保守しやすいコードを書くべきだと思います。 サードパーティのコードでより適切に機能させるためにシムが必要な場合は、それを個別に管理できます。

// 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（））。 これにより、必要に応じて他の返品タイプが妨げられることはありません。

パブリックメソッドを繰り返し呼び出すというアプローチは本当に好きではありません。そのメソッドは、正しく返されるまで機能を繰り返し実行します。 受け入れられると思うケースが1つあります（インターフェイスに「Execute」タイプのメソッドがある場合でも、それを機能させるためのより良い方法もあると思います）。

それに関する問題;

• 同時に呼び出すことができるクラスで実行パスを作成することができます/作成しています。 つまり

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

• クラスは、その状態を内部で管理する必要があります。 メソッドを使用して、その状態の要求と変更を行うことができます。また、プロパティを使用して、ステータスにアクセスしたり、単純な状態を設定したりすることもできます。
• メソッドにどのように名前を付けて、そのように使用されているのか、なぜ使用されているのかを明確にしますか？ axis.GoToEndTrueWhenComplete（）？
• クラスの基礎となる状態が、呼び出しの実行方法を変更する方法で変更された場合はどうなりますか？
• 競合状態をより簡単に生成できます。 何かに対して.Enable（）を繰り返し呼び出すが、1回のスキャンでエラーが発生した場合、.Enable（）は、「完了するまで呼び出しを続ける」アプローチを使用して、とにかく有効にすることができます。 代わりに、これは.RequestEnable：BOOLである必要があります。これは、要求の時点での基本的な条件が正しいかどうかを示します（呼び出し元のコードがその時点で正常にフォールバックできるようにします）。 要求を行うことができる場合、呼び出し元のコードは.IsEnabledと.InErrorの完了を監視できます。

@philippleidigはTwinCATHMIに精通していません。 非0ベースの配列はそこでどのように処理されますか？

@ mark-lazarides

メソッドは、そのメソッドにとって合理的なものを返す必要があると思います。 メソッドの名前は、それを理解するのに役立つはずです。
👍

並行性と競合状態はすべて合理的な懸念事項です。 IMHOこれらの問題は、コンポーネントのレベルで可能な限り対処する必要がありますが、より重要なのは、コンポーネントを消費する際の調整のレベルで対処する必要があります。 コンポーネントメソッドは、適切に実装された状態コントローラーのようなプリミティブ（単純なCASE、IF、ELSIF、またはより複雑なシーケンサー/セレクター/イテレーター）内から呼び出す必要があります。これにより、コンポーネントの同じインスタンスの競合するメソッドの同時呼び出しが防止されます。 。

このようなことは、コンポーネントのコンシューマーコードで防止する必要があります
〜atEnd：= axis.GoToEnd（）;atBeginning：= axis.GoToBeginning（）;〜

完了するとtrue executing methodsは、クリーンな宣言型の使用を可能にします。

私が念頭に置いているのは、次のようなものです。

~~~
VAR
_state：INT;

END_VAR

CASE _state OF
0：
IF（axis.MoveAbsolute（Position：100.0））THEN
_state：= 1;
END_IF;
1：
IF（axis.MoveRelative（Position：100.0））THEN
_state：= 2;
END_IF;
2：
IF（axis.MoveAbsolute（Position：300.0））THEN
_state：= 3;
END_IF;
3：
_state：= 0;
END_CASE
~~~

これはに減らすことができます

~~~
VAR
_state：INT;

END_VAR

CASE _state OF
0：
Await（axis.MoveAbsolute（Position：100.0）、1）;
1：
Await（axis.MoveRelative（Position：100.0）、2）;
2：
Await（axis.MoveAbsolute（Position：300.0）、3）;
3：
Await（true、0）;

END_CASE

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

方法を待つ
VAR_INPUT
完了：BOOL
nextState：INT;
END_VAR
IF（完了）THEN
_state：= nextState;

END_IF;

~~~
編集：コンポーネントは単一のPLCタスクで使用されていると思います

それはコードの消費に制約を課します。 消費者がそれらを間違った順序で使用した場合、当社のコンポーネントはエラーの責任を負わないはずです。 彼らはすべての相互作用にうまく反応するはずです。 それらは必ずしも「機能」する必要はありません（つまり、 axis.Enable()が機能しない前に$ res := axis.MoveTo(Position:=100);を呼び出す）が、消費するコードには、問題が発生する場所を理解するためにすべてのポイントで十分な情報を提供する必要があります。

それでも私にはよく読めません。 axis.MoveAbsolute（syx）を読み取って、周期的に呼び出す必要があることを理解することはできません。 私たちの慣用的なスタイルがあなたのスタイルを必要としていることを知っていれば、あなたは理解するでしょう。その時点で、私たちは非常に使いやすいものを作成できなかったと思います。

また、エラーを除外できるかどうかに関係なく、エラーが発生する可能性が高くなります。 循環メソッド呼び出しアプローチを使用すると、オブジェクトの状態を呼び出す準備ができているかどうかを確認するメソッドを作成してから、循環メソッドを呼び出し、オブジェクトの他の状態を監視して、その間に何も起こらなかったことを確認できます。 または、成功したかどうかを通知するリクエストを作成してから、ステータスの完了を監視します。 必要に応じて、リクエストの一部としてそのコールバックを登録できます。これは、これに対する適切なオブジェクト指向アプローチであり、より多くの呼び出し/問い合わせを周期的に減らします。

@ mark-lazarides正解です！ 私はexecute methods （そのように呼びましょう）は循環ロジックを実装するべきではありません。 私は以前に議論したことを、循環的に実行する必要があるものがFBの本体またはCyclicメソッドのいずれかに配置されることを保証すると仮定しました。 これは、消費者プログラムの適切な場所で呼び出す必要があります。

わかった。 では、なぜこのメソッドを周期的に呼び出すのでしょうか。 私はまだ元の議論が立っていると思います。 メソッドは1つのジョブを実行する必要があります。 何かを開始する（したがって、その成功を報告する）か、何かを取得する（そしてそれを返す）。

わかった。 では、なぜこのメソッドを周期的に呼び出すのでしょうか。 私はまだ元の議論が立っていると思います。 メソッドは1つのジョブを実行する必要があります。 何かを開始する（したがって、その成功を報告する）か、何かを取得する（そしてそれを返す）。

異議はありません。実行メソッドを周期的に呼び出す必要はありませんが、呼び出す場合は問題になりません。

メソッドが操作の結果を返すことができなかった理由がわかりません。

もっと複雑なコンポーネントを考え出し、これらのアイデアのプロトタイプを作成する必要があると思います（空気圧ピストンはこの議論には十分複雑ではありません）ドライブ/軸から始めることができると思います。

同意しました、ピーター。

スレッド名の関係で、これをコンベンションとして目指していると思いました！ 誤解された場合はお詫び申し上げます。

クリスは現在PRとして基本的な軸ブロックを持っています-私はそれについてコメントしました、しかしそれはそれにもっと目を向ける必要があります。

@ mark-lazarides謝罪は必要ありませんマーク、私たちは自由に議論するためにここにいます、私は明日PRを見ていきます...

@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 Prop

こんにちは、 @PeterZerlauthとありがとう。 PLCと従来のソフトウェアエンジニアリングの中間にあるため、規則に同意するのは少し面倒です。

これが議論の初期からの世論調査です：

TcOpen.Survey.Result.pdf

それに加えて、ここで議論があり、Slack Channelでは、 @dhullett08TcOpenリポジトリにも何かがあるかもしれません。

プレフィックスが有用な情報を提供しない場合、または最新のIDEが過去にプレフィックスで伝達した情報を提供する場合は、プレフィックスを破棄する必要があるという一般的な感覚がありました（または少なくとも私はそれをそのように解釈します）。

私はこれが個人的な好みに関するものであり、それを行う正しい方法も間違った方法もないことを理解しています。 何かに同意する必要があります。

ここで締めくくりはここで議論を続けます： https ：//github.com/TcOpenGroup/TcOpen/discussions/11