2019년 4월 23일

syncAxis 데모 프로그램 공개


최근 소개드렸던 syncAXIS 기반의 테스트 프로그램을 공개합니다.
v.1.2.5 기반으로 제작되었으며, 주요 기능으로는

  • XML 설정 파일을 기반으로 초기화/재초기화 기능
  • 스테이지 제어권 변경 (Follow/Unfollow)
  • 오퍼레이션 모드 변경(스캐너 , 스테이지, 스캐너+ 스테이지)
  • 보정파일(Correction) 변경
  • 레이저 주파수, 펄스폭 변경
  • 수동 스테이지, 스캐너 위치이동
  • 리스트 버퍼 테스트 (사각형, 원, 직선 등)

와 같습니다.


실행된 모습


리스트 명령 테스트시에는 버튼에 표기된 것처럼 +- 위치값이 입력됩니다. 때문에 스테이지를 기구 중심에 두고 엔코더 카운트를 0 으로 초기화 후 테스트를 진행하시기 바랍니다.

리스트 핸들링 모드는 기본적으로 slsc_ListHandlingMode_RepeatWhileBufferFull (1) 을 사용하게 됩니다. 변경에 주의 바랍니다.


몇가지 구현시 주의사항으로는
  • 초기화(initialize) 함수사용시 만약 실패하게 되면, 에러개수(slsc_ctrl_get_error_count)및 상세 에러 사유(slsc_ctrl_get_error)를 확인해 보아야 합니다.
  • 콜백함수들을 등록하여 사용할 경우, 해당 함수는 항상 syncAxis 내부의 쓰레드내에서 콜백호출되기 때문에, 공유 데이타에 대해서는 적절한 동기화가 필수입니다.
  • 모션 가동을 중단(slsc_ctrl_stop)할 경우, 재시작(slsc_cfg_reinitialize_from_file) 혹은 삭제(slsc_cfg_delete)후 초기화(slsc_cfg_initialize_from_file)를 반드시 해야 합니다.
  • 메뉴얼 문서에 따르면 내부 리스트 명령 버퍼는 기본적으로 약 40초간의 구동 데이타를 저장하게 된다고 하지만 실제로는 상당히  버퍼가 금방 차오르게 됩니다. 떄문에 리스트 데이타 삽입후 모션 계획(planning)의 계산이 충분히 되면 바로 가공을 시작(start)하는것이 바람직 한 방법입니다.
  • 모션 계산이 모두 완료되면 계획된 모션 정보를 확인할수있습니다. (slsc_ctrl_get_job_characteristic) 위치, 속도, 가속도, Jerk 및 10usec 단위로 분리된 micro벡터 개수등을 알수있습니다. micro벡터개수 / 100000 하게 되면 총 가공 시간(sec) 을 알 수 있습니다.
  • 가공을 시작후 리스트 데이타의 삽입이 지연되면 버퍼 언더런(under run)이 유발되어 내부 로직이 망가지는것 같습니다. (가공중 break-point 를 찍고 디버깅을 하게되어도 발생 주의)
  • acqure/release 함수 대신 follow/unfollow 를 사용하세요. (문제가 많으므로)


다운로드 링크 https://drive.google.com/file/d/1E-CsBJzso8iLJiOo5uxQeHNKEt0oD6xz/view?usp=sharing

2019년 4월 2일

syncAXIS 를 사용한 멀티헤드 On the fly 기법

2019.3월경 스캔랩에서는 자사의 syncAXIS 제품을 1.2.5 버전으로 업그레이드 하며 이를 공개하였습니다. 제가 파악해 보니 매우 흥미로운 기능이 추가되었는데 다름아닌 멀티헤드 on the fly 기능입니다.

