Tech Blog/技術ブログ

こんにちは、株式会社アーチのT.Tです。 WPF (Windows Presentation Foundation) でモダンなUIを構築する際、.NETが提供する Fluentテーマ (PresentationFramework.Fluent) は、手軽に洗練された見た目を取り入れられるため非常に便利です。私自身、最近のプロジェクトでこのテーマを採用する機会が増えており、その恩恵を大いに受けています。 しかし実務で使い込んでいくと、その便利さの反面「かゆいところに手が届かない」といった細かなレイアウトの壁にぶつかることも少なくありません。例えば、「デフォルトの CheckBox の幅が固定されていて、思うように配置できない」と悩んだことはありませんか？ 今回は、私の実体験から得た知見をもとに、この問題の背景と、GitHubで公開されている公式ソースコードを活用して独自にカスタマイズし、スマートに解決する方法について解説します。 CheckBoxの変更前、変更後のイメージ 1. 問題の背景：CheckBoxの幅が固定されてしまう WPFのFlue

株式会社アーチのN-Sです。 弊社でPLCラダープログラム製作を主に担当して20年ほど経過しました。入社当初は触ったことすらなく、一から制作方法を学ぶこととなりました。 　 今回は開発をおこなう上で身についた技能についてお話しさせていただきます。 プログラム2巡目からの挙動予測 私がラダー作成で身についた技能が「プログラム2巡目からの挙動予測」でした。 ラダープログラムの特性で必ず同じプログラムを毎回処理することとなり、1巡目で考え通りの動作でも、2巡目では意図した動作とならないことがあるためです。 挙動事例 例えば、スイッチ操作にてモーター運転、停止指示を出すラダーがあります。また運転中に何らかの異常が検知された場合にモーターを停止させるラダーを作成しました。（下図） このラダーを実際に動作させ運転スイッチをオンしますが、モーターが運転できませんでした。 実際の動作は以下のものとなりました。 1巡目で運転指示を出して運転指令保持をオン、そのまま運転指令出力をオンします。 続く1巡目の処理でモーター動作確認の信号返答（運転アンサー）がオフのままの

はじめまして、この記事を書いているレイです。 入社してもう少しで半年になる一番社歴の浅いメンバーです。まだまだ未熟ではありますが日々新しい技術や知識を吸収しながら業務に取り組んでいます。今回は業務の中で気づいたことについて書いていきます。 先日、あるプロセスのCPU使用率が時間の経過とともに上昇し、パソコンの動作が重くなるという問題に遭遇しました。調査する中で、タスクマネージャーに表示されるCPU使用率は「一定時間の間に、そのプロセスがどれだけCPUを占有していたか」という割合から計算されていることを知りました。 OSやタスクマネージャーが「使用率」を算出する仕組みは一見複雑そうに見えますが、単純な時間の計算で求められているのであれば、自作のプログラムでも近い値を再現できるのではないでしょうか。今回は、その仕組みをもとに実際に検証してみます。 差分からもとめる C#では Processクラス の GetProcesses()メソッド を使うと、実行されているすべてのプロセスのリソース使用状況を取得できます。 今回はこの中の TotalProces

こんにちは、トミーです。 今回は、私が弊社内での困り事解決に取り組んだお話をさせていただきたいと思います。 弊社では、事務所内からトイレのドアが直接見えないレイアウトのため、使用状況を確認するには毎回廊下まで見に行く必要がありました。 事務所にいてもトイレの使用状況がわかったらいいのに…そんな声が多く挙がり、この手間を解消するため、「事務所にいながらトイレの使用状況が一目でわかるシステム」を製作することになりました。そのシステムづくりを私と同僚CTの２名が担当することとなりました。 システムは、トイレの施錠・開錠や室内の人物を検知し、その情報をBLE(Bluetooth)を用いて事務所内の表示灯を制御させる仕組みです。 トイレ使用状況の可視化システム機器構成イメージ 各機器の構成と役割 システムは主に以下の3つのユニットで構成されています。 トイレドアに設置された送信器とスイッチ 蛍光灯に取り付けた光センサおよび人感センサを内蔵した送信器 事務所に設置された受信器と表示灯 それぞれの詳細を解説します。 1. トイレドア側ユニット（カギの状態検知）

はじめまして。株式会社アーチの「2K（にけ）」です。 社内では中堅プログラマーとして、日々コードと格闘しています。 記念すべき技術ブログの第一号記事担当に抜擢されました。 日記すら小学生の絵日記以来ご無沙汰で、ブログ執筆は人生初の試みです。 拙い文章かもしれませんが、どうか寛容な心でお付き合いいただければ幸いです。 今回は、私がプログラマーとして入社して1年目、初めてメインで任されたジョブで、 現在も稼働中の 「加工スケジュールの可視化」 事例をもとに、技術的なアプローチと当時の気づきについてお話しします。 当時は、通信ステータスの管理やフラグ制御の複雑さに翻弄され、通信断が発生した際の「自動復旧処理」の考慮漏れを指摘されるなど、まさに試行錯誤の連続でした。 技術的な未熟さを痛感し、てんてこ舞いだったことを覚えています。 しかし、このプロジェクトを通じて得た最大の学びは、プログラミング技術だけではありませんでした。 「お客様と自分との間にある『イメージの乖離』をどう埋めるか」 「専門的な仕様を、いかにわかりやすい言葉で説明するか」...

昨今、AIの進化は目覚ましいものがありますね。 弊社では、ソフトウェア開発の 支援 にAIを活用することはありますが、まだ製品自体にAIを組み込むまでには至っていないのが現状です。 そこで、「自社製品にもAIを本格的に活用していこう！」という目的のもと、社内で定期的にAI勉強会を開催しています。 今月のテーマと中間発表 現在は、以下の3つのテーマから各自が調査したいものを選び、チームで調査を進めています。 そして9月は、その中間発表会が行われました。 調査テーマ: 音声によるPLC操作 AIによるPLCラダー（制御プログラム）の作成 生産計画のAI化 特に PLC （※工場の機械などを制御するコンピューター）関連の2テーマは、業界全体でもAI活用がまだ進んでいない分野であり、弊社としても非常に期待の高いテーマです。 また「生産計画のAI化」については、最終的に「月ごとに注文される製品とその量を予測する」という、より具体的な 受注予測 の実現を目指すことになりました。 実現可能性と次のステップ 今回は中間発表ということで、主に「それぞれのテーマが技