13

The company I am doing my intership/appretinceship in, does mainly PLC programming with Siemens modules. Comes from the fact that most of the people were electric guys and switched over to engineering.

My problem as newbie there is, that I can't be really efficient and fast when I code PLC software.

Even though I am very efficient when I am coding C# or Java in VS/Eclipse

It really bothers that I can't be really productive with PLC as opposed to the "real" programming languages.

  • Is it the lack of code completion?
  • Is it the lack of overall knowledge on the automation side?
  • Is it the lack of innovation in PLC as opposed to VS (LINQ, Dynamics, Lambda)

Have you guys any good experience with PLC? And how did you get productive with it?

Notice: It is my last year at the company, that's also why I want to be very productive.

Looking forward to many great answers!

4

6 に答える 6

27

PLC プログラミングは、いくつかの点で従来の手続き型プログラミングとは異なります。

1) Relay Ladder Logic はかなり原始的な言語です。生産性を高めるのは難しいです。ほとんどの PLC プログラマーはサブルーチンを使用しません。まるで PLC の世界は、当時とソフトウェア エンジニアリングが忘れていた世界のようです。結果として単純なソフトウェア エンジニアリング手法を適用することでうまくいく可能性があります。たとえば、たとえ抽象的であっても、コード ブロック間のインターフェイスを定義します。

2) PLC プログラミングの多くはブール式に関係しています。PLC プログラミングが上手になりたい場合は、ブール論理を扱うことに一生懸命取り組みます。ブール代数、特に AND と OR に NOT を分配するためのド モルガンスの定理のようなものを学びます (PLC は通常 NOT 演算子を提供しないため、これは必要です。予想よりもはるかに頻繁に）

3) PLC プログラミングは、リアルタイムでの制御とフィードバックに関するものであることを理解します。ほとんどの標準的なプログラミング言語 (Java など) は、これに対処したとしても不十分です。PLC コードは出力を駆動するロジックであり、駆動される機械システムは実質的に PLC 入力を駆動する「ロジック」であるという事実について慎重に検討してください。実際の工場の機械を制御する必要なく、自分の PLC プログラムをデバッグできるようにするためだけに、別の PLC を使用して機械システムをモデル化することがよくあります。これにより、障害をシミュレートすることもできます。ポイント6を参照してください。

4) PLC プログラミングの多くは、抽象的な状態から状態への遷移に関するものです。状態は、PLC が外部世界について知っていることを表し、遷移は、PLC が外部入力を読み取り、世界の状態が多少変化したことを発見したときに発生します。有限状態オートマトンと離散システムの監視制御についてできる限り学びましょう。それはあなたに気前よく支払います。

5) PLC は多くの場合、過去のイベントを記憶する必要があります。その結果、PLC ロジックの多くは、ブール値/数値状態変数やタイマーの設定/リセット/テストに関係しています。そのため、PLC プログラムのコードは純粋なロジックのように見えることがよくありますが、実際には多くの副作用があり、プログラムについての推論が非常に難しくなっています。実際、C や Java などのより現代的な言語で書くのと同じくらい難しいことです。

6) 機械的故障の取り扱いに注意してください。ほとんどの PLC プログラムは、制御されたシステムが宣伝どおりに機能することを前提としています。これは本当に悪い習慣です。現実の世界では、制御されたシステムは壊れるまで宣伝どおりに機能しますが、最終的には常に壊れます。PLC プログラムで機械的に壊れているものを特定するのに役立つ診断コードを含めると、それらを書くのに時間がかかりますが、ユーザーはあなたを気に入ってくれるでしょう。なぜなら、工場の機械が壊れていてもそれが分からないことほど悪いことはないからです。あなたはどのように。停止した工場は停止した現金自動預け払い機であり、工場の管理者はそれを嫌います。

于 2009-09-01T09:50:44.203 に答える
9

PLC プログラミングが、いわゆる「本物の」プログラマーから軽蔑の目で見られると、イライラします。ここでのいくつかの投稿は、PLC プログラミングはそれ自体が専門分野であるという基本的な事実をほのめかしています。

「PLC プログラミングは、リアルタイムでの制御とフィードバックに関するものであることを理解してください。ほとんどの標準的なプログラミング言語 (Java など) は、これに対処するとしても不十分です。」

「そのため、人々は結果と論理矛盾のチェック、個別の時間と状態のモデリングなどのための分析ツールを開発し始めていますが、実際には物事を単純化することはなく、問題空間削減のエンジニアリング原則から逸脱しています。」

ラダーロジックが「忘れられた訓練時間」であることをほのめかすことは、その機能を実行するためのツールを軽蔑することです。結局のところ、Ladder はソフトウェアで実際に物理デバイスを表現した最初の言語であり、パラダイムとしてのオブジェクト指向プログラミングの発祥の地です。

さらに、PC および PC ベースのコントロールはまったく信頼できないことを忘れないでください。クラッシュします。コンポーネントが陳腐化し、せいぜい数年以内に購入できない。クラッシュします。ウイルスや、ワークステーションに「ドンキーコング」を置く人々によって破損します。クラッシュします。退屈なオペレーターは、3 番目のシフトでソフトウェアをアンインストールします。言いましたが、クラッシュしますか？

PLC は、PC の世界で何年にもわたるいわゆる「進歩」の後も存在し続けています。これは、今日に至るまで、PC がまだバグが追加された使い捨ての商品であるためです。そして、数百万ドルの組み立てラインはそうではありません。

最後に、ユーモアのテストを続けます。IT 担当者が PLC コードを書き込もうとしているのを見て、私は頭がおかしくなりました。終わりのない質問 (文字通りにも比喩的にも) は、「プログラムの先頭に戻ると、ウォッチドッグ エラーが発生するのはなぜですか?」というものです。または、別の個人的なお気に入り - 「ラダーで for-next ループを作成するにはどうすればよいですか?」

どちらも、PLC の動作に関する基本的な知識の欠如を示しており、さらにオートメーション プログラミングは別の分野であり、別のツールが必要であることを示しています。

TM

于 2010-07-29T12:33:32.487 に答える
2

私はあなたが言及する3つの問題についてあなたに同意します。

私はCoDeSysの使用経験があり、これらの問題のうち2つはバージョン3.xで解消されたと思います。

* Is it the lack of code completion?
* Is it the lack of innovation in PLC as opposed to VS (LINQ, Dynamics, Lambda)

CoDeSys 3.xは、インテリジェンスとユーザーフレンドリーなエディターを備えており、オブジェクト指向プログラミングをPLCの世界にもたらします。これは、私の見解では非常に優れたイノベーションです。

生産性の向上に役立つと思います。CoDeSysの競合他社が同様のことをしているのかどうかはわかりませんが、PLCプログラミング市場では興味深いことが起こっていると思います。

知識の欠如はすべてのテクノロジーに共通しています。IEC-1131は、開発者の背景（電気技師の場合はLD、自動化エンジニアの場合はFBD、C / PASCALプログラマーの場合はSTなど）が何であれ、簡単に理解できるように設計されています。だから私の意見では、他の何よりも複雑ではありません。VSにも複雑さがあります。C++で独自のOPCサーバーを作成してみてください。そうすれば、ほとんどのSoftPLCでこの機能をすぐに使用できるようになります。その場合、インテリセンスは大きな助けにはなりません。

確かに、PLCプログラミング市場は通常のプログラミングツールほどダイナミックではありません。私はそれがマーケティングよりもブーレットプルーフ技術を好む産業界から来ていると思います-セクシーなもの。

お役に立てば幸いです

于 2009-10-15T12:49:12.937 に答える
1

プログラミング言語はツールです。1 つの言語しか知らない場合、ツールは 1 つしかありません。このツールは、1 つの仕事には適しているかもしれませんが、他のいくつかの仕事には問題なく、他のすべてには役に立たないかもしれません。より多くのツールを知っていれば、より多くの仕事をすることができます。

あなたが見ているのは、C# と Java のような「実際の」言語の違いだけではなく、PC 上の非リアルタイム アプリケーションと、PLC の主な用途であるリアルタイム マシン コントロールとの違いです。

優れたプログラマーは言語を知っており、優れたプログラマーはプロセスを知っています。彼らは、プログラミングに使用している言語だけでなく、プログラミングのプロセスも理解しています。会計ソフトウェアを作成する場合は、会計について知っておく必要があります。機械を制御する PLC コードを作成する場合は、その機械が何をどのように行うかを知っておく必要があります。

