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가 명확해 보여서 이걸 쓰면 간단할텐데…(?) 아쉽게도 이건 잘 안쓰는거같다.

암튼 이쯤에서 끝!

fdisk로 4K 섹터 정렬된 파티션 생성

parted나 fdisk나 4K 정렬을 지원하지만 그냥 생성한다고해서 정렬 된 파티션으로 생성되지않는다. 정렬되지 않았다고 그냥 경고 메시지만 출력할 뿐(…) 직접 계산하여 생성할 수 있겠지만 그럴 필요성까지는 느껴지지않는다. parted같은 경우 정렬 된 파티션을 생성하려면 이전에 남긴 “Parted 사용정리” 글을 보면 될것이고 fdisk는 실행할 때 옵션을 주면 된다.

1. fdisk 버전 2.17.1 미만일경우
# fdisk -S 32 -H 64 disk.img

2. fdisk 버전 2.17.1 이상일경우
# fdisk -c -u disk.img

이렇게 실행하여 경우 결과는 아래와같다.

Welcome to fdisk (util-linux 2.30.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p):

Using default response p.
Partition number (1-4, default 1):
First sector (2048-262143, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-262143, default 262143): +10K

Created a new partition 1 of type 'Linux' and of size 10 KiB.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p):

Using default response p.
Partition number (2-4, default 2):
First sector (2068-262143, default 4096):
Last sector, +sectors or +size{K,M,G,T,P} (4096-262143, default 262143):

Created a new partition 2 of type 'Linux' and of size 126 MiB.

Command (m for help): p
Disk disk.img: 128 MiB, 134217728 bytes, 262144 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe765896f

Device     Boot Start    End Sectors  Size Id Type
disk.img1        2048   2067      20   10K 83 Linux
disk.img2        4096 262143  258048  126M 83 Linux

Command (m for help):

그런데 정렬된 파티션을 생성할 때 왜 2048섹터가 시작점이 되는지 모르겠다. 섹터당 512 bytes라면 8섹터가 4096바이트, 2048섹터는 1메가바이트인데… 구글링해도 시원한 답이 안보인다. 그냥 넘어가야겠다.

추가내용) 4K 섹터 정렬에 대한 잘 설명된 글은 데스게이트의 글인 고급 포맷 4K 섹터 하드 드라이브로의 전환에서 볼 수 있다. (왜 데스게이트라고 불리는지는 나무위키 Seagate 페이지의 돌연사 항목을 보자. 나중에 번호가 바뀌더라도 돌연사 항목을 찾아서 보면 될것이다. WD는 자회사인 HGST보다 안정성 떨어져 불량이 많이 늘어 마찬가지로 신뢰 안하는 중. 모든 하드가 다 마찬가지긴 한데 쓰려면 최소한 RAID-1을 써야 나중에 피 안본다.)

참고페이지: Partition Alignment

몬스터 헌터 월드 사운드 설정

팁이라고하기엔 너무나도 부실한 팁.

첫 시작 때 사운드가 박진감 너무 없어서 이상했는데 기본 설정이 TV 스피커 출력이여서 그랬던거같다. 가끔 기본 설정이 저가형 스피커 기준으로 되어있어 2.1채널 스피커를 쓴다거나 헤드폰으로 즐길 때 어딘가 나사빠진 음향출력을 하는 경우가 있는데 몬헌 월드도 이러한 경우인거같다.

(위에 다이나믹 레인지 설정이 풀 레인지 스피커, 멀티 웨이 스피커같은 유닛 종류에 따른 설정인 줄 알았지만 하위항목 설명을 보니 그런건 아니였다.)

우퍼가 따로있는 스피커를 쓴다거나 헤드폰을 쓴다면 기호에 맞게 설정하면 저음만큼은 확실하게 차이나게되므로 음향에 쓴 돈값어치를 좀 하게 될것이다(…).

덧) 사냥 좀 해보니 느껴지는것이 대형 몬스터와 전투 시 음악이 은근 박진감이 없다 orz

두근두근 문예부 한글패치 1.1.7버전 맥에서 적용하기 (1.2버전 가능)