스캔랩 사이트 주소 : https://scanlab.de/en/download/syncaxissoftware
* syncAXIS, RTC6, excelliSCAN  에 대해서는 이전글을 참고해 주시기 바랍니다.

  • syncAXIS v1.2.5 버전의 주요 변경사항
  1.  설정파일(XML)의 버전이 1.2로 대폭 바뀌었고, DTD 포맷도 구체적으로 변경되었습니다. XML system configuration 파일은 삭제되었고, DynamicLimits 라는 노드가 추가되었는데 주로 제한(영역크기 제한, 속도, 가속도, 가가속도 등의 동역학 값들) 값을 추가하고 이를 침범할 경우의 처리를 설정할 수 있습니다. 아마도 안전 관련 사항이 대폭 추가된듯 합니다.
  2. 몇몇 API 함수들이 추가되었습니다. 
    1. 주파수, 펄스폭을 런타임에 설정이 가능하게 되었습니다. 
    2. 멀티헤드별 행렬설정이 가능하게 되었습니다.
    3. 드디어 c# 에서 callback 을 지원하도록 개선(?) 되었네요. (완성된 버전은 아닌것 같네요. delegate 방식도 아니고 상속해서 사용하는 방식인거 같은데 생성이 되지 않는 부모 클래스를 제공하다니 -_-;)
  3. XML 설정파일에서 멀티헤드를 설정할 수 있도록 개선되었습니다. (최대 4개까지 지원한다고 합니다)
  4. syncAXIS Viewer 가 업데이트 되었습니다. (DirectX 기반으로 초기버전보다는 렌더링이 비약적으로 빨라졌습니다. (참고) 시뮬레이션 모드에서 생성된 로그 파일을 기반으로 모션 프로파일링이 가능합니다.

  • 멀티헤드의 구성

아래 사진과 같이 여러개의 RTC6 카드를 사용합니다. 또한 master-slave 연결을 사용해야 하며, 특이한것은 첫번째 카드에서 SLEC 컨버터(2nd head 커넥터)로 Ehtercat 통신 변환이 발생되며, 이후 카드들에서는 2nd head 커넥터에 스캐너(excelliSCAN) 를 연결합니다.
즉 스캐너 4개를 구동하기 위해 RTC6카드는 3개가 연결된 모습입니다. (레이저 소스 제어용 시그널이 3개가 되는데 으음... -_-;)

헤드 별로 하드웨어적인 상태 (틀어짐등의 오차)가 약간의 차이를 가지고 있을 것이므로, 이 상태를 적절히(?) 찾아서 오차량(dx, dy, theta)을 미리 설정파일에(xml)에 적용할수있게 되어 있습니다. (드디어 스테이지 스캐너간 X,Y 좌표방향을 맞출 필요가 없습니다. 설정 파일에서 행렬값만 바꾸면 됩니다. 이 버전에 와서야 지원되는군요.)



  • 모션 스테이지 한개 + 스캐너2 개가 구성된 모습

이후 가공 대상을 올려놓게 되는데 이 대상역시 약간의 오차를 가지고 올려놓게 될것 입니다. 이 오차역시 설정 파일(XML) 에 지정하게 됩니다. (해당 기능의 함수를 제공하고 있으므로, XML 에 설정하기 보다는 프로그램 런타임시 호출하여 사용하게 되겠군요 !)

즉 앞서 설정된 스캐너의 장착 오차(기계적 오차)와 대상 물체의 오차(대상 자재 오차)에 해당하는 3x3 행렬(Matrix)값을 계산해 주어야 합니다.

결과적으로 on the fly 가공을 하게 되면 syncAXIS DLL 라이브러는 Master 스캐너의 동작을 그대로 Slave 로 복사하여 가공하는 방식이 아니라, 서로간의 차이점을 계산한후 공통된 모션경로를 스테이지 제어에 사용하면서 동시에 그 차이점을 두개의 모션 경로로 분리하여 스캐너 1, 2에 각기 다른 모션 움직임이 발생하는 방식입니다.


  • On the fly 모션을 합치고 분리하는 모습

아래에서는 스테이지 모션을 위해  하나의 공통된 움직임을, 스캐너 2개는 서로 다른 움직임을 각각 경로를 추출하고 이를 계산해 내는 과정입니다.




추신) 현재 4개까지가 공식적인 지원이고, 추후에는 더 많은 멀티헤드 사용이 가능할 것으로 보입니다.

