なーおさん、お帰りなさい。
新しいパソコンから初めての書き込みです。
（グラフィックチップが不調になりかけたので見切りました）

　共有メモリでのデータのやりとりですが、なーおさんのおっしゃるとおりですね。ただ、「なぜ、三菱が位置決めを割り込み命令にしているのか？」と考えたとき、私は「OSの設計者は基本的にS.TOやMULTR（SP.DDWR）を使ってデータをやりとりさせるつもりだった」のではないかと考えました。
　なーおさんの指摘通りQやQHでは「指令を自動リフレッシュで送る」か、「データを割り込みで送る」かで解決できるのですが、指令を自動リフレッシュで送るのであれば、割り込みのS.SVSTやS.SFCSは割り込みである意味がなくなるため、QやQHモーションでは「（高速に始動できる）割り込みが本命で自動リフレッシュはおまけ」と考えました。
　本来は、データを先読みして予めモーションCPUのデバイスまでデータをコピーをしておき、必要になったらSFCSかSVSTで始動したかったのですが、自分でゼロから作っているわけではないので、それも難しいのが現状です。

i-brownさん、こんにちは。
SFCへ共有メモリ経由でDATAを渡して始動する場合は、シーケンスで共有メモリ経由でDATAを書いて、共有メモリ経由で待ちフラグをオンでSFC移行で始動でOKなんです。同じ共有メモリ経由なのでリフレッシュも同じタイミングですから。

万一、DATAリフレッシュ前に始動されてしまう場合、リフレッシュ確認フラグを軸ごとに行き帰り一つずつ作りサイクリックSFCで戻せば安心です。
普通は不要ですが、DATAを共通メモリ経由でSVST始動する場合などは必要になります。

従来のQシリーズのSVSTには直前のDDWR命令がお薦めですが、QDシリーズには高速リフレッシュで問題ありません。

なーおさん、こんばんわ。
私がやっている方法は
1. S.TO命令で位置決めアドレスをシーケンサCPUの共有メモリに書く。
2. S.TO完了後SP.SFCSで位置決め用SFC起動。
3. モーションSFCのF箱でMULTR命令を使ってS.TOでかかれたデータをモーションコントローラの適当なデバイスにコピー。
4. サーボプログラム始動。
となります。（結構面倒ですが、活性ステップを減らすことを優先しています。）
　QDモーションになれば、単純に共有メモリにアドレスを書いてからDP.SVSTで起動をかければOKになるので、ずいぶん楽になるのですが。
　私が思うに、QやQHモーションの設計思想は、自動リフレッシュでのデータ送受信は同期を問題にしなくて良いものだけで、位置決めデータなどの重要なデータは共有メモリへの読み書き命令を使用するようになっているのではと考えています。

i-brownさんが、デバイスリスト雛形を公開してくださいましたので、リンクしておきます。

公開Data集​/Hint集​/ツール​/デバイスリスト

ありがとうございます。

i-brownさん、こんばんは。

なるほど。それもありますねえ。

でも、軸数が増えるに従いサブルーチン呼出しが増えるとやっぱり辛いように思います。　条件待ちで止めておく場合でも、軸番号毎にきちんと整理した構成にしないと、同じことですけどね。

あとは、サーボプログラムを位置決めアドレス毎に持つのか、始動直前のF箱で間接デバイスに格納するのか、それによっても組み方が変わってきます。

私が好むのは、単なる位置決めの場合はサーボプログラムはできるだけ１つに統一しておき、Ｇ箱で分岐して移行条件ＯＮ後にアドレスを書き換え、結合して始動する方法です。　これならラダーからのフラグ待ち、他SFCからのフラグ待ち、全て１つのＳＦＣだけを見れば良くて、なおかつ排他的（万一２つの位置決め条件が同時にＯＮしても早いもの勝ちになる）にもなるわけですが、やはり実行速度は遅くなりがちですね。

ただ、軸数が増えればそれだけ演算周期を長く設定せざるをえなくなるので、その分メイン周期に割り振れる演算時間も増えて行き、結果として実用上はあまり問題にならないことが多かったです。　（Ａシリーズの頃を除く。笑）

なーおさん、おはようございます。

　実は、私も後者の方の仕事をしています。
　従って、「ユーザがプログラムをいじる場合」についてにどう考えるかがやはり問題になります。「ループで待ちを作った方がわかりやすい」話もよく聞きます。
　これはシーケンサのSFCの場合なのですが、ループで待っていると「仕事をしていないブロックまで活性で待っているので、モニタしたときにどのSFCを見ればよいか分からない」と言う問題があると思います。
　サブルーチンの二重起動については、2カ所以上から呼び出されるルーチンを作ったことがないもので、言われてから問題に気づきました。ただ、同一のSFCから2回呼び出してしまうこともあるので、どちらにせよインターロックを確実に取る必要があるのでしょうね。
　ユーザから組み方を指定された場合は仕方ありませんが、ユーザもそれぞれなので、状況に応じて（合理的な範囲内で）組み方を返るしかないのでしょうね。シーケンスプログラム内でリンクダイレクトデバイス（Jn\Wn）を使用したときに、「このデバイスは何か」と質問を受けたこともあります。

こんにちは。

ここまで用語を蓄積してきて、SFCの考え方は様々だなあと改めて思います。

• ラインアップ機械の組み込み用途では実行速度が大事で、メンテマンは自社管理下にあるメンバーが行うことができるため、理想的な組み方を追求できると想像します。

• 私のような業界の場合はユーザー工場向けで一品料理が多く、故障時の一刻を争う中でのメンテマンの力量不足を考慮して、実行速度よりもプログラムの可読性やメンテナンス性、改造の容易さ、など「簡単さ、わかりやすさ」を基本として組んでゆくことが多いです。　（ユーザーから組み方を指定される場合もあります。）

端的に言えば、G箱内の条件待ちで止めておけば、その条件フラグを検索すれば、どこから始動するのかわかりますが、SFCの
サブルーチン呼出／サブルーチン起動の場合ですと、必要なときだけ実行するので余分な計算負荷が無くなりますが、　複数箇所から呼び出されると、どこから呼び出されるのかを検索するのに苦労する場合がありますし、2重起動への配慮など難しい面もあります。

このあたりは、ユーザーの状況に応じて異なると思いますので、投稿の際に見解を入れる場合には、その背景や用途などを併記していきたいと思いますので、ご協力お願いします。

皆さん、こんにちは。

イベントタスクを動かすとき、SFC演算時間が問題になります。
できるだけ「軽い」命令で構成したりしても、結局は「SFC図の分岐処理」が一番重くて閉口しますよね。

いくつかの方法で、SFC図の分岐処理を減らすことができますので、それらを紹介しておきます。

まずは、これ

１軸あたり0.1?0.2msの短縮は、10軸程度以下で高速性を要求する場合などに特に効果を発揮します。

皆さんも、「こんなことで縮まるよ」という一般的なものがあればぜひご紹介下さい。

では。