Merge branch 'dev'

AlexShkarin · Jun 26, 2021 · 7f9ef1d · 7f9ef1d
2 parents 3482cfa + 630b4f5
commit 7f9ef1d
Show file tree

Hide file tree

Showing 132 changed files with 8,941 additions and 2,214 deletions.
diff --git a/.gitignore b/.gitignore
@@ -61,6 +61,8 @@ nosetests.xml
 coverage.xml
 *.cover
 .hypothesis/
+.tox.*
+run-tox-dev.py
 
 # Translations
 *.mo

diff --git a/.pylintdict b/.pylintdict
@@ -350,4 +350,21 @@ cyclemode
 readonly
 enums
 devio
-unpacker
+unpacker
+vbox
+hbox
+sublayouts
+unscheduling
+unschedule
+callsync
+genicam
+grayscale
+csd
+csdi
+ctl
+sn
+autofill
+infos
+paddings
+fg
+QQueueScheduler
diff --git a/build_distrib.py b/build_distrib.py
@@ -9,6 +9,7 @@ def clear_build():
     shutil.rmtree("build",ignore_errors=True)
     shutil.rmtree("dist",ignore_errors=True)
     shutil.rmtree("pylablib.egg-info",ignore_errors=True)
+    shutil.rmtree("pylablib_lightweight.egg-info",ignore_errors=True)
 def make():
     subprocess.call(["python","setup.py","sdist","bdist_wheel"])
 def upload(production=False):

diff --git a/docs/.apidoc/pylablib.core.gui.widgets.rst b/docs/.apidoc/pylablib.core.gui.widgets.rst
@@ -22,6 +22,15 @@ pylablib.core.gui.widgets.combo\_box module
     :undoc-members:
     :show-inheritance:
 
+pylablib.core.gui.widgets.container module
+------------------------------------------
+
+.. automodule:: pylablib.core.gui.widgets.container
+    :members:
+    :inherited-members:
+    :undoc-members:
+    :show-inheritance:
+
 pylablib.core.gui.widgets.edit module
 -------------------------------------
 
@@ -40,6 +49,15 @@ pylablib.core.gui.widgets.label module
     :undoc-members:
     :show-inheritance:
 
+pylablib.core.gui.widgets.layout\_manager module
+------------------------------------------------
+
+.. automodule:: pylablib.core.gui.widgets.layout_manager
+    :members:
+    :inherited-members:
+    :undoc-members:
+    :show-inheritance:
+
 pylablib.core.gui.widgets.param\_table module
 ---------------------------------------------
 

diff --git a/docs/.apidoc/pylablib.devices.SiliconSoftware.rst b/docs/.apidoc/pylablib.devices.SiliconSoftware.rst
@@ -0,0 +1,24 @@
+pylablib.devices.SiliconSoftware package
+========================================
+
+Submodules
+----------
+
+pylablib.devices.SiliconSoftware.fgrab module
+---------------------------------------------
+
+.. automodule:: pylablib.devices.SiliconSoftware.fgrab
+    :members:
+    :inherited-members:
+    :undoc-members:
+    :show-inheritance:
+
+
+Module contents
+---------------
+
+.. automodule:: pylablib.devices.SiliconSoftware
+    :members:
+    :inherited-members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/docs/.apidoc/pylablib.devices.rst b/docs/.apidoc/pylablib.devices.rst
@@ -28,6 +28,7 @@ Subpackages
     pylablib.devices.Pfeiffer
     pylablib.devices.PhotonFocus
     pylablib.devices.Rigol
+    pylablib.devices.SiliconSoftware
     pylablib.devices.SmarAct
     pylablib.devices.Tektronix
     pylablib.devices.Thorlabs

diff --git a/docs/.skipped_apidoc b/docs/.skipped_apidoc
@@ -26,6 +26,9 @@
 ..\pylablib\devices\PCO\sc2_sdkstructures_defs.py
 ..\pylablib\devices\PhotonFocus\pfcam_defs.py
 ..\pylablib\devices\PhotonFocus\pfcam_lib.py