추신) syncAXIS DLL 내부적으로 모션 Planning 을 계산하게 되는데, CPU 자원을 상당히 소비하며, 좌표데이타 전달이 지속적으로 되지 않으면 문제가 될 소지가 다분합니다. 버퍼 언더런(buffer underrun) 상황을 조심하시기 바랍니다.

추신) 즉 on the fly 가공중에 절대로 break point 를 찍고 디버깅 하시면 않됩니다. ! 가공 데이타 전달이 중단되어 버퍼 고갈로 심각한 문제가 예상됩니다.

추신) C# 기반으로 콜백 함수 등록시 버그는 리포트하여 금일(2019.4.5) 스캔랩으로부터 패치가 되었고 이메일로 받아 정상 동작을 확인하였습니다. 조만간 홈페이지에 공개되겠지요.

2018년 11월 30일

고급 스캐너 및 레이저 제어기법



1. 위치 의존적 보정 기법

스캐너는 F-Theta 렌즈를 사용하여 레이저빔을 아주 작은 영역에 모아 큰 에너지를 낼수있는 구조입니다.

 2차원의 필드(Field)의  영역을 가공하기 위해서는 갈바노메터(미러가 달린)의 각도를 살짝 돌려야 겠지요? 이때 필드의 중심에서 외곽으로 갈수록 레이저 파워(에너지)가 일정할까요? 빔의 경로가 다르고 빔의 이동 거리도 다르고 렌즈라는 물리적 매체를 통과하면서 손실되는 에너지도 다르지 않을까요? 렌즈를 통과한 레이저 빔이 수직으로 목표에 떨어질까요? 레이저 빔의 스팟(spot)의 크기가 영역별로 미세하게 바뀐다면?
결국 다양한 광학 오차가 반영되어야 합니다.


이처럼 필드 영역에서 에너지 손실 오차가 있고 이를 상쇄할만한 기능이 필요합니다.
이를 통상, 위치에 의존적인 파워 보정이라고 부르고 있습니다.

해당 보상 방식으로는
  • 2차원 필드의 영역을 중심에서의 거리값(즉 반지름값)에 스케일 값을 적용해 출력을 변경하는 방법
  • 2차원 필드의 영역을 파워 스케일 (power scale factor) 맵을 만들어 가중치를 적용해 이를 근사하는 방법
등이 가능합니다.


참고) 렌즈를 바꾼다던지, 레이저 빔의 경로가 변경된다면 이 보정 절차를 새로 해야 겠지요.


2. 속도 의존적 보정 기법


스캐너가 위와 같은 모양 가공을 한다면, 당연히 그 시작 끝 부분에서는 가속, 감속이 발생하게 되는데, 이로 인해 가감속 영역에서는 레이저 출력펄스를 여러대 더 맞게(!)되고, 결국 의도하지 않은 에너지가 중첩되어 전달되고, 레이저 가공면의 폭도 일정하지 않고, 단위면적당 에너지 밀도(density)도 다르고, 이에 따라 열 에너지가 그 주변에 확산(HAZ 영역 증가)되는등의 부작용이 발생합니다.

더군다나 연속된 형상(mark, arc, ...)을 가공할지라도 스캐너의 속도는 각 벡터별로 사용자가 다양하게 변경하여 가공할수 있으니 가속 감속이 항상 발생할 수 밖에 없습니다. 아예 90도 혹은 180도를 꺽어서 움직여야 한다면? (시속 100km/h 달리던 차가 급정거하여 후진을 한다면 당연히 스키드마크가 생기는건 예상해야 겠지요 !)

이를 해결하기 위해, 통상 속도에 의존적인 파워 보정이라는 방법을 사용합니다. 해당 방식으로는
  • 레이저 출력 주파수(Frequency)을 가변하는 방식
  • 레이저 출력 펄스폭(Pulse width)을 가변하는 방식
  • 레이저 출력 제어용 아날로그  혹은 디지털 출력을 가변하는 방식
  • 외부 신호(속도 입력용 엔코더)를 활용해 위 3가지를 적용하는 방식
