USB3105 and raspberry pi4b

[Gregoire]

Hi,

 

I am facing some issue with an usb-3105 board controlled with a raspberry pi4b.

Until now, I was controlling this board with a raspberry pi3b+ / OS Raspbian buster lite through a python software.

 

Recently I have switched to raspberry pi4B 4Gb with raspiOS bullseye lite.

Python software is the same.

Since then, I am experiencing connection loss with the 3105 board.

For information, I am updating the output values every 10ms (so 160ms to update all 16 values).

It happens randomly after more or less 30 minutes of use.

I also have an USB 2408 in my setup which works fine.

 

If I close the connection with the board and open it again, it works fine again until next connection loss.

 

Here is the error message I get:

 

Exception in thread Thread-2:

Traceback (most recent call last):

File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner

self.run()

File "/home/pi/rackcc/rackccscan_temp_v1.0.0.py", line 757, in run self.aocards.setAO(chan, self.allpoints[chan])

File "/home/pi/rackcc/rackccscan_temp_v1.0.0.py", line 309, in setAO

self.all_ao_cards[card_to_set].a_out(int(physical_channel_to_set), self.output_range, AOutFlag.DEFAULT, float(out_val))

File "/usr/local/lib/python3.9/dist-packages/uldaq/ao_device.py", line 81, in a_out

raise ULException(err)

uldaq.ul_exception.ULException: ULError.DEV_NOT_CONNECTED: Device not connected or connection lost

 

 

Have you experienced such a problem ?

Thanks for your help.

[JRys]

Hello @Gregoire

I've check our support database and could not find similar cases to yours. So, no we have not experienced such a problem.

The maximum update rating of the USB-3105 is 100 Hz / number of channels. You could try slowing down so that the updates less than 100 times per second.

Does the device work for 30 minutes only if it has been unplugged for a while, or does restarting the program make it work for 30 more minutes?

What are you controlling with 16 outputs?

Is it near any equipment that emits electrical noise like RFI/EMI? If so, try using a USB cable the has built-in ferrite filters.

Best regards,

John

[Gregoire]

Hi @JRys,

 

thanks for your answer !

Just after posting my message I actually tried to lower the update rate. Before was 160ms to update the 16 channels, I tried 800ms (50 ms between each channel) and leave it overnight but same result.

Only restarting the program is enough to have 30 minutes of working time.

I am controlling apparatus requiring a 0-10V analog control voltage (very low current consumption).

The environment is the same as when I was using a raspberry pi3b+ successfully. And we have built a dozen of this system working well with the rasp pi3b+. But since it is going to disappear we have to switch to pi4.

Still it is worth to try ferrite filters.

 

[JRys]

Hello @Gregoire

For the record, are you running 32 or 64-bit Bullseye and do you have the RPI 4 with 2, 4 or 8Gb?

John

[Gregoire]

Hi @JRys,

 

this is 32-bit bullseye, RPI 4b 4Go.

 

For the test, I have switched the pi4 with a RPI 3b (so not my usual pi 3b+) with raspian buster.

My set up has run overnight, no connection loss.

 

I have another setup equipped with raspberry pi 4b and one usb 3105 (and one usb 2408) which was ready for test. I tested it yesterday evening and same issue.

[JRys]

Hi @Gregoire

It is best to stay with the Buster operating system because, although some initial checks indicate it works, MCC has not fully tested Bullseye. 

Best regards,
John

[Gregoire]

Hi @JRys,

 

ok, seems a good option. I will tell the result !

 

Regards,

Gregoire