+..\pylablib\devices\SiliconSoftware\fgrab_define_defs.py
+..\pylablib\devices\SiliconSoftware\fgrab_prototyp_defs.py
+..\pylablib\devices\SiliconSoftware\fgrab_prototyp_lib.py
 ..\pylablib\devices\SmarAct\SCU3DControl_defs.py
 ..\pylablib\devices\SmarAct\SCU3DControl_lib.py
 ..\pylablib\devices\Thorlabs\tl_camera_sdk_defs.py

diff --git a/docs/changelog.rst b/docs/changelog.rst
@@ -23,6 +23,29 @@ you can write
     import pylablib.legacy as pll
     from pylablib.legacy.aux_libs.devices import Lakeshore
 
+1.1.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- General
+
+    * Reorganized the core modules import structure: now ``__init__.py`` modules are mostly empty, and all the necessary imports are either exposed directly in ``pylablib`` (e.g., ``pylablib.Fitter``), or should be accessed directly by the module (e.g. ``pll.core.dataproc.fitting.Fitter``). Intermediate access (e.g., ``pll.core.dataproc.Fitter``) is no longer supported.
+    * File IO functions (e.g., ``read_csv``) can now take file-like objects in addition to paths.
+
+- Devices
+
+    * Added Silicon Software frame grabbers interface and rearranged PhotonFocus code to include both IMAQ and SiliconSoftware frame grabbers.
+    * Fixed various compatibility bugs arising for specific versions of Python or dependency modules: Kinesis error with specific pyft232 versions, some DLL-dependent devices errors with Python 3.8+, DLL types in 32-bit Python
+    * Addressed issue with occasional uc480 acquisition restarts, fixed M2 communication report errors,
+
+- GUI and threading
+
+    * Added container and layout management classes in addition to parameter tables for more consistent GUI structure organization.
+    * Added ``pylablib.widgets`` module which combines all custom widgets for the ease of using in layout managers or custom applications.
+    * Fixed  support for ``PySide2`` Qt5 backed.
+    * Renamed ``setupUi`` -> ``setup`` for all widgets, and changed the GUI setup organization for many of them (the functioning stayed the same).
+    * Reorganized scheduling in ``QTaskThread`` to treat jobs, commands, and subscriptions more consistently.
+    * Added basic data stream management.
+
 
 
 1.0.0

diff --git a/docs/conf.py b/docs/conf.py
@@ -29,7 +29,7 @@
 # The short X.Y version
 version = ''
 # The full version, including alpha/beta/rc tags
-release = '1.0.0'
+release = '1.1.0'
 
 
 # -- General configuration ---------------------------------------------------
@@ -57,6 +57,9 @@
 sys.modules['pyvisa']=mock.Mock(VisaIOError=object, __version__='1.9.0')
 sys.modules['serial']=mock.Mock(SerialException=object)
 sys.modules['ft232']=mock.Mock(Ft232Exception=object)
+sys.modules['PyQt5.QtCore']=mock.Mock(QObject=object,QThread=object)
+sys.modules['PyQt5.QtWidgets']=mock.Mock(QWidget=object,QFrame=object,QGroupBox=object,QTabWidget=object,QPushButton=object,QComboBox=object,QLineEdit=object,QLabel=object)
+sys.modules['PyQt5']=mock.Mock(QtCore=sys.modules['PyQt5.QtCore'],QtWidgets=sys.modules['PyQt5.QtWidgets'])
 if os.path.exists(".skipped_apidoc"):
     with open(".skipped_apidoc","r") as f:
         for ln in f.readlines():
@@ -82,7 +85,7 @@
                        'rpyc': ('https://rpyc.readthedocs.io/en/latest/', None),
                        'pyqtgraph': ("https://pyqtgraph.readthedocs.io/en/latest/", None),
                        'pySerial': ("https://pythonhosted.org/pyserial/", None),
-                       'PyVISA': ("https://pyvisa.readthedocs.io/en/master/", None),
+                       'PyVISA': ("https://pyvisa.readthedocs.io/en/latest/", None),
                        'nidaqmx': ("https://nidaqmx-python.readthedocs.io/en/latest/", None),}
 
 
@@ -210,7 +213,7 @@ def setup(app):
 #  dir menu entry, description, category)
 texinfo_documents = [
     (master_doc, 'pylablib', 'pylablib Documentation',
-     author, 'pylablib', 'One line description of project.',
+     author, 'pylablib', 'Code for use in lab environment: experiment automation, data acquisition, device communication.',
      'Miscellaneous'),
 ]
 