등이 가능합니다.

(참고) 물론 각도가 급격히 꺽이는것은 sky-writing 이란 기법으로도 해결이 가능하지만 해당 방식은 레이저 출력이 꺼졌다 켜지는 추가시간이 필요하므로 논외로 하겠습니다.



마치며, 레이저 소스의 출력 변경이 위 방식을 대응할만큼 지연(latency)없이 기민해야 가능하며 일부 벤더에서는 벤더고유의 가변방식을 제공하기도 합니다.

2018년 11월 27일

스캐너와 레이저간 동기화 방법

1. 트래킹 에러(Tracking Error) 시간값

스캐너는 두개의 모터끝에 거울을 장착하고 있고, 그 모터의 회전량을 아주 작지만 고속으로 움직이도록 목표로 되어 있습니다. 결국 두 거울에 레이저 광선을 쏘아 반사시켜 2차원 평면 영역에 가공을 하고자 하는 것인데요.

지정된 속도가 마이크로 벡터 단위(10usec)로 출력이 되나 실제 스캐너의 움직임이 따라오지 못하는 모습

사용자가 특정 가공 속도를 지정하게 되면, 스캐너 제어기는 통상 매 10 마이크로초(usec)의 제어 주기(micro-vectoring)로 이 속도 프로파일을 출력시키게 됩니다. 하지만 위 그림처럼 스캐너 장치에 장착된 모터의 움직임은 질량(거울등의 무게 부하)이 있으므로 사용자가 원하는 가공속도를 지정하더라도 각각 가속 감속을 필연적으로 동반하게 되며, 결국 사용자의 명령시간과 실제 모터의 움직인 시간의 차이가 발생하게 됩니다. 이를 통상 트래킹 에러(Tracking error) 라 부릅니다.

트래킹 에러 = 명령된 시간 - 실제 위치에 도달한 시간

일부 스캐너 제어기들은 트래킹 에러 시간값을 직접 입력받아 "스캐너의 구동시작과 레이저 광선의 시작간의 지연(불일치)을 해결" 하기도 합니다.



만약 트레킹 에러값이 실제 에러값보다 너무 크게 설정 되면,
스캐너가 너무 빠르게 응답한다고 설정한 것이기 때문에 레이저를 일찍 쏘개 되어 시작점(mark 시작점)에서 레이저가 과도하게 뭉치게 진행되며, 실제 에러값보다 너무 작게 설정 되면 스캐너가 너무 느리게 응답한다고 설정한 것이기 때문에, 레이저를 늦게 쏘개 되어, 시작점(mark 시작점)이 이빨이 빠진채로 진행될 수 있겠지요. 적정한 값은 해당 벤더의 사양서를 참고해 주시기 바랍니다. 대략적인 근사값은

트래킹 에러 = 스캐너 가속시간 * 0.6 

스캐너 제품별 Tracking Error 시간값 (공급사에서 제공)

마지막으로, 스캐너의 레이저 광선 구경(Apperture)가 클수록 내부에 사용된 거울의 질량이 크고, 소위 무겁고 굼뜨기 때문에 트래킹 에러 가 당연히 클수밖에 없습니다. 제조사에서는 무게를 줄이기 위해 거울이 디자인을 네모반듯하게 만드는 것이 아닌 레이저 광선이 반사되지 않는 끝 영역을 없애 무게를 줄이기 위해 다양한 형상을 만들고 있습니다.


무게를 줄이기 위해 반사에 불필요한 면적을 줄여 다양한 반사거울의 모습.


2. 레이저 트리거 지연 (On Delay) 시간값

스캐너와 유사하게 레이저 출력장치 역시 레이저 출사를 시작할때 유사한 오차값을 가지고 있습니다. 즉 외부에서 사용자가 레이저 출력을 시작하는 신호를 주는 시간과 실제 레이저가 발진하는 시간의 차이(On delay)가 존재하게 됩니다. 

