How do the new RS-485 boards configure in Windows XP?

[RudyRed]

I just finished assembling 6 brand new identical PCs for use as test controllers.  Each PC has installed a brand new NI RS-485 board and a brand new NI GPIB board (both are PCI versions).  Installation of the drivers that came with the boards went well and the serial and GPIB diagnostics found no problems.  In all cases, the serial drivers were installed first.

I go to fire up my serial communications test application andI remember that I forgot to configure the serial board for 2-wire Tx Auto-ready (at least that's what it was called five years ago--I think it's called 2-wire auto these days).  I need the base address of the port for the app init anyway so I go to WinXP's Device Manager (as always), pop up Properties, crank the receive fifo to max and the xmit fifo to min, change to 2-wire, and click the Resources tab.  I was expecting to see the usual 4-character hex address for the port.  Instead, I see the same 8-character hex address as has the Multifunction Adapter--no port address at all!  The same for the other port.  Normally, the multifunction parent shows, besides its 8-char address, the 4-char addresses of its children.  Not so in this case!  I have an up-to-date XP system with a slightly older one of these boards and it functions fine--and the XP configuration is proper; but in this system, MAX doesn't show RS-485 ports, just com ports.  The Device Manager shows RS-485 ports.  But this is my development system, which is oddly configured to run both LabVIEW 7.1 and 6.0.2, as well as both the LV7.1 and LV602 NIDAQs, with NIserial v5.1.  On the one new system I've been describing, I've backed up from NIserial v8.1 to v6.1 with no improvement.

