GcodeDriver는 사용자 지정 드라이버 코드를 작성하지 않고도 피더와 같은 복잡한 기계 및 애드온 하드웨어를 구성할 수 있게 해주는 범용 드라이버입니다. 모든 구성은 구성 파일의 명령을 통해 수행됩니다.

GcodeAsyncDriver는 이 드라이버의 고급 확장입니다. 이 페이지의 지침은 여전히 적용되지만 여기에 더 많은 설정이 설명되어 있습니다. 모든 설정을 유지하면서 문제 및 솔루션 마법사 시스템을 사용하여 고급 드라이버로 자동 업그레이드할 수 있습니다.

특정 컨트롤러에 대해 GcodeDriver를 구성할 때 추가 정보는 다음 페이지를 참조하십시오:

• Grbl
• TinyG
• Marlin
• Smoothie -- 그 외 참고 Smoothie Configuration

커뮤니티에서 제공하는 일부 구성 예제는 GcodeDriver: 예제 환경설정를 참조하십시오. 컨트롤러와 일치하는 컨트롤러를 찾으면 해당 컨트롤러를 사용자 시스템의 시작점으로 사용할 수 있습니다.

컨트롤러에 드라이버를 연결하세요.

GcodeDriver를 구성하려면 적어도 COMMAND_CONFIRM_REGEX와 하나 이상의 명령을 설정해야 합니다. COMMAND_CONFIRM_REGEX는 드라이버가 컨트롤러의 응답을 일치시키기 위해 사용하는 정규식입니다. 응답이 일치하면 명령이 완료된 것으로 간주됩니다. 명령을 정의하면 OpenPnP가 특정 작업을 수행하려는 경우 컨트롤러로 보낼 내용이 드라이버에 표시됩니다.

모든 명령은 변수 치환을 지원합니다. 변수 자리 표시자는 {VariableName:Format} 형식입니다. 각 명령에 사용할 수 있는 변수 이름은 아래 명령과 함께 나열됩니다. 형식은 printf와 유사한 Java 스타일 형식 문자열입니다. 형식이 지정되지 않은 경우 형식은 %s로 기본 설정되며 이는 단순히 변수의 값을 문자열로 변환합니다.

변수 자리 표시자는 명령에 변수가 있을 때만 방출됩니다. 그렇지 않으면 간단히 텍스트에서 제거됩니다(예: {에서 }로). '형식'에는 고정 텍스트 또는 형식 지정자가 삽입된 고정 텍스트의 조합도 포함될 수 있습니다. 따라서 변수가 있는 경우에만 조건부로 정적 텍스트를 내보낼 수 있습니다. 예를 들어 축 문자가 좌표와 함께 방출되어야 하거나 전혀 방출되지 않아야 하는 경우에 유용합니다. {X:X%.4f}.

아래 명령어에서 명령어에 사용 가능한 변수가 있는 경우 명령어 뒤에 해당 변수가 표에 나열됩니다.

명령어, 변수 및 예제의 전체 목록은 GcodeDriver: Command Reference를 참조하십시오.

GcodeDriver는 정규식을 사용하여 컨트롤러의 응답을 파싱합니다. 정규식은 매우 유연하며 거의 모든 종류의 텍스트에서 거의 모든 값을 구문 분석할 수 있습니다.

GcodeDriver가 사용하는 대부분의 정규식은 특정 응답이 수신되도록 텍스트를 일치시키는 데 사용됩니다. 다른 항목에는 응답에서 값을 캡처하는 특수 시퀀스가 포함됩니다.

RegExr은 정규식을 실험하기에 좋은 사이트입니다. 설명 탭을 클릭하면 식의 각 부분이 수행하는 작업이 표시되고 세부 정보 탭에는 일치 항목 및 캡처된 값에 대한 정보가 표시됩니다.

참고: 가장 일반적인 컨트롤러 펌웨어의 경우 OpenPnP는 많은 명령과 정규식을 자동으로 구성할 수 있습니다. 기계에 구성된 대로 축을 사용하여 올바른 변수로 구성합니다. 문제 및 솔루션 마법사 시스템을 사용하여 제안된 코드를 얻으십시오. 언제든지 해제/실행 취소하거나 나중에 변경/확장할 수 있습니다.

드라이버는 이 정규식을 사용하여 컨트롤러의 응답을 찾습니다. 명령을 보낸 후 명령 완료를 고려하기 전에 이 정규식과 일치하는 줄을 기다립니다. 많은 컨트롤러에서 이는 단순히 ok이지만 일부 컨트롤러는 명령 결과와 함께 추가 정보를 전송하므로 ^ok.*을 사용하는 것이 좋습니다.