레이저 트리거 시작 지연 (On delay) = 외부출력 시작 신호 시간 - 실제 레이저 발진 시작 시간

이 지연값은 레이저 소스의 종류및 발진방식에 따라 매우 다르기 때문에 해당 벤더의 사양문서를 참조하여 설정해야 합니다.

3. 점프 지연값 (Jump Delay)

스캐너는 두가지 큰 움직임을 합니다. 레이저를 출사하지 않고 이동하는곳(jump)과 출사하면서 이동하는곳(mark)으로, 사용자가 점프 속도와 가공속도 각각 2가지 속도값을 지정하게 됩니다.

스캐너가 점프을 완료하게 되면,  즉 감속을 시작하게 되면 약간의 출령임(?)이 유발되게 되고 이 같은 상태가 안정화 되기까지 안정화 시간이 필요합니다. 이를 점프 지연(jump delay) 으로 부르고 있으며, 통상 점프 속도가 클수록, 거리가 멀수록, 지연값도 같이 높여 설정해 주어야 합니다. 50km/h 차와 100km/h 차의 브레이크를 밣았을때 멈추기 까지 서로 다른 시간이 필요한것을 상상해 보시기 바랍니다.

만약 스캐너가 가감속을 충분히 하지 못할만큼 점프구간이 매우 짧다면, 점프 지연값을 작게 사용하는게 차라리 낫게 됩니다. 왜냐하면 스캐너가 충분히 목표 속도에 도달하지 못할정도였고, 이 때문에 가감속 관성이 작아졌다면 안정화에 필요한 지연시간이 클 필요가 없기 때문입니다.

SCANLAB RTC 제어기의 variable jump table 설정된 모습


이처럼 점프 거리에 따라 점프 지연값을 다양하게 사용해야 할 경우가 있기 때문에, 특정 제어기들은 점프 거리에 따른 지연값 테이블을 지정할수있는 기능을 제공하기도 합니다. 이 점프 지연값이 작을수록 전체 가공시간이 짧아지기 때문에 점프가 많은 가공의 경우 당연히 전체 가공시간도 같이 짧아지게 되겠지요? 반대로 충분히 큰 값을 사용하면 총 시간이 늘어나지만 스캐너 감속에 필요한 안정시간이 충분히 부여되므로 여유가 생기게 됩니다.
물론 높은 점프 속도와 짧은 점프 지연값의 사용으로 누군가의 퇴근이 빨라질수 있습니다 !

4. 마크 지연값 (Mark Delay)

앞서 점프 지연과 마찬가지로, 실제 레이저 가공을 마치는 시점(mark)에도 명령된 위치와 실제 스캐너 위치의 차이가 있습니다. 즉 스캐너는 아직 명령된 위치에 오지 못했는데 레이저 출력 신호를 꺼버리게 되면 끝 부분의 가공이 되다 말게 되는 것입니다. 이는 트레킹 에러로 인한 것으로 보아야 겠지요.

결국 스캐너가 Mark 명령을 완료한 후 실제 명령된 도착 위치에 올때까지 대기 혹은 지연되는 시간값을 마크 지연값(Mark delay)이라고 합니다. 물론 값이 크면 안정시간이 충분히 부여되므로 여유가 생기게 되지만 총 가공시간이 늘어나겠지요.


5. 폴리 지연값 (Poly Delay)

앞서 본 마크 지연값은 마크 명령의 끝에서 발생되지만, 통상 'ㄱ' 형태와 같이 하나이상의 연속된 마크 명령을 주로 사용합니다. 이때 연속된 마크 명령 사이에 지연시간을 줄수있는 것이 폴리곤(Polygon) 혹은 줄여서 폴리 지연값입니다.

당연히 이 값을 많이 주게 되면 꺽이는 부분에서 시간이 지연되고 그 시간동안 레이저 광선이 더 맞게 되는 효과가 있습니다. 이를 활용하면 꺽이는 부분을 부드럽게(?) 혹은 각지게(?) 하는 효과를 얻을수 있게 됩니다.

