Q17xDSCPUだと、一旦書いたラベルをデバイスに戻せない件。

これができないと、ちょっとした不便な点が、より困ったことになるという例を示しておきます。

1. ラベル構造を変えたい時
   　ラベルの置き換え機能が実装されていないので、ラベル構造を変えた時には、プロジェクト内のSFCの記述を、一つ一つ、手打ちで新ラベル構造に合わせて修正するしかありません。
   　ラベル→デバイスに戻す機能があれば、一旦デバイスに戻して、変更後のラベル構造に差し替えて、　デバイス→ラベル一括変換で完了です。　できたらこんなに楽なのに、なんでできないのかな。。
2. ラベル構造体配列が現時点で使えない
   　現時点でラベルの構造体に配列を使えないので、本サンプルは構造体から各軸展開をラベル構造のインスタンスで一つずつ定義しています。
   　将来的に機能アップして構造体配列が使えるようになった時に、既に出来上がったプロジェクト内の記述を簡単に置き換える手段がないとすると、手修正か・・　そう思うだけで使う気が失せてしまいますね。

ラベルファイルがあると、SFCプログラムのオンライン時の指定ステップモニタが劇遅になることが判明。

１つのF箱に多い場合だと200~300行書いてあるのだけど、　ラベルを使わない時は、指定ステップモニタが一覧表示完了するのに5秒程度。
それが、ラベル定義すると、20秒程度に伸びてしまう。
デバイス記法で10秒かかる箱では、ラベル記法で60秒かかりました。表示するまでの間はマウスが砂時計となり、他の操作は全く受け付けません。

デバグ時は瞬時に表示してほしいくらいなのに、これじゃあ使えないじゃないか。ひどいものだ。

ちなみに、パソコンは、WindowsXP-sp2．

モーションのラベル機能、　Q17xDSCPUのアドバンスト同期制御でデバイスに戻せないとか、色々な問題があるので、当分使うのは見送ろうと思う。

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

• 読み出し

  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軸位置決めユニットしかなかったのですが、知らない間に進歩しているのですね。続報、お待ちしております。

当WEBサイトにご訪問の方々、こんにちは。

サイトサーバー管理者の、なーおです。

今回の東北関東大震災の影響で、計画停電が実施されています。
この停電により、当サイトが稼働しております、(有)モーションクリエイトのサーバーも、毎日停電となるため、その時間に合わせてサイトがクローズ・再起動を繰り返します。

つきましては、今後は以下の時間帯とその前後、およびなーお自身が出張等により自宅・自社に居られない場合には不測の長時間停止があるかもしれませんので、ご承知いただきたく、よろしくお願いします。

・　グループ５：　１５：２０　?　１９：００（日毎に変動）

皆様のご安全を今後もお祈りしています。　以上ご理解いただき、今後も当サイトをよろしくお願いします。

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

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

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

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

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

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

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

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

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

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

このワイヤーエンコーダー。
使い出があった良かったです。
ただ、巻き取りリール１回転毎に変動がありますね。（±0.1mm程度）

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

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トリガで同期する仕組みが無いので、本来のロギング動作をその間、必要以上に長めに待たせるような処理が必要になってきます。
（つまり、実際の時刻と記録時刻とのズレが大きくなる）
（１日１回の日報でも、同様です。）