Does anybody have example code where Pclk1 and Pclk2 run simultaneously when both groups 1 and 2 configured

[tesfaye]

Does anybody have example code where Pclk1 and Pclk2 run simultaneously when both groups 1 and 2 configured using c, LabWindows

[aasenjo]

Tesfaye,

I don't believe we have such an specific example but I might suggest duplicating the code found in our shipping examples for both groups. A typical example for Burst handshaking (it uses PCLK) would be:

DIsingleBufBurstHandshake653x.PRJ

Normally found in the folder:

...Program Files\National Instruments\MeasurementStudio\CVI\samples\daq\di

You must try to interleave the function calls so that the operations are setup at about the same time, the synchronization should come from the hardware side (PCLCK and the handshaking lines will really determine when the operation starts and the board outputs or inputs data).

I hope this helps,

Alejandro Asenjo
Applications Engineers
National Instruments

[Tmax]

Do you have a PCI6533 card installed in a computer on which you could actually set up the routine(s) in question. Using pre-existing examples has not been a lot of help. The function explanations are clear. Why will they not work under some circumstances? Have you actually been able to configure both groups of this card without errors? Have you seen both Pclk1 and 2 run at the same time? We get repeating errors 10412 and 10413 when attempting to configure group1(=1) and group2(=2).

[aasenjo]

Tmax,

I have set it up and was able to get both PCLKs running at the same time. The application I created is basically duplicating the code found in the DIsingleBufBurstHandshake653x shipping example, one instance for each group. I interleaved the calls so that the same function call is executed twice in a row, once for each group.

Nevertheless, in the process of creating the application I ran into some situations that might be related to the problems you are seeing. Allow me to give a little background before I talk about the specific error codes.

The way the current (traditional) DAQ (DIO portion) driver works requires asynchronous operations (like the one in DIsingleBufBurstHandshake653x to place the DIO 653X board in certain states where it expects to interact with the external world, be it waiting for the handshaking lines or for an external clock. If the operation (process you are debugging) is stopped (killed) while the board is in such a state, then it becomes difficult to get the board back into its ready state. There are certain function calls that I add to the beginning of my code to try to make sure the board is in a certain state before I start the DIO operation:

iStatus = Init_DA_Brds (iDevice, &deviceNumberCode);

iRetVal = NIDAQErrorHandler(iStatus, "DIG_Grp_Config",
iIgnoreWarning);

iStatus = DIG_Block_Clear(iDevice, iGroup1);

iStatus = DIG_Block_Clear(iDevice, iGroup2);

Iinit_DA_Boards issues a device reset that most of the times is able to get the board back to its default (ready) state.

DIG_Block_Clear helps clear the operation for a given group. When running the application in debug mode you will get a dialog warning you that there was no operation taking place (if there was not). This dialog does not show up when running the application in release mode.

Regarding the specific errors:

1) �10412: No group is assigned, or the specified line or channel cannot be assigned to a group.
2) �10413: A group is already assigned, or the specified line or channel is already assigned to a group.

Both errors are very similar and they normally show up because one of the groups is already being used or it is in one of the locked states I mentioned above. Both errors
Can probably be avoided by using the function calls above to clear the operations and reset the board before you start a new operation.

Another things to watch out for is that the handshaking signals must be properly applied:
- ACK must be observed by the external device,
- REQ should be provided and PLCK must exist
- The 653X or the external device must provide PCLK.

If the handshaking signals are not applied correctly (after the operation has been fully setup and started) then you might get some of your ports in a state where it is still waiting for data) it may seem like the application is locked up and normally the developer tends to kill the process, which might lead to other temporary errors.

While debugging my application I unfortunately had to halt the execution (and kill the process I was debugging) this caused the board to remain in a state where resetting it or trying to clear the ports did not clear the DMA error I was receiving. I believe it was error �10455: No DMA channel is available for use. I am not certain about the error code but I know it was DMA related. Please notice that this could be considered expected behavior because I killed the process that was controlling the board while it was performing a handshaked operation.

In order to get rid of this error I suggest two solutions:

- Reset the PC. This will power cycle the 653X device.
- Under Windows 2000/XP: Delete the board from MAX, open Device Manager (notice it is no longer listed). Scan for hardware changes (windows detects the board again) and then refresh MAX. The board should be ready for use.

After I modified my code (adding the necessary fixes and checks to reset the board before starting the operation) I was able to run the application every time after that.

Unfortunately I can�t make my code available yet because I still need to clean it up and document it, otherwise we will not be able to support it. I do plan on making it available through the NI Developer Zone in the near future.

I hope this helps,

Alejandro Asenjo
Applications Engineer
National Instruments

[Tmax]

Alejandro,

Thanks very much for your reply. Yes, your code seems to do much the same thing as ours. And we will include the clear/initilize functions for both groups. The explanation is helpful in our learning that the -10608 and -10609 warnings are exactly that ---a warning and not an error and will not appear in the executable. The DMA -10455 error is a problem for us. We have used the clear function, but only by de-configuring a group before starting up another can we be assured of no assignment errors or the dreaded DMA -10455. We are using group 1 to recieve messages and group 2 to transmit messages to the external device. The asyncronous operation requires that the external controller continuously poll message receivers using one half Pc
lk1. We set our clock speed to 2Mhz over a 18 foot cable. Infrequent transmissions of group 2 are performed during the period of the recieve poll. In order to know when receive polling is in progress, the Pclk1 must always run when the Dig_Block_Out function of group 2 is called..both groups must be configured. We will let you know how the intilize and clear functions help. Keep us in mind as the successful operation of the 6533 card is critical for our task. Thanks for the help. Tom and Tesefaye.