하지만 꺽이는 각도가 그 모양에 따라 다른데, 한가지 지연값만 지정할 경우 그 품질이 일정하지 못한 문제가 있습니다. 때문에 일부 제어기에서는 이 꺽이는 각도에 따라서 지연값 을 다양하게 지정할 수 있는 기능을 제공하기도 합니다.

2018년 11월 13일

RTC TESTCASE 를 활용한 예제



Case 1. 고속으로 움직이는 물체에 1차원 MOTF(Marking On The Fly)를 하고자 한다면

  • RTC5 객체를 생성한다 이때 인자로 CntPerMm (밀리미터당 엔코더 개수)를 측정하여 생성해 준다. 측정방법은 ctrlGetEncoder 함수를 사용하여 현재의 엔코더 펄스 개수를 확인할 수 있다. 예를 들어 1mm 물체를 이동하여 2000 개의 펄스가 생성되면 CntPerMm = 2000 을 인자로 준다.
  • listBegin / listJump ... listMark... listArc  / listEnd 가 통상적으로 사용하는 방식인데, MOTF 를 위해서 listOnTheFlyBegin / listOnTheFlyEnd 를 추가적으로 사용한다.
  • 즉 listBegin / listOnTheFlyBegin  / listJump ... listMark... listArc  / llistOnTheFlyEnd / listEnd 의 순서로 호출하여 사용한다.
  • listOnTheFlyBegin / llistOnTheFlyEnd  사이에 호출되는 Jump/Mark 명령의 좌표값은 호출당시의 입력된 엔코더의 값 만큼 상쇄되어 이동 물체를 추종하게 된다
  • 마치 아래와 같은 방식의 동작이 가능해진다. 




Case 2. 윈도우즈 폰트를 이용해 'Sepwind is Best!' 의 외곽선을 레이저를 이용해 가공한다면,




2018년 11월 6일

RTC TESTCASE 버전 0.5

지난 시간에 "RTC를 이용한 SW 개발 플랫폼" 이란 내용으로 RTC Testcase 프로젝트를 공개한후 이에 대한 신규 변경 사항을 알려드립니다. 개발에 관심이 있는 분들은 참고해 주시기 바랍니다.

Git Hub 사이트https://github.com/labspiral/rtctestcase


버전 0.5 변경사항
  • 3*3 행렬적용이 가능해졌습니다.
    • 회전, 이동등의 선형변환을 적용할수있습니다.
    • 행렬스택에 push, pop 하는 방식을 도입하였습니다. (opengl 방식과 유사)
  • measurement 관련 버그가 해결됨

버전 0.4 변경사항
  • marking on the fly 기능 추가됨 (XY 엔코더에 의한 MOTF 가공)
    • 엔코더 리셋, 현재 엔코더 카운트 값 조회기능
    • X, Y 엔코더의 특정위치 대기 기능
  • measurement 기능 추가됨 (최대 100KHz 로 스캐너 위치및 레이저 시그널 저장가능)
    • list gather start/end 사이의 정보가 내부 메모리에 저장됩니다. 
    • 2개의 채널(x,y, laser 시그널 등) 저장 지원가능


버전 0.3 변경사항
  • 3D 가공용 옵션 기능 추가 (VarioScan 기능 활성화)
  • list jump/mark/arc 에 z 축 위치정보 인터페이스 추가됨


버전 0.2 변경사항
  • RTC6 인터페이스 (PCI Express 타입) 추가됨
  • RTC6 이더넷 버전(LAN 통신 타입) 인터페이스가 추가됨
    • experimental 버전입니다
  • RTC3, 4, 5, 6 ,6이더넷 모두 대용량 데이타 (다수의 리스트 명령어) 처리 가능
    • 내부에서 더블버퍼링 처리됨 (auto_change 모드 사용됨)
    • 하드웨어적인 리스트 명령 버퍼 제한 (RTC3,4 의 경우 8천개, RTC5의 경우 백만여개 등)에 상관없이 대용량의 리스트 명령어를 삽입하여 가공이 가능해짐
      • 3500 개의 리스트 명령을 지속적으로 실행하는 방식적용
      • 대용량 데이타의 통신(PCI Express)으로 인한 데이타 통신 lack 현상 방지



