Blogの記事をまとめたつもりのサイトです。

P.40

P42ドライブフローの右側にフォーカスを変更すると、フローのHEP(ヘッドエンドパワー)部分が表示されます。 このフローはHEPを非常に忠実にモデル化します。速度に依存し、重い負荷音、通常の負荷、およびスタンバイモードがモデル化されています。 共有とシフトのさまざまな設定を使用して、HEPをプロトタイプにし、関数を介してユーザーに応答します。 また、スタンディング(アイドル)用のスタンバイモードがあり、ユーザーが希望する場合は無音にすることができます。


Fig. 105: P42 HEP flow

上記の図105は、機関車の進行中に原動機の音と同時に実行される基本的なHEPを示しています。 通常の負荷から重い負荷とスタンバイの両方に移行するHEPをシミュレートするために、上下にrpm遷移があります。 下の図106は、スタンドバイコンテナからのドリルダウンを示しており、ループ部分に描画されたクイック終了機能を示しています。 終了時の共有の設定に注意してください。


Fig. 106: P42 HEP, loop portions quick exit

P42プロジェクトの最後の例では、HEPのサイレントモードを可能にするHEPのスタンバイモードを表示しています。 サウンドスロット18に設定された単純なフローです。フローセットは開始時に3に等しく、フローがアクティブになる前にshiftがtrueで、speed = 0の両方が必要です。 終了すると、shareを2に設定し、速度が0より大きい場合、またはfunction = falseの場合に終了し、f13にマッピングされます。


Fig. 107: P42 HEP, standby mode when standing

ESUサウンドライブラリとダウンロード可能なプロジェクトには、非常に多くのフローチャートの例があります。よく見る価値があります。

ヒント:コピーと貼り付けを使用して、1つのサウンドスロットからコピーし、有用な部分を別の部分に貼り付けてから、遷移線を接続します。コピーする前にサウンドリンクを削除した場合は、フローと他のサウンドへのリンクを後で使用できます。または、サウンドが必要な場合は、サウンドリンクを使用してフローをコピーし、貼り付けるとフロー全体または一部、サウンド、すべてを取得できます。

ヒント:組織用のコンテナを使用して、モジュールを作成します。例えば; P42フローの駆動ステップはすべて同じ駆動ステップフロー(モジュール)を使用し、一度作成してから何度も使用します。 P42フローでは、ドライブステップとHEPに11回使用され、同じフロー部分、使用ごとに異なる音だけが使用されます。

ヒント:状態とコンテナーだけでなく、遷移線のコピーと貼り付けもできます。

ヒント:ドラッグアンドドロップを使用してサウンドを状態にリンクしたり、ファイルリストから状態にドラッグしたり、ファイルリストから図面ビューにドラッグしたりすることもできます。飛ぶ"。左下のペインのファイルナビゲーションビューからドラッグアンドドロップすることもできます。サウンドファイルが変換され、状態が作成され、サウンドがリンクされます。

ヒント:取り消し機能(Undo)は、間違えたり誤ってエラー状態を引き起こしたりした場合に大いに役立ちます。忘れないでください。

ヒント:Constant Value Tabele(「定数値」テーブル)を使用します。テーブルはオプションです。ただし、変更項目を紛失したり描画エラーを引き起こしたりする危険はないため、フローチャートを使用すると、速度範囲やその他の値の変更が大幅に簡素化されます。ドライブサウンドなどの複雑なサウンドフローを更新または調整するときに、文字通り何時間もの作業を節約できます。

ヒント:一度に複数のLokProgrammerのインスタンスを開くことができ、コピーと貼り付けがずっと簡単になります。

P.41

13.エラーとトラブルシューティング

描画形式の調査を開始すると、間違いを犯してエラーを発見します。 フローチャート描画プロセスの結果は、デコーダーにファイルリストにあるサウンドのシーケンスと再生方法を指示するコンピューターコードに変換されるため、ソフトウェアはエラーから自身を保護する必要があります。 したがって、ソフトウェアはやや簡潔なエラーメッセージを発行し、問題のある状態またはコンテナに小さな赤い「x」を配置することにより、自身を保護します。

ほとんどすべての場合、エラーが存在する場合、ソフトウェアはサウンドデータの書き込みまたはサウンドプロジェクトファイルの保存を許可しません。

音の流れを描く方法を学び始めると、小さな赤いxに慣れてきます。 最も一般的なエラーとその解決方法を以下に示します。

13.1。 最後の遷移は無条件でなければなりません

このエラーは、状態間に遷移を追加するとき、および遷移に条件を設定するときに発生します。 また、コピーと貼り付けを使用する場合、またはドラッグアンドドロップを使用して遷移と状態のグループを移動する場合にも発生する可能性があります。 ほとんどの場合、アクション中にリセットされる遷移の優先順位、または遷移の追加または削除中に発生した優先順位の不一致が見つかります。


Fig. 108 “Last transition must be unconditioned”

これを修復するには、遷移の優先順位を調べ、条件のないものを見つけ、優先順位を変更してサイクルの最後の遷移にします。 たとえば、図108では、手動ループの優先度を「2」に変更します。 状態がコンテナ内にある場合、このエラーも上方に継承されます。 図109は、コンテナー内の図108の状態で条件がどのように表示されるかを示しています。


Fig. 109, Error inherited from state inside container

図109に示されているエラーは自明であり、コンテナー内の問題を指摘し、遷移2を見て優先順位または状態を調べるのに適しています。 このエラーの修正がほぼ自動化されるのに慣れたら、優先順位を変更して、もう一度検証をクリックします。

13.2。 ダングリング発信遷移

「Dangling…..」エラーコードは、オブジェクトのグループでコピーアンドペーストを使用する場合に最もよく表示されます。頻繁に遷移がスタックし、ステートに正しく接続する必要があります。 コンテナまたは状態のいずれかで見られるように、修正は赤い遷移を探し、接続先の状態またはコンテナに端を接続することです。


Fig. 110, Error from unhooked transition

上記のエラーが明らかなように、主要な描画作業に従事している場合、見逃しやすいことがわかります。 コンテナー内の状態と、コンテナーレベルでの継承されたエラーから、切断された遷移からの他の2つの例が続きます。


Fig. 111, Error from unhooked transition inside container


Fig. 112, inherited error from inside the container

13.3 ...終了ダングリング着信遷移

コンテナ内の状態レベルの観点から、またコンテナの観点から示されるこのエラーは、以前よりも微妙です。 これは、「検証」ユーティリティのロジックチェックに合格するサウンドフローのパスがあるため、問題が状態レベルでエラーメッセージにフラグを立てず、図113のフローにエラーが表示されないためです。 しかし、図114を見ると、コンテナが存在する上位レベルの問題として認識されていることが明らかです。


Fig. 113, unhooked transition from state end inside container

元の状態でフックが解除されたときの遷移エラーの違いに注意してください


Fig. 114, inherited error from transition inside the container

13.4。 未処理の例外

未処理の例外エラーは、発生する可能性がある最も重大なエラーです。 エラーにはいくつかのバリエーションがあります。 これは、プロジェクトのコアレベルで使用されるフローまたは定数値のテーブルの重要な部分を削除することによって引き起こされるものです。 この場合の手がかりは、「インデックスが範囲外でした」というエラーステートメント内にあります。 この場合にエラーを生成する方法は、定数値のテーブルの一部を削除することでした。 通常、アイテムが使用中の場合、プログラムは削除を許可しません。この場合、デモ用のエラーを生成するために意図的に強制されました。 新しいサウンドプロジェクトのビルド中にこれが発生した場合は、プロジェクトを保存せずにLokProgrammerを終了し、以前に保存されていない項目を再起動して再ロードし、再実行することをお勧めします。 ソフトウェアは現在非常に成熟しており、このエラーはあまり見られません。


Fig. 115, unhandled exception error

このエラーは、ソフトウェアの再インストールまたはドライバーのインストールを強制的に何らかの破損を修正する可能性があり、発生の状況に依存します。 引き続き発生する場合は、トラブルシューティングのセクションをご覧ください。

P.42

13.5。 デコーダーを読み取るときの問題

プログラムがデコーダーデータを読み込めない場合、エラーメッセージが表示されます。 そのメッセージの表示には、いくつかの理由が考えられます。
•機関車がプログラミングトラックに正しく設定されていないか、トラックがLokProgrammerに正しく接続されていません。
•機関車のデコーダー、特にモーターリードが正しく配線されていません。
•機関車には、モーター回路または回路基板にコンデンサが含まれている場合があります。
•デコーダーに欠陥がある可能性があります。
•トラックが汚れています。

13.6。問題のトラブルシューティング

解決策を知っていると確信している場合でも、上記のリストを慎重に進め、時間をかけて各ポイントを確認してください。
•別の機関車に置き換えることにより、プログラマトラックの添付ファイルをすばやくテストします。この方法で、正常にインストールされていることが確認できます。
•配線接続を注意深くトレースし、可能であればデコーダーを配線から分離してください。そうすれば、配線接続をより簡単にトレースできます。
•トラックリードとモーターリードのみを接続するなど、簡単な接続が必要な場合がありますが、短絡を防ぐように注意してください。プラグインデコーダーを使用する場合は、別のデコーダーに置き換えてください。
•デコーダーテスターを使用している場合、デコーダーをテスターに​​配線し、正常に動作するかどうかを確認します。これにより、デコーダーまたは機関車の不良が確認されます。
•デコーダーのリセットを試してください。
•動作が断続的である場合、機械的な問題、不良な電力ピックアップ、汚れたトラックについて慎重にテストします。
•コンデンサが見える場合は、コンデンサから1本のリード線を外します。
•トラブルシューティングの目標は、問題を原因因子、デコーダー/機関車/設置に切り分けることです。いったん切り分けられたら、問題を修正できます。

13.7。 カスタマーサービス–支援とサポート

www.esu.eu
(省略)

このマニュアルについて:
これは非公式のマニュアルであり、ESUエンジニアリングによってレビューされていません。 ただし、ライターと、ESU v3.0、v3.5、およびv4.0シリーズのデコーダーで高いレベルの経験を持っているいくつかのボランティアによって徹底的なスクラブが行われました。
校正者の意見と、勤勉さと専門知識に感謝します。 これらの人々は、LokSoundコミュニティのよく知られた貢献者です。 ありがとうございました!

Peter Ross
Mike Walters
Ian Bishop
Dave Heap
Jim Albanowski
Ted Najzer
Mark Roach
Special Thanks to Matthew (Matt) Herman, for his support
and enthusiasm given to the ESU user community and the
v4.0 decoder!!!
Phil Dunlop

管理人/副管理人のみ編集できます