diff --git a/docs/devices/Andor.rst b/docs/devices/Andor.rst
@@ -126,4 +126,4 @@ The operation of these cameras is also relatively standard. They support all the
       
       The description of the attributes is given in `manual <https://andor.oxinst.com/downloads/uploads/Andor_SDK3_Manual.pdf>`__.
     
-    - USB cameras can, in principle, generate data at higher rate than about 320Mb/s that the USB3 bus supports. For example, Andor Zyla with 16 bit readout has a single full frame size of 8Mb, which puts the maximal USB throughput at about 40FPS. At the same time, the camera itself is capable of reading up to 100FPS at the full frame. Hence, it is possible to overflow the camera internal buffer (size on the order of 1Gb) regardless of the PC performance. If this happens, the acquisition process halts and needs to be restarted. To check for the number of buffer overflows, you can use :meth:`.AndorSDK3Camera.get_missed_frames_status`, and to reset this counter, :meth:`.AndorSDK3Camera.reset_overflows_counter` (it also automatically resets on acquisition clearing, but not stopping). In addition, the class can implement different strategies when encountering overflow while waiting for a new frame. It is set using :meth:`.AndorSDK3Camera.set_overflow_behavior`, and it can be ``"error"`` (raise :exc:`.AndorError`, which is the default behavior), ``"restart"`` (restart the acquisition and immediately raise timeout error), or ``"ignore"`` (ignore the overflow, which will eventually lead to a timeout error, as the new frames are no longer generated).
+    - USB cameras can, in principle, generate data at higher rate than about 320Mb/s that the USB3 bus supports. For example, Andor Zyla with 16 bit readout has a single full frame size of 8Mb, which puts the maximal USB throughput at about 40FPS. At the same time, the camera itself is capable of reading up to 100FPS at the full frame. Hence, it is possible to overflow the camera internal buffer (size on the order of 1Gb) regardless of the PC performance. If this happens, the acquisition process halts and needs to be restarted. To check for the number of buffer overflows, you can use :meth:`.AndorSDK3Camera.get_missed_frames_status`, and to reset this counter, :meth:`.AndorSDK3Camera.reset_overflows_counter` (it also automatically resets on acquisition clearing, but not stopping). In addition, the class can implement different strategies when encountering overflow while waiting for a new frame. It is set using :meth:`.AndorSDK3Camera.set_overflow_behavior`, and it can be ``"error"`` (raise :exc:`.AndorFrameTransferError`, which is the default behavior), ``"restart"`` (restart the acquisition and immediately raise timeout error), or ``"ignore"`` (ignore the overflow, which will eventually lead to a timeout error, as the new frames are no longer generated).
diff --git a/docs/devices/Arcus_performax.rst b/docs/devices/Arcus_performax.rst
@@ -23,6 +23,9 @@ The controller has several communication modes: USB, R485, and Ethernet. USB mod
 
 The controller has only been tested with USB communication.
 
+.. warning::
+    There appear to be some issues with Python 3.6 which result in out-of-bounds write, memory corruption, and undefined behavior. Hence, Python 3.7+ is required to work with this device.
+
 
 Connection
 -----------------------

diff --git a/docs/devices/IMAQ.rst b/docs/devices/IMAQ.rst
@@ -28,7 +28,7 @@ The cameras are identified by their name, which usually looks like ``"img0"``. T
 
     >> from pylablib.devices import IMAQ
     >> IMAQ.list_cameras()
-    [`img0`, `img1`]
+    ['img0', 'img1']
     >> cam1 = IMAQ.IMAQCamera('img0')
     >> cam2 = IMAQ.IMAQCamera('img1')
     >> cam1.close()
@@ -74,4 +74,4 @@ Known issues
 - If you are unable to access full camera sensor size, check the camera file (it can be opened in the text editor). ``MaxImageSize`` parameter defines the maximal allowed image size, and it should be equal to the camera sensor size.
 - Same goes for bitness. If the camera bitness is higher than set up in the frame grabber, a single camera pixel gets treated as several pixels by the frame grabber, typically resulting in 1px-wide vertical stripes on the image. In the opposite case, the frame grabber expects more bytes than the camera sends, it never receives the full frame, and the acquisition times out.
 - Keep in mind that as long as the frame grabber is accessed in NI MAX, it is blocked from use in any other software. Hence, you need to close NI MAX before running your code.