컨트롤러가 ACTUATOR_READ_COMMAND에서 반환된 값 다음에 OK를 반환하지 않으면 여기에 이 응답도 포함해야 합니다. 예: "^(ok)|(Read:).*".

드라이버는 이 정규식을 사용하여 컨트롤러의 응답 오류를 확인합니다. 정규식이 설정되고 응답 중 하나와 일치하면 오류가 발생하고 응답 메시지가 포함됩니다. 컨트롤러가 유효하지 않거나 부적절한 명령에 대한 오류를 보낼 수 있는 경우 이 정규식을 사용하여 오류가 수신될 때 OpenPnP가 중지되도록 할 수 있습니다.

예: ^error:.*

최신 버전의 OpenPnP 2.0 및 최신 컨트롤러 펌웨어의 경우 더 이상 필요하지 않은 경우가 많습니다. TinyG 사용자는 펌웨어 업그레이드해야 합니다. 문제 및 솔루션 마법사 시스템을 사용하여 현대적인 방식으로 설정하세요. 즉, MOVE_TO_COMPLETE_COMMAND를 사용합니다.

이전 버전의 OpenPnP 및/또는 이전 펌웨어의 경우 다음 지침을 따르십시오.

If specified, the driver will check for this regex in the responses after a move-to-command is sent and will not return until the regex is matched. This can be used to support motion controllers that return the command confirmation before movement is complete.

Example: .*vel:0.00.*

ACTUATOR_READ_COMMAND를 보낸 후 액추에이터에서 값을 파싱하는 데 사용됩니다. 정규식은 필수 응답 값을 포함하는 Value로 명명된 그룹을 포함해야 합니다.

예: read:(?<Value>-?\d+)

이것은 read:255 형식으로 컨트롤러의 응답을 읽습니다. 정규식은 다음과 같이 분류됩니다.

1. read:는 컨트롤러가 값 앞에 보내는 고정 텍스트입니다.
2. 나머지 정규식 주위의 괄호는 캡처하려는 값으로 다른 모든 것을 표시합니다. 이것을 캡처링 그룹이라고 합니다.
3. ?<Value>는 캡처 그룹에 OpenPnP가 결과를 읽는 데 사용할 "Value"라는 이름을 부여합니다. 이 텍스트는 정규식의 어딘가에 있어야 합니다. 정확히 ?<Value>로 나타나야 하며 정규식의 값 일치 부분도 포함하는 괄호로 묶어야 합니다.
4. -?는 값 앞에 선택적 음수 부호를 허용합니다.
5. \d+는 값 자체를 나타내는 하나 이상의 숫자를 의미합니다.

참고: 가장 일반적인 컨트롤러 펌웨어의 경우 OpenPnP가 이 정규식을 자동으로 구성할 수 있습니다. 문제 및 솔루션 마법사 시스템을 사용하십시오.

위치 보고를 파싱하는 데 사용됩니다. 프로그램 외부에서 이동이 이루어졌을 때 OpenPnP에 업데이트하기 위해 컨트롤러가 위치 보고서를 보낼 수 있습니다. 이는 수동 조그 펜던트와 같은 외부 조그를 지원하는 컨트롤러에 특히 유용합니다.

정규식은 업데이트하려는 각 축에 대해 명명된 그룹을 포함해야 합니다.

예: <Idle,MPos:(?<x>-?\d+\.\d+),(?<y>-?\d+\.\d+),(?<z>-?\d+\.\d+),(?<rotation>-?\d+\.\d+)>

컨트롤러에서 사용하는 측정 단위입니다. 밀리미터가 가장 일반적이지만 미터, 센티미터, 미크론, 피트, 인치 및 밀도 지원됩니다. 이것은 moveTo 명령을 보내기 전에 위치 데이터를 변환하기 위해 내부적으로 사용됩니다.

move-to-command에서 전송될 최대 이송 속도 값입니다. 전송되는 실제 값은 이 값보다 작거나 같습니다.

명령을 보내기 전에 직렬 포트에 연결한 후 대기하는 시간(밀리초)입니다. 이는 연결 시 재설정되는 컨트롤러가 있거나 응답을 시작하는 데 몇 초가 걸리는 경우에 유용합니다.

이스케이프 문자 시퀀스를 명령에 포함할 수 있도록 하려면 이 옵션을 활성화하십시오. 이스케이프 형식은 백슬래시 U(대문자 또는 소문자)와 유니코드 문자를 나타내는 정확히 4개의 16진수 문자(대문자 또는 소문자)가 나옵니다. 예를 들어 ctrl-x 문자(16진수 18)를 보내려면 명령에 \u0018을 입력합니다. 다음 바로 가기 이스케이프 시퀀스도 허용됩니다. 예를 들어 ctrl-x 문자(16진수)를 보내려면 명령에 \u0018을 입력합니다. 다음과 같은 바로 가기 이스케이프 시퀀스도 허용됩니다:

