LabVIEW
Desktop RT target with USB camera support
Hi,
I am converting a desktop PC into an RT target to deploy vision system for inspection. I'm just protyping my design and to have Real-Time control I have opted for this approach. My question is, can I use Vision modules with USB camera support inside the RT target?. The desktop PC has four USB ports and it should have required vision software installed inside. Can someone guide on the approach and walk me through the procedure of installing vision modules inside RT target so I could use Vision acquisition and Development modules and deploy entire system inside the RT target.
The part "I/O control" comes next defnintely by using PCI cards.
Regards.
LabVIEW RT on a desktop is always running on Pharlap ETS. LabVIEW RT on a cRIO is running on either Pharlap ETS, VxWorks, or NI Linux RT depending on the hardware model of the RIO hardware. If it is old and has a x86 compatible CPU it generally runs Pharlap ETS. If it has a Power PC CPU it runs VxWorks and if it is based on the Zync embedded ARM CPU or is one of the modern x86 targets it runs NI Linux RT either for ARM or x64.
Generally driver support for other than NI hardware on the Pharlap and VxWorks based targets is non-existent. For NI Linux RT based targets you can definitely get almost every driver to work if you have the driver source code available for a fairly recent Linux system. Developing an USB camera driver for Pharlap or VxWorks would be a very huge effort and there aren't any readily available anywhere, not even for a lot of money.
Well if you get to step 7 in that tutorial and see the card in NI-Max the VISA driver should be ok. Now comes the real fun part. Do you have a register description of your PCI device? Basically your PCI device has a certain number of basic registers as mandated by the PCI standard for Plug and Play configuration and then it has another set of registers that are entirely proprietary to what it implements. There is no further standard in what a PCI device has to provide, in the most simple case it only supports a few extra registers that let you configure some functionality and read and write some data to it. In the worst case it contains a myriad of registers that control just about anything imaginable and some shared memory interface to transfer data to and from it.
What of all that and how is defined in the register description of your device which you must have available of course. For many devices however this type of information is considered top secret trade secret and gets guarded with not only an absence of any available documentation but also with involvment of a legal departement that is determined to suffocate any attempt to get such information out there right in the earliest possible stages.
Assuming you have a proper documentation of your PCI device register map you would start using the VISA->Register Access functionality in LabVIEW. Expect to forget about anything you have learned so far about communicating with devices. This is not about sending a SCPI formatted string command of type ::DATA:ACQ? to the device but about setting the bit x in register 0x2345 to TRUE after you properly wrote address 0xZZZZZZZZ into device register 0x1234 together with a few dozen other bit manipulations in different other registers and the amount of data to transfer in register 0x3456. Repeat and rinse for every other operation you want to do on your PCI device. Also expect the register map description to assume that any reader of it knows the device already intimately and has a very good low level understanding about interrupt handling, DMA transfers and how the various bits and bytes in all the registers are supposed to work together.
VISA makes most of this available without any need to dive into kernel device driver programming in C or assembly code but it can not take away the inherent complexity of such a low level device interface.
Well I never did this but it would seem that you are almost there. Now you need to create a LabVIEW project and add that target to it. In there you should be able to open a VISA resource to your board using the PXI::.... resource identifier and then using the low level VISA functions to read and write the registers. Have you tried that?
I’m just guessing here but have you tried to read address 0x0000 instead. The address you show llooks like an absolute linear address as how the PCI resource was mapped into your system but it will of course change if the board is placed in a different slot. Accordingly you do not want this variation in a driver but instead only want to use the offset to the register map base in your driver. I’m convinced VISA will add that offset to the base address as assigned by the PCI enumerator.
This post here seems to be relevant to your problem although not a complete solution.
