Problem programming a 6503

[kander1]

Hi,
 
Platform: Windows Xp running Labwindows/CVI on one PC and the realtime application on another pc.
 
Labwindows/CVI version: 8.1
Labview realtime: 8.2
Visa driver: 4.2
 
 
I'm having a problem programming a pci-6503.  I'm using VISA to directly access the registers rather than DAQmx.  When I first installed the card it worked.  It's been sitting around for a few months and I tried it again and it doesn't work.  There may be a version problem.  I vaguely recall that we upgraded one or more of the software packages listed above.
 
I'm including the file I'm using to test the 6503.  It's programmed for output only and every other output is 1 and 0.  The program gets through the test program reporting no errors, yet I don't see the outputs on the connector.  I'm sure I have the correct pinout. 
 
Some clues that may be helpful:
 
1) The examples in 'Find Examples' don't work either (they use DAQmx).  They give me an illegal device or device not found error.
 
2) The 6503 shows up in the devices section in MAX and is reported as operating properly.  I used to be able to run the card through the Visa test panel, but now I'm getting the following error: VI_ERROR_MACHINE_NAVAIL.
 
3) The test code example code I gave you correctly identified the NI board number.  This means that it is at least talking to the card.


tmp1.c:
http://forums.ni.com/attachments/ni/70/8397/1/tmp1.c

[Brooks_C]

Hello Kevin,
As far as I can tell the software version you have should be compatible.  From the information you've given it?s a little difficult to determine if it?s a software or hardware issue.  I know you've already done some tests in the Measurement and Automation Explorer, but can you please clarify a few things?
1.  Does the device pass a self-test?
2.  Does the device reset successfully?
3.  Can you change the output using a DAQmx test panel?
The Measurement and Automation Explorer accesses the card directly and eliminates software from the issue.  If the card doesn't pass these steps then it has likely been damaged in some way.  I hope this helps narrow down the problem.
Have a good night!

[kander1]

Hi,
I'm not sure what you mean about resetting the card or doing a self test.  I haven't seen anything in the software or documentation that supports these functions.  I don't see anything in MAX that does either.  MAX reports the device is working properly.  I already ran the examples in 'Finding Examples' that use DAQmx and none of them worked.
 
FYI the exact error message I get when I run the Visa test panel is:
Unable to open session to "visa://129.197.139.58/PXI3::15::INSTR"
Return status code: 0xBFFF00A7
Status name:  VI_ERROR_MACHINE_NAVAIL
"The remote machine does not exist or is not accepting any connections.  If the NI-VISA server is installed and running on the remote machine, it might have an incompatible version or might be listening on a different port"
 
Thanks!
Kevin

[Tom W [DE]]

Hi Kevin-
Judging by the error you posted, it looks like you're trying to access the PCI-6503 device remotely using VISA server.  By "remote" I mean that you have a host machine that is attempting to access the PCI-6503 on some other machine on your network and that the code that interfaces with the PCI-6503 will be running on the host machine.  Is this correct?
The VISA error you're seeing could result from the NI VISA versions being out of date between your host machine and the LabVIEW RT target machine.  It sounds like you may have updated the NI VISA version on your host machine; did you also update the software on your RT target via Measurement and Automation Explorer (MAX)?  I don't have an RT system available so I can't describe the exact menu listings, but you should look under Remote Systems in MAX, find your system, and right-click>>Install Software (or similar) to make sure your version of NI VISA on the target machine is up to date.
Aside from the VISA error, I also see a potential issue with your code.&nbsp; The <a href="http://sine.ni.com/nips/cds/view/p/lang/en/nid/11737" target="_blank">MHDDK</a> example programs show the steps necessary to configure the MITE interface for communication with the rest of the on-board functionality.&nbsp; Check out the initMite() function in any MHDDK example for the steps necessary to complete this configuration.
One final question- is there a reason why you have chosen to use NI VISA rather than NI-DAQmx?&nbsp; I should point out that NI-DAQmx supports a variety of targets including your Windows-based desktop and LabVIEW Real-Time target.&nbsp; NI-DAQmx would provide all of this functionality to you as well as a potentially much more robust device configuration system via MAX.
&nbsp;
Hopefully this helps-

