Home 개발

libmodbus 3.1.4 분석내용

보통의 plc 기반 modbus rtu는 2 wire RS-485 방식을 사용하는것으로 보인다.

RS-485가 병렬연결 방식이라 모든 장치에 메시지를 전송할 수 있다는것이 장점인데 modbus 프로토콜은 명확하게 구분되는 STX와 ETX가 없다. 이렇다보니 master가되는 서버가 1번 아이디의 장치로 데이터를 요청하여 1번 아이디의 장치가 응답을 하였을경우 2번 아이디의 장치의 시리얼에 수신되는 데이터는 1번 아이디의 장치 요청데이터, 1번 아이디 장치의 응답데이터이다.

즉, 1번 장치에 요청되고 응답 되었을경우 아래처럼 2번장치에 수신된다. (read holding registers 기준)
[SLAVE ID][FUNCTION CODE][START][QUANTITY][CHECK SUM][SLAVE ID][FUNCTION CODE][BYTES][UINT16 DATA 1][UINT16 DATA 2]…[UINT16 DATA n][CHECK SUM]

STX와 ETX가 없다보니 2번 장치에서 자신의 요청이 아닌 1번 응답을 무시하더라도 바로 뒤에 붙어오는 데이터를 읽게되면 ‘1번 장치의 holding register의 데이터 x주소에서부터 y만큼의 데이터 요청’으로 해석되어진다. 하지만 응답되는 데이터의 길이가 더 크기때문에 이후에 또 읽게되면 UINT16 DATA 부분이 읽혀지게되고 이후 파싱이 안된다.

libmodbus는 rtu일경우 기본적으로 요청 -> 응답 순으로 데이터가 수신되는 조건으로 만들어져있다. 즉, 처음 modbus_receive(3)를 호출하면 데이터 요청, 그다음 modbus_receive(3)을 호출하면 데이터 응답인것으로 수신한다. 따라서 처음 modbus_receive(3) 호출 시 [SLAVE ID][FUNCTION CODE][START][QUANTITY][CHECK SUM]으로 데이터를 읽고 자신에 대한 요청이 아닐경우 데이터 응답을 읽도록 상태가 변경되어 다음 modbus_receive(3) 호출 시 응답 데이터인 [SLAVE ID][FUNCTION CODE][BYTES][UINT16 DATA 1][UINT16 DATA 2]…[UINT16 DATA n][CHECK SUM] 형식으로 읽게되어 완전하게 읽은 후 데이터 요청을 읽도록 상태를 변경한 후 읽은 데이터는 버리도록 한다.

modbus_receive(3)을 호출하면 처음 [SLAVE ID][FUNCTION CODE]를 읽기까지 receive timeout값(기본 0.5초)만큼 버퍼의 데이터를 대기하고 이후 나머지 데이터는 byte timeout값(기본 0.5초)만큼 버퍼의 데이터를 대기한다. 만약 receive timeout값을 5초로 주어지고 slave id가 2번으로 설정되어있을 때 1번 장치에 대한 요청이 modbus_receive(3) 호출하여 읽혀지면 응답 데이터를 읽도록 상태가 변경되어있기때문에 5초 이내 master에서 2번, 또는 다른 장치에 대한 데이터 요청이 발생하면 데이터 응답이 수신되지 않기때문에 에러 즉, -1이 반환된다. (이후 다시 modbus_receive(3)을 호출하면 정상으로 다시 데이터 요청을 읽을지 테스트 하지는 않았다.)

이런 상태를 보면 modbus rtu는 master와 slave간의 요청 응답의 타임아웃을 서로 여유를 두고 잘 정해야 할것으로 보인다.