사용방법


오픈소스 저장소 정보


syncAXIS 개발환경 설정하기



https://scanlab.de/en/download/syncaxissoftware 에서 예제 프로그램, 라이브러리 메뉴얼 및 최신 버전의 DLL (작성일 기준 1.0.7.2) 을 배포하고 있습니다.

1. 메뉴얼 상에 주의할 내용으로는
"이 패키지에는 RTC6 파일 (RTC6DLL, RTC6Dat.dat, RTC6Out.out, RTC6Dat.dat)이 포함되어 있습니다. 이 파일들은 RTC6 보드 자체와 함께 제공되거나 SCANLAB 웹 사이트에서 다운로드 된 RTC6 파일로 대체되어서는 안됩니다."
2. syncAXIS-1.0.7.2-win32\configuration 폴더안의 XML 파일을 열어 필요한 설정내용을 변경합니다. 시뮬레이션 모드로 일단 시작하도록 합니다.
  • syncAXISConfig.Template.xml 파일
    • <cfg:SysConfigFilePath>sysconfig xml 파일의 절대경로</cfg:SysConfigFilePath>
    • <cfg:ACSController>ACS 제어기의 IP 주소</cfg:ACSController> 
    • <cfg:SimulationMode>true</cfg:SimulationMode> 시뮬레이션 모드로 테스트함
    • <cfg:SimOutputFileDirectory>시뮬레이션 모드의 결과가 저장될 파일의 절대 경로</cfg:SimOutputFileDirectory>
    •  <cfg:LogfilePath>로그파일의 절대 경로</cfg:LogfilePath>
    • <cfg:CorrectionFilePath CalibrationFactor="bit/mm 값"> 보정파일의 절대 경로 </cfg:CorrectionFilePath>
    • <cfg:ProgramFileDirectory>작업디렉토리 경로</cfg:ProgramFileDirectory>
    • <cfg:SerialNumber>USB 동글에 적힌 시리얼 번호</cfg:SerialNumber>
  • SysConfig.Template.xml 파일
    • <cfg:Bandwidth Unit="Hz">로우 패스 필터 주파수</cfg:Bandwidth>
    • <cfg:ReducedStageDynamicFactor>스테이지 다이나믹 팩터값</cfg:ReducedStageDynamicFactor>
3. syncAXIS-1.0.1-win32\example\Installation_Project 에 Visual Studio 용 예제 프로젝트가 있습니다. 이를 개방한 후
  • const std::string ConfigFilePath = "syncAXISConfig.Template.xml 파일의 절대경로";

위와 같이 설정한후 예제 프로그램을 빌드후 실행하면 됩니다.
slsc_cfg_initialize_from_file 함수가 정상적으로 리턴(0 값) 되는지가 중요합니다.


4. https://scanlab.de/en/download/syncaxissoftware 사이트에서 TrajectoryViewer 를 배포하고 있는데, 이 툴은 시뮬레이션 모드 사용시 생성되는 출력 파일을 지정해 보시면 그 사용방법을 알수 있습니다.

시뮬레이션 출력 파일 (상당한 크기의 파일이 생성됩니다)

시뮬레이션 출력파일을 TrajectoryViewer 에서 불러들인 모습


시리우스 라이브러리 홈페이지 오픈

현재 시리우스(Sirius) 라이브러리라는 제품을 개발하고 이를 소개하는 홈페이지를 오픈 하였습니다. 관심있는 분들의 많은 방문 요청드립니다. 앞으로 업데이트 소식및 변경사항은 스파이럴랩 홈페이지를 통해 진행할 예정입니다. 스파이럴랩 홈페이지 :  h...