-- As mentioned above, ROI is defined within a frame transferred by the camera. Hence, if it includes pixels with positions outside of the transferred frame, the acquisition will time out. For example, suppose the camera sensor is 1024x1024px, and the *camera* ROI is selected to be central 512x512 region. As far as the frame grabber is concerned, now the camera sensor size is 512x512px. Hence, if you try to set the same *frame grabber* ROI in the (i.e., 512x512 starting at 256,256), it will expect 768x768px frame. Since the frame is, actually, 512x512px, the acquisition will time out. The correct solution is to set frame grabber ROI from 0 to 512px on both axes. In general, it is a good idea to always follow this pattern: control ROI only on camera, and always set frame grabber ROI to cover the whole transfer frame.
+- As mentioned above, ROI is defined within a frame transferred by the camera. Hence, if it includes pixels with positions outside of the transferred frame, the acquisition will time out. For example, suppose the camera sensor is 1024x1024px, and the *camera* ROI is selected to be central 512x512 region. As far as the frame grabber is concerned, now the camera sensor size is 512x512px. Hence, if you try to set the same *frame grabber* ROI (i.e., 512x512 starting at 256,256), it will expect 768x768px frame. Since the frame is, actually, 512x512px, the acquisition will time out. The correct solution is to set frame grabber ROI from 0 to 512px on both axes. In general, it is a good idea to always follow this pattern: control ROI only on camera, and always set frame grabber ROI to cover the whole transfer frame.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -126,4 +126,4 @@ The operation of these cameras is also relatively standard. They support all the

		The description of the attributes is given in `manual <https://andor.oxinst.com/downloads/uploads/Andor_SDK3_Manual.pdf>`__.

		- USB cameras can, in principle, generate data at higher rate than about 320Mb/s that the USB3 bus supports. For example, Andor Zyla with 16 bit readout has a single full frame size of 8Mb, which puts the maximal USB throughput at about 40FPS. At the same time, the camera itself is capable of reading up to 100FPS at the full frame. Hence, it is possible to overflow the camera internal buffer (size on the order of 1Gb) regardless of the PC performance. If this happens, the acquisition process halts and needs to be restarted. To check for the number of buffer overflows, you can use :meth:`.AndorSDK3Camera.get_missed_frames_status`, and to reset this counter, :meth:`.AndorSDK3Camera.reset_overflows_counter` (it also automatically resets on acquisition clearing, but not stopping). In addition, the class can implement different strategies when encountering overflow while waiting for a new frame. It is set using :meth:`.AndorSDK3Camera.set_overflow_behavior`, and it can be ``"error"`` (raise :exc:`.AndorError`, which is the default behavior), ``"restart"`` (restart the acquisition and immediately raise timeout error), or ``"ignore"`` (ignore the overflow, which will eventually lead to a timeout error, as the new frames are no longer generated).
		- USB cameras can, in principle, generate data at higher rate than about 320Mb/s that the USB3 bus supports. For example, Andor Zyla with 16 bit readout has a single full frame size of 8Mb, which puts the maximal USB throughput at about 40FPS. At the same time, the camera itself is capable of reading up to 100FPS at the full frame. Hence, it is possible to overflow the camera internal buffer (size on the order of 1Gb) regardless of the PC performance. If this happens, the acquisition process halts and needs to be restarted. To check for the number of buffer overflows, you can use :meth:`.AndorSDK3Camera.get_missed_frames_status`, and to reset this counter, :meth:`.AndorSDK3Camera.reset_overflows_counter` (it also automatically resets on acquisition clearing, but not stopping). In addition, the class can implement different strategies when encountering overflow while waiting for a new frame. It is set using :meth:`.AndorSDK3Camera.set_overflow_behavior`, and it can be ``"error"`` (raise :exc:`.AndorFrameTransferError`, which is the default behavior), ``"restart"`` (restart the acquisition and immediately raise timeout error), or ``"ignore"`` (ignore the overflow, which will eventually lead to a timeout error, as the new frames are no longer generated).