Digital I/O with sensor sharing clock line

[mooseo]

Hi,

I'm trying to communicate with several relative humidity sensors using LV 8.6 and a USB-6009. The sensors are Sensirion SHT71. They communicate with 2 lines, a bi-directional data line and an SCK line. Thanks to code posted on this forum 

http://forums.ni.com/ni/board/message?board.id=170&requireLogin=False&thread.id=179022

I can easily communicate with 1 probe.

What I would like to do is expand this to read from several probes simultaneously. I would like the readings to be as close together in time as possible. I will use as many sensors as I have data pins available.

I am wondering if anyone thinks it would work to share a single clock line between several sensors and just use a single data line for each.  In this way, a single 8-line port could read 7 sensors simultaneously.

I have tried to do it with 2 sensors using a very klugy modification of the code that worked for a single probe... in this case, I simply added 2 read and write routines to a single port. It doesn't seem to work, but I'd guess I probably should go through and re-write the whole thing using  multiple lines per channel.

I have a feeling that this may be a doomed idea, however, so I'd really appreciate it if someone can tell me if they think it will or won't work before I spend most of a day re-writing the code. I've posted the single-probe code that works.

Thanks!

mike

[nayer]

Hello Mike,

You can definitely do that,it will require some major change in the code. You can reffer to the attached example code where you can read of the multilpe lines on the same channel, you will use similar approach. 

The DAQmx write or read configuration will be Single channel, single sample 1D boolean (N lines) and you can update or read N lines on the same channel.  I hope that answers your question.

Keep us posted if you have any other questions.

Thanks

nAyer

[mooseo]

Hi,

Thanks very much for the encouragement. I'm now going through my code and changing all the DAQmx functions from 1 data line to N data lines. Many bits of it seem to be working fine, but I've been banging my head on this problem for a while. 

For some reason, the updated code is getting an error out of the sensor where I don't really expect it. I have set it up so that, even though the vi's can accomodate N data lines, I only actually have a single one.

Can someone please look and tell me if they see something obviously different between these 2 code snippets?

In the first (s_write_byte_one data line.vi) the DAQmx vis are Digital Bool 1 line 1 point. 

In the 2nd, ( s_write_byte_multi.vi ) the DAQmx vis are 1D Bool 1channel 1sample. 

I'm clearly confused about the difference between these, and would appreciate some help. I thought that the 2nd one would behave like the first, but writing a different element of the array to each data line. In the case where the array only has one element, should this behave just like the 1 line 1 point case? According to my sensor, apparently not.

Thanks for any suggestions.

cheers,

mike

[nayer]

Hello Mike,

Following the definition of

Digital Bool 1 line 1 point:

Writes a single Boolean sample to task a that contains a digital output channel composed of a single line, which means it will update the one line of the specified channel everytime your loop iterates. 

1D Bool 1channel 1sample:

Writes a single sample of Boolean values to a task that contains a single digital output channel. The channel can contain one or more digital lines, which essentially update N lines of the specified channel one point eveytime your loop iterates.

Looking at the code you modified, I tired running it on my computer it worked fine (did not give any errors), the only modification I did was removing the global variable and replaced it with regular 1D boolean array. Keep us posted if you have any specific questions on the same.

Thanks 

nAyer

[mooseo]

Hi nAyer,

Thanks for your reply. I'm still a bit confused; I thought that I understood the difference betweent the DAQmx write routines.

According to my understanding, if I use 1D bool 1 channel 1 sample, but my channel has only a single line and I only pass it 1 value, shouldn't it effectively be doing the exact same thing as Bool 1 line 1 point?  

The routine runs, and it even works in the context of my larger program. The problem is that the sensor it is talking to sees the output of the two routines differently so I get a different result.

thanks,

mike

[nayer]

Hello Mike,

You are correct,  1D bool 1 channel 1 sample (N lines) is same as Bool 1 line 1 point if you have only one line. As far as talking to your sensor. I would double check on the clock signal as well. You can use highlight execution in LabVIEW to make sure that your outputs are as expected. Let me know in case you have any other questions.

Cheers

nAyer

[mooseo]

I'm starting to despair of this one working... I've gone through and checked everything I can think of...

Basically, if I use Bool 1 line 1 point, my routine works fine. If I use 1D bool 1 channel 1 sample (N lines), it doesn't. This is true even when there is only a single line connected. 

Essentially, my routine pulls the pin high while it waits for the sensor to finish taking a reading. When the sensor is done, it pulls the pin low to indicate it is ready for the next step. With the 1D bool 1 channel 1 sample (N lines), this line never goes low. 

Can anyone think of any way in which these routines differ that might be causing the different behavior?

Can anyone think of a workaround?  I will have a variable number of sensors connected, but at this point I'd hard-code in different numbers of channels if I have to.

Thanks,

mike

[mooseo · Accepted solution]

Solved it! Turns out that the simple routine for single point digital output must somehow handle tristate configuration. The polymorphic one does not.  So, rather than reading the actual value at the pin, the DAQmx Read 1D bool 1 channel 1 sample was simply reading the last value sent to it.

The trick is to set the tristate property to true before trying to read from the pin and then set it back to false after finishing a read...

Thanks to MarkGrot and this thread for helping me figure it out. 

http://forums.ni.com/ni/board/message?board.id=250&message.id=46293&query.id=323548#M46293

[mindmeld]

Mike - can you post your final code?  It may be of use to many.  I'll hope to get to a similar project this summer, and would appreciate the chance to look through it.

Thanks !!

Charlie

[mooseo]

Hi Charlie,

Here is the subroutine out of my code that actually deals with the tristate property. 

Note that I originally had the tristate property setting within the for loop and the code didn't work. Every time the property changed, the line got reset and the probe on the other end didn't like it. Moving the property change outside fo the loop fixed it... note, also, that in the 2 days it took me to fix this, I added a bunch of random time delays that might not be necessary. 

If you want to see the whole program with this routine in context, I've posted it in this thread

http://forums.ni.com/ni/board/message?board.id=170&message.id=406440&jump=true#M406440

Hope this is helpful to someone. 

cheers,

moose