[kander1]

Hi Tom,
Thanks for getting back to me.&nbsp; We are not trying to access the 6503 from the RT machine through a host.&nbsp; We are using the 6503 to run timing tests in the software running on the RT.&nbsp; That's why we want to use VISA instead of DAQmx.&nbsp; Writing to the registers directly has a much shorter and deterministic latency than going through the overhead associated with DAQmx.&nbsp; If it comes down to it we'll use DAQmx if we can't get VISA working.
&nbsp;
Regarding the versions of VISA, we were running V4.2.&nbsp; I rolled it back to V3.6 and that didn't work either.&nbsp; Our version of MAX is 4.3.&nbsp; I'm aware of the issues with MITE.&nbsp; I wrote a short program based on an example in the users manual.&nbsp; Basically I follow the steps&nbsp; 4 and 5 on page B-15.&nbsp; I'll check out the examples in the MHDDK.
&nbsp;
I talked to an NI engineer named Brian on the phone.&nbsp; He recommended I try pulling the card from the machine and putting it back in.&nbsp; I tried that and it didn't work.&nbsp; The one difference it made was that the 6503 doesn't show up under devices in the DAQmx anymore.&nbsp; Is the card supposed to be autodetected by MAX if DAQmx is installed?&nbsp; Prior to that the card showed up, but there was a little red x next to it and all the panel tabs (ie reset, self-check) were dimmed out except for reset.&nbsp; The 6503 still shows up in the VISA section of the devices.
&nbsp;
I much appreciate any help in getting this problem solved
Thanks!
Kevin
&nbsp;
&nbsp;

[deroth47]

I am also working on this project and would like to add a few comments:
&nbsp;
1.&nbsp; The target is a realtime PC with the following software versions (from MAX):
LabVIEW Real-Time 8.2 (recently upgraded from 8.0)
LabWindows/CVI Run-Time Engine for RT 8.1.0 (upgraded from 8.0)
NI-Serial RT 3.0.0
NI-VISA 3.6
&nbsp;
To try to diagnose this problem, we also added (but don't normally use):&nbsp;
NI-VISA Server 3.6
NI-DAQmx 8.6.0
These were added to try to use DAQmx to access the board directly.&nbsp; As Kevin said, we could see it but the PCI-6503 board was red-x'd and we could not do anything with it.
It now does not even show up as a DAQmx board, but does as a VISA board.
&nbsp;
The realtime PC has the PCI-6503 DIO board (PXI3::15::INSTR), PCI-8431/8 serial board (PXI2::14:INSTR), and an IRIG board (PXI2::13::INSTR)
&nbsp;
2.&nbsp; The development PCs&nbsp;have the following software versions:
LabWindows/CVI 8.1.1 (recently upgraded from 8.0)
Real-Time module 8.1.0 (upgraded from 8.0)
NI-VISA 3.6
NI-DAQmx 8.6.1f0
MAX 4.3.0.49152
&nbsp;
The development PCs connect to the realtime PC via the usual ethernet.
&nbsp;
3.&nbsp; We are not using NI-DAQmx since we are not doing extensive data collection and need to minimize overhead in the realtime system.&nbsp; The VISA libraries give us a simpler, common&nbsp;interface for serial communications and register level IO to the IRIG card and (hopefully) the PCI-6503 DIO card.&nbsp;
&nbsp;
4.&nbsp; We cannot use VISA 4.2.&nbsp; When we upgraded from v.3.6 we&nbsp;could no longer access the on-board COM1/2 ports&nbsp;without getting buffer overrun errors.&nbsp;Changing buffer sizes did not help. &nbsp;Reverting to VISA 3.6 eliminated these errors and gave us serial operation again.
&nbsp;
5.&nbsp; We registered the PCI-6503 card on the realtime PC using the VISA driver development wizard with Vendor ID 0x1093 and Device ID 0x17d0 and copied the resulting&nbsp;.inf and .ini files to the realtime PC.&nbsp; This made the card visible to MAX as a PXI device.&nbsp; Also, using viFindRsrc in our code, we can detect the board.
&nbsp;
6.&nbsp; The VISA test panel can see and access the board, somewhat.&nbsp; We can read the VI_PXI_CFG_SPACE, offset 0, and get 0x17d01093, as expected.&nbsp; However, viOut with VI_PXI_BAR1_SPACE, offset 0,1,2, does not change the outputs.&nbsp; They all stay at ~5 volts.
&nbsp;
I believe that our earlier VI_ERROR_MACHINE_NAVAIL was due to the VISA security options not being set to enable access to the realtime PC's address.&nbsp; We can now see it.
&nbsp;
7.&nbsp; Basically, we configure the board in software&nbsp;for all outputs using:
&nbsp;&nbsp;&nbsp; viOpenDefaultRM(&amp;defaultRM)
&nbsp;&nbsp;&nbsp; viFindRsrc(defaultRM, "PXI?*INSTR", &amp;flist, &amp;numInstrs, desc);&nbsp; /* desc correctly&nbsp;returns "PXI3::15::INSTR */
&nbsp;&nbsp;&nbsp; viOpen(defaultRM, desc, VI_NULL, VI_NULL, &amp;instrDIO);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* loop to check for proper ID's to determine DIO board here */
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* configure board to all outputs */
&nbsp;&nbsp;&nbsp; viOut8(instrDIO, VI_PXI_BAR1_SPACE, 0x3, 0x80);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* and try to set the IO */
&nbsp;&nbsp;&nbsp; viOut8(instrDIO, VI_PXI_BAR1_SPACE, 0x0, 0xff); /* port A to 0xff, etc. */
&nbsp;
We do not get any vi errors on any of these calls and do detect the PCI-6503 board based on the vendor and model IDs.
The IO lines do not change when we try to set them (in our code nor with VISA or DAQmx test panels).
&nbsp;
Let us know if you need any more information on our setup.
Thanks,
&nbsp; Don Roth
&nbsp;

[Tom W [DE]]

Hi Don and Kevin-
Thanks for the detailed explanations.&nbsp;
Don- It seems promising that you're able to access the remote device successfully now.&nbsp; I do not see the MITE configuration code I alluded to in my previous post as part of the code section you posted.&nbsp; Can you please confirm whether you are performing this configuration (basically, steps 4-5 of the "PCI Initialization" section of the product <a href="http://digital.ni.com/manuals.nsf/websearch/0488381BEBA3D5138625712C007B27F2" target="_blank">manual</a>).&nbsp; Kevin mentioned he had tried that previously, but my understanding was that you did not have normal VISA communication with the device at the time he performed that test.&nbsp; Can you please confirm?
Thanks-

[deroth47]

Hi Tom --
&nbsp;
We hadn't performed the MITE initialization since we couldn't get the NI-DAQmx panel to access the board at all, and that should have done the board mappint for us.&nbsp; We need for NI-DAQ to see the board first before we continue with the VISA access.&nbsp; We are pursuing this in parallel&nbsp;with Brian from NI support.
&nbsp;
As far as the MITE goes, we created the driver .inf file with the VISA driver development wizard and copied it to \ni-rt\system on the realtime PC.&nbsp; This allows access to the correct VI_PXI_CFG_SPACE and BAR0/1.&nbsp;
&nbsp;
Do we still need to perform the MITE init?&nbsp;
Does the .inf driver do this mapping the same as the NI-DAQmx driver does?&nbsp;
Do we have to remove the NI-DAQmx driver from the RT in order to do correct VISA access?
&nbsp;
Don
&nbsp;

[Tom W [DE]]

Guys-
&nbsp;
Normally (where normally is the case where the board is used with DAQmx), the MITE is initialized automatically by DAQmx.&nbsp; If DAQmx doesn't "claim" the board then the MITE must be initialized by your software.&nbsp; The MITE configuration is seperate from the O/S mapping of BAR0 and BAR1 for the board and is a necessary extra step beyond device recognition.&nbsp; If you created a VISA inf then DAQmx will never attempt to claim the board and your software will have to initialize it.
&nbsp;
Kevin- I see one small problem with your use of VI_PXI_BAR1_SPACE in your computation of 'val'.&nbsp; VI_PXI_BAR1_SPACE is basically part of an enum (#defined in visa.h) that is used by the ViOut/ViIn calls to determine offsets.&nbsp; In order to calculate the correct value to point the MITE at BAR1, you'll actually need to use viGetAttribute() to query the mapped location of BAR1 for the board and then perform the operation you used to come up with val in your code.&nbsp;
&nbsp;
As an FYI- if the MITE is not configured correctly for BAR1, VISA writes to BAR1 will still succeed (since the device is indeed mapped into memory at that location), but the MITE won't pass them through to the DIO application hardware so you won't see valid data on the output lines of the I/O connector.&nbsp; So it's absolutely essential to get this step right.
&nbsp;
Please give this suggestion a try and let me know if you're still unable to see better result.

[kander1]

Hi Tom,
I added the following lines to the procedure and it didn't fix the problem:
&nbsp;
&nbsp;val = (VI_PXI_BAR1_SPACE&amp;0xffffff00)|0x00000080;&nbsp;status = viOut32(instrDIO, VI_PXI_BAR0_SPACE, 0xC0, val);
&nbsp;
I just tried it with the correct VISA configuration and it didn't make a difference
&nbsp;
Kevin
&nbsp;
&nbsp;

[deroth47]

Hi again --
What we thought was a hardware failure was the&nbsp;.inf file&nbsp;keeping NI-DAQmx from accessing the board correctly, as you said.
We did the MITE init using the actual BAR1 address and we can now set the DIO bits correctly.&nbsp; The manual instructions for setting this were a little confusing, since we didn't want to change the address mapping.&nbsp;&nbsp;The MAX VISA&nbsp;properties for the board&nbsp;did give the actual BAR0/1 addresses,&nbsp;as did the&nbsp;VISA test panel.&nbsp;&nbsp;The BAR1 address, for example, is written and read&nbsp;at offset 0x14 from the VI_PXI_CFG_SPACE, as the manual instruction #3 says, but instruction #4 says the new board address is the value in BAR1.&nbsp; If you read VI_PXI_BAR1_SPACE, offset 0 (how I interpreted "value in BAR1"), you don't get the address, but the DIO register.&nbsp;
Anyway, thanks again for all the help.&nbsp; We seem to be working now.
Don
&nbsp;

[Tom W [DE]]

Hey Don-
Apologies for the confusion there- the manual tries to explain the need to only perform certain steps based on whether you want to re-map the board or not, but it is admittadly a bit confusing.&nbsp; Honestly, the need to re-map below 1MB procedure itself seems a bit antiquated to me, so I'll make a note to file an updated request for that doc.
In the future, you might consider posting to the DDK <a href="http://forums.ni.com/ni/board?board.id=90" target="_blank">forum</a>.&nbsp; I monitor it regularly (along with a few other NI R&amp;D members) and receive auto-notifications any time new posts are added.&nbsp; The main DAQ forums (Multifunction DAQ, Digital I/O, etc) are&nbsp;intended more for "mainstream" DAQ&nbsp;discussions (for NI-DAQmx, NI-DAQ, etc)&nbsp;with other users and&nbsp;NI standard support engineers.
In any event, glad to hear you're up and running now.&nbsp; Let me know if you run into any other problems.&nbsp;