Запрос на связь с Python и IronPython

Question

Назначение этой программы - управлять двумя измерительными приборами через GPIB с использованием Python.

Inst_A: управляется с помощью CPython и PyVISA (пока недоступно в IronPython).
Inst_B: контролируется библиотекой DLL, предоставляемой производителем; IronPython и его __import clr__

Я пробовал Python .NET, но возвращает с исключением файла, не найденным, тогда как одни и те же команды работают в IronPython. Может ли это быть связано с this?

Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import clr 
>>> clr.AddReference('QDInstrument') 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
System.IO.FileNotFoundException: Unable to find assembly 'QDInstrument'. 
    at Python.Runtime.CLRModule.AddReference(String name) 

В настоящее время inst_b.py будет работать под IronPython и многократно выполнять новые экземпляры Python вместе с несколькими аргументами в inst_a.py в цикле.

Есть ли способ сохранить inst_a.py в живых в течение всего периода получения вместо этого и быть в состоянии принимать входные данные от inst_b.py? В некотором смысле, как слушатель?

версия ОС: Windows 7 Professional SP1 amd64
версия Python: 3.5.1
Python .NET версия: 2.1.0 (от ПУМ)

Спасибо,
Павла.

Answer 1

Согласно my comment, я сосредоточусь на вашем последнем вопросе: Предпочитаемые способы IPC между Python и IronPython.

Прежде всего, любой МПК включает в себя две вещи:

• канал данных (трубы/потоки, управляемые системой объекты IPC, общее хранилище)
• протокола данных (процедуры связи, формат данных)

---

единственный встроенный «питон конкретных» IPC канала, что я в курсе, multiprocessing.Queue (и производные). Но он работает только в том случае, если дочерний процесс был запущен с модулем multiprocessing, который здесь не применим.

Итак, вы ограничены мерами IPC, которые предоставляет ОС. Это слишком широкая тема, чтобы углубиться в детали. На первый взгляд, если это последовательности сообщений данных (а не, скажем, сигналов), которые вы хотите передать, трубы или сокеты приходят на ум в качестве одного агента-агностика и сразу очевидного пути.

---

Что касается формата данных, они могут быть разделены на две группы:

• форматов сериализации и
• форматов
связи

Первая группа «простой & глупо "(r) и не имеет ограничений на объекты, которые он может сохранить (и восстановить), но по своей сути является небезопасным из-за последнего. Он также по своей сути зависит от внутреннего представления объектов, что потенциально несовместимо между разными базами кода и вне единой архитектуры.

• pickle - это встроенный формат Python первого типа. При внимательном предупреждении вы можете ожидать совместимости для встроенных типов, если базовые примитивные типы имеют одинаковую длину.
• json является примером гибкого формата второго типа, struct является примером фиксированного.

---

Если вы используете потоки, вы также должны как-то разделение входящего потока байтов в сообщениях. Один простой способ - отправить <data_length> (в независимом от платформы формате согласованного формата), а затем <payload>, еще один способ - использовать разделители (которые никогда не должны возникать в полезной нагрузке).

Answer 2

Согласно denfromufa и this thread, все, что требовалось, чтобы добавить путь к DLL до добавления ссылки (не требуется в IronPython),

import clr 
import os 
import sys 
sys.path.append(os.path.dirname('__file__')) 

Просто обеспечивая абсолютный путь к результатам clr.AddReference с SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 2-3: truncated \UXXXXXXXX escape.