NI 9403 slow switching between input and output

[menzi74]

Hi, I am using a NI 9403 module (in connection with NI-RIO) in which I read some non-time critical code from a couple of inputs, and execute a time critical code on four other outputs, which control the adresssing of a multiplexer for data acquistion. My problem is that reading from an input is distubring the output, because the resources from inputs and outputs seem to be shared. That means that if I read from a input pin within the non-cricitcal time loop, the outputs of the critical time loops are delayed for 18us, that is the time to switch between input and output function EVEN IF THE INPUTS AND OUTPUTS ARE ON SEPARATE PINS. The 18us are in line with oscilloscope measurements.Now, I was thinking that I might have made a mistake during configuration. Is it possible to assign a set of pins for inputs, while at the same time another set of pins is set as an output, so that they can be acessed independently without chaning the direction?I hope that there is a solution for this, or else I have to live with non-deterministically sampled data, have to significantly decrease my sampling rate, or buy an additional module (which is my last option).Cheers, Clemens

[Eirikur]

Hi menzi74What configurations have you done on the IO lines?Try take a look at <a href="http://digital.ni.com/public.nsf/allkb/293A2707081229A18625738B00090F6D?OpenDocument" target="_blank">this KB</a> which talks about how to configure each IO line separately on NI-9403. Please post back if this does not help.

[menzi74]

Hi Erikur, please refer to my discussion with Basset Hound below. I have made a mistake with the input/output configuration of a single pin but I have to see if that was the problem..Best regards, Clemens

[Bassett Hound]

Clemens,
I don't think the configuration is the problem and it sounds like its how the LabVIEW FPGA digram is written.&nbsp; Are you writing to the 9403 IO nodes in the same grown IO node?&nbsp; If not, then what your seeing&nbsp;sounds like how I would expect the module to behave.&nbsp;
A liIttle explanation is probably neccessary.&nbsp; First, the 9403 moudule specs a 7 usec update rate for all channels so every IO node read/write should take ~7usec + setup and hold time.&nbsp; Since the 9403 module has 32 channels, the data to and from the module must be seralized to an from the module.&nbsp;&nbsp;Now, why you see greater than 7use + setoup and hold time could be a couple things:
1.&nbsp;&nbsp;&nbsp; Depending on whether the 9403&nbsp;samples just before the edge change or just after the edge change, you should expect a jitter of at least 1 sample if your trying to do edge detection which equals 7 microseconds + setup and hold time.
2.&nbsp; If your not using the same grown IO node, then you now have <a href="http://zone.ni.com/reference/en-XX/help/371599C-01/lvfpgaconcepts/arbitration_options/" target="_blank">arbitration</a> between the two different IO nodes on the block diagram that could be increasing the amount of time to read.
If you could it would be nice to understand how the application is using the IO nodes and how the signals are being measured by the scope.
Basset Hound

[menzi74]

<img alt="" src="file:///C:/DOCUME%7E1/dkaacled/LOCALS%7E1/Temp/moz-screenshot.jpg">Hi "Basset Hound" I have selected disable arbitration for this resource (the 9403 module), because I do not call the same resource (at least the same input or output pin) simultaneously from different parts of the VI.<img alt="" src="file:///C:/DOCUME%7E1/dkaacled/LOCALS%7E1/Temp/moz-screenshot-4.jpg"> However, I think that I have found the culprit: Parts of the diagram that I am writing about - depicting the two concerned loops-&nbsp; are attached for illustration.One loop is updated at 10us, DOI4 until DIO7, all configured as outputs. DIO7 is however set (by mistake) as input, using the module settings.The other loop is running at 1ms, where DIO2 is used to read data. This switching can cause a delay in the onset of the sequence starting with DIO4. This might be due to the time it takes to reverse the input/output direction of DIO7 when calling the faster loop again. However, if that was so, I would be able to see a delay in DIO7 all the time, but I can only see a delay every 1ms; that is, when DIO2 is accessed.I will try again and see if changing the "default" direction of DIO7 will make a difference, and get back to you if THAT was the problem.Cheers,ClemensPS: what do you mean by "grown" IO node? I have dragged and dopped the nodes from the project explorer, should I use a different method to access them in different loops?&nbsp;<img alt="" src="file:///C:/DOCUME%7E1/dkaacled/LOCALS%7E1/Temp/moz-screenshot-3.jpg"><img alt="" src="file:///C:/DOCUME%7E1/dkaacled/LOCALS%7E1/Temp/moz-screenshot-1.jpg"><img alt="" src="file:///C:/DOCUME%7E1/dkaacled/LOCALS%7E1/Temp/moz-screenshot-2.jpg">

[menzi74]

.I think that it seems to have caused the problem. To make a long story short: The module settings seem to be binding throughout the execution time, and any access outside the present scope (for example other loops accessing differnet parts of the module) might RESET the I/O settings, and cause a delay of 18us in reversing the direction if&nbsp; the I/O pin&nbsp; was used&nbsp; other&nbsp; than inidicated in the module settings?If that is really correct, a better programming style would be to set the direction inside the VI, at the beginning of the code (and overwriting the module settings...). What you could not see in my last attachment (did not work) was how I set the direction, I simply dragged and dropped the desired I/O node, and changed the settings by a right mouse-click and selected&nbsp; "change to read" or "change to write". But then again, this seems wrong, because ONLY the module settings dominate.Is it safe to say that the module settings can NEVER be overwritten during run-time? This does not look right...Best regards, Clemens

[Bassett Hound]

Clemens,
There is an API for programatically changing the direction.&nbsp; Using either the property nodes or method nodes should allow you to change the direction.&nbsp; Also for the 9403, if you attempt to write the DO line it will handle direction changing for you under the hood, but you will still incurr the amount of time it takes to change the line.&nbsp; The LabVIEW Help for the 9403 will have more information on the methods and Line change capabilities if you would like to read more.
The module properties should only affect the initial conditions and anything change at runtime should remain in that state.
Bassett Hound

[menzi74]

Hi Basset, Thanks for the reply. I have checked again if I could reproduce the same behaviour as before, by simply changing the I/O direction in the module settings, but I could not. So, there must have been some other bug in the programme. You are of course right, once the direction is set during run-time, it remains in that state.Best regards, Clemens