気になるのが、マニュアルにもあるのですが、共有メモリからの読み出し・書き込み命令時間ですね。

• 読み出し

  QBF_FromBuf
  ワード数	自号機	1号機
  1ワード	433μs	437μs
  64ワード	481μs	508μs
  512ワード	585μs	736μs

• 書き込み

  QBF_ToBuf
  ワード数	自号機	1号機
  1ワード	423μs	－
  64ワード	454μs	－
  512ワード	577μs	－

これだと、1ワードの単純な送受信で既に0.88msを超えてしまいますね。モーションの高速動作が目的なら、モーションSFC内部計算でできるところはした方が速いかも。

そういった使い方よりも、複雑な計算をやらせるとか、色々とごにょごにょするのに使うのが一番良さそうな感じに思えます。　そういった使い方ならば、　ビット・ワードとも1024点ずつ割りつけて使っても十分な速度だと思います。

（追記）従来の製品に比べても、大きく後退している。
C言語関数処理時間

私は何の因果かSiemensを触っています。
C言語などが扱える人には悪くないとは思いますが（Functionや構造体宣言ができるので、ソースコードを再利用しやすい）、予備部品を注文したときに1ヶ月かかるのには閉口します。KEYENCEなら即日出荷なんですが。
改めて三菱、KEYENCE、SiemensのPLCを比較すると、三菱の取っつきやすさが光ります（単純なことしかしない場合は覚えることが少なく、不完全な知識でも何とか動かすことができる）。Siemensは真逆ですね。

i-brownさん、こんにちは。

いやー、ごぶさたです。お元気ですか？

私のほうは、相変わらず、元いた某メーカー系の仕事メインで、難解な仮想モードばっかり回ってきます。（汗）

KV-1000、懐かしい。　私はKV-500の時代だったかな、三菱互換のを使ったのが最後ですね。

KEYENCEのモーションの件ですが、モーターの容量も拡充されてますので試してみる価値はあると思いつつ。。　他に優先事項が沢山あって、まだ箱も開けてません

いつかそのうち・・

なーおさん、しばらくぶりです。
KEYENCEはKV-1000時代しか知りませんが、そのころからモーターのコネクタは安川っぽい部分がありました。
その頃は4軸位置決めユニットしかなかったのですが、知らない間に進歩しているのですね。続報、お待ちしております。

この記事の参照数が多いようですので、補足しておきます。

　使用可能なCFメモリについてですが、秋葉原で買った汎用品を使用しました。　トランセンドブランドだった気がしますが、２ＧＢで1,300円くらいでした。問題なく連続稼働しています。
　　（たぶん、コレだと思います。）
　　
　なお、高速データロガーユニット自体のほうは、２０１０年６月２２日のバージョンアップで、タイムスタンプ式ファイル名への対応や、トリガ指定の拡張などの改善がされているようですので、最新の機能はマニュアルでご確認ください。
　（マニュアルを見ても、なかなか解らないことが多いですけどね。。）

本日、EXCELレポート機能でもうひとつ問題が浮上。

例えばシステムの立ち上げ時など、ロギングされたバイナリファイルの始めのほうに不要なデータが入ってしまうことがありますよね。

それを削除しようと思って、設定ツールのファイルブラウザを使って「LOGGING」フォルダ内の当該「.BIN」ファイルを削除すると、、　そのロギングファイルデータを参照するEXCELレポート機能がコード「07E4H」の「レポートソースファイルエラー」で当該レポートが止まってしまいます。　（他の機能は継続）

削除されたロギングファイルは、新たに採番が始まって正常に保存されますが、　そのファイル名がEXCELレポート機能側で期待するファイル名と違うということらしい。

これを回避するには、「シーケンサリセット」が必要とのことです。　んー、マジですかぁ？　今回もマニュアルに記載無しです。

