Windows95/98の場合「自己診断情報」を確認してください。
WindowsNTの場合「システムイベントログ」を確認してください。
可能です。アプリケーションプログラムはオブジェクトレベルで互換性があります。
ただし、アプリケーションプログラムのポータビリティーに関してはいくつかの制約があるので注意してください。例えば、AISA1517AやAdpci1526で複数枚対応のAPIを利用したアプリケーションプログラムを、APCM1519/APCM1519Aで動作させることはできません。APCM1519/APCM1519Aは複数枚で動作させることができないので、複数枚対応のAPIを用意していません。
デバイスドライバを更新するには、まず既存のドライバを削除してから、新しいデバイスドライバをインストールします。
デバイスドライバを更新するには、必要なファイルをハードディスクの所定のディレクトリにコピーするとう方法もあります。（詳細はマニュアルを参照してください。）しかし、この方法は、あくまでもデバイスドライバの「更新」にしか適用できません。つまり、この方法でインストール（新規に登録すること）はできません。
弊社の提供する全てのARCNET用デバイスドライバは、データ受信には割込を使用しています。そもそも、Windows95やWindowsNTでは、ユーザープログラムで割込を直接使用することはできません。
ArcReadを呼び出す際に、タイムアウト値を-1や0ではない値（希望のタイムアウト時間）に設定します。すると、他のスレッドで送信やその他の処理を行うことができます。
ArcNet ActiveXコントロール（OCX）では、パケットを受信するとイベントが発生するという割り込みに似た機能を提供しています。
以下に示すように、GetProcAddressで、取得する関数を正確に型キャストしてください。
ArcOpen = (int (WINAPI*)(void))GetProcAddress(hlnstDLL, ”ArcOpen”);
ArcClose = (int (WINAPI*)(void))GetProcAddress(hlnstDLL, ”ArcClose”);
ArcRead = (int (WINAPI*)(char *, int))GetProcAddress(hlnstDLL, ”ArcRead”);
ArcWrite = (int (WINAPI*)(char *, int))GetProcAddress(hlnstDLL, ”ArcWrite”);
ArcIoctl = (int (WINAPI*)(int, void *))GetProcAddress(hlnstDLL, ”ArcIoctl”);
残念ながら、デバイスドライバの内部では、１つしかタイマを持っていないため、別々の値を設定することはできません。
残念ながらできません。
ArcnetClose()を呼ぶ前にコンフィグレーションレジスタのTXENビットを0にするという方法がありますが、期待通りの動作は保証できません。
現在のドライバでは、ArcCloseを呼び出してもTXENをクリアしないようになっています。
ARCNETボード側でArcCloseを呼び出すと、受信動作は禁止され、相手側は送信できなくなります。
ArcCloseが呼び出されたARCNETボードに対してパケットを送信する相手ノードは、送信できなくなります。このため、送信完了するまで待つというようなソフトウェアになっていると、ずっとそこでループすることになりますので、注意してください。
可能です。しかし、同時に単一のドライバを重複してオープンすることはできません。別々のプロセスから同一ボード用のドライバを同時にオープンすることはできません。別々のプロセスから同一ボード用のドライバを共有使用したい場合には、排他制御を行い、一方のプロセスが使用する場合には、他方のプロセスは使用しないようにする必要があります。
複数のスレッドから同時にArcReadとArcWriteを使用することは可能ですが、ArcReadとArcReadあるいはArcWriteとArcWriteを同時に発行しないようにしてください。ArcIoctlについては、このような制限はありません。
できません。
Ackは受信応答です。受信側がパケットを受信し、COM20020から読み出したことを送信側に伝えるために用いられています。（Ackの詳細についてはTMCのマニュアルを参照してください）
デバイスドライバは、受信割り込みを使用していますが、Windows98/NTにおいては100μs以内に割り込みに応答できるという保証がないので、WindowsXXを使用する限りこの問題は解決できないでしょう。
バッファサイズは、ショートパケットの場合でも、送信時には256バイト、受信時には512バイトを取るようにしてください。弊社のデバイスドライバでは、アプリケーションとCOM20020の送受信バッファの間のデータ転送を行うのみであり、たとえ100バイトのパケットであったとしても、COM20020に書き込まれるイメージは100バイトではなく、256バイトです。
また、ネットワークに送信されるデータ数（ビット長）は、パケットフォーマットの中のCOUNTに依存します。常に256バイト送信されるわけではありません。
ISAからPCIに移行することによって大きく異なる点は、PnPになることです。ボード上のCOM20020のレジスタはI/O空間に配置されますが、このアドレスはPnP BIOSが決定します。また、割り込みもPnP BIOSが決定します。
PnPやPCIに関する簡単な知識があれば、問題ないでしょう。
弊社で提供しているARCNETのデバイスドライバはTCP/IPの下位層として動作するようになっていませんので、WinsockからARCNETを利用することはできません。
HUBを使用すれば、物理的に接続可能なノード数を増やすことができます。
ネットワークをスター状に構成することができ、障害切り分けが簡単になります。
欠点は、コスト的に高く付くことです。
HUB(E-042シリーズ）には、終端抵抗が内蔵されています（スイッチで切り換え）が、ネットワークのもう一方の端は終端する必要があります。（HUBを使用するとネットワークの端は複数できます。）
HUBの動作は簡単ですので、次のようなものであると理解して下さい。
HUBは、あるポートからパケットを受信し始めると、それ以外の全てのポートにそのパケットを送信します。ポートに全くノードが接続されていなくても、必ず送信します。
実験用として使用されるのは構わないと思いますが、実機に使用されるのは、以下のような理由からお勧めできません。
市販の電話用コードは、実は全くツイスト処理（ひねるという意味）がされておらず、単に電線平行なコードなのでノイズの影響を受けやすいため。
実質的には91Ω（弊社標準品）でも問題ありません。終端抵抗は、インピーダンスのミスマッチによる反射を抑止するためのものです。
特性インピーダンスが93Ωの同軸ケーブルに対して、91Ωの抵抗で終端を行った場合のSWR（定在波比）は1.022であり、全く問題のない値であると言えます。これは、以下の式から算出されます。
反射率ρ＝（93-91）／（93+91）＝0.011
SWR＝（1+｜ρ｜）／（1-｜ρ｜）＝0.011／0.989＝1.022
通常、SWRが1.2以下であれば問題ないと言われています。あまり、ミスマッチにこだわると、BNCコネクタのインピーダンスまで問題視しなければならなくなります。一般的なBNCコネクタは50Ω用に設計されており、一部の特殊なものは75Ω用に設計されています。おそらく、93Ω用に設計されたBNCコネクタは市販されていないと思います。
TMCによると、HYC2485Sの場合ノード間最小距離は5mという制約があります。
この場合、COM20020をバックプレーンモードに設定する必要があります。更に、P1MODEを1に設定する必要があります。Windows95/NT用でデバイスドライバでは、トランシーバとして「RS-485タイプ」が選択された場合、自動的にこれらの設定を行います。伝送速度を5Mbpsで使用するには、トランシーバにHYC2485Sなどを使用して下さい。HYC9088S-SKなどの2.5Mbps専用のトランシーバを5Mbpsには絶対に設定しないでください。焼損など破壊する可能性があります。
基本的には、Phase-A/Phase-B信号の極性は一致していることが求められます。
HYC9088S-SKやHYC2485Sなどのトランシーバの場合には極性が一致していなくても通信できます。
ダイパルストランシーバの場合には、パルスの有無によりビットを判定しているようなので、逆に接続しても動作します。ダイパルストランシーバは、一対の正負のパルスにより符号を形成しているからです。
バックプレーンモードでHYC2485などのトランシーバを使用した場合も、極性が逆でも動作します。この種のトランシーバは、ライン上の符号としてダイパルスに似た符号を用いているからです。
上記の２つのケースでは、ライン上の信号にDC成分が含まれていないため、パルスの有無が符号１／０に対応しており、パルスの極性が逆であっても符号１／０には影響せず、通信は成立するようです。
しかし、SN75176などのRS-485トランシーバの場合、状況は異なります。このトランシーバの出力にはDC成分が含まれます。極性の違いは、符号１／０を逆にすることになりますので、極性を合わせないと通信が成立しません。
可能です。例えば、ArcNaviはVisualBasicだけを用いて作成しています。ボードへのアクセスはOCXのみを使用しており、COM20020のレジスタを直接操作することも行っています。
原因として以下のようなことが推測されます。
1) DoEventでポーリングを行っていると、これによってコンテキストスイッチが発生します。コンテキストスイッチが発生することにより、他のARCNETに関するメソッドやプロパティーの参照が起こると、OCX内部の状態が破綻する危険性があります。例えば、他のコンテキストでReadメソッドを呼んでいる場合などです。
2) サンプルプログラムでは、Writeメソッドにより、パケット送信のきっかけを作っています。パケット送信が完了したことを知るには、イベントにより知るべきであり、ポーリングするべきではありません。ポーリングするのであれば、DoEventによってコンテキストスイッチを起こすべきではありません。DoEventを用いても構いませんが、イベントの通知により、Writeが完了していない間はReadメソッドを呼び出すべきではありません。
3) デバッグ環境では、OCXが正常に動作しないことがあるとの報告（事例）があります。デバッグ環境というのは、VBによって生成される.EXEを実行するのではなく、単にgoとすることを意味します。なにか問題があれば、.EXEを生成してそれを実行してみてください。
基本的に、ブロードキャストパケットを全て（取りこぼし無く）受信することは保証できません。つまり、データの取りこぼしはあり得ます。
データの取りこぼしの原因として以下のようなことが挙げられます。
1) ブロードキャストされるデータ量と、それを受信して処理する側の処理能力のバランスが悪い
2) パソコンが遅い
3) デバイスドライバが遅い
4) アプリケーションプログラムが遅い
5) 他のデバイスからの割り込みが頻繁にかかりすぎている
6) OSが遅い
ReceiveAllの場合には、フロー制御が働かないため、前述のブロードキャストと同様に、取りこぼしという問題も発生し得ると考えられます
ARCNETを利用するアプリケーションとArcNavi とを同一のボードで使用することはできません。
ArcNaviを使用している時には、ArcNaviがデバイス（ボード）を占有しますので、他のARCNETを（ARCNET用ドライバを）使用するアプリケーションを起動すると、以下のようなメッセージが表示されます。
「ARCNETデバイスのオープンに失敗しました。デバイスドライバがインストールされていないか、デバイスが使用中の可能性があります。」