My next step, sans advice from the illustrious members of this forum (you've helped me before--thank-you!), is to strip everything NI from one of these new systems and start fresh with just the serial, hoping that my LV6i distribution contains NIserial v5.1.  My test app uses traditional serial VIs (necessarily) and I will load AccessHW.

More food for thought:  Motherboards are ASUS A8N-SLI Premium, CPU is AMD Athlon 64 3700, memory is Kingston HyperX 512 MB DDR400--no overclocking, ever.  If anyone has any ideas I'd appreciate hearing them.  Thanks.

[RudyRed]

UPDATE--On the one of the six PCs that has the 4-port RS-485 board I reinstalled all the NI stuff from the LabVIEW 6i distribution, then installed NIserial v1.5.  Everything flew fine.  The Windows configuration is proper and it works!  MAX doesn't know there's an RS-485 board, and it doesn't know, in its software section, that there's a NIserial driver (it's MAX v2.0).  Then I went through the same process with one of the other of the six PCs (which have the recently purchased 2-port RS-485 boards).  After rebooting after serial driver installation, Windows can't find the driver for the hardware it senses.  Taking a slightly different route, I can get to the point that I can select from available drivers for NI multifunction adapters.  I choose the RS-485 multifunction parent, but then in Device Manager the ports have yellow exclamation points; and the properties page has no Resources tab!  Since I need the base address this situation is non-functional for me.

Is there really no interest in this matter?  Doesn't anyone buy new RS-485 PCI boards to run on WinXP anymore?  It seems pretty clear to me that either there's a bug in this board's hardware/firmware or NI is pulling another fast one, trying to force their vision of how test and measurement computing should be done on unsuspecting buyers.  What am I supposed to do now?  Buy new 4-port boards?  What a clever and profitable (for NI) solution!  I'll probably try the tech support route, but when you haven't PAID for product support...well, you get what you pay for.  I get routed to a salesman who wants to get me to buy the support program.  He likes to say that they won't leave me hanging and finally routes me to tech support which has become totally worthless.  They require so much hand-holding...before they fail utterly to provide any worthwhile solution--unless you consider reinstalling the OS to be worthwhile.  They simply have no insight into these matters.  Maybe those of us whose companies have decided to eliminate the considerable expense of the support program and perpetual upgrades just get routed to the tech support training section (after the sales pitch) and are promptly forgotten.  If you opt for an email exchange with an "engineer" the useless result is the same, it just takes much longer.

Good luck to you all.

[JasonSmith]

Hi RudyRed,

I am sorry that you did not receive an adequate answer from our technical support engineers.  If you post the reference number(s) from your technical support phone call / email I can look into what happened with those requests.

It sounds like you are using two different types of RS-485 boards in your computers.  We now sell two lines of RS-485 PCI boards: the PCI-485 series is our Legacy line of boards, while the PCI-843x series is our high performance line.  There are significant differences in the architecture of these boards, so it will be important to know exactly which you are using before I go on to answer your question.

Please post back with the part numbers (Usually starts with ASSY on the board) for the two boards (One in the working computer, one in the non-working computer) so that I will know exactly which you are using.

Thanks,

Jason S.
GPIB & Serial
National Instruments

[RudyRed]

Thanks for the response, Jason.  You are correct.  I did get the high performance instead of the new "legacy".  I never considered that I might want the legacy line, especially since "legacy" has for the last many years meant "ISA/EISA" buss; and I've become used to product designation changes.  It looked like an improved PCI RS-485.  How different is it?  Can I somehow get individual port addresses to use in my programs?  Can I still use the accesshw to check for transmit fifo empty?

[JasonSmith]

Hi RudyRed,

I can confirm for you that there are no I/O registers with the 843x series boards.  There are several improvements with the new boards, with the most significant being the use of DMA for serial data transfers and arbitrary baud rates from 57 baud to 1Mbaud.  The downside is that they are not compatible with applications which would have used standard 16550 style registers.

I am currently investigating whether there is another means which can be used to check the status of the transfer FIFO, I will let you know what I find out.

Thanks,

Jason S.

GPIB & Serial

National Instruments

[JasonSmith]

Hi RudyRed,

I was able to confirm that the board was designed to eliminate the use of I/O Space due to the problems which is brings.  With more and more peripherals sharing the same small amount of I/O space, it is common for the system to be unable to allocate the I/O Space needed by a resource.

From your reference to AccessHW I assume that you are using LabVIEW as your programming environment?  If this is true, then I also assume you are using NI-VISA to access your serial hardware.  When using VISA in LabVIEW, the VISA Write function will not return until the last byte has been transferred to the serial board's hardware FIFO.  Once the data is in the hardware FIFO, it will be transferred out the port in a deterministic time.  Your application should be able to delay for a brief moment to ensure that the bytes in the FIFO have been transmitted.

The calculate the maximum amount of time it can take for the last byte to leave the serial port the following equation can be used:

(SizeOfTransmitFifo) * (SizeOfSerialFrame) / (BaudRate)

The size of the transmit FIFO can be set through the Windows Device Manager, and the size of the serial frame depends on your data bits, stop bits, and parity settings.

For Example: Using 115,200 Baud, 8 Data Bits, 1 Stop Bit, and no Parity, with a 64 byte Transmite Buffer:

64 * 10 (Start bit + 8 data bits + stop bit) / 115,200 = 5.5ms

I would highly recommend something of this manner in your application, so that you can continue to use the newer serial boards which you have purchased.  In addition to several performance enhancements, the lack of an I/O space dependency is only going to become more important in the future.  If this will not work for you, you could always work with your sales representative to see about exchanging these for the Legacy PCI boards, with which your existing application works.

Please let me know if you have any more questions, or if I can help in any other way,

Jason S.
GPIB & Serial
National Instruments

[RudyRed]

Thanks for the info, Jason.  No, we don't use VISA, but rather the traditional serial VIs to receive and LabVIEW code that uses the inport/outport VIs to transmit.  We found in early development that inserting any set value of LV wait yielded unpredictable results.  In our application we send an address with mark parity followed by data with space parity.  If parity is changed before the address is fully sent, the communications is corrupted.  A few years ago we worked for a while with an NI person named, if I remember correctly, Andy Watchorn, trying to figure out a way to use VISA to accomplish our communications reliably and as fast as possible.  But it was not possible.

That's an interesting looking equation...but wouldn't you be at the mercy of Windows in doing the timing of the 5.5 ms--and how do you propose to get tenths of a millisecond resolution out of the LabVIEW timer?  I will take your suggestion and contact our sales rep about an exchange/credit.  Thanks for your help, Jason.