IOTAモデルからPLSモデルに移行するに際して何年も苦悶したこと。
結論から言えば、要求仕様の根幹が不明なままだったことに帰します。
今はたくさん出荷されていることから少なからず実用的だったのだとホッと安心していますが！
DUO青木保さんが井一義人さん・小木曽さん・田辺和夫さんの要求に応じて提示したIOTAモデルは図形要素が複雑な入れ子になっており、さらに形状特徴まで含まれており、そして図形要素の属性として工具軌跡を持たせる構造でした。
＜１：AP40の図形とは何ぞや？＞
IOTAモデルを語る前に、AP40の図形とは何だったのかという疑問がありました。つまり一本の直線分でさえ、板金製品の形状の直線分要素なのか、それとも工具軌跡を割り付ける為の直線分（すなわち、工具の運動軌跡を指摘するための直線分）なのかということです。PLSモデルは前者の形状の要素と捉えたのですが、AP40の図形は何とでも解釈できます。もし、自動加工(自動割付)しかないとすれば、PLSモデルのように捉えるのが素直なのですが、手動割付ならばどのようにでも解釈できます。
板金製品の形状と捉えたことで、随分悩みました。
旧アムテックの石井さんからも、「AP40・AP60の仕様は、線一本でも割付くだ！」と言われて苦悶しました。ループ化してしまうことで、無駄が生まれたからです。
但し、ループ化するメリットは自動加工のみならず、レーザーの工具軌跡を生成するにも有益であると考えていました。もっとも、旧C＆Cの田辺和夫さんが、「AP40・AP60では隣接要素を探しに行っているんだ」と仰っていましたが。
＜２：図形穴さえ図形要素の属性なの？＞
IOTAモデルには図形穴は、図形要素の属性として実現するようにしようとしていました。もしそうなら、これは大変面倒な実装を必要とするのです。
AP40では図形穴は基本的に金型が開ける形状のことで、図形要素の属性などにするのは変な取り扱いです。従って、PLSモデルでは、GRIDやLAAなどのパターン穴を含めて、形状穴としての図形にしました。
井一さんたちは一体青木さんにどんな要請をして図形の属性などという形式を取らせる事にしたのか、悩みました。
＜３：IOTAモデルは複雑な入れ子図形になっている？＞
IOTAモデルはツリー状の複雑な入れ子図形になっていました。そして、その図形の中に形状特徴も含まれていました。いわゆる、形状としての図形が入れ子になっていること自体は分からなくもないのですが、この構造だと一つの展開図が入れ子状の展開図を持てる構造となったりします。ソフト工房１０階に席が戻った時、旧アムテックの坂口聡さんが「アセンブリーはサブアセンブリーからなるんだ」と言われましたが、これをどうやら青木さんに暗示して、IOTAモデルに含ませた気配がありました。
PLSモデルでは展開図(MfDevelopParts)は複数の外形(Outer Loop)を持てますが、入れ子にはでいませんし、たとえば図形穴がその子供に直線分を持つようなこともできません。
こうしてしまったことで、随分苦しみました。
＜４：自動加工の形状特徴が入れ子になっている？＞
IOTAモデルでは、切り欠き形状などの形状特徴が子供や孫の形状特徴を持てるような構造でした。これは形状特徴をサブに分解していける構造を持たせるもののようでしたが、PLSモデルでは形状特徴の入れ子構造はありません。
というのは、大きな形状特徴を分解して、まず工具軌跡を割り付けて、そして割り付けきれないサブの形状特徴にさらに工具軌跡を割り付けるようなことを想定しなかったからです。大きな形状特徴に割り付ける大きな工具が、サブの小さな形状特徴に割り付ける小さな工具というのは現実にはあまりなさそうと考え、それくらいならマニュアル（手動）割付にすればいいと考えたからです。どうせ自動割付には限界があり、ユーザーの意図通りには割付ようがないという先入観もありました。
形状特徴を入れ子構造にしなかったことでも後々随分悩みました。
＜５：工具軌跡のダブルモデル？＞
旧C＆Cの田辺和夫さんの意図では、IOTAモデルの基本工具軌跡は図形要素にT番号や必要な加工に関する情報を付加したものとしてAP40などの工具軌跡は踏襲しない考えでした。でもそれでは素直にパッケージポストに繋ぐことができないので、ポストに繋ぐ中間状態として、基本工具軌跡からGコードベースの工具軌跡を生成するダブルモデルが必要になると思っていました。
でもそれを実現するダブルモデルは少なからず複雑で混乱するものになっていくことが想定されました。
従って、PLSモデルでは素直にGコードベースの工具軌跡を生成するようにしました。が、そうしてしまうことが私を苦しめました。