예전 클라이언트를 만들었을 때 로직은 시리얼 데이터를 읽는 스레드 내 데이터가 수신되면 마지막으로 버퍼에 데이터가 읽힌 시간을 확인하여 0.2초(예시값)이상 지났을경우 버퍼를 비우고 수신된 데이터를 버퍼에 쌓은 후 파싱하고 자신에 대한 요청이 아니면 무시, 자신에 대한 요청이면 응답하는 단순한 구조였다. 첫 바이트가 자신의 아이디와 동일하고 Function Code가 유효하더라도 Check Sum 값이 동일할 경우는 희박하고 데이터 요청 개수(quantity)의 최소, 최대가 이미 정해져있으므로 문제가 발생하지 않았다.

범용적인 상황에서는 libmodbus의 구현이 더 맞겠지만 요청 데이터의 address와 개수의 범위가 이미 정해진 상태에서는 직접 만들었던 방식으로 충분하다고 생각되기때문에 무엇이 더 좋은 방법인지는 모르겠지만 나중에 참고가 필요할 때 참고하기 위해 분석 내용을 기록한다.

여담이지만 그냥 modbus ascii 프로토콜은 STX, ETX가 명확해 보여서 이걸 쓰면 간단할텐데…(?) 아쉽게도 이건 잘 안쓰는거같다.

암튼 이쯤에서 끝!

Qt Multimedia의 QMediaPlayer가 동작 안할 때

여기에서 말하는 문제는 윈도에서의 Qt 문제.

먼저 Backends 별 사용할 수 있는 기능(?)의 표는 아래 링크에서 확인가능.
https://wiki.qt.io/Qt_Multimedia_Backends

Qt 홈페이지에서 받을 수 있는 바이너리 라이브러리는 Multimedia Backends가 DirectShow로 되어있는것으로 보인다. 구글링해도 뾰족한 답을 찾기 힘들었는데 결국 이것도 몇시간동안 삽질해본 결과 재생 안되면 적절한 코덱을 깔아야하고(…) 아니면 Media Foundation을 사용하는 것이였다.

Media Foundation을 사용하려면 Multimedia 라이브러리를 빌드할 때 Media Foundation을 사용하도록 해야한다. 아래는 내가 사용한 qt-everywhere-opensource 패키지의 configure 옵션.

configure -opensource -confirm-license -prefix D:\OpenSource\Qt5.9.0.x64 -nomake examples -nomake tests -force-debug-info -platform win32-msvc -mp -opengl dynamic -mediaplayer-backend wmf

핵심은 -mediaplayer-backend wmf 옵션이다. 이렇게 빌드된것과 기본인 DirectShow를 사용하도록 빌드했을 때 대략 아래와같이 차이가 난다.

– DirectShow

dsengine.dll은 211KB, wmfengine.dll은 42KB

– Media Foundation

dsengine.dll은 63KB, wmfengine.dll은 167KB (qtmedia_audioengined.pdb 파일이 약간 차이있지만 코드에서 backend 별로 메크로 차이가 있는지는 확인 안해보았다.)