于 2010-07-29T12:54:20.507 に答える
0

Siemens Simatic Step7 の次の 2 つの製品をご覧ください。

  1. SCL (すでに Step7 Professional にあり、ST または構造化テキストとも呼ばれます)
  2. CFC（別製品）

簡単に言えば、最初のものは実際には Pascal であり、独自のブロックを作成するのに非常に役立ちます。2 つ目は、左から右へのナビゲートが容易なグラフィカルな表示とこれらのブロックのリンク、およびそれらのオンラインでの強力なオンライン監視です。

これらの 2 つは、求めている効率を提供するため、STL/LAD/FBD を完全に忘れることができます (他の人のコードを分析する場合を除く)。組み合わせると、PLC プログラミング用の非常に強力な RAD ツールになります。

于 2010-09-15T23:51:50.287 に答える
-1

PLC ソフトウェア エンジニアリングには、次のような背景があります。

  1. (全体的なプロセス フロー設計の) 機械的および電気的モデリングのソリューション スペースの補完的な部分である
  2. より価値のある代替実装である PLC への依存度が高まっていますが、独立したモデリング手法はありません。
  3. IEC61499 では、PLC プログラミングの設計手法として UML を推奨しています。

詳しく説明するには:

  1. 補完的なコンポーネントである PLC は、シーケンス/状態/ループ コントローラ、保護インターロック、信号調整などとして使用され、IEC61131 で規定されている機能を備えていました。要件は、機械および電気モデル内で十分に把握されており、独立したモデリングは必要ありません。

  2. プロセスの例外、回復手順、複数段階の障害モード分析、および結果管理に関する要件の開始時に PLC への依存度が高まり、パターン設計手法の無意識の採用が開発されました。ただし、業界が異なれば、プロセス会社が異なれば、異なるアプローチが使用されます。一般に、それらは従来のモデル、機能設計仕様の文献、エンドツーエンドの原因と結果のリスト、論理図を使用した状況の条件付き管理の上に構築されます。基本原則は、広範なテスト、継続的な適用と修正、設計アプローチを完成させるための再利用性です。

  3. PLC ソフトウェア モデリングの欠如と IEC61158 (Foundation fieldbus Distributed Object/Data/Dependency Modeling) の失敗を理解した上で、IEC61499 が 2006 年に導入され、設計手法として UML が推奨されました。しかし、この傾向は以前も今も機能オブジェクト モデリング アプローチを推進しており、IT 業界のようにデータが重いのではなく、ロジックが重いプロセス アプリケーションに通常固有の一時的および状態バインディングにより、オブジェクトの依存関係が複雑になります。そのため、人々は結果と論理矛盾のチェック、時間と状態のモデリングの分離などのための分析ツールを開発し始めていますが、実際には物事を単純化することはなく、問題空間削減のエンジニアリング原則から逸脱しています。このアプローチはまた、機械、電気、およびプロセス モデリングのドキュメントとの親和性と継続性に欠けています。

現在の状況は次のとおりです。

を。IEC61131 & IEC61499 は製造業者の標準であり、制御エンジニアがリアルタイム OS の問題に取り組む必要がないため、今後もアプリケーションの標準であり続けるはずです。

b. UMLは非常に可能性のある設計アプローチです

c. UML 上の設計パターンは、オブジェクト モデルがプロセス モデル (製品フローではなくデータ フロー、実用的なオブジェクト プロパティであるデータ モデル)、バインダー パターン、障害エスカレーション パターン、インターロック エスカレーション パターン、暗黙的なプラントとオブジェクトのパターンなど。PLC での優れたデータ モデルも、UI や SCADA の設計を成功させる鍵です。

私は、水処理プラントと、積み降ろし機を備えた工場コンベア用の完全に合理化された一連の設計パターンを開発することにより、システムの実装に成功しました。設計パターンを詳しく説明する環境が必要です。説明するには多すぎます。測定/機器/サブシステム/プロセス/プラント オブジェクトの概念的背景、それらの最小依存関係、それらの暗黙の関係、変更の伝播を制限および管理するためのいくつかの簡単なルールが必要です。など

于 2009-09-22T05:10:47.143 に答える