私は多くのPLCプログラミングを行い、今ではかなりの.NETプログラミングを行っています。転送できると思われる多くのスキル（パターンなど）があなたを非常に遠くに導くので、どちらの方法に切り替えることも非常に危険です。
PCのプログラムコードは、他のプログラマーがオーディエンスであるかのように書く必要があるが、PLCプログラム（ラダーロジック）は、保守担当者がオーディエンスであるかのように書く必要があるということです。ほとんどの施設（特に製造業）の保守は、PLCに直接接続することが多く、オンラインモードでは、コードがグラフィカルに実行されるのを監視して、問題の原因を突き止めることができます。
たとえば、出力がオンにならない場合、彼らは出力電気デバイスIDをプログラミングソフトウェアの検索機能に入力し、その出力コイルを見つけ、そこからトレースを開始して問題を探します。一部のPLCプログラマーがよく犯す間違いの1つは、I/Oを構造に「マップ」することです（PLCでは、これらはユーザー定義型と呼ばれます）。コピー命令を使用して、すべての入力または出力をすぐに構造。 PCプログラミングの観点からは理にかなっていますが、それは保守担当者があなたを殺そうとすることを意味します。通常、プログラミングソフトウェアは、その出力コイルを指定できる相互参照機能を提供し、プログラム内のどこにでもそれが使用されていることを伝えます。コピー命令を使用して10ワードのI/Oを10ワードのデータ構造に移動する場合、彼はそこに座ってビットを数え、コピーのソースのどのビットがコピー先のどのビットにマップされるかを把握する必要があります。コピー。確かに、コメントは役に立ちますが、それにも問題があります... PLCはプログラム全体を保存し、トラブルシューティングが必要で元のプログラムのコピーがない場合に、緊急時にプログラムからプログラムをアップロードできます。問題は、スペース上の理由から、PLCがコメントを保存しないことです。したがって、回線がダウンしている場合、ダウンタイムは1分あたり5000ドルであり、ラップトップを持っていたら、コメントなしで簡単にアップロードしてトラブルシューティングを行う必要があるかもしれません。そこにコピーの指示があると、彼の時間の10分が無駄になり、会社のダウンタイムは50,000ドルになりました。これらは、PLCプログラムを作成するときに注意する必要があることです。
その他のヒント：一部のPLCはFORループをサポートしています。 決してそれらを使用しないでください。上記と同じ理由で、保守担当者はコードをトラブルシューティングするのが非常に困難になります。これは、PLCに1回のスキャンで複数回スキャンされるコード（ループの内容など）がある場合、オンラインデバッグモードに入ると、ソフトウェアがそれぞれの値を表示できないためですこのスキャンを実行した10のループのうち、実際にどのような値を見ているのかわかりません。次に、このすべてのトリッキーなコードを記述して、特定のループインデックスのループ値を、監視可能な他のいくつかのタグ（変数）に引き出す必要があります。これは、緊急時に問題を解決するためのもう1つのインピーダンスです。スキャンごとに1回以上サブルーチンを使用すると、同じ問題が発生します。
間接アドレッシング（これを配列と呼びます）は、保守担当者が理解するのが非常に困難です。レシピ管理（部品の作成方法の値の保存と取得）を処理する場合は、通常これらを使用しますが、プログラムの制御部分ではそれを避けてください。
もちろん、PCプログラミングでは、可能な限りコードを再利用することを目指しています。ただし、PLCと制御システムでは、ダウンタイムは非常に高く、ハードウェアは高価です。メモリは安価であり、実際にはPLCプログラマーは安価です。したがって、マシン上に同じものが10個ある場合（コンベヤドライブなど）、ドライブごとに1つずつ、10個の異なるファイル（サブルーチン）があり、各ドライブには独自の変数が関連付けられていることが予想されます。 Drive1_Run、Drive2_Run、Drive3_Runなど。これは、PCプログラミングのバックグラウンドを使用している場合は非常に「間違っている」と感じるでしょうが、これはすべて、上記で説明した点が原因です。ダウンタイムの状況で、誰かがドライブ3が機能していないと言ったら、ラップトップを開いてドライブ3のファイルに移動し、実行出力ラングを確認します。プログラムの実行中に、そこからトラブルシューティングを開始します。ブレークポイントはありません（プログラムは停止しません）。
頑張って頑張ってください。チェックアウトしたい場合は、さらに書き留めておきます PLCをプログラミングしてきた長年の洞察 。
PLCプログラミングは、インターネット上のさまざまなソースから学ぶことができます。その1つは this（wikibooks） または this です。
作成するプログラムは、PLC固有の機能を使用しない限り、LLD（ラダーロジックダイアグラム）用のさまざまなブランドのPLCでほとんど同じです。ただし、IL（Instruction List）などの言語を使用すると、さらに多くの違いがあります。ただし、プログラムを作成すると、ストレージと実行の形式はブランド間で大きく異なります
ラダーロジックは、PLCの5つのプログラミング言語の1つであり、その他はFBD（機能ブロック図）、ST（構造化テキスト、Pascalプログラミング言語に類似）、IL（命令リスト、アセンブリ言語に類似）およびSFC（順次関数）です。チャート）。これらは、プログラミング言語のさまざまな表現であり、さまざまなフレーバーです。ただし、通常、特定のブランドはこれらの1つのみをサポートします。米国ではLLDが広く使用されていますが、ヨーロッパではILの方が人気があります。
はしご、しばしばLDは、ISO 61131オートメーションプログラミング標準で定義されているいくつかの言語スタイルの1つです。その他は、SFC（シーケンシャルフローチャート）、FBD（機能ブロック図）、ST（構造化テキスト）、およびIL（命令リスト）。ILはアセンブラーに似ており、使用する人はごくわずかです。STは、BASICの初期のバージョンとよく似たテキストベースのプログラミングです。また、あまり使用されません。LD is （多くのPLCが交換した）電気制御パネルのリレー接点に似た設計になっています。FBDは回路図に似ています。SFCは基本的にフローチャートです。
一部のPLCはすべて、一部のみ、または1つをサポートしています。 LDが最も一般的ですが、FBDとSFCは人気があります。
ブランドが異なれば、使用するプログラミング言語も若干異なります。これらは通常、1つのブランドを理解すればどのブランドでも使用できるほど十分に類似していますが、1つのPLCから直接コードを取得して別のブランドで使用することはできません。
これまでに出された答えはかなり目標通りです。 PLCの言語とセットアップに関しては、個性が分かれていることが1つわかりました。彼らの中心的な設計は、全体的な設計のために制御ロジックをセットアップする柔軟な手段を電気関係者に提供することです。 PLCは基本的には一連の入力と一連の出力であり、それらがどのように接続されるかは、デバイスにロードするソフトウェアによって制御されます。
PLCで使用される言語の重要な点の1つは、電気的背景から来た人々がそれらにアクセスできることです。したがって、イディオムと構造は、高級言語やアセンブリ言語にさえ慣れた人にとっては直観に反するように見えます。たとえばラダーロジックは、電気関係者にとって非常にアクセスしやすいものです。
ただし、近年、PLCは最大限の柔軟性を実現するために多数の言語をサポートしています。ただし、私の意見では、私が作業した数個のPLCは、プログラミング環境であるという点で非常に不足しています。変数名をメモリ位置に割り当てるなどの単純なことは、多くの場合、使用する言語では設計されていません。作業しやすいものは、多くの場合、その仕事に最も費用対効果が高くありません。
これらのハンディキャップにもかかわらず、それらは複雑な電気システムを簡素化するために優れています。プロジェクトで他の人と一緒に作業している場合、プログラミングの知識がプロジェクトが厄介なプログラムを解決するのに役立つことがわかります。 100ラングのラダーロジックプログラムを取得して、ラングの3分の1に書き換えることができました。ラダーロジック言語を学ぶことができたら、プログラムの複雑さを軽減するさまざまな最適化を実装することができました。
1つのヒントは、ラッチングについて学ぶ必要があるということです。場合によっては、一部の出力を保存または保持する必要があります。ラッチがない場合、結果は次のサイクルで消えます。問題を理解すると明らかになりますが、最初はそれが私にとって大きな不満の原因でした。
PLCプログラミングは、PLCを機械的または電気的ソリューションの代替コンポーネントの純粋な一部として使用している場合を除き、PLCソフトウェアエンジニアリング出力の実装アクティビティと見なす必要があります。
これを基本として、PLCプログラミング環境は通常IEC61131駆動で、保証されたサイクルタイム、「プリエンプティブ」リアルタイム、リアルタイムOS関連の問題を処理する必要がない、継続的なコードスキャン、非プログラムポインター、通常のコンピュータータスクの生成とは異なる概念一種のマルチタスク。コードの実行は当然アトミックであり、タスク間でモニターを使用する必要はありません。
各言語は、実装するロジックモデルに対してコードがどの程度考えられるかと密接に関連しています。
はしごには、電力潮流のインターロックスタイルに関する基本概念があります。単一ネットワーク内のコード解決は、水平または垂直スキャンです（このトピックに関するリソースは、製造元または他のサイトから見つけることができます）。コードが単一のスキャン解像度の性質を持ち、1つのネットワーク内にある場合、スキャンの種類が原因で考えられない動作が発生する可能性があります（ラダーは電気回路のエミュレーションにすぎないことを覚えておくことが重要です。
FBDまたは機能ブロック図は電子信号フローでしたが、現在はPLCのタイプによってはデータフローになる可能性があります。 FBDは、スキャンシーケンスの水平スキャンラダーと非常によく似た、より明確な実行シーケンスを示します。現在、FBDは通常、オブジェクト機能ブロックのコンテナーとして使用されていますが、依存関係の実装とプロセスモデルへの視覚的な類似性はPLCタイプに依存しています。
リテラルはBASICによく似ていますが、構文のみです。実行はまだスキャンスルーです。リテラル言語は数学的計算に適しています。高レベルの実装では、オブジェクト内の属性のメソッドまたは派生は、Literalを使用する方が簡単です。英語のような状態表現または定数を使用した状態機械プログラミングは、プログラムを非常に読みやすくします。
ステートメントリストはアセンブリニーモニックに似ていますが、やはり実行はスキャンスルーであり、プログラムポインターではありません。ビット演算と括弧スタイルの離散ロジックに強いです。これは、適切な構造化とコメントで使用する非常に効率的な言語になる可能性があります。
SFCまたはシーケンシャルフローチャートは、シーケンス実装のための補完的な言語です。 SFCには、アクションブロックのアクティブ化、状態遷移、並列シーケンスのアクティブ化、およびマージに関する固有のルールがあります。ただし、複雑な例外分岐または並行アクション管理により、実装が複雑になり、フローチャートが読みにくくなる場合があります。
IOのPLCシステム管理は、処理、通信、ホットスタンバイはハードウェア構成作業であり、製品に依存します。通常、ソフトウェアエンジニアリングとは別に処理できます。ただし、PLCシステム管理に関連するデータは「ロケート」（独立データアドレッシングエリア）タイプの場合、ソフトウェアエンジニアリングにおける優れたデータモデリングアプローチは、システムデータの管理に役立ちます。
オンラインPLCシミュレータ が役立つ場合があります。
構造化テキスト（ST）は、高水準言語（ "IF..THEN..ELSE"）またはループ（WHILE..DO ）実行できます。
標準のプログラミング言語に近いため、Ladderよりも優れていると思います。
ラダーロジックを学習しようとする初心者にとって、最善の方法は http://plcs.net で無料のオンライントレーニングに参加することです。
Allen-Bradleyには、特にトレーニング用の無料のDOSベースのソフトウェアPLCがあります。あなたはおそらくあなたが彼らのサイトに行くならそれを見つけることができます、またはそれをグーグル。学校でPLCプログラミングを教えるために使用されます。
私は大学で少しPLCプログラミングをしました。私にはアセンブリより1レベル低いように見えましたが、使用していたデバイスは最新のものではありませんでした。
PLCドライバーが必要だと思いますが、購入する前に、まずシミュレーターを探して、それについてもっと読むでしょう。