Debugging ARCNET Connections

If the computer beeps when the main ARCTEST screen comes up, and constantly "reconfigures," then there may be a cable problem - either no terminator or the cable is not attached to the card.

Remember, ARCTEST checks the hardware directly and does not need the network to be setup at all. If this test fails you have a hardware problem and LBL will surely not work until you correct the problem! Look at POSSIBILITY 2, and POSSIBILITY 3.

If ARCTEST runs and can succesfully transmit between the nodes, then LBL should work. If it is not working it is most likely due to a setup problem.

One utility we provide which might be helpful is WATCH.COM in the \LBL\DIAGNOSE subdirectory. To use this, put the word "DEBUG" on the ARC_LINK line in AUTOEXEC.BAT, then reboot.

Just add the word "debug" to the end of this line in AUTOEXEC.BAT:

        C:\LBL\ARC_LINK INT?  DEBUG

        C\LBL\DIAGNOSE> WATCH

If you do not get IRQs one direction, but do get them the other direction, at least we have narrowed down the problem. If you get no IRQs on a computer, then it is probably that computer's IRQ. Look at POSSIBILITY 2 below. Or it is a setup problem on the other computer. Look at POSSIBILITY 1. If you get IRQs both directions, but the "busy" counter has activity, then it is POSSIBILITY 1 on the computer getting "busy", or you may merely need to reboot both machines because the network is in an unstable state due to leftovers from a prior (already corrected by you) problem.

POSSIBILITY 1:

First, make sure each node knows how to reach the other. We have found this to be the most common problem. To check this, run LBL.COM on both computers. Use the right arrow key to select "Connections" and then hit . You should see both computers listed on this screen (ie, their node name). Lets say you used node numbers 1 and 2. Lets also say you are looking at the "Connections" screen on node 1. Then on the row for node 2 you should see the "Use Link Module" columns filled in with the appropriate method to reach that node. In the case of arcnet it must say "40 ARCNET". If this information is not there then select "Enter", move to the proper row/column, type in 40 as the module number, or type "ARCNET" as the module name, then hit the Escape key, select "Save Defaults", and hit . Go to the other node and verify it is also setup in the same way. But remember, you are looking at the world on node 2 from its point of view so the row you need to look at is the row for node 1 (because node 1 is the node you are attempting to reach). This should have "40 ARCRNET" for node 2 to know to reach node 1 it must use the arcnet driver. What you are doing here is telling each computer what method to use to reach a particular node.

If the "Connection" is blank, but "Load Defaults" fills in the data, then you may have two copies of a file named "CONNLIST.x". Make sure only one copy of these files exist, and they are in the \LBL directory, not the root directory.

POSSIBILITY 2:

The other, second most likely cause of trouble is an IRQ problem. If ARCTEST works then this is not the problem. But if ARCTEST fails to see all nodes (except itself) then this is a possibility. You should try experimenting with other IRQ selections. Remember to tell your ARC_LINK which IRQ you have jumpered your hardware for.

Most arcnet cards are shipped with IRQ 5 selected. Most documentation will tell you IRQ 7 and IRQ 5 are dedicated to the printer ports. What they fail to mention is that the printer ports will never use their IRQs. The only exceptions to this are programs such as Little Big LAN when using the parallel ports to link, or some other file transfer programs, or a few printer spoolers. So, it is almost always safe to use the printer IRQs for arcnet cards. If you have an XT type hard drive controller it is also using IRQ 5 so you must change the ARCNET IRQ to something else.

If you have switch the card to something other than IRQ 5 then you should know that IRQ 3 is used by COM2 and COM4, and IRQ 4 is used by COM1 and COM2 If a mouse driver, for example, loads on COM2 then it will effectively steal IRQ 3 away from a arcnet card using IRQ 3. IRQ 4 has the same problem for COM1 and COM3. Other possible conflicts are CDROMS, sound cards, FAX cards, scanners, bus mice, and some video cards. But the printer ports almost never cause an IRQ conflict.

POSSIBILITY 3:

The I/O address selection is sometimes a problem. If you use I/O address 2E0 or 300H then you are usually safe. Some CDROM boards may use the 300H address. If you have COM4 then 2E0 for the arcnet card is not a good idea. This is because COM4 uses 2E8 so when software enables COM4 it will reset the arcnet card and bring down the network.

Again, the only way to tell if you have an i/o address conflict is to try a few combinations.

POSSIBILITY 4:

Arcnet cards have onboard memory which may conflict with EMM386 or the bios shadowing. Make sure you tell EMM386 the exclude the arcnet memory. For example, if your card is set to segment D000:

        DEVICE=EMM386.EXE X=D000-D3FF

GENERAL

Make sure the network loads. It is possible AUTOEXEC.BAT has a line which exits to a secondary batch and never returns. If this line is located above the network lines then the network never loads even though the proper lines are there. Make sure you see our sign on message with version and serial number.

FINAL NOTE:

Since there are so many combinations to try it is usually easier to get the network working and then work backwards from there. So you might have to remove or disable other hardware to be sure nothing else is in the way. Also remove (or REM out) as much as is possible in CONFIG.SYS and AUTOEXEC.BAT. Once, working, restore your system item by item until the problem shows up.

Top of Tech Help -or- Table of Contents -or- Top of Form