試しに、当該レポート機能を消去した設定を書き込んでも、使い先も無いはずのトリガを監視してしまっているのか、上記と同じエラーを無意味に吐き続ける始末。　

これは少なくとも設定ファイルの上書きで初期化（最新ファイルを参照）するように改善していただかないと、まずいっす。

ご使用の皆様、どうぞご注意を。

高速データロガーユニットで、またまた不思議な仕様を一つと、　珍しいバグを発見したので、注意情報として書いておきます。

1. データへのINDEX付加機能の制約
   　トリガロギングを行うと、トリガの度にINDEXが初期化される仕様らしい。　ということで、トリガの度に「１」に戻ってしまうので、マニュアルに書いてあるような「データの連続性のチェックのためにINDEXを付加」する使い方は、この場合はできません。
   
   
2. FTPサーバーの「MDTM」コマンドで日付ズレ
   　データロガーユニットのFTPサーバー機能にユーザー側のFTPクライアントから接続する時、「LIST」コマンドでは正しい日時が返ってくるのだが、「MDTM」コマンドだとなぜだか丁度１ヶ月前の数値が返ってきます。　（FFFTP、NextFTPで確認済）

　経緯をこちらに書いたとおり、不幸中の幸いでphpで書かれたftpクラスを使っていたので、「ftp_mdtm」をコピー・改変した「ftp_mdtm2」関数を作って使うことにしました。　再配布もＯＫらしいので、そのソースを下に貼っておきます。

ftptool.txt

　はあ。。もう疲れたよ。

もうひとつ、新たな問題が発覚しました。

　データロギングのバイナリファイルの「保存」を時刻指定しても、実際の保存は、その時刻を経過した後の最初のトリガ直後、とのことです。
　想像するに、トリガと保存が重なった時のデータ欠損を避ける狙いの仕様だと思います。

　ということで、上の投稿でタイムチャートで提案した「日報作成時刻マスク」は役に立たないばかりか、保存時刻を早めに設定したとしても、トリガ時刻が日付をまたいで前後するので、日付変更時刻付近のデータ１つは、当日の日報に入ったり翌日のほうに入ったりするわけです。　（実際には、当日と翌日の両方に入るデータが１つ存在するので、EXCELにマクロを乗せて余分なデータを削除する方法をとりました。）

この件も、マニュアルで見つけられません。

あ”ーもう、融通が利かなすぎます。
こんな単純な日報すらまともに作成できない製品だとは。　まったくもって、イヤになってきた。。

うーん。。　訳のわからない仕様が判明し、上記のタイミングチャートではうまくいかないですね。

修正タイミングチャート

　こんな感じかな。

使ってみないと分からないことが、色々ありすぎる。。

＊＊　追記
マニュアルには、申し訳程度に文章の説明がありました。（９?１章）
それから、この案も結局無意味でした。　下の投稿を参照。。

主題の件、現状のユニット仕様ですと、MX-sheet互換の機能を行うためには、添付EXCELのようなPLCとのハンドシェークが必要になりそうです。

特に、レポートの際にＥＸＣＥＬ保存?トリガロギングのバイナリファイル保存を、ＰＬＣからのBitトリガで同期する仕組みが無いので、本来のロギング動作をその間、必要以上に長めに待たせるような処理が必要になってきます。
（つまり、実際の時刻と記録時刻とのズレが大きくなる）
（１日１回の日報でも、同様です。）

高速データロガーユニットの続報です。
使ってみないと分からない情報ですので、掲載しておきます。

norさん

おめでとうございます!

JointBoxには発言はしてませんが、たまに覗いてます。

ことしもよろしくお願いします。

とても遅くなりましたが 明けましておめでとうございます。

風邪やインフルエンザが流行っているようですのでお体にはお気をつけ下さい。

今年もよろしくお願いします。

今、台北の桃園空港で、遅れた便を気長に待つています。帰宅は夜九時すぎかな。
それにしても、借りた携帯は使いづらい。