Check connection with DAQ every second

[Sid_1]

Hi there, I am using the Python library mcculw on a Windows 10 mcahine. I am using the USB 231 DAQ.

I want to have a feature in my software which can show whether the connection to DAQ is alive or not.

So, I thought of a polling method like this:

    def get_daq_status_str(self):
        '''
        Print status of daq every 1 second
        '''
        while True:
            status = ul.get_status(self.board_num)
            if status == Status.IDLE:
                print('Status: Idle')
            elif status == Status.RUNNING:
                print('Status: Running')
            else:
                print('Status: Error')
            time.sleep(1)

But from the docs I read that, all that ul.get_status() does is "Returns the status about the background operation currently running". So, I don't think it will work for my use case (since I am not transferring any data).

So, what function can I use for this purpose?

Apart from this, my application has to do usual a_out_scan() to send out voltages. So, as far as I can see, I must run this status check (polling method) in a separate thread, so that any other DAQ operation remains unaffected.

Edited October 31, 2022 by Sid_1

[Jeffrey]

Hello @Sid_1

44 minutes ago, Sid_1 said:

I must run this status check (polling method) in a separate thread, so that any other DAQ operation remains unaffected.

You don't need a separate thread, The USB-231 is capable of concurrent operations, including analog input scan, analog output scan and GetStatus() for both types of scan.

But why do you need "...to have a feature in my software which can show whether the connection to DAQ is alive or not."?

Have you seen instance(s) where the USB-231 drops off line?  There are few ways that can manifest itself. Most common is if your computer it set to allow it to turn off power to the USB port.  There is a setting for that in your computer's Device manager, USB Root hub power. Or, if the USB-231 receives a signal beyond its input range as listed in the published spec.

If you really want to implement this, I recommend you periodically call a_in() and check the return code. 

If it is 0, there is no error, the device is working correctly.

if it is > 0  there is a problem.  For example error 5: Dead A/D, "The A/D device on the specified board is not responding. Either the board was installed incorrectly or the board is defective. Run the configuration program and make sure that the correct boards was installed."

For a complete list of errors the device / UL can return, see https://www.mccdaq.com/pdfs/manuals/Mcculw_WebHelp/ULStart.htm

[Sid_1]

Hi @Jeffrey

Thanks for your response.

2 hours ago, Jeffrey said:

But why do you need "...to have a feature in my software which can show whether the connection to DAQ is alive or not."?

I have one reason behind this: to let the user of my software know whether the DAQ is connected. So, it's just for information purposes. At an initial stage, I feel get_daq_device_inventory() can be used. But for prolonged usage I don't know what to use. I have a doubt regarding a_in(). The documentation says that a_in "The raw A/D value is converted to an A/D value and returned". So, how do I use a_in() to get return code ?

2 hours ago, Jeffrey said:

Have you seen instance(s) where the USB-231 drops off line?

No, I have not seen anything of this sort. But very rarely I get the 'FIFO went empty...' error.

2 hours ago, Jeffrey said:

The USB-231 is capable of concurrent operations

Can you please tell how to do this ? Is it using scanoptions.background ?

2 hours ago, Jeffrey said:

You don't need a separate thread

Is it unsafe to launch multiple threads (for other use cases maybe)? I have observed that ul.a_in() stops when I run ul.a_out(). I think my previous question (concurrent operations) is related to this question.

Edited October 31, 2022 by Sid_1

[Jeffrey]

1 hour ago, Sid_1 said:

So, how do I use a_in() to get return code ?

Take a look at example ULAI01.py.

the UL function call to a_in() is enclosed in a Try/else/Except.  Note that in the Except clause is where the error code is trapped.

1 hour ago, Sid_1 said:

Can you please tell how to do this ? Is it using scanoptions.background ?

yes, all you need do is launch background scans for analog in or analog out.  the driver handles concurrent operations.

1 hour ago, Sid_1 said:

I have observed that ul.a_in() stops when I run ul.a_out().

these are static library calls in that they only return a single value.  they don't "stop" when you call the alternate, you simply cannot call them both at the same time.

Threading is not recommended when using MCC devices, each time you instantiate a new thread for the device, you are re-initializing the device. Sometimes it can recover, sometimes it cannot.  I have no data on when either scenario will occur.

1 hour ago, Sid_1 said:

...But very rarely I get the 'FIFO went empty...' error.

That is a very different problem.  when the fifo goes empty, error 29 for input and error 78 for output, it means the system was too busy to service the driver's fifo flag(s).  it could be caused by multi threading or you just have too many other apps running at the same time.  But it doesn't mean the device dropped off line.

[Sid_1]

On 11/1/2022 at 12:22 AM, Jeffrey said:

Threading is not recommended when using MCC devices

Hi @Jeffrey thanks for your response. I observe that while using scanoptions.background in a Tkinter environment, the screens freezes during the background scan. Obviously I want to avoid such things which harm the user experience. I learnt that, the freezing is due to the fact that Tkinter GUI itself runs on a thread. So, when one runs some code on the same thread that Tkinter is on, then nothing else is going to perform until that section of code is done.

So, it seems intuitive to run background scans in a separate thread.

In fact, I have been able to solve the freezing problem in this manner.

Do you still recommend not using threading with MCC devices ?

[Jeffrey]

31 minutes ago, Sid_1 said:

Do you still recommend not using threading with MCC devices ?

Yes, that is MCC's recommendation.