전 버전의 영상을 유튜브 주계정에 올리지 않았음을 알게되어 다시 녹화 하려다 한글패치가 1.1.7로 업데이트되고 기존의 방법이 안된다는것을 알게되었다. 방법은 거의 같지만 다른점이 한가지있으므로 새로운 글로 패치 과정을 기록한다. (이번엔 귀찮으므로 글로는 대충적고 영상으로 때워야겠다.)

추가) 1.2버전도 동일하게 적용됨을 확인 완료.

1. 최신 한글패치(현재 1.1.7버전)와 renpy sdk를 다운로드한다.
renpy: https://www.renpy.org/latest.html
한글패치: https://sites.google.com/view/dokidokikor/home

2. 한글패치 다운로드 페이지를 참고하여 [로컬 컨텐츠 폴더]를 연다.

3. 한글패치의 game 폴더내 파일 세개를 선택하여 [로컬 컨텐츠 폴더] 내의 game 폴더로 이동하여 덮어씌운다.

(game 폴더를 복사하여 대치하면 다른 파일들이 지워지고, 병합하면 파일의 수정날짜로 비교하여 덮어지거나 넘어가버리므로 복사되지않을 수 있다.)

4. renpy sdk의 renpy 폴더를 복사하여 [로컬 컨텐츠 폴더]에 붙여넣기하고 대치한다.

5. [로컬 컨텐츠 폴더]에서 DDLC 패키지 폴더를 연다.

6. Contents – MacOS – lib – darwin-x86_64 – Lib 폴더로 이동한다.

7. renpy sdk 폴더에서 lib – darwin-x86_64 – lib – python2.7 폴더로 이동한다.

8. 7번에서 열어놓은 python2.7 폴더에서 pygame_sdl2와 renpy폴더를 복사하여 6번에서 열어놓은 Lib 폴더에 붙여넣기하여 대치한다.

9. 실행하면 끝!

아래는 영상으로 남기는 한패과정

윈도 저장소 폴(저장소 공간)의 성능

저장소 공간은 이미 나온지가 꽤 지난 기술이지만 의외로 정보가 없다. 일단 이 글은 저장소 공간을 설정하는걸 설명하는게 목적이 아니기때문에 설정은 패스. 부실하지만 간략한 방법 및 설명은 [이곳 페이지]에서 확인가능.

그래도 저장소 공간을 만들 때 중요한 부분을 설명하자면

  • 단순(복원 없음) – RAID 0에 해당. 디스크 두개 이상이 모두 이어저 하나로 연결된 형태(1테라 + 1테라 => 2테라). 단점은 하드 중 하나라도 고장나면 모든 데이터가 소실된다.
  • 양방향 미러 – RAID 1에 해당. 모든 디스크에 동일하게 데이터를 기록하는 형태(1테라 + 1테라 => 1테라). 두개 이상의 하드에 동일하게 기록하기때문에 구성 된 하드 중 하나만 정상이고 나머지는 망가져도 데이터는 보존된다.
  • 패리티 – RAID 5에 해당. 이건 좀 복잡하다. 단순하게 생각하면 디스크 세개이상을 두개의 용량으로 사용하면서(1테라 + 1테라 + 1테라 => 2테라) 하나의 디스크가 문제있어도 해당 디스크 교채 후 재구성이 가능하다.

그 외 3방향 미러가있지만 패스. HDD가 다섯개 이상 필요하기도하고 이정도로 구성할 사용자가 개념을 알기위해 이걸 볼 이유가 없을것이기때문(…). 첨언을 하자면 저장소 공간은 기본 할당 가능한 용량보다 높게 설정가능하지만 그 용량 을 넘어서 기록 된 데이터 안정성 보장이 안되므로 추천하고싶지않다.

목적이 아닌 서론은 이정도에서 끝. (참고로 아래 내용은 일부 OS의 환경이나 하드웨어에 따라 다를 수 있으니 모든 사용자에 해당하지 않을 수 있다고 본다.) Continue reading 윈도 저장소 폴(저장소 공간)의 성능