パスワードを忘れた? アカウント作成
13980446 journal
日記

lccの日記: まさかバーコード1つで・・・ 10

日記 by lcc

自動倉庫が止まった・・・

最近、頻繁に止まるということで、調べたらバーコードを数値変換でエラーが発生していた。
バーコードは仕様書確認してないけど、おそらくNW-7。通常は数値しか使ってないが、誤読み取りで数値以外もありうる。今回は「2」が「:」に化けてた。

さらに追っていくと、常駐プロセスのはずなのにエラー処理がほとんど exit(1) とか・・・

直せるなら直したいけど、太古のシステムで、修正が必要な個所多すぎ、デバッグ・テスト環境無し。どうすっかなぁ

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2019年08月13日 20時38分 (#3668525)

    なんて出来たらいいんですけど、現実的には出来ないですよね。
    # 誤読み取りした時にどう処理するかによりますけど、私ならバーコードリーダとシステムの通信経路に何か入れて、システム側に異常な値が行かない様にするみたいな禁じ手(?)検討しちゃいそうです。

    • by Anonymous Coward

      まっとうな対策だと思うけどな。
      真因は、対応してないバーコードを読まされた場合のエラー処理が上手くない点。
      相手はほぼブラックボックス。
      となったら、入力を何とかするしかないでしょう。
      入力IFが解らんけど、それこそ、バーコードを読めない時用のテンキーデバイス風に仕立てて間に挟むとか。

      それよりも、最近リードエラーが多発する要因をなんとかしないと不味い気がします。
      バーコードラベルを生成しているサーマルプリンターか何かがドット欠けしてるとか、
      バーコードリーダーのスキャナが汚れて上手く読めなくなってるとか。

      • by Anonymous Coward

        ハードウェアも化石でとっくの昔に生産終了とか、買い替え費用がないとかじゃないの。ここの事案って。
        つまり修正するしか手段がない、だったりして。

        • ラベラ、リーダは掃除するように頼みました。
          ベルトコンベア上なのでリトライは不可。
          数字以外のバーコード検証はサーバに送らないとできないので、エラーレスポンスの仕様追加しないと・・・

          で、この手のシステムはデバッグ環境がないので業務止めないとテストができない。
          影響範囲が小さければコードレビューで何とかなることもあるけど、影響範囲がでかい場合は・・・

          親コメント
  • by Anonymous Coward on 2019年08月14日 11時17分 (#3668814)

    エラーが起きる商品コードがわかってれば、事前に手動で仕分けておく。
    あとはエラーが起きたら手動で対応できるようマニュアル化する。

    現場「馬鹿野郎システム直せよ!」
    SE「予算と人員」

    • by Anonymous Coward

      エラーが起きたらシステム落ちるので再起動に2、30分かかるんですよ。
      全体を一通り見て回って、引っかかってる荷物を除去。安全確認して順番に再起動と。

    • by Anonymous Coward

      この場合、読取エラーなんで事前に仕分ける事は難しいのでは。
      それに自動システムなので、通常頻繁に起こらない読取エラーぐらいでは運転を止めず、読取エラーした物だけ専用の所へ搬送させたのち、人が確認するなどの処理が必要じゃないのかな(後から流れてくるものは通常通り処理する)。
      恐らく自動倉庫なら現場にいる人もほとんどおらず、手動対応はかなりイレギュラーな対応となるはず。

      • by lcc (46023) on 2019年08月14日 19時18分 (#3669130) 日記

        読み取れなかった場合(チェックデジット不一致も)はそうなります。

        問題は低確率で起こるチェックデジットも一致した場合で、
        クライアントは照合の為、サーバにバーコード情報を送ります。
        サーバでは通常、データ照合等を行ってレスポンスを返しますが、バーコードの一部が化けていた場合、データ照合に失敗して自殺します。

        数字変換エラーであれば数字以外をクライアント側でエラーにできますが、根本的解決とならず、
        直すにはサーバにエラーレスポンスを返す処理を加えないといけません。
        が、その仕様が見当たらない&追加するにもテスト環境がないでお手上げといった状態です。

        倉庫1日止めてテストするか・・・
        倉庫動かすだけで数人いるんだよなぁ

        親コメント
  • by Anonymous Coward on 2019年08月14日 16時34分 (#3669026)

    > 常駐プロセスのはずなのにエラー処理がほとんど exit(1) とか・・・

    組み込み屋の書いたブツって、常駐/非常駐にかかわらず、よくこの「いきなりexit()で終了」使いがちだけど。
    ( 他にも「なんの説明もマクロ/変数置き換えもなくいきなりマスク連発」とか、「いきなり登場したマジックナンバーと比較」とか、
    「やたら長い(200行くらい)関数作りがち」とか、「途中からインデント狂ってる」とか「やたら長い変数/関数名」とかもさぁ。 )
    一体どこで誰にあのやり方を学ぶんだろう?

    初めて見た時は「クソみたいなコード書きやがって…」くらいの気持ちしかわいてこなかったが。
    まるで判子でも押したかのように、組み込み屋がどいつもこいつも同じ書き方してるの見ると、そっちの方が不思議でしょうがない。

    • by Anonymous Coward

      組み込み屋を悪く言うな。
      奴らだけじゃないorz
      質の悪い自称技術者に分野の偏りはないです。特に二束三文で派遣されてくる奴。
      二束三文しか払わないから、という話でもあるけど。

typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...