Media Foundation은 범용적으로 사용하는 코덱을 지원하므로 프로그램이 윈 7 이상이라면 이쪽을 사용하도록하는것이 더 나아보인다. (자세한 정보는 https://msdn.microsoft.com/ko-kr/library/windows/desktop/dd757927 이곳에서.) 물론 기존의 DirectShow가 더 다양한 코덱이 있을것으로 보기때문에 특정 포맷만 지원할것이 아니라면 DirectShow를 사용하는것이 더 나을 수 있다.

빌드 자체를 남기는 기록이 아니기때문에 여기까지. 만약 빌드 방법을 찾는다면 http://rette.iruis.net/2017/05/qt-5-8-0-webengine-%EB%AA%A8%EB%93%88-%EB%B9%8C%EB%93%9C/ 이 글을 참조.

오늘의 네시간짜리 QtMultmedia QAudioInput 뻘짓.

format은 아래와같이

QAudioFormat formatAudio;
formatAudio.setSampleRate(44100);
formatAudio.setChannelCount(2);
formatAudio.setSampleSize(24);
formatAudio.setCodec("audio/pcm");
formatAudio.setByteOrder(QAudioFormat::LittleEndian);
formatAudio.setSampleType(QAudioFormat::SignedInt);

audio device info는 아래와같이

QAudioDeviceInfo getAudioDevice(const QString &name)
{
  foreach(const QAudioDeviceInfo &deviceInfo, QAudioDeviceInfo::availableDevices(QAudio::AudioInput))
  {
    if(deviceInfo.deviceName() == name)
    {
      return deviceInfo;
    }
  }
  return QAudioDeviceInfo();
}

audioDevice = getAudioDevice(“hw:CARD=G5,DEV=0”);

그 후 start하면 iodevice에 어떠한 데이터가 수신되지 않는다. 결론은 이유가 Qt는 24비트 셈플은 S24_LE로 초기화 하기때문이였다.

쉘에서 아래처럼 정보를 확인해보면 지원하는 포맷은 S24_3LE(…)

$ cat /proc/asound/card2/stream0
Creative Technology Ltd Sound BlasterX G5 at usb-3f980000.usb-1.3.1, high speed : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S24_3LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000
    Data packet interval: 500 us

Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S24_3LE
    Channels: 2
    Endpoint: 2 IN (ASYNC)
    Rates: 44100, 48000, 88200, 96000
    Data packet interval: 500 us

좀 더 깔끔하게 코딩하기위해 Qt의 Multmedia를 사용하려했지만 결국 alsa api를 써야할거같다. 아… 왜 저런 차이를 생각하지 못하고 네시간을 삽질했을까… PulseAudio를 활성화 시키면 리셈플링 되어 처리가 가능할거같은데 lite 이미지에서 PulseAudio를 활성화 하는 방법이 구글링되지않아 그건 포기해야겠다.

TV 리모컨으로 USB DAC 볼륨조절

TV의 광 출력 -> USB DAC -> 스피커로 구성 된 환경.
TV가 광으로 소리를 출력할 경우 자체 볼륨조절이 안된다. (PCM출력일 경우 조절 되어서 출력되면 좋을텐데…)

몇번 헛돈을 쓴 끝에 SoundBlasterX G5가 광 입력을 USB 인터페이스와 관계없이 아날로그 출력이 가능하다는것을 알게되어 라즈베리 파이에 IR 수신기를 연결하고 리모컨으로 광 출력의 볼륨을 조절. 단점이있다면 전력 부족인지 정식적으로 리눅스에서 제품이 보장되지 않아서인지 DAC의 초기화가 잘 안된다. USB를 여러번 뽑고 꼽아봐야 인식된다. 라즈베리 파이를 재부팅시키면 USB 전원이 끊어졌다 연결되는데 이 때 인식이 안될경우 약 1분정도 뽑고 다시 꼽으면 대체로 인식되는 듯 하다. (내부 전원이 완전 방전되지 않아서 그런가?) 즉 왠만하면 리즈베리 파이는 끄지 말아야한다(…). 이 부분은 나중에 윈도 10 환경의 라떼판다 제품으로 때워 볼 예정.

일단 이정도로 해놓고 천천히 UI를 제외한 소스코드를 정리해서 올려봐야겠다.

덧.
볼륨조절을 노브(knob)로 돌려서 해야하는 제품은 스피커 볼륨 조절기로 조절하는것과 다를바 없으므로 의미가 없고, 그런 DAC가 아닐경우 보통 USB 인터페이스에서 OS로 신호를 받고 다시 DAC로 전송하는데 이 때 딜레이가 발생한다. 특히 리듬게임을 하면 정확도가 차이날 정도로 딜레이 발생.

덤으로 몇달이나 제품을 찾아봤지만 이 제품만큼의 가격으로 믿을만한 음질에 이런 구성이 가능한 하드웨어를 찾지 못했다. 스피커와 궁합이 꽤나 맞는건지 아날로그 출력도 상당히 만족 중.