Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Use of viPeekxx in a loop instead of viMoveIn32

I'm using the NI-VISA driver, a VXI-PCI-Controller, the operating system Windows XP and the development tool MS Visual Studio C++ 6 (SP5). Our software includes the command viMoveIn32, which causes several "hangings" in the past (the system never returned from this function).
 
viStatusMove = viMoveIn32 (viSession, VI_A24_SPACE, 40, 0x40, buffer);
 
Changing the controller and the cards hadn't any effect. As a temporary solution, this function was put in an separate thread, which is killed after some time (5 ms) and restarted. This works fine, but it couldn't be permanent.
I read about the possibility to replace this high level block command shown above by a number of calls of the low level command viPeek (Syntax: viPeekxx (ViSession instr, ViAddr address, ViUInt16 value ), but I havn't any idea how to do. Could somebody help me, please?
0 Kudos
Message 1 of 9
(4,850 Views)
Could you please provide some more information about this issue?
  1. What type of VXI-PCI-Controller are you using? Is this an NI device (e. g. PCI-MXI-2, PCI-MXI-3)
  2. If this is an NI device: What NI-VISA/NI-VXI versions are you using?
Regards,

Jochen Klier
National Instruments Germany
0 Kudos
Message 2 of 9
(4,825 Views)

Here the requested information. Due to the fact that I didn't install VXI (the colleague isn't available at present), I hope that the answers are complete.

VXI-PCI-Controller: PCI-MXI-2 (likely)

The NI-VXI directory says "NIVXI331" and it has a subdirectory called "NIVISA261". I assume, 331 and 261 are the versions. Is this correct?

 

0 Kudos
Message 3 of 9
(4,822 Views)
 

Thank you for the information. You are using the latest driver versions so no action is needed here.

Please let me know if this helps. If not, is it possible for you to reproduce the issue with a small example? If so it would be great if you could post it to your next answer.

Jochen Klier
National Instruments Germany

 

Message Edited by Jochen on 10-26-2005 12:52 PM

0 Kudos
Message 4 of 9
(4,819 Views)
Unfortunately the described solutions do not help. I already use the block command and the SyncMXI was disabled.
Therefore I arrived at the starting point again. My original question aimed at replacing the block command with low level commands. In other words: Are the following lines
 
        ViSession instr; 
        ViAddr addr; 
        ViUInt32 value;
 
        status = viMapAddress(instr, VI_A24_SPACE, 0, 0x40, VI_FALSE, VI_NULL,&addr);
        
        for (int k = 0; k < 64; k++)
        {
            viPeek32(instr, (((ViPByte)addr) + k), &value);
        }
 
        status = viUnmapAddress(instr);
 
 
the correct substitution for
 
         viStatusMove = viMoveIn32 (viSession, VI_A24_SPACE, 40, 0x40, buffer);
?
0 Kudos
Message 5 of 9
(4,787 Views)
Dear Forum,

we are facing the same problem: The functions viMoveIn32() and viMove16 () hang.
They hang so hard, that the whole process cannot be killed, not even root using kill -9 . That means, that the PC has to be rebootet every time the above mentioned functions are called.
We tried already to disable DMA as proposed in the Knowledge Base elsewhere but faced the same result.

Our application has been originally written in 2000 using Linux-Kernel 2.2 with the same PC-card and VXI-MXI-2 controller. Now we are porting the application to a more recent Linux version.

We are working now with Linux (SuSE 9.3, Kernel 2.6), NIVisa 3.2, NI-VXI 2.1 using a PCI-MXI-2 in the PC and a Slot-0-Controller model VXI-MXI-2.

It would be great if anyone has a hint for some solution / work around.

Christoph
0 Kudos
Message 6 of 9
(4,721 Views)

Try using NI-VISA 3.4.

-Josh

0 Kudos
Message 7 of 9
(4,705 Views)

VISA 3.4 did not change the situation.

Meanwhile we did some more tests using ltrace to monitor the VISA calls.
In this environment longer VISA calls are listed like this:
call <unfinished ...>
  .... some other operations ...
<call resumed>

The outcome of our tests (using viMoveIn16) is listed below, only the last lines are shown:

    printf("do %s\n", "viMoveIn16" <unfinished ...>
        SYS_write(1, "do viMoveIn16\n", 14)      = 14
    <... printf resumed> )                       = 14
    viMoveIn16(0x080bf930, 3, 0, 4096, 0xbfffcb50 <unfinished ...>
        SYS_gettimeofday(0xbfff8a10, 0, 0x4011e99c, 0, -1) = 0
        SYS_ipc(1, 983060, 1, 0, 0xbfff8a50)     = 0
        SYS_ipc(1, 983060, 1, 0, 0xbfff8a50)     = 0

This means, that viMoveIn16 does not return at all (which leads to the fact that the whole program can not be killed).
We finally replaced the viMovexx call by viInxx loops. This may be slower but works.

0 Kudos
Message 8 of 9
(4,624 Views)

Dear Christoph,

reading your last sentence about using viInxx, I immediately searched for this command. Unfortunately the user manual gives only few information. I think, the command has the following syntax:

status = viInxx (session, space, offset, value)

Is this right? I would be glad if you could give me an example of a viInxx loop. In my first and third message I posted the viMoveIn32-command to replace. Many thanks in advance.

 

For a short time I have got a NI VXI-USB-Controller available. Does anybody have experience with it, i.e. knows about problems after changing from the PCI-MXI-2- to the USB-Controller?

 

0 Kudos
Message 9 of 9
(4,618 Views)