Tristate-ing IO line on PXIe-6535

[ZannahBanana]

Hi CurtisHx,

Bidirectional lines indicate that communication can take place in both directions on one digital line. That command is specific to your device given that it does not have bidirectional lines. Were you able to get everything to function as expected?

Cheers,

Hannah

[CurtisHx]

I did get everything working.

I understand that bidirectional lines are required to use the LineStateDoneState property.  I do not understand why I need bidirectional lines to use the LineStateDoneState property.

[ZannahBanana]

I think it is important to consider what tri-state does and how that may change when a line is bidirectional or unidirectional. 

Tri-state is used to ensure high impedance on one of the lines so that there isn't a conflict over the state of the signal on the bus. I like to think of it like a valve where signals flow through if the tri-state valve is set to be open (i.e. not high impedance). In this case, if you consider a line with unidirectional communication compared to a line with bidirectional communication, there will be a difference in internal circuitry. The line with unidirectional communication will only have to be capable of stopping the flow in one direction whereas the line with bidirectional communication will have to be capable of stopping flow in one of two directions. I think this difference in circuitry is what causes there to be an alternative command for each device.

If that does not provide enough reason, consider a bidirectional line in comparison to a unidirectional line - the circuitry for these are different from each other. Therefore, a command that might work for one would have an issue working for another depending on their differences. This is the case with these devices.

I hope this answers your question.

Hannah

[Kyle_A.]

Your error with the function is due to the lack of hardware-timed tristate. You can only call tristate in software time with that board. Therefore, the error in your 2nd post was due to setting your device up with a sample clock and attempting to tristate the channel based on the clock, which is not a supported feature of this board.

[Kyle_A.]

Also, to be clear, the 6535 is a bidirectional device. The difference is it is not per-cycle tristate compatible (hardware timed tristate) and you can only tristate with a software timed call. This means you cannot communicate on a bus that requires a response time to be within X ms of a particular message. But you can generate values, tristate the lines, start an acquisition task on the same lines, and work bidirectionally just fine. 

[CurtisHx]

It's a bi-directional device in the sense that lines can be configured for input or output.  However, the lines cannot be configured for simultaneous input and output.  If the direction on a line needs to be changed, the old task needs to be cleaned up and a new one created.

[Kyle_A.]

If a line on the 6535 was both input and output, it would simply read whatever it is outputting, which wouldn't be very useful. The output driver and input comparator are tied together for each line, which is required to make a bidirectional line. For this DAQmx board, you can only use one or the other because you cannot drive tristate per-cycle.

On our higher performance NI-HSDIO boards that support per-cycle tristate, it is very common to have simultaneous input and output. To configure that, you create a pattern like 0101ZZZZ where the first 4 samples drive, and the second 4 samples tristate (terminate driving). This allows for an external device to drive the line, so then your input could sample and/or you could use hardware compare to sample a response and report bit errors. A hardware compare acquisition waveform would look like XXXXLHLH where X's are don't care/don't compare (since the HSDIO board would be driving) and LHLH compares and expects the low/high values in that pattern.

I say all of this to mention that the simultaneous IO does exist, but not for the 6535.