Functionality of NI-845x in Borland Builder

[krisken]

Hello Joris,

No Panic, did some research and here are my findings and don't ask how in hell it can happen.  Anyways, I just read the device ID from the PCB and that stated (in print on the PCB) that it is an USB-6501 device.  On the label on the box it said that it was and USB 8451 I2C/SPI interface, board only, OEM VERSION.   And since it answers to the commands from the library I assume it is the correct one and that the print on the PCB is false.  As for further labels on the print, perhaps you recognise some of them as serial numbers I have one label indicatin1922317B-51 and another one being 12C702D.   On the box I have another number stating SN : HA5882938.   So I really think it's an 8451 device (because that what we need) and that only the print on the PCB is wrong.   Don't ask me how it got there but that's a question you can perhaps answer, I can't.

Kind regards,

Kris

[Joris_D.]

Hi Kris,

Thanks for all the numbers, they helped me to make sure that you are in deed using the 8451 so no problem there. What i meant with our software is that if you have the possibility you could perhaps try out the code with Labwindows/CVI. That's our text based programming enviroment. Or if possible try to use labview itself. I would like to know if it's a simple programming error (like clock rate configuration, ...) or if it's an more general error (like hardware problem).

And i don't know if you already have seen this on the website but maybe this article can help you to examine your settings. The programming itself is done in labview, so that's to bad but maybe the settings alone will explain something.

http://zone.ni.com/devzone/cda/tut/p/id/4692

You also said "it looks to me like a buffering problem of some sort just as if the NI module can't follow" so if i understand you correctly when you measure the signals comming out from the AD you don't see anything for 1 ms.
So if the 8451 is the problem, he will not transmit any data to the AD and this one in his turn will not be able to send anything cause he is not receiving.
But if it's an timing error of some sort it could be that if you measure the signals going to your AD (comming from the 8451) that they are still there but that the AD will not send anything because the timing is bad. Can you investigate this also please?

[krisken]

Hello again Joris,

I'll check for the SW to run under labview and see what I can do, but I'm not quite sure whether I'll be able to do so because I don't know anything about labview.   But I'll give it a try anyway.

As for the timing, it is indeed true that I don't see anything coming out of the NI8451 for about 1ms... that includes SPI clock just as well.  When I disconnected all the SPI slaves (only the NI left), I got the same result so I'm sure that it is not slave related.  It sends 51 bytes, pauses and then continues.   I did the measurements directly on the NI board, as it was stand alone, so there was no interference.  What I noticed on the logic analyser was 51 one bytes, perfectly clocked, with perfect answer, a pause, and then the remaining data being clocked out.   I'll try to grab you a screenshot of the logic analyser tomorrow if that would be of any help to you.

Kind regards,

Kris

[krisken]

Hello Joris,

Finally, the screenshot of the scope is there.  You'll find it in the attachment.  

The CS_4 is the chip select command.  Then you'll see the in and out of the data and the clock data.  You can see that the clock data suspends after a while.  If you need it, I'll can give you a more detailed zoom but I don't think that's necessary.  you can see that it works OK for about 1ms and then it suspends for a little over 1ms.

I've looked into the labview code of the example you provided, but that doesn't show me anything new.  Can you help me out ?

Kind regards,

Kris

[Joris_D.]

Hi,

I have an idea which perhaps would make it easier for us to solve the problem and to know what is causing the problem.
However i don't know how you fill feel about it, but it would be nice to see if labview or labwindows/CVI together with your ni hardware would also
cause this strange problem.

You can download trial versions (30 day) of labview and labwindows/CVI here:

http://digital.ni.com/demo.nsf/websearch/211E20AC7A564A59862571E7000377BE?OpenDocument&node=157200_US
http://digital.ni.com/demo.nsf/websearch/14F9CE475127ADE786256AC60070926C?OpenDocument&node=157200_US

I know this will be not so easy for you because you are not used to work with labview, but normally it should not be so difficult
and you will find many examples online. The following link will help you get on your way:

http://zone.ni.com/devzone/cda/tut/p/id/4692#toc4

(Look at the example attached: ex8451ti.zip + the links below for some further information)

Let me know if you think it's possible to investigate this, it would be a good step for me cause then i can't blame the borland builder and
then i have examples which i can open and take a look at.

[DivyaS]

Has anyone worked on 3-wire SPI with Ni-8451x

[DirkW]

Hi All,

Sorry, i missed this request somehow. Here is some clarification on this "hickup" issue.

The 8451 is not perfect and not meant for streaming applications like reading from a A/D converter. It is designed based on our USB 6501 digital device and therefore limited to a page size of 128 byte in both directions. Thus after receiving or writing approx. 100 byte the firmware needs to reload or read  the pages and that needs some time (ms).

And then there is another limitation for the script api. This api allways uses 2 Bytes for a single byte operation because it needs to bundle a command to every byte written or read. That leads to the fact that the useable memory reduces the half if someone uses the advanced script api. (approx. 50 byte)

I hope we can find a "better" solution for future hardware revisions, but right now there is nothing we can do about it. 

DirkW

[krisken]

Hello All,

Is there any workaround or possible sollution(s) because this is a "disaster" for me.   We've designed a custom made board on which the NI-8451 is plugged for interfacing with that board.   (It has all different SPI devices).  We don't have the possibility for another USB to SPI converter because then we have to redesign the boards (for which we don't have the time) so I have to solve the problem with this board.  Is there a fix possible ?   I only need 100 bytes so if you can double the capacity of the registers that would work for me.

Kind regards,

Kris

[DirkW]

That's nothing we can change on the fly. We are working on next generation but this is nothing for the near future. The only thing you can do is using the basic API, because the basic API can transfer more data at a time. Theoretical you should get the 100 bytes transfered without any hickup.

Is there any reason why you are using the script api?

DirkW

[krisken]

Where is the problem exactly situated ?   Is it in the hardware ?  In the NI-8451 dll ?  In the VISA Layer ?  

As for the script, I only use it for performance so that I can group the commands for chipselect and so on in one script, which I thought was faster then every time again calling the functions.  

Would the behaviour of direct commanding be different then scripting ?  

Kind regards,

Kris

Message Edited by krisken on 01-23-2008 09:09 AM