Serial Rapid IO

[Manatee]

Hello all, would like to use Labview to communicate with a new product design that uses XMC connectors and has a "serial rapid IO" interface. It also has a serial interface that we use for initial development, but its slow for data aquisition; so I would like to use the srio interface, any suggestions.

[JÞB]

Do or do not, there is no try-

---

XMC- looks good on paper-   It MAY replace JTAG someday-  or it may go the way of beta format tapes.   Support for the standard prior to adoption as a common interface is allways a risk.  Do or do not.

[Manatee]

Well, I agree with you on that point. We have had some trouble with the XMC connectors staying on; some issue with the solder process. We actually had no choice in the selection of the connectors. The customer spec detailed this connector for use with the project. I'm not sure anyone on the design team had any prior experience with the XMC connector. So, do you have any thoughts on the srio interface and labview?

[Dennis_Knutson]

It does not look like NI has a card that suppots Gb rates. If you have done a search for instruments, you would want one with some sort of interface with which you can remotely program the instrument. It might be GPIB, Ethenet, USB and all of these are easy to use with LabVIEW. You can use the Instrument Driver Network to see if a LabVIEW driver exists for a particular instrument.

[Manatee]

Actually I was thinking of trying a PCI to SRIO bridge card. I figure that labview can access PCI with no problem. I can use PCI as a bridge to the SRIO port. I have found a couple of these cards on the net from different manufacturers. I guess all I will need to know is if labview can talk to the card. Here is the link to one such card; http://www.jennic.com/products/wireline/serial_rapidio_pci_bridge; just to give you an idea of what I was thinking.

[Dennis_Knutson]

LabVIEW can access PCI if you take the time to write a low register level driver (not trivial) with VISA or the vendor of the card has a documented api for their driver.

[Manatee]

Writing a low level driver is out of the question. How ever you make a good point about the API. I will make sure of that fact before I go purchasing a card that may well cost a couple thousand dollars.

[LV_Pro]

Yes, be very careful when selecting, don't necessarily buy into a vendor's statement "LabVIEW drivers" available. I have been burned a number of times by this, particularly when the customer has already invested in the hardware. If you find something, come back and ask about it here, there may be someone who has proceeded you and can offer yea/nay for the particular equipment. Too often the "driver" appears to have been written by someone that had no experience with LabVIEW prior to that task. I just spent a couple of painful weeks tracking down a "LabVIEW crashing randomly" problem to discover that it was the LabVIEW calls to the hardware manufacturers dll (they supplied the "driver"). After a lot of conversation with them I got info about their dll's calls to an underlying dll, which when I duplicated their calls to the dll directly eliminated the problem. So when you find the hardware ask here first before commiting to that path. It may end up that you are the first scout down that path, but it may be that others have gone before.

Good Luck!