• \b - backspace character, equivalent to \u0008
• \f - form feed character, equivalent to \u000C
• \n - line feed character, equivalent to \u000A
• \r - carriage return character, equivalent to \u000D
• \t - tab character, equivalent to \u0009

The TinyG controller is traditionally configured via the CONNECT_COMMAND using a series of $var=<value> statements. These might cause TinyG to write some settings back to the EEPROM (only if they're changed). During that EEPROM write, interrupts on the MCU have to be disabled therefore no further serial communication is allowed.

There is now a $-Command Wait Time [ms] that pauses sending for that many milliseconds after each command starting with a $ sign:

Notes: The 50ms default was taken from the Liteplacer Software source code. See also the user discussion.

With Confirmation Flow Control enabled, this is always going to work, which is what Issues & Solutions automatically suggests for the TinyG.

With Confirmation Flow Control disabled (i.e. truly asynchronous operation), this is only guaranteed to work, if the $-commands come as the first thing inside the CONNECT_COMMAND, or if the controller is otherwise guaranteed to be idle before sending $-commands.

The wait time will now be added to any $-commands, regardless of whether it actually writes to the EEPROM or not. To check the effect, go to the Log tab (set to Trace level):

최신 버전의 OpenPnP 2.0에서는 하위 드라이버가 더 이상 사용되지 않습니다. 이제 드라이버 트리 노드에서 일반적인 [+] 버튼을 사용하여 모든 유형의 여러 드라이버를 추가할 수 있습니다.

이전 버전의 OpenPnP의 경우 다음 지침을 따르십시오.

Sub-Drivers allow you to interface multiple controllers by passing commands through. This can be used to control additional boards attached to your machine for functions such as feeders, actuators, conveyers, lighting, etc.

When a command is sent to the driver it is first processed by the main driver and then it is passed on to each defined sub-driver. If the main driver or any sub-driver does not define a handler for the command it is simply ignored.

For example, let's say you have your machine setup to use a Smoothieboard and you are using GcodeDriver to control it. You will have configured various commands such as the move-to-command, pick-command, place-command, etc.

Now perhaps you'd like to add an automatic feeder but don't have any I/O left on your Smoothieboard. You could add an Arduino connected by USB serial and control it with a sub-driver. On the sub-driver you would only define actuate-boolean-command.

Now when OpenPnP sends a movement command it will be processed by the main driver, which will move the machine. It will then be passed to the sub-driver, but since the sub-driver doesn't have a move-to-command it will be ignored. Then when OpenPnP wants to actuate your feeder it will send an actuate command. The main driver does not have actuate-boolean-command defined so it ignores it and passes it on to the sub-driver which processes it.

Using this system you can build up a series of controllers of any complexity that you like and control as many devices as you need.

Here is an example sub-drivers section of the main driver configuration:

<sub-drivers class="java.util.ArrayList">
   <reference-driver class="org.openpnp.machine.reference.driver.GcodeDriver" port-name="/dev/tty.usbmodem1A12421" baud="9600" flow-control="Off" data-bits="Eight" stop-bits="One" parity="None" set-dtr="false" set-rts="false" units="Millimeters" max-feed-rate="50000" timeout-milliseconds="5000" connect-wait-time-milliseconds="750">
      <command type="COMMAND_CONFIRM_REGEX">
         <text><![CDATA[^ok.*]]></text>
      </command>
      <command type="ACTUATE_DOUBLE_COMMAND">
         <text><![CDATA[{Index}]]></text>
      </command>
   </reference-driver>
</sub-drivers>

최신 버전의 OpenPnP 2.0의 경우 GUI에서 축을 직접 매핑할 수 있습니다. 구동 축 매핑 페이지를 참조하세요.

이전 버전의 OpenPnP의 경우 다음 지침을 따르십시오.

If your system has more than one nozzle you will need to tell OpenPnP which axes on your controller map to which nozzles, and other devices. Axis Mapping allows you to do this, along with specifying axes that should be ignored or included for a given head mounted device. This is an advanced option and will not be used by everyone. By default OpenPnP will create a basic axis mapping configuration that will work for a single nozzle, four axis system.

See GcodeDriver: Axis Mapping for the full documentation of this feature.

최신 버전의 OpenPnP 2.0의 경우 GUI에서 직접 구성할 수 있습니다. 비쥬얼 호밍 페이지를 참조하십시오.

이전 버전의 OpenPnP의 경우 다음 지침을 따르십시오.

GcodeDriver supports the ability to complete the homing operation using a vision check. If there is a part defined in your Parts list called FIDUCIAL-HOME then after GcodeDriver completes the standard homing operation (using HOME_COMMAND) it will do a fiducial check for the FIDUCIAL-HOME part and reset the home coordinates.

To use visual homing:

1. Create a Part called FIDUCIAL-HOME. The Part should follow the same rules are used for setting up Fiducials.
2. Set the GcodeDriver POST_VISION_HOME_COMMAND as as described in the Reference. This command is sent after visual homing is complete and will reset the coordinates to the home coordinates.
3. Set up your machine so that when mechanical homing is complete the fiducial is visible to the camera.
4. When mechanical homing is complete, GcodeDriver will look for the fiducial, center on it and then reset the X and Y coordinates to the home coordinates.

If your homing fiducial is in a different location than the camera can see after homing you can change the location that is searched by adding <homing-fiducial-location units="Millimeters" x="0.0" y="0.0" z="0.0" rotation="0.0"/> to your driver in machine.xml. Also you will need to add a G0 X Y command (fiducial X, Y coordinates) at the end of your HOME_COMMAND so after homing the machine moves to the approximate homing fiducial location.

최신 버전의 OpenPnP 2.0의 경우 GUI에서 직접 구성할 수 있습니다. 백래시 보상 페이지를 참조하십시오. 아래에 설명된 특수 Gcode 구성은 더 이상 필요하지 않습니다.

이전 버전의 OpenPnP의 경우 다음 지침을 따르십시오.

The GcodeDriver includes basic basic backlash compensation; also known as slack compensation. When enabled, the machine will always overshoot the target position and then move back to the target at a slower rate. This has been found to resolve issues with improperly tensioned belts and other sources of backlash.

To enable backlash compensation, there are two steps:

1. In the GcodeDriver configuration, set the backlash offset X and Y to a small value that you think is greater than your backlash. Starting with -0.4mm is a good choice. Also set the backlash feed rate factor to 0.1. The max feed rate is multiplied by this value for the backlash move, so using 0.1 will move the head at 10% of it's normal speed for the final position approach.
2. In the GcodeDriver Gcode configuration, change your move to command to look something like:

G0 {BacklashOffsetX:X%.4f} {BacklashOffsetY:Y%.4f} {Z:Z%.4f} {Rotation:A%.4f} F{FeedRate:%.0f}
G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:A%.4f} F{BacklashFeedRate:%.0f}

