Вопросы Теги

Как я вызываю метод записи последовательного порта ожидать строки для очистки прежде, чем отправить ее данные?

Я бы пошел с рекурсивной функцией, чтобы выполнить это, предполагая, что все строки значений ваших ключей верны: 

def assign_value(sample_dict, str_keys, value):
  access_key = str_keys[0]

  if len(str_keys) == 1:
    sample_dict[access_key] = value
  else:
    sample_dict[access_key] = assign_value(sample_dict[access_key], str_keys[1:], value)

  return sample_dict

Идея состоит в том, чтобы проходить через dict, пока вы не достигнете самого низкого key и затем мы присваиваем наше новое значение этому последнему ключу; 

if __name__ == "__main__":
  sample_dict = {
      'user': {
          'username': 'mic_jack',    
          'name': {
              'first': 'Micheal',
              'last': 'Jackson'
          },
          'email': 'micheal@domain.com'
      }     
  }

  str_key_1 = 'user.username=john'
  str_keys_1, value_1 = str_key_1.split('=')
  sample_dict = assign_value(sample_dict, str_keys_1.split('.'), value_1)

  print("result: {} ".format(sample_dict))


  str_key_2 = 'user.name.last=henry'
  str_keys_2, value_2 = str_key_2.split('=')
  sample_dict = assign_value(sample_dict, str_keys_2.split('.'), value_2)

  print("result: {}".format(sample_dict))

Чтобы использовать assign_value, вам нужно разделить ваш оригинальный ключ на ключи и значение [ 116] как видно выше;

11
задан Jeff LaFay 26 August 2011 в 15:04
поделиться

3 ответа

Управление потоком является корректным ответом здесь, и это не может быть, представлять/реализовывать/применимы Вашему подключению Bluetooth.

Проверьте спецификацию Зебры и посмотрите, реализуют ли они, или если можно включить, программное управление потоком (xon, xoff), который позволит Вам видеть, когда различные буферы станут полными.

Далее, радио Bluetooth вряд ли будет способно к передаче быстрее, чем 250k в максимуме. Вы могли бы рассмотреть искусственно ограничение его к 9,600 бит/с - это разрешит радио, которое большое дыхание комнаты для ретранслирует, коррекция ошибок, обнаружение и его собственное управление потоком.

Если бы все остальное перестало работать, взлом, который Вы используете прямо сейчас, не плох, но я назвал бы техническую поддержку Зебры и узнал бы то, что они рекомендуют перед отказом.

- Adam

5
ответ дан 3 December 2019 в 08:31
поделиться

Хорошо я нашел способ сделать это на основе этих двух предложений, уже данных. Я должен настроить свой объект последовательного порта со следующим:

serialPort.Handshake = Handshake.RequestToSendXOnXOff;
serialPort.WriteTimeout = 10000; // Could use a lower value here.

Затем я просто должен сделать вызов записи:

serialPort.Write(labelData);

Так как принтер Зебры поддерживает программное управление потоком, он отправит значение XOff на мобильное устройство, когда буфер будет почти полон. Это заставляет мобильное устройство ожидать значения XOn, которое будет отправлено от принтера, эффективно уведомляя мобильное устройство, что это может продолжить передавать.

Путем установки времени записи свойство, я даю общее время, допускал передачу, прежде чем исключение тайм-аута записи будет выдано. Вы все еще хотели бы поймать тайм-аут записи, поскольку я сделал в своем примере кода в вопросе. Однако не было бы необходимо циклично выполниться 3 (или произвольная сумма) времена, пытаясь записать каждый раз, так как программное управление потоком запустит и остановит передачу записи последовательного порта.

7
ответ дан 3 December 2019 в 08:31
поделиться

Проблема вероятна не с кодом последовательного порта, а с базовым Bluetooth-стеком. Порт, который Вы используете, чисто виртуален, и маловероятно, что любое квитирование даже реализовано (поскольку это было бы в основном бессмысленно). DTR/DSR CTS/РТС просто неприменим для того, что Вы продолжаете работать.

Базовая проблема - то, что то, когда Вы создаете виртуальный порт под ним, должно связать с Bluetooth-стеком и подключением к парному последовательному устройству. Сам порт понятия не имеет, сколько времени это могло бы взять, и он, вероятно, настраивается, чтобы сделать это асинхронно (хотя это была бы просто до устройства OEM, как это сделано) препятствовать тому, чтобы вызывающая сторона заперлась в течение длительного периода, если нет никакого спаренного устройства, или спаренное устройство вне диапазона.

В то время как Ваш код может чувствовать себя подобно взлому, это является, вероятно, лучшим, большая часть портативного способа сделать то, что Вы делаете.

Вы могли использовать Bluetooth-стек API, чтобы попытаться видеть, там ли устройство и живо перед соединением, но нет никакой стандартизации стека API, таким образом, Widcom и Microsoft APIs расходятся в том, как Вы сделали бы это, и Widcom является собственным и дорогим. То, с чем Вы закончили бы, является путаницей попытки обнаружить, что тип стека, динамично загружая соответствующий класс верификатора, имея ее называет стек и ищет устройство. В свете этого Ваш простой опрос кажется намного более чистым, и Вы не должны выходить из оболочки несколько $k для SDK Widcom.

2
ответ дан 3 December 2019 в 08:31
поделиться
Другие вопросы по тегам:

Похожие вопросы: