static write 32

[ajog]

Hi All,

In the PXI-6551 (HSDIO) if a certain channel is configured for a static write, but the final StaticWrite32(handle, etc.) function call is not invoked, will that leave that particular channel in tri-state mode?

If not, how can one explicity tri-state a particular channel in the PXI-6551?

Please advise for each case.  Thank you.

Anand

[DJ_L.]

Hey Anand,

Check out the NI Digital Waveform Generator/Analyzer Help documentation, either in .chm form, or check out the html form here. Specifically, you should check out the page on the niHSDIO_WriteStaticU32 function. It states the following:

"Static channels explicitly disabled with the niHSDIO_TristateChannels function remain disabled, but the channel data value changes internally. Re-enabling a channel with niHSDIO_TristateChannels causes the channel to drive any value that you have written to it, even while the channel was disabled."

So based on the above WriteStaticU32 help, you should also check out the help on the niHSDIO_TristateChannels function. It states the following:

"Use this function to force a channel into a high-impedance state. The effect is immediate; it does not require the session be committed. The channel remains tristated regardless of what other software commands are called. Call this function again and pass VI_FALSE into the tristate channels parameter to allow other software commands to control the channel normally.

Channels are kept in a high-impedance state while the session remains open. Closing the session does not affect the high-impedance state of the channel, but future sessions can now control it."

I hope this answers your question(s). Please let us know if you have any further questions or concerns. Thanks, and have a great day. 

Regards,

DJ L.

[ajog]

Thank you DJ,

This was a major oversight on my part.  Don't know how I missed the 'niHSDIO_TristateChannels function while scanning the niHSDIO Functions list.

Thanks again.

Anand

[ajog]

Hi DJL,

Something strange happening with C#.

My code statement

my_task.TristateChannels("channelName", false);   // false is boolean

is interpreted as an attempt to UNtristate a channel that was not tristated.  This runs contrary to the help file description of niHSDIO_TristateChannels(...).

Please advise.

Thanks.

Anand

[DJ_L.]

Hey Anand,

"Call this function again and pass VI_FALSE into the tristate channels parameter to allow other software commands to control the channel normally."

What happens if you do the following:

1) Tristate (True) channel x

2) Static write 1 on channel x

3) Tristate (False) channel x

Not until #3 will you see a one on the line.

Also, if you have already driven a 0 or 1 on a channel, meaning that the channel has not been tristated yet, and then you call Tristate (False), that really will not do anything, as you are basically just telling the channel to keep doing what it was already doing, or a "no change". But if you want to Drive a 0, then Tristate, then Drive a 0 again, then Tristat again, and repeat, you can do the following:

1) Static Write (0) on channel x (0 driven on line)

2) Tristate (False) channel x (0 still driven on line, no change)

3) Tristate (True) channel x (Z on line, high impedance)

4) Tristate (False) channel x (0 driven on line)

5) Tristate (True) channel x (Z on line)

6) Tristate (False) channel x (0 driven on line)

7) Tristate (True) channel x (Z on line)

etc....

Side note: I think you are trying to do I2C communication with the 655x, so it is going to be a little different in your case if you have the line hooked up to your I2C line, because of the open-drain nature of the I2C lines. Driving a 0 is a low on the I2C line, but Tristating the I2C line should be a high, becuase of the pull-up that should be on the line. Is this having any affect in how/what you are testing things out?

I hope this helps, and/or clarifies what you are seeing. Please let me know if you have any further questions or concerns. Thanks, and have a great day. 

Regards,

DJ L.

p.s. Do you still need help with these two discussion forum posts?:

- HSDIO and C# GetAttribute and SetAttribute methods are invisible, and ConfigureAcquisitionSize

- trouble with WriteNamedWaveformWDT and C#

If you found a solution to those issues, can you let the community know what you did to solve them 😉 Thanks.

[ajog]

Thanks DJL,

I will experiment with your detailed explanation and will let you know.  Thanks again.

About my other two posts.

1.  The Number of Records being limited to 1

I noticed this during my reading of the function and thought I would point it out.  In future I might need to attempt triggered multi-record acquisition and this might be important.

2.  I received C# sample code from National Instruments and have yet to try it out.  There was a 10 day latency in receiving it and I hence had to try alternate approaches to my immediate needs.  My current approach (you are right it is I2C) employs WriteWaveformU32 but chooses open collector logic.  This allows me to tri-state SDA and SCL but CS must be driven static high.

In the event that CS is supplied by an external source, I need to tri-state the corresponding HSDIO line.  This lead to the earlier post about static write and tri-state. 

Static write on CS does permit I2C.  However, it is only the WriteNamedWaveformWDT that permits 0,1 and 2 (tri-state) in a cycle-to-cycle setting and is one of the key functions (if not *THE* key functions of the 6551.

Will keep you posted as soon as I'm done with my current stuff and experiment with the sample code supplied.  At a first glance the only difference I notice between my code and NI's is the manner in which the byte array is defined.

Anand