The way this works is that the first command moves past the target position by the backlash offset amount at the normal feed rate. The second command then moves to the final position at the backlash feedrate, which will be slower.

More information about this feature can be found in https://github.com/openpnp/openpnp/issues/318.

최신 버전의 OpenPnP 2.0의 경우 이제 선형 축 변환에 의해 보다 보편적으로 처리됩니다. Linear Transformed Axes 페이지의 비 직각성 보상 사용 사례 섹션을 참조하세요.

이전 버전의 OpenPnP의 경우 다음 지침을 따르십시오.

No matter how well you planned your pnp machine and how well you assembled it chances are that the X and Y moving axes are not 100% perpendicular to each other. A very small 0.1° alignment error will already result in a physical offset of 0.52mm (already a bit more than the width of one 0402 component) when the head travels 300mm.

The GCodeDriver can compensate such non squareness with a "Non-Squareness Factor". This factor basically tells the ratio between X offset and Y movement distance.

Measurement method:

1. Make sure the current Non-Squareness Factor in the GcodeDriver settings panel is zero.
2. Put a piece of graph paper with fine grid into your PnP machine.
3. Align the grid with the X-Axis by moving the camera left and right until a reference grid line matches the motion path exactly.
4. Move the camera into Y direction along a grid line by a defined distance (the further you move the more precise the measurement will be). 100mm is a good start.
5. You will probably find that the camera has not traced the Y line exactly and now it is offset from the center of the camera. Click the DRO and use the relative coordinates to measure the offset from the line.
6. Use the formula in the image above to calculate the Non-Squareness Factor. Positive factors mean a machine leaning left, negatives ones leaning right.
7. Enter the Non-Squareness Factor into the GcodeDriver settings panel and apply.
8. Repeat steps 3 to 5. This time there should be no offset. If the offset is even greater try inverting the sign of the Non-Squareness Factor.

카메라가 이동 명령을 받은경우 노즐이 움직이는 경우(특히 Z방향), Z축에 카메라가 포함되지 않도록 G코드 드라이버_구동축 매핑을 설정하셔야 합니다. 이 작업은 "*" 대신 Z축에 노즐 ID만 지정하여 수행합니다. 자세한 내용은 G코드 드라이버_구동축 매핑을 참조하세요. 또한 이것은 카메라가 회전하도록 명령을 받고 노즐도 회전하는 경우 x,y,z축에서 제한된 이동 속도를 해결합니다(다소 느리게).