diff --git a/docs/locales/lt/LC_MESSAGES/Axis_Twist_Compensation.po b/docs/locales/lt/LC_MESSAGES/Axis_Twist_Compensation.po new file mode 100644 index 0000000000..469e12878a --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Axis_Twist_Compensation.po @@ -0,0 +1,111 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: docs/Axis_Twist_Compensation.md:block 1 (header) +msgid "Axis Twist Compensation" +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 2 (paragraph) +msgid "This document describes the [axis_twist_compensation] module." +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 3 (paragraph) +msgid "" +"Some printers may have a small twist in their X rail which can skew the " +"results of a probe attached to the X carriage. This is common in printers " +"with designs like the Prusa MK3, Sovol SV06 etc and is further described " +"under [probe location bias](Probe_Calibrate.md#location-bias-check). It may " +"result in probe operations such as [Bed Mesh](Bed_Mesh.md), [Screws Tilt " +"Adjust](G-Codes.md#screws_tilt_adjust), [Z Tilt " +"Adjust](G-Codes.md#z_tilt_adjust) etc returning inaccurate representations " +"of the bed." +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 4 (paragraph) +msgid "" +"This module uses manual measurements by the user to correct the probe's " +"results. Note that if your axis is significantly twisted it is strongly " +"recommended to first use mechanical means to fix it prior to applying " +"software corrections." +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 5 (paragraph) +msgid "" +"**Warning**: This module is not compatible with dockable probes yet and will" +" try to probe the bed without attaching the probe if you use it." +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 6 (header) +msgid "Overview of compensation usage" +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 7 (quote) +msgid "" +"**Tip:** Make sure the [probe X and Y offsets](Config_Reference.md#probe) " +"are correctly set as they greatly influence calibration." +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 8 (ordered list) +msgid "" +"After setting up the [axis_twist_compensation] module, perform " +"`AXIS_TWIST_COMPENSATION_CALIBRATE`" +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 9 (unordered list) +msgid "" +"The calibration wizard will prompt you to measure the probe Z offset at a " +"few points along the bed" +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 9 (unordered list) +msgid "" +"The calibration defaults to 3 points but you can use the option " +"`SAMPLE_COUNT=` to use a different number." +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 10 (ordered list) +msgid "[Adjust your Z offset](Probe_Calibrate.md#calibrating-probe-z-offset)" +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 10 (ordered list) +msgid "" +"Perform automatic/probe-based bed tramming operations, such as [Screws Tilt " +"Adjust](G-Codes.md#screws_tilt_adjust), [Z Tilt " +"Adjust](G-Codes.md#z_tilt_adjust) etc" +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 10 (ordered list) +msgid "Home all axis, then perform a [Bed Mesh](Bed_Mesh.md) if required" +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 10 (ordered list) +msgid "" +"Perform a test print, followed by any [fine-" +"tuning](Axis_Twist_Compensation.md#fine-tuning) as desired" +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 11 (quote) +msgid "" +"**Tip:** Bed temperature and nozzle temperature and size do not seem to have" +" an influence to the calibration process." +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 12 (header) +msgid "[axis_twist_compensation] setup and commands" +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 13 (paragraph) +msgid "" +"Configuration options for [axis_twist_compensation] can be found in the " +"[Configuration Reference](Config_Reference.md#axis_twist_compensation)." +msgstr "" + +#: docs/Axis_Twist_Compensation.md:block 14 (paragraph) +msgid "" +"Commands for [axis_twist_compensation] can be found in the [G-Codes " +"Reference](G-Codes.md#axis_twist_compensation)" +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/BLTouch.po b/docs/locales/lt/LC_MESSAGES/BLTouch.po new file mode 100644 index 0000000000..8636ead464 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/BLTouch.po @@ -0,0 +1,380 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "Connecting BL-Touch" +msgstr "" + +msgid "" +"A **warning** before you start: Avoid touching the BL-Touch pin with your " +"bare fingers, since it is quite sensitive to finger grease. And if you do " +"touch it, be very gentle, in order to not bend or push anything." +msgstr "" + +msgid "" +"Hook up the BL-Touch \"servo\" connector to a `control_pin` according to the" +" BL-Touch documentation or your MCU documentation. Using the original " +"wiring, the yellow wire from the triple is the `control_pin` and the white " +"wire from the pair is the `sensor_pin`. You need to configure these pins " +"according to your wiring. Most BL-Touch devices require a pullup on the " +"sensor pin (prefix the pin name with \"^\"). For example:" +msgstr "" + +msgid "" +"It's important that the z_hop movement in safe_z_home is high enough that " +"the probe doesn't hit anything even if the probe pin happens to be in its " +"lowest state." +msgstr "" + +msgid "Initial tests" +msgstr "" + +msgid "" +"Before moving on, verify that the BL-Touch is mounted at the correct height," +" the pin should be roughly 2 mm above the nozzle when retracted" +msgstr "" + +msgid "" +"When you turn on the printer, the BL-Touch probe should perform a self-test " +"and move the pin up and down a couple of times. Once the self-test is " +"completed, the pin should be retracted and the red LED on the probe should " +"be lit. If there are any errors, for example the probe is flashing red or " +"the pin is down instead of up, please turn off the printer and check the " +"wiring and configuration." +msgstr "" + +msgid "" +"If the above is looking good, it's time to test that the control pin is " +"working correctly. First run `BLTOUCH_DEBUG COMMAND=pin_down` in your " +"printer terminal. Verify that the pin moves down and that the red LED on the" +" probe turns off. If not, check your wiring and configuration again. Next " +"issue a `BLTOUCH_DEBUG COMMAND=pin_up`, verify that the pin moves up, and " +"that the red light turns on again. If it's flashing then there's some " +"problem." +msgstr "" + +msgid "" +"After completing the BL-Touch control pin and sensor pin tests, it is now " +"time to test probing, but with a twist. Instead of letting the probe pin " +"touch the print bed, let it touch the nail on your finger. Position the " +"toolhead far from the bed, issue a `G28` (or `PROBE` if not using " +"probe:z_virtual_endstop), wait until the toolhead starts to move down, and " +"stop the movement by very gently touching the pin with your nail. You may " +"have to do it twice, since the default homing configuration probes twice. Be" +" prepared to turn off the printer if it doesn't stop when you touch the pin." +msgstr "" + +msgid "" +"If that was successful, do another `G28` (or `PROBE`) but this time let it " +"touch the bed as it should." +msgstr "" + +msgid "BL-Touch gone bad" +msgstr "" + +msgid "" +"Once the BL-Touch is in inconsistent state, it starts blinking red. You can " +"force it to leave that state by issuing:" +msgstr "" + +msgid "BLTOUCH_DEBUG COMMAND=reset" +msgstr "" + +msgid "" +"This may happen if its calibration is interrupted by the probe being blocked" +" from being extracted." +msgstr "" + +msgid "" +"However, the BL-Touch may also not be able to calibrate itself anymore. This" +" happens if the screw on its top is in the wrong position or the magnetic " +"core inside the probe pin has moved. If it has moved up so that it sticks to" +" the screw, it may not be able to lower its pin anymore. With this behavior " +"you need to open the screw and use a ball-point pen to push it gently back " +"into place. Re-Insert the pin into the BL-Touch so that it falls into the " +"extracted position. Carefully readjust the headless screw into place. You " +"need to find the right position so it is able to lower and raise the pin and" +" the red light turns on and of. Use the `reset`, `pin_up` and `pin_down` " +"commands to achieve this." +msgstr "" + +msgid "BL-Touch \"clones\"" +msgstr "" + +msgid "" +"Important! Do not configure `pin_up_reports_not_triggered` or " +"`pin_up_touch_mode_reports_triggered` to False without first following these" +" directions. Do not configure either of these to False on a genuine BL-" +"Touch. Incorrectly setting these to False can increase probing time and can " +"increase the risk of damaging the printer." +msgstr "" + +msgid "" +"Some \"clone\" devices are unable to perform Klipper's internal sensor " +"verification test. On these devices, attempts to home or probe can result in" +" Klipper reporting a \"BLTouch failed to verify sensor state\" error. If " +"this occurs, then manually run the steps to confirm the sensor pin is " +"working as described in the [initial tests section](#initial-tests). If the " +"`QUERY_PROBE` commands in that test always produce the expected results and " +"\"BLTouch failed to verify sensor state\" errors still occur, then it may be" +" necessary to set `pin_up_touch_mode_reports_triggered` to False in the " +"Klipper config file." +msgstr "" + +msgid "" +"A rare number of old \"clone\" devices are unable to report when they have " +"successfully raised their probe. On these devices Klipper will report a " +"\"BLTouch failed to raise probe\" error after every home or probe attempt. " +"One can test for these devices - move the head far from the bed, run " +"`BLTOUCH_DEBUG COMMAND=pin_down`, verify the pin has moved down, run " +"`QUERY_PROBE`, verify that command reports \"probe: open\", run " +"`BLTOUCH_DEBUG COMMAND=pin_up`, verify the pin has moved up, and run " +"`QUERY_PROBE`. If the pin remains up, the device does not enter an error " +"state, and the first query reports \"probe: open\" while the second query " +"reports \"probe: TRIGGERED\" then it indicates that " +"`pin_up_reports_not_triggered` should be set to False in the Klipper config " +"file." +msgstr "" + +msgid "BL-Touch v3" +msgstr "" + +msgid "" +"Some BL-Touch v3.0 and BL-Touch 3.1 devices may require configuring " +"`probe_with_touch_mode` in the printer config file." +msgstr "" + +msgid "" +"If the BL-Touch v3.0 has its signal wire connected to an endstop pin (with a" +" noise filtering capacitor), then the BL-Touch v3.0 may not be able to " +"consistently send a signal during homing and probing. If the `QUERY_PROBE` " +"commands in the [initial tests section](#initial-tests) always produce the " +"expected results, but the toolhead does not always stop during G28/PROBE " +"commands, then it is indicative of this issue. A workaround is to set " +"`probe_with_touch_mode: True` in the config file." +msgstr "" + +msgid "" +"The BL-Touch v3.1 may incorrectly enter an error state after a successful " +"probe attempt. The symptoms are an occasional flashing light on the BL-Touch" +" v3.1 that lasts for a couple of seconds after it successfully contacts the " +"bed. Klipper should clear this error automatically and it is generally " +"harmless. However, one may set `probe_with_touch_mode` in the config file to" +" avoid this issue." +msgstr "" + +msgid "" +"Important! Some \"clone\" devices and the BL-Touch v2.0 (and earlier) may " +"have reduced accuracy when `probe_with_touch_mode` is set to True. Setting " +"this to True also increases the time it takes to deploy the probe. If " +"configuring this value on a \"clone\" or older BL-Touch device, be sure to " +"test the probe accuracy before and after setting this value (use the " +"`PROBE_ACCURACY` command to test)." +msgstr "" + +msgid "Multi-probing without stowing" +msgstr "" + +msgid "" +"By default, Klipper will deploy the probe at the start of each probe attempt" +" and then stow the probe afterwards. This repetitive deploying and stowing " +"of the probe may increase the total time of calibration sequences that " +"involve many probe measurements. Klipper supports leaving the probe deployed" +" between consecutive probes, which can reduce the total time of probing. " +"This mode is enabled by configuring `stow_on_each_sample` to False in the " +"config file." +msgstr "" + +msgid "" +"Important! Setting `stow_on_each_sample` to False can lead to Klipper making" +" horizontal toolhead movements while the probe is deployed. Be sure to " +"verify all probing operations have sufficient Z clearance prior to setting " +"this value to False. If there is insufficient clearance then a horizontal " +"move may cause the pin to catch on an obstruction and result in damage to " +"the printer." +msgstr "" + +msgid "" +"Important! It is recommended to use `probe_with_touch_mode` configured to " +"True when using `stow_on_each_sample` configured to False. Some \"clone\" " +"devices may not detect a subsequent bed contact if `probe_with_touch_mode` " +"is not set. On all devices, using the combination of these two settings " +"simplifies the device signaling, which can improve overall stability." +msgstr "" + +msgid "" +"Note, however, that some \"clone\" devices and the BL-Touch v2.0 (and " +"earlier) may have reduced accuracy when `probe_with_touch_mode` is set to " +"True. On these devices it is a good idea to test the probe accuracy before " +"and after setting `probe_with_touch_mode` (use the `PROBE_ACCURACY` command " +"to test)." +msgstr "" + +msgid "Calibrating the BL-Touch offsets" +msgstr "" + +msgid "" +"Follow the directions in the [Probe Calibrate](Probe_Calibrate.md) guide to " +"set the x_offset, y_offset, and z_offset config parameters." +msgstr "" + +msgid "" +"It's a good idea to verify that the Z offset is close to 1mm. If not, then " +"you probably want to move the probe up or down to fix this. You want it to " +"trigger well before the nozzle hits the bed, so that possible stuck filament" +" or a warped bed doesn't affect any probing action. But at the same time, " +"you want the retracted position to be as far above the nozzle as possible to" +" avoid it touching printed parts. If an adjustment is made to the probe " +"position, then rerun the probe calibration steps." +msgstr "" + +msgid "BL-Touch output mode" +msgstr "" + +msgid "" +"A BL-Touch V3.0 supports setting a 5V or OPEN-DRAIN output mode, a BL-Touch " +"V3.1 supports this too, but can also store this in its internal EEPROM. If " +"your controller board needs the fixed 5V high logic level of the 5V mode you" +" may set the 'set_output_mode' parameter in the [bltouch] section of the " +"printer config file to \"5V\"." +msgstr "" + +msgid "" +"*** Only use the 5V mode if your controller boards input line is 5V " +"tolerant. This is why the default configuration of these BL-Touch versions " +"is OPEN-DRAIN mode. You could potentially damage your controller boards CPU " +"***" +msgstr "" + +msgid "" +"So therefore: If a controller board NEEDs 5V mode AND it is 5V tolerant on " +"its input signal line AND if" +msgstr "" + +msgid "" +"you have a BL-Touch Smart V3.0, you need the use 'set_output_mode: 5V' " +"parameter to ensure this setting at each startup, since the probe cannot " +"remember the needed setting." +msgstr "" + +msgid "" +"you have a BL-Touch Smart V3.1, you have the choice of using " +"'set_output_mode: 5V' or storing the mode once by use of a 'BLTOUCH_STORE " +"MODE=5V' command manually and NOT using the parameter 'set_output_mode:'." +msgstr "" + +msgid "" +"you have some other probe: Some probes have a trace on the circuit board to " +"cut or a jumper to set in order to (permanently) set the output mode. In " +"that case, omit the 'set_output_mode' parameter completely." +msgstr "" + +msgid "" +"If you have a V3.1, do not automate or repeat storing the output mode to " +"avoid wearing out the EEPROM of the probe.The BLTouch EEPROM is good for " +"about 100.000 updates. 100 stores per day would add up to about 3 years of " +"operation prior to wearing it out. Thus, storing the output mode in a V3.1 " +"is designed by the vendor to be a complicated operation (the factory default" +" being a safe OPEN DRAIN mode) and is not suited to be repeatedly issued by " +"any slicer, macro or anything else, it is preferably only to be used when " +"first integrating the probe into a printers electronics." +msgstr "" + +msgid "" +"[bltouch]\n" +"sensor_pin: ^P1.24\n" +"control_pin: P1.26\n" +msgstr "" + +#: docs/BLTouch.md:block 1 (header) +msgid "BL-Touch" +msgstr "" + +#: docs/BLTouch.md:block 6 (paragraph) +msgid "" +"If the BL-Touch will be used to home the Z axis then set `endstop_pin: " +"probe:z_virtual_endstop` and remove `position_endstop` in the `[stepper_z]` " +"config section, then add a `[safe_z_home]` config section to raise the z " +"axis, home the xy axes, move to the center of the bed, and home the z axis. " +"For example:" +msgstr "" + +#: docs/BLTouch.md:block 7 (code) +msgid "" +"[safe_z_home]\n" +"home_xy_position: 100, 100 # Change coordinates to the center of your print bed\n" +"speed: 50\n" +"z_hop: 10 # Move up 10mm\n" +"z_hop_speed: 5\n" +msgstr "" + +#: docs/BLTouch.md:block 13 (paragraph) +msgid "" +"The next step is to confirm that the sensor pin is working correctly. Run " +"`BLTOUCH_DEBUG COMMAND=pin_down`, verify that the pin moves down, run " +"`BLTOUCH_DEBUG COMMAND=touch_mode`, run `QUERY_PROBE`, and verify that " +"command reports \"probe: open\". Then while gently pushing the pin up " +"slightly with the nail of your finger run `QUERY_PROBE` again. Verify the " +"command reports \"probe: TRIGGERED\". If either query does not report the " +"correct message then it usually indicates an incorrect wiring or " +"configuration (though some [clones](#bl-touch-clones) may require special " +"handling). At the completion of this test run `BLTOUCH_DEBUG COMMAND=pin_up`" +" and verify that the pin moves up." +msgstr "" + +#: docs/BLTouch.md:block 22 (paragraph) +msgid "" +"Many BL-Touch \"clone\" devices work correctly with Klipper using the " +"default configuration. However, some \"clone\" devices may not support the " +"`QUERY_PROBE` command and some \"clone\" devices may require configuration " +"of `pin_up_reports_not_triggered` or `pin_up_touch_mode_reports_triggered`." +msgstr "" + +#: docs/BLTouch.md:block 24 (paragraph) +msgid "" +"Some \"clone\" devices do not support `touch_mode` and as a result the " +"`QUERY_PROBE` command does not work. Despite this, it may still be possible " +"to perform probing and homing with these devices. On these devices the " +"`QUERY_PROBE` command during the [initial tests](#initial-tests) will not " +"succeed, however the subsequent `G28` (or `PROBE`) test does succeed. It may" +" be possible to use these \"clone\" devices with Klipper if one does not " +"utilize the `QUERY_PROBE` command and one does not enable the " +"`probe_with_touch_mode` feature." +msgstr "" + +#~ msgid "" +#~ "The next step is to confirm that the sensor pin is working correctly. Run " +#~ "`BLTOUCH_DEBUG COMMAND=pin_down`, verify that the pin moves down, run " +#~ "`BLTOUCH_DEBUG COMMAND=touch_mode`, run `QUERY_PROBE`, and verify that " +#~ "command reports \"probe: open\". Then while gently pushing the pin up " +#~ "slightly with the nail of your finger run `QUERY_PROBE` again. Verify the " +#~ "command reports \"probe: TRIGGERED\". If either query does not report the " +#~ "correct message then check your wiring and configuration again. At the " +#~ "completion of this test run `BLTOUCH_DEBUG COMMAND=pin_up` and verify that " +#~ "the pin moves up." +#~ msgstr "" + +#~ msgid "" +#~ "Many BL-Touch \"clone\" devices work correctly with Klipper using the " +#~ "default configuration. However, some \"clone\" devices may require " +#~ "configuration of `pin_up_reports_not_triggered` or " +#~ "`pin_up_touch_mode_reports_triggered`." +#~ msgstr "" + +#~ msgid "" +#~ "[safe_z_home]\n" +#~ "home_xy_position: 100,100 # Change coordinates to the center of your print bed\n" +#~ "speed: 50\n" +#~ "z_hop: 10 # Move up 10mm\n" +#~ "z_hop_speed: 5\n" +#~ msgstr "" + +#~ msgid "" +#~ "If the BL-Touch will be used to home the Z axis then set `endstop_pin: " +#~ "probe:z_virtual_endstop` in the `[stepper_z]` config section and add a " +#~ "`[safe_z_home]` config section to raise the z axis, home the xy axes, move " +#~ "to the center of the bed, and home the z axis. For example:" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Beaglebone.po b/docs/locales/lt/LC_MESSAGES/Beaglebone.po new file mode 100644 index 0000000000..c9952eabfd --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Beaglebone.po @@ -0,0 +1,160 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: docs/Beaglebone.md:block 1 (header) +msgid "Beaglebone" +msgstr "" + +#: docs/Beaglebone.md:block 2 (paragraph) +msgid "" +"This document describes the process of running Klipper on a Beaglebone PRU." +msgstr "" + +#: docs/Beaglebone.md:block 3 (header) +msgid "Building an OS image" +msgstr "" + +#: docs/Beaglebone.md:block 4 (paragraph) +msgid "" +"Start by installing the [Debian 9.9 2019-08-03 4GB SD " +"IoT](https://beagleboard.org/latest-images) image. One may run the image " +"from either a micro-SD card or from builtin eMMC. If using the eMMC, install" +" it to eMMC now by following the instructions from the above link." +msgstr "" + +#: docs/Beaglebone.md:block 5 (paragraph) +msgid "" +"Then ssh into the Beaglebone machine (`ssh debian@beaglebone` -- password is" +" `temppwd`) and install Klipper by running the following commands:" +msgstr "" + +#: docs/Beaglebone.md:block 6 (code) +msgid "" +"git clone https://github.com/Klipper3d/klipper\n" +"./klipper/scripts/install-beaglebone.sh\n" +msgstr "" + +#: docs/Beaglebone.md:block 7 (header) +msgid "Install Octoprint" +msgstr "" + +#: docs/Beaglebone.md:block 8 (paragraph) +msgid "One may then install Octoprint:" +msgstr "" + +#: docs/Beaglebone.md:block 9 (code) +msgid "" +"git clone https://github.com/foosel/OctoPrint.git\n" +"cd OctoPrint/\n" +"virtualenv venv\n" +"./venv/bin/python setup.py install\n" +msgstr "" + +#: docs/Beaglebone.md:block 10 (paragraph) +msgid "And setup OctoPrint to start at bootup:" +msgstr "" + +#: docs/Beaglebone.md:block 11 (code) +msgid "" +"sudo cp ~/OctoPrint/scripts/octoprint.init /etc/init.d/octoprint\n" +"sudo chmod +x /etc/init.d/octoprint\n" +"sudo cp ~/OctoPrint/scripts/octoprint.default /etc/default/octoprint\n" +"sudo update-rc.d octoprint defaults\n" +msgstr "" + +#: docs/Beaglebone.md:block 12 (paragraph) +msgid "" +"It is necessary to modify OctoPrint's **/etc/default/octoprint** " +"configuration file. One must change the `OCTOPRINT_USER` user to `debian`, " +"change `NICELEVEL` to `0`, uncomment the `BASEDIR`, `CONFIGFILE`, and " +"`DAEMON` settings and change the references from `/home/pi/` to " +"`/home/debian/`:" +msgstr "" + +#: docs/Beaglebone.md:block 13 (code) +msgid "sudo nano /etc/default/octoprint\n" +msgstr "" + +#: docs/Beaglebone.md:block 14 (paragraph) +msgid "Then start the Octoprint service:" +msgstr "" + +#: docs/Beaglebone.md:block 15 (code) +msgid "sudo systemctl start octoprint\n" +msgstr "" + +#: docs/Beaglebone.md:block 16 (paragraph) +msgid "" +"Make sure the OctoPrint web server is accessible - it should be at: " +"" +msgstr "" + +#: docs/Beaglebone.md:block 17 (header) +msgid "Building the micro-controller code" +msgstr "" + +#: docs/Beaglebone.md:block 18 (paragraph) +msgid "" +"To compile the Klipper micro-controller code, start by configuring it for " +"the \"Beaglebone PRU\":" +msgstr "" + +#: docs/Beaglebone.md:block 19 (code) +msgid "" +"cd ~/klipper/\n" +"make menuconfig\n" +msgstr "" + +#: docs/Beaglebone.md:block 20 (paragraph) +msgid "To build and install the new micro-controller code, run:" +msgstr "" + +#: docs/Beaglebone.md:block 21 (code) +msgid "" +"sudo service klipper stop\n" +"make flash\n" +"sudo service klipper start\n" +msgstr "" + +#: docs/Beaglebone.md:block 22 (paragraph) +msgid "" +"It is also necessary to compile and install the micro-controller code for a " +"Linux host process. Configure it a second time for a \"Linux process\":" +msgstr "" + +#: docs/Beaglebone.md:block 23 (code) +msgid "make menuconfig\n" +msgstr "" + +#: docs/Beaglebone.md:block 24 (paragraph) +msgid "Then install this micro-controller code as well:" +msgstr "" + +#: docs/Beaglebone.md:block 26 (header) +msgid "Remaining configuration" +msgstr "" + +#: docs/Beaglebone.md:block 27 (paragraph) +msgid "" +"Complete the installation by configuring Klipper and Octoprint following the" +" instructions in the main [Installation](Installation.md#configuring-" +"klipper) document." +msgstr "" + +#: docs/Beaglebone.md:block 28 (header) +msgid "Printing on the Beaglebone" +msgstr "" + +#: docs/Beaglebone.md:block 29 (paragraph) +msgid "" +"Unfortunately, the Beaglebone processor can sometimes struggle to run " +"OctoPrint well. Print stalls have been known to occur on complex prints (the" +" printer may move faster than OctoPrint can send movement commands). If this" +" occurs, consider using the \"virtual_sdcard\" feature (see [Config " +"Reference](Config_Reference.md#virtual_sdcard) for details) to print " +"directly from Klipper." +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Bed_Level.po b/docs/locales/lt/LC_MESSAGES/Bed_Level.po new file mode 100644 index 0000000000..2adf890633 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Bed_Level.po @@ -0,0 +1,324 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"Bed leveling (sometimes also referred to as \"bed tramming\") is critical to" +" getting high quality prints. If a bed is not properly \"leveled\" it can " +"lead to poor bed adhesion, \"warping\", and subtle problems throughout the " +"print. This document serves as a guide to performing bed leveling in " +"Klipper." +msgstr "" + +msgid "" +"It's important to understand the goal of bed leveling. If the printer is " +"commanded to a position `X0 Y0 Z10` during a print, then the goal is for the" +" printer's nozzle to be exactly 10mm from the printer's bed. Further, should" +" the printer then be commanded to a position of `X50 Z10` the goal is for " +"the nozzle to maintain an exact distance of 10mm from the bed during that " +"entire horizontal move." +msgstr "" + +msgid "" +"In order to get good quality prints the printer should be calibrated so that" +" Z distances are accurate to within about 25 microns (.025mm). This is a " +"small distance - significantly smaller than the width of a typical human " +"hair. This scale can not be measured \"by eye\". Subtle effects (such as " +"heat expansion) impact measurements at this scale. The secret to getting " +"high accuracy is to use a repeatable process and to use a leveling method " +"that leverages the high accuracy of the printer's own motion system." +msgstr "" + +msgid "Choose the appropriate calibration mechanism" +msgstr "" + +msgid "" +"Different types of printers use different methods for performing bed " +"leveling. All of them ultimately depend on the \"paper test\" (described " +"below). However, the actual process for a particular type of printer is " +"described in other documents." +msgstr "" + +msgid "" +"Prior to running any of these calibration tools, be sure to run the checks " +"described in the [config check document](Config_checks.md). It is necessary " +"to verify basic printer motion before performing bed leveling." +msgstr "" + +msgid "" +"For printers with an \"automatic Z probe\" be sure to calibrate the probe " +"following the directions in the [Probe Calibrate](Probe_Calibrate.md) " +"document. For delta printers, see the [Delta Calibrate](Delta_Calibrate.md) " +"document. For printers with bed screws and traditional Z endstops, see the " +"[Manual Level](Manual_Level.md) document." +msgstr "" + +msgid "" +"During calibration it may be necessary to set the printer's Z `position_min`" +" to a negative number (eg, `position_min = -2`). The printer enforces " +"boundary checks even during calibration routines. Setting a negative number " +"allows the printer to move below the nominal position of the bed, which may " +"help when trying to determine the actual bed position." +msgstr "" + +msgid "The \"paper test\"" +msgstr "" + +msgid "" +"The primary bed calibration mechanism is the \"paper test\". It involves " +"placing a regular piece of \"copy machine paper\" between the printer's bed " +"and nozzle, and then commanding the nozzle to different Z heights until one " +"feels a small amount of friction when pushing the paper back and forth." +msgstr "" + +msgid "" +"It is important to understand the \"paper test\" even if one has an " +"\"automatic Z probe\". The probe itself often needs to be calibrated to get " +"good results. That probe calibration is done using this \"paper test\"." +msgstr "" + +msgid "" +"The first step of the paper test is to inspect the printer's nozzle and bed." +" Make sure there is no plastic (or other debris) on the nozzle or bed." +msgstr "" + +msgid "**Inspect the nozzle and bed to ensure no plastic is present!**" +msgstr "" + +msgid "" +"If there is plastic on the nozzle then heat up the extruder and use a metal " +"tweezers to remove that plastic. Wait for the extruder to fully cool to room" +" temperature before continuing with the paper test. While the nozzle is " +"cooling, use the metal tweezers to remove any plastic that may ooze out." +msgstr "" + +msgid "" +"**Always perform the paper test when both nozzle and bed are at room " +"temperature!**" +msgstr "" + +msgid "" +"It may seem odd to calibrate the distance at room temperature when the goal " +"is to have a consistent distance when heated. However, if one calibrates " +"when the nozzle is heated, it tends to impart small amounts of molten " +"plastic on to the paper, which changes the amount of friction felt. That " +"makes it harder to get a good calibration. Calibrating while the bed/nozzle " +"is hot also greatly increases the risk of burning oneself. The amount of " +"thermal expansion is stable, so it is easily accounted for later in the " +"calibration process." +msgstr "" + +msgid "**Use an automated tool to determine precise Z heights!**" +msgstr "" + +msgid "" +"Klipper has several helper scripts available (eg, MANUAL_PROBE, " +"Z_ENDSTOP_CALIBRATE, PROBE_CALIBRATE, DELTA_CALIBRATE). See the documents " +"[described above](#choose-the-appropriate-calibration-mechanism) to choose " +"one of them." +msgstr "" + +msgid "" +"Run the appropriate command in the OctoPrint terminal window. The script " +"will prompt for user interaction in the OctoPrint terminal output. It will " +"look something like:" +msgstr "" + +msgid "" +"The current height of the nozzle (as the printer currently understands it) " +"is shown between the \"--> <--\". The number to the right is the height of " +"the last probe attempt just greater than the current height, and to the left" +" is the last probe attempt less than the current height (or ?????? if no " +"attempt has been made)." +msgstr "" + +msgid "" +"Place the paper between the nozzle and bed. It can be useful to fold a " +"corner of the paper so that it is easier to grab. (Try not to push down on " +"the bed when moving the paper back and forth.)" +msgstr "" + +msgid "![paper-test](img/paper-test.jpg)" +msgstr "" + +msgid "" +"Use the TESTZ command to request the nozzle to move closer to the paper. For" +" example:" +msgstr "" + +msgid "" +"The TESTZ command will move the nozzle a relative distance from the nozzle's" +" current position. (So, `Z=-.1` requests the nozzle to move closer to the " +"bed by .1mm.) After the nozzle stops moving, push the paper back and forth " +"to check if the nozzle is in contact with the paper and to feel the amount " +"of friction. Continue issuing TESTZ commands until one feels a small amount " +"of friction when testing with the paper." +msgstr "" + +msgid "" +"If too much friction is found then one can use a positive Z value to move " +"the nozzle up. It is also possible to use `TESTZ Z=+` or `TESTZ Z=-` to " +"\"bisect\" the last position - that is to move to a position half way " +"between two positions. For example, if one received the following prompt " +"from a TESTZ command:" +msgstr "" + +msgid "" +"Then a `TESTZ Z=-` would move the nozzle to a Z position of 0.180 (half way " +"between 0.130 and 0.230). One can use this feature to help rapidly narrow " +"down to a consistent friction. It is also possible to use `Z=++` and `Z=--` " +"to return directly to a past measurement - for example, after the above " +"prompt a `TESTZ Z=--` command would move the nozzle to a Z position of " +"0.130." +msgstr "" + +msgid "After finding a small amount of friction run the ACCEPT command:" +msgstr "" + +msgid "" +"This will accept the given Z height and proceed with the given calibration " +"tool." +msgstr "" + +msgid "" +"The exact amount of friction felt isn't crucial, just as the amount of " +"thermal expansion and exact width of the paper isn't crucial. Just try to " +"obtain the same amount of friction each time one runs the test." +msgstr "" + +msgid "" +"If something goes wrong during the test, one can use the `ABORT` command to " +"exit the calibration tool." +msgstr "" + +msgid "Determining Thermal Expansion" +msgstr "" + +msgid "" +"This type of calculation is generally not needed as most users find the " +"simple \"paper test\" provides good results." +msgstr "" + +msgid "" +"The easiest way to make this calculation is to print a test object that has " +"straight walls on all sides. The large hollow square found in " +"[docs/prints/square.stl](prints/square.stl) can be used for this. When " +"slicing the object, make sure the slicer uses the same layer height and " +"extrusion widths for the first level that it does for all subsequent layers." +" Use a coarse layer height (the layer height should be around 75% of the " +"nozzle diameter) and do not use a brim or raft." +msgstr "" + +msgid "" +"Print the test object, wait for it to cool, and remove it from the bed. " +"Inspect the lowest layer of the object. (It may also be useful to run a " +"finger or nail along the bottom edge.) If one finds the bottom layer bulges " +"out slightly along all sides of the object then it indicates the nozzle was " +"slightly closer to the bed then it should be. One can issue a " +"`SET_GCODE_OFFSET Z=+.010` command to increase the height. In subsequent " +"prints one can inspect for this behavior and make further adjustment as " +"needed. Adjustments of this type are typically in 10s of microns (.010mm)." +msgstr "" + +msgid "" +"If the bottom layer consistently appears narrower than subsequent layers " +"then one can use the SET_GCODE_OFFSET command to make a negative Z " +"adjustment. If one is unsure, then one can decrease the Z adjustment until " +"the bottom layer of prints exhibit a small bulge, and then back-off until it" +" disappears." +msgstr "" + +msgid "" +"The easiest way to apply the desired Z adjustment is to create a START_PRINT" +" g-code macro, arrange for the slicer to call that macro during the start of" +" each print, and add a SET_GCODE_OFFSET command to that macro. See the " +"[slicers](Slicers.md) document for further details." +msgstr "" + +msgid "" +"Recv: // Starting manual Z probe. Use TESTZ to adjust position.\n" +"Recv: // Finish with ACCEPT or ABORT command.\n" +"Recv: // Z position: ?????? --> 5.000 <-- ??????\n" +msgstr "" + +msgid "TESTZ Z=-.1\n" +msgstr "" + +msgid "Recv: // Z position: 0.130 --> 0.230 <-- 0.280\n" +msgstr "" + +msgid "ACCEPT\n" +msgstr "" + +#: docs/Bed_Level.md:block 1 (header) +msgid "Bed leveling" +msgstr "" + +#: docs/Bed_Level.md:block 13 (paragraph) +msgid "" +"In order to perform the paper test, cut a small rectangular piece of paper " +"using a pair of scissors (eg, 5x3 cm). The paper generally has a thickness " +"of around 100 microns (0.100mm). (The exact thickness of the paper isn't " +"crucial.)" +msgstr "" + +#: docs/Bed_Level.md:block 16 (paragraph) +msgid "" +"If one always prints on a particular tape or printing surface then one may " +"perform the paper test with that tape/surface in place. However, note that " +"tape itself has a thickness and different tapes (or any other printing " +"surface) will impact Z measurements. Be sure to rerun the paper test to " +"measure each type of surface that is in use." +msgstr "" + +#: docs/Bed_Level.md:block 19 (paragraph) +msgid "" +"When the nozzle is heated, its position (relative to the bed) changes due to" +" thermal expansion. This thermal expansion is typically around a 100 " +"microns, which is about the same thickness as a typical piece of printer " +"paper. The exact amount of thermal expansion isn't crucial, just as the " +"exact thickness of the paper isn't crucial. Start with the assumption that " +"the two are equal (see below for a method of determining the difference " +"between the two distances)." +msgstr "" + +#: docs/Bed_Level.md:block 40 (paragraph) +msgid "" +"After successfully performing bed leveling, one may go on to calculate a " +"more precise value for the combined impact of \"thermal expansion\", " +"\"thickness of the paper\", and \"amount of friction felt during the paper " +"test\"." +msgstr "" + +#~ msgid "" +#~ "In order to perform the paper test, cut a small rectangular piece of paper " +#~ "using a pair of scissors (eg, 5x3 cm). The paper generally has a width of " +#~ "around 100 microns (0.100mm). (The exact width of the paper isn't crucial.)" +#~ msgstr "" + +#~ msgid "" +#~ "If one always prints on a particular tape or printing surface then one may " +#~ "perform the paper test with that tape/surface in place. However, note that " +#~ "tape itself has a width and different tapes (or any other printing surface) " +#~ "will impact Z measurements. Be sure to rerun the paper test to measure each " +#~ "type of surface that is in use." +#~ msgstr "" + +#~ msgid "" +#~ "When the nozzle is heated, its position (relative to the bed) changes due to" +#~ " thermal expansion. This thermal expansion is typically around a 100 " +#~ "microns, which is about the same width as a typical piece of printer paper. " +#~ "The exact amount of thermal expansion isn't crucial, just as the exact width" +#~ " of the paper isn't crucial. Start with the assumption that the two are " +#~ "equal (see below for a method of determining the difference between the two " +#~ "widths)." +#~ msgstr "" + +#~ msgid "" +#~ "After successfully performing bed leveling, one may go on to calculate a " +#~ "more precise value for the combined impact of \"thermal expansion\", \"width" +#~ " of the paper\", and \"amount of friction felt during the paper test\"." +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Benchmarks.po b/docs/locales/lt/LC_MESSAGES/Benchmarks.po new file mode 100644 index 0000000000..ba300056b2 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Benchmarks.po @@ -0,0 +1,1255 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "This document describes Klipper benchmarks." +msgstr "" + +msgid "Micro-controller Benchmarks" +msgstr "" + +msgid "" +"This section describes the mechanism used to generate the Klipper micro-" +"controller step rate benchmarks." +msgstr "" + +msgid "" +"The primary goal of the benchmarks is to provide a consistent mechanism for " +"measuring the impact of coding changes within the software. A secondary goal" +" is to provide high-level metrics for comparing the performance between " +"chips and between software platforms." +msgstr "" + +msgid "" +"The step rate benchmark is designed to find the maximum stepping rate that " +"the hardware and software can reach. This benchmark stepping rate is not " +"achievable in day-to-day use as Klipper needs to perform other tasks (eg, " +"mcu/host communication, temperature reading, endstop checking) in any real-" +"world usage." +msgstr "" + +msgid "" +"In general, the pins for the benchmark tests are chosen to flash LEDs or " +"other innocuous pins. **Always verify that it is safe to drive the " +"configured pins prior to running a benchmark.** It is not recommended to " +"drive an actual stepper during a benchmark." +msgstr "" + +msgid "Step rate benchmark test" +msgstr "" + +msgid "" +"The above tests three steppers simultaneously stepping. If running the above" +" results in a \"Rescheduled timer in the past\" or \"Stepper too far in " +"past\" error then it indicates the `ticks` parameter is too low (it results " +"in a stepping rate that is too fast). The goal is to find the lowest setting" +" of the ticks parameter that reliably results in a successful completion of " +"the test. It should be possible to bisect the ticks parameter until a stable" +" value is found." +msgstr "" + +msgid "" +"On a failure, one can copy-and-paste the following to clear the error in " +"preparation for the next test:" +msgstr "" + +msgid "AVR step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on AVR chips:" +msgstr "" + +msgid "avr" +msgstr "" + +msgid "ticks" +msgstr "" + +msgid "1 stepper" +msgstr "" + +msgid "3 stepper" +msgstr "" + +msgid "Arduino Due step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the Due:" +msgstr "" + +msgid "sam3x8e" +msgstr "" + +msgid "Duet Maestro step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the Duet Maestro:" +msgstr "" + +msgid "sam4s8c" +msgstr "" + +msgid "70" +msgstr "" + +msgid "Duet Wifi step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the Duet Wifi:" +msgstr "" + +msgid "sam4e8e" +msgstr "" + +msgid "Beaglebone PRU step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the PRU:" +msgstr "" + +msgid "pru" +msgstr "" + +msgid "STM32F042 step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the STM32F042:" +msgstr "" + +msgid "stm32f042" +msgstr "" + +msgid "STM32F103 step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the STM32F103:" +msgstr "" + +msgid "stm32f103" +msgstr "" + +msgid "71" +msgstr "" + +msgid "STM32F4 step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the STM32F4:" +msgstr "" + +msgid "stm32f446" +msgstr "" + +msgid "51" +msgstr "" + +msgid "stm32f407" +msgstr "" + +msgid "52" +msgstr "" + +msgid "LPC176x step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the LPC176x:" +msgstr "" + +msgid "lpc1768" +msgstr "" + +msgid "lpc1769" +msgstr "" + +msgid "SAMD21 step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the SAMD21:" +msgstr "" + +msgid "samd21" +msgstr "" + +msgid "SAMD51 step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the SAMD51:" +msgstr "" + +msgid "samd51" +msgstr "" + +msgid "1 stepper (200Mhz)" +msgstr "" + +msgid "3 stepper (200Mhz)" +msgstr "" + +msgid "Linux MCU step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on a Raspberry Pi:" +msgstr "" + +msgid "Linux (RPi3)" +msgstr "" + +msgid "Command dispatch benchmark" +msgstr "" + +msgid "" +"When the test completes, determine the difference between the clocks " +"reported in the two \"uptime\" response messages. The total number of " +"commands per second is then `100000 * mcu_frequency / clock_diff`." +msgstr "" + +msgid "" +"Note that this test may saturate the USB/CPU capacity of a Raspberry Pi. If " +"running on a Raspberry Pi, Beaglebone, or similar host computer then " +"increase the delay (eg, `DELAY {clock + 20*freq} get_uptime`). Where " +"applicable, the benchmarks below are with console.py running on a desktop " +"class machine with the device connected via a high-speed hub." +msgstr "" + +msgid "MCU" +msgstr "" + +msgid "Rate" +msgstr "" + +msgid "Build" +msgstr "" + +msgid "Build compiler" +msgstr "" + +msgid "stm32f042 (CAN)" +msgstr "" + +msgid "18K" +msgstr "" + +msgid "c105adc8" +msgstr "" + +msgid "arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1" +msgstr "" + +msgid "atmega2560 (serial)" +msgstr "" + +msgid "23K" +msgstr "" + +msgid "b161a69e" +msgstr "" + +msgid "avr-gcc (GCC) 4.8.1" +msgstr "" + +msgid "sam3x8e (serial)" +msgstr "" + +msgid "arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0" +msgstr "" + +msgid "at90usb1286 (USB)" +msgstr "" + +msgid "75K" +msgstr "" + +msgid "01d2183f" +msgstr "" + +msgid "avr-gcc (GCC) 5.4.0" +msgstr "" + +msgid "samd21 (USB)" +msgstr "" + +msgid "223K" +msgstr "" + +msgid "arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0" +msgstr "" + +msgid "pru (shared memory)" +msgstr "" + +msgid "260K" +msgstr "" + +msgid "c5968a08" +msgstr "" + +msgid "pru-gcc (GCC) 8.0.0 20170530 (experimental)" +msgstr "" + +msgid "stm32f103 (USB)" +msgstr "" + +msgid "355K" +msgstr "" + +msgid "sam3x8e (USB)" +msgstr "" + +msgid "418K" +msgstr "" + +msgid "lpc1768 (USB)" +msgstr "" + +msgid "534K" +msgstr "" + +msgid "lpc1769 (USB)" +msgstr "" + +msgid "628K" +msgstr "" + +msgid "sam4s8c (USB)" +msgstr "" + +msgid "650K" +msgstr "" + +msgid "8d4a5c16" +msgstr "" + +msgid "samd51 (USB)" +msgstr "" + +msgid "864K" +msgstr "" + +msgid "stm32f446 (USB)" +msgstr "" + +msgid "870K" +msgstr "" + +msgid "Host Benchmarks" +msgstr "" + +msgid "" +"SET start_clock {clock+freq}\n" +"SET ticks 1000\n" +"\n" +"reset_step_clock oid=0 clock={start_clock}\n" +"set_next_step_dir oid=0 dir=0\n" +"queue_step oid=0 interval={ticks} count=60000 add=0\n" +"set_next_step_dir oid=0 dir=1\n" +"queue_step oid=0 interval=3000 count=1 add=0\n" +"\n" +"reset_step_clock oid=1 clock={start_clock}\n" +"set_next_step_dir oid=1 dir=0\n" +"queue_step oid=1 interval={ticks} count=60000 add=0\n" +"set_next_step_dir oid=1 dir=1\n" +"queue_step oid=1 interval=3000 count=1 add=0\n" +"\n" +"reset_step_clock oid=2 clock={start_clock}\n" +"set_next_step_dir oid=2 dir=0\n" +"queue_step oid=2 interval={ticks} count=60000 add=0\n" +"set_next_step_dir oid=2 dir=1\n" +"queue_step oid=2 interval=3000 count=1 add=0\n" +msgstr "" + +msgid "clear_shutdown\n" +msgstr "" + +msgid "ECHO Test result is: {\"%.0fK\" % (3. * freq / ticks / 1000.)}\n" +msgstr "" + +msgid "" +"DELAY {clock + 2*freq} get_uptime\n" +"FLOOD 100000 0.0 debug_nop\n" +"get_uptime\n" +msgstr "" + +msgid "" +"time ~/klippy-env/bin/python ./klippy/klippy.py config/example-cartesian.cfg" +" -i something_complex.gcode -o /dev/null -d out/klipper.dict\n" +msgstr "" + +msgid "RP2040 step rate benchmark" +msgstr "" + +msgid "The following configuration sequence is used on the RP2040:" +msgstr "" + +msgid "rp2040" +msgstr "" + +msgid "66" +msgstr "" + +msgid "5" +msgstr "" + +msgid "22" +msgstr "" + +msgid "rp2040 (USB)" +msgstr "" + +msgid "873K" +msgstr "" + +msgid "c5667193" +msgstr "" + +msgid "arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0" +msgstr "" + +#: docs/Benchmarks.md:block 1 (header) +msgid "Benchmarks" +msgstr "" + +#: docs/Benchmarks.md:block 9 (paragraph) +msgid "" +"The test is performed using the console.py tool (described in " +"). The micro-controller is configured for the particular " +"hardware platform (see below) and then the following is cut-and-paste into " +"the console.py terminal window:" +msgstr "" + +#: docs/Benchmarks.md:block 86 (paragraph) +msgid "" +"The command dispatch benchmark tests how many \"dummy\" commands the micro-" +"controller can process. It is primarily a test of the hardware communication" +" mechanism. The test is run using the console.py tool (described in " +"). The following is cut-and-paste into the console.py terminal" +" window:" +msgstr "" + +#: docs/Benchmarks.md:block 92 (paragraph) +msgid "" +"It is possible to run timing tests on the host software using the \"batch " +"mode\" processing mechanism (described in ). This is typically" +" done by choosing a large and complex G-Code file and timing how long it " +"takes for the host software to process it. For example:" +msgstr "" + +#: docs/Benchmarks.md:block 14 (paragraph) +msgid "" +"To obtain the single stepper benchmarks, the same configuration sequence is " +"used, but only the first block of the above test is cut-and-paste into the " +"console.py window." +msgstr "" + +#: docs/Benchmarks.md:block 17 (paragraph) +msgid "" +"The benchmarks are run with parameters suitable for TMC Drivers. For micro-" +"controllers that support `STEPPER_BOTH_EDGE=1` (as reported in the `MCU " +"config` line when console.py first starts) use `step_pulse_duration=0` and " +"`invert_step=-1` to enable optimized stepping on both edges of the step " +"pulse. For other micro-controllers use a `step_pulse_duration` corresponding" +" to 100ns." +msgstr "" + +#: docs/Benchmarks.md:block 20 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PA5 dir_pin=PA4 invert_step=0 step_pulse_ticks=32\n" +"config_stepper oid=1 step_pin=PA3 dir_pin=PA2 invert_step=0 step_pulse_ticks=32\n" +"config_stepper oid=2 step_pin=PC7 dir_pin=PC6 invert_step=0 step_pulse_ticks=32\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 21 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `avr-gcc (GCC) " +"5.4.0`. Both the 16Mhz and 20Mhz tests were run using simulavr configured " +"for an atmega644p (previous tests have confirmed simulavr results match " +"tests on both a 16Mhz at90usb and a 16Mhz atmega2560)." +msgstr "" + +#: docs/Benchmarks.md:block 22 (table) +msgid "102" +msgstr "" + +#: docs/Benchmarks.md:block 22 (table) +msgid "486" +msgstr "" + +#: docs/Benchmarks.md:block 25 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PB27 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PB26 dir_pin=PC30 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PA21 dir_pin=PC30 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 26 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `arm-none-eabi-" +"gcc (Fedora 10.2.0-4.fc34) 10.2.0`." +msgstr "" + +#: docs/Benchmarks.md:block 27 (table) +msgid "257" +msgstr "" + +#: docs/Benchmarks.md:block 30 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PC26 dir_pin=PC18 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PC26 dir_pin=PA8 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PC26 dir_pin=PB4 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 32 (table) +msgid "260" +msgstr "" + +#: docs/Benchmarks.md:block 35 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PD6 dir_pin=PD11 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PD7 dir_pin=PD12 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PD8 dir_pin=PD13 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 36 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `gcc version " +"10.3.1 20210621 (release) (GNU Arm Embedded Toolchain 10.3-2021.07)`." +msgstr "" + +#: docs/Benchmarks.md:block 37 (table) +msgid "48" +msgstr "" + +#: docs/Benchmarks.md:block 37 (table) +msgid "215" +msgstr "" + +#: docs/Benchmarks.md:block 40 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=gpio0_23 dir_pin=gpio1_12 invert_step=0 step_pulse_ticks=20\n" +"config_stepper oid=1 step_pin=gpio1_15 dir_pin=gpio0_26 invert_step=0 step_pulse_ticks=20\n" +"config_stepper oid=2 step_pin=gpio0_22 dir_pin=gpio2_1 invert_step=0 step_pulse_ticks=20\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 41 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `pru-gcc (GCC) " +"8.0.0 20170530 (experimental)`." +msgstr "" + +#: docs/Benchmarks.md:block 42 (table) +msgid "231" +msgstr "" + +#: docs/Benchmarks.md:block 42 (table) +msgid "847" +msgstr "" + +#: docs/Benchmarks.md:block 45 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PA1 dir_pin=PA2 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PA3 dir_pin=PA2 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PB8 dir_pin=PA2 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 47 (table) +msgid "59" +msgstr "" + +#: docs/Benchmarks.md:block 47 (table) +msgid "249" +msgstr "" + +#: docs/Benchmarks.md:block 50 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PC13 dir_pin=PB5 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PB3 dir_pin=PB6 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PA4 dir_pin=PB7 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 52 (table) +msgid "61" +msgstr "" + +#: docs/Benchmarks.md:block 52 (table) +msgid "264" +msgstr "" + +#: docs/Benchmarks.md:block 55 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PA5 dir_pin=PB5 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PB2 dir_pin=PB6 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PB3 dir_pin=PB7 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 56 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `arm-none-eabi-" +"gcc (Fedora 10.2.0-4.fc34) 10.2.0`. The STM32F407 results were obtained by " +"running an STM32F407 binary on an STM32F446 (and thus using a 168Mhz clock)." +msgstr "" + +#: docs/Benchmarks.md:block 57 (table) +msgid "46" +msgstr "" + +#: docs/Benchmarks.md:block 57 (table) +msgid "205" +msgstr "" + +#: docs/Benchmarks.md:block 61 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=P1.20 dir_pin=P1.18 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=P1.21 dir_pin=P1.18 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=P1.23 dir_pin=P1.18 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 62 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `arm-none-eabi-" +"gcc (Fedora 10.2.0-4.fc34) 10.2.0`. The 120Mhz LPC1769 results were obtained" +" by overclocking an LPC1768 to 120Mhz." +msgstr "" + +#: docs/Benchmarks.md:block 63 (table) +msgid "222" +msgstr "" + +#: docs/Benchmarks.md:block 67 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PA27 dir_pin=PA20 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PB3 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PA17 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 68 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `arm-none-eabi-" +"gcc (Fedora 10.2.0-4.fc34) 10.2.0` on a SAMD21G18 micro-controller." +msgstr "" + +#: docs/Benchmarks.md:block 69 (table) +msgid "306" +msgstr "" + +#: docs/Benchmarks.md:block 72 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PA22 dir_pin=PA20 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PA22 dir_pin=PA21 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PA22 dir_pin=PA19 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 73 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `arm-none-eabi-" +"gcc (Fedora 10.2.0-4.fc34) 10.2.0` on a SAMD51J19A micro-controller." +msgstr "" + +#: docs/Benchmarks.md:block 74 (table) +msgid "39" +msgstr "" + +#: docs/Benchmarks.md:block 74 (table) +msgid "191" +msgstr "" + +#: docs/Benchmarks.md:block 74 (table) +msgid "181" +msgstr "" + +#: docs/Benchmarks.md:block 77 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=gpio25 dir_pin=gpio3 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=gpio26 dir_pin=gpio4 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=gpio27 dir_pin=gpio5 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 78 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `arm-none-eabi-" +"gcc (Fedora 10.2.0-4.fc34) 10.2.0` on a Raspberry Pi Pico board." +msgstr "" + +#: docs/Benchmarks.md:block 82 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=gpio2 dir_pin=gpio3 invert_step=0 step_pulse_ticks=5\n" +"config_stepper oid=1 step_pin=gpio4 dir_pin=gpio5 invert_step=0 step_pulse_ticks=5\n" +"config_stepper oid=2 step_pin=gpio6 dir_pin=gpio17 invert_step=0 step_pulse_ticks=5\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 83 (paragraph) +msgid "" +"The test was last run on commit `59314d99` with gcc version `gcc (Raspbian " +"8.3.0-6+rpi1) 8.3.0` on a Raspberry Pi 3 (revision a02082). It was difficult" +" to get stable results in this benchmark." +msgstr "" + +#: docs/Benchmarks.md:block 84 (table) +msgid "160" +msgstr "" + +#: docs/Benchmarks.md:block 84 (table) +msgid "380" +msgstr "" + +#: docs/Benchmarks.md:block 15 (paragraph) +msgid "" +"To produce the benchmarks found in the [Features](Features.md) document, the" +" total number of steps per second is calculated by multiplying the number of" +" active steppers with the nominal mcu frequency and dividing by the final " +"ticks parameter. The results are rounded to the nearest K. For example, with" +" three active steppers:" +msgstr "" + +#: docs/Benchmarks.md:block 59 (header) +msgid "STM32G0B1 step rate benchmark" +msgstr "" + +#: docs/Benchmarks.md:block 60 (paragraph) +msgid "The following configuration sequence is used on the STM32G0B1:" +msgstr "" + +#: docs/Benchmarks.md:block 61 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PB13 dir_pin=PB12 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PB10 dir_pin=PB2 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PB0 dir_pin=PC5 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 62 (paragraph) +msgid "" +"The test was last run on commit `247cd753` with gcc version `arm-none-eabi-" +"gcc (Fedora 10.2.0-4.fc34) 10.2.0`." +msgstr "" + +#: docs/Benchmarks.md:block 63 (table) +msgid "58" +msgstr "" + +#: docs/Benchmarks.md:block 63 (table) +msgid "243" +msgstr "" + +#: docs/Benchmarks.md:block 63 (table) +msgid "stm32g0b1" +msgstr "" + +#: docs/Benchmarks.md:block 59 (header) +msgid "STM32H7 step rate benchmark" +msgstr "" + +#: docs/Benchmarks.md:block 60 (paragraph) +msgid "The following configuration sequence is used on a STM32H743VIT6:" +msgstr "" + +#: docs/Benchmarks.md:block 61 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PD4 dir_pin=PD3 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PA15 dir_pin=PA8 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PE2 dir_pin=PE3 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +msgstr "" + +#: docs/Benchmarks.md:block 62 (paragraph) +msgid "" +"The test was last run on commit `00191b5c` with gcc version `arm-none-eabi-" +"gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision " +"273027]`." +msgstr "" + +#: docs/Benchmarks.md:block 63 (table) +msgid "stm32h7" +msgstr "" + +#: docs/Benchmarks.md:block 63 (table) +msgid "44" +msgstr "" + +#: docs/Benchmarks.md:block 63 (table) +msgid "198" +msgstr "" + +#: docs/Benchmarks.md:block 85 (header) +msgid "AR100 step rate benchmark" +msgstr "" + +#: docs/Benchmarks.md:block 86 (paragraph) +msgid "" +"The following configuration sequence is used on AR100 CPU (Allwinner A64):" +msgstr "" + +#: docs/Benchmarks.md:block 87 (code) +msgid "" +"allocate_oids count=3\n" +"config_stepper oid=0 step_pin=PL10 dir_pin=PE14 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=1 step_pin=PL11 dir_pin=PE15 invert_step=-1 step_pulse_ticks=0\n" +"config_stepper oid=2 step_pin=PL12 dir_pin=PE16 invert_step=-1 step_pulse_ticks=0\n" +"finalize_config crc=0\n" +"\n" +msgstr "" + +#: docs/Benchmarks.md:block 88 (paragraph) +msgid "" +"The test was last run on commit `08d037c6` with gcc version `or1k-linux-" +"musl-gcc (GCC) 9.2.0` on an Allwinner A64-H micro-controller." +msgstr "" + +#: docs/Benchmarks.md:block 89 (table) +msgid "AR100 R_PIO" +msgstr "" + +#: docs/Benchmarks.md:block 89 (table) +msgid "85" +msgstr "" + +#: docs/Benchmarks.md:block 89 (table) +msgid "359" +msgstr "" + +#: docs/Benchmarks.md:block 105 (table) +msgid "ar100 (serial)" +msgstr "" + +#: docs/Benchmarks.md:block 105 (table) +msgid "138K" +msgstr "" + +#: docs/Benchmarks.md:block 105 (table) +msgid "08d037c6" +msgstr "" + +#: docs/Benchmarks.md:block 105 (table) +msgid "or1k-linux-musl-gcc 9.3.0" +msgstr "" + +#~ msgid "" +#~ "To produce the benchmarks found in the Features.md document, the total " +#~ "number of steps per second is calculated by multiplying the number of active" +#~ " steppers with the nominal mcu frequency and dividing by the final ticks " +#~ "parameter. The results are rounded to the nearest K. For example, with three" +#~ " active steppers:" +#~ msgstr "" + +#~ msgid "" +#~ "To obtain the single stepper and dual stepper benchmarks, the same " +#~ "configuration sequence is used, but only the first block (for the single " +#~ "stepper case) or first two blocks (for the dual stepper case) of the above " +#~ "test is cut-and-paste into the console.py window." +#~ msgstr "" + +#~ msgid "" +#~ "Benchmarks may be run with the micro-controller code compiled using a \"step" +#~ " pulse duration\" of zero (the tables below report this as \"no delay\"). " +#~ "This configuration is believed to be valid in real-world usage when one is " +#~ "solely using Trinamic stepper drivers. The results of these benchmarks are " +#~ "not reported in the Features.md document." +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `01d2183f` with gcc version `avr-gcc (GCC) " +#~ "5.4.0`. Both the 16Mhz and 20Mhz tests were run using simulavr configured " +#~ "for an atmega644p (previous tests have confirmed simulavr results match " +#~ "tests on both a 16Mhz at90usb and a 16Mhz atmega2560)." +#~ msgstr "" + +#~ msgid "104" +#~ msgstr "" + +#~ msgid "2 stepper" +#~ msgstr "" + +#~ msgid "296" +#~ msgstr "" + +#~ msgid "472" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `8d4a5c16` with gcc version `arm-none-eabi-" +#~ "gcc (Fedora 7.4.0-1.fc30) 7.4.0`." +#~ msgstr "" + +#~ msgid "388" +#~ msgstr "" + +#~ msgid "405" +#~ msgstr "" + +#~ msgid "576" +#~ msgstr "" + +#~ msgid "1 stepper (no delay)" +#~ msgstr "" + +#~ msgid "77" +#~ msgstr "" + +#~ msgid "3 stepper (no delay)" +#~ msgstr "" + +#~ msgid "299" +#~ msgstr "" + +#~ msgid "527" +#~ msgstr "" + +#~ msgid "535" +#~ msgstr "" + +#~ msgid "638" +#~ msgstr "" + +#~ msgid "254" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `59a60d68` with gcc version `arm-none-eabi-" +#~ "gcc 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]`." +#~ msgstr "" + +#~ msgid "519" +#~ msgstr "" + +#~ msgid "520" +#~ msgstr "" + +#~ msgid "525" +#~ msgstr "" + +#~ msgid "4 stepper" +#~ msgstr "" + +#~ msgid "703" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `b161a69e` with gcc version `pru-gcc (GCC) " +#~ "8.0.0 20170530 (experimental)`." +#~ msgstr "" + +#~ msgid "861" +#~ msgstr "" + +#~ msgid "853" +#~ msgstr "" + +#~ msgid "883" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `0b0c47c5` with gcc version `arm-none-eabi-" +#~ "gcc (Fedora 9.2.0-1.fc30) 9.2.0`." +#~ msgstr "" + +#~ msgid "247" +#~ msgstr "" + +#~ msgid "328" +#~ msgstr "" + +#~ msgid "558" +#~ msgstr "" + +#~ msgid "347" +#~ msgstr "" + +#~ msgid "372" +#~ msgstr "" + +#~ msgid "600" +#~ msgstr "" + +#~ msgid "288" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `8d4a5c16` with gcc version `arm-none-eabi-" +#~ "gcc (Fedora 7.4.0-1.fc30) 7.4.0`. The STM32F407 results were obtained by " +#~ "running an STM32F407 binary on an STM32F446 (and thus using a 168Mhz clock)." +#~ msgstr "" + +#~ msgid "757" +#~ msgstr "" + +#~ msgid "761" +#~ msgstr "" + +#~ msgid "767" +#~ msgstr "" + +#~ msgid "226" +#~ msgstr "" + +#~ msgid "709" +#~ msgstr "" + +#~ msgid "714" +#~ msgstr "" + +#~ msgid "729" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `8d4a5c16` with gcc version `arm-none-eabi-" +#~ "gcc (Fedora 7.4.0-1.fc30) 7.4.0`. The 120Mhz LPC1769 results were obtained " +#~ "by overclocking an LPC1768 to 120Mhz." +#~ msgstr "" + +#~ msgid "448" +#~ msgstr "" + +#~ msgid "450" +#~ msgstr "" + +#~ msgid "523" +#~ msgstr "" + +#~ msgid "56" +#~ msgstr "" + +#~ msgid "240" +#~ msgstr "" + +#~ msgid "526" +#~ msgstr "" + +#~ msgid "545" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `8d4a5c16` with gcc version `arm-none-eabi-" +#~ "gcc (Fedora 7.4.0-1.fc30) 7.4.0` on a SAMD21G18 micro-controller." +#~ msgstr "" + +#~ msgid "277" +#~ msgstr "" + +#~ msgid "410" +#~ msgstr "" + +#~ msgid "664" +#~ msgstr "" + +#~ msgid "83" +#~ msgstr "" + +#~ msgid "321" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `524ebbc7` with gcc version `arm-none-eabi-" +#~ "gcc (Fedora 9.2.0-1.fc30) 9.2.0` on a SAMD51J19A micro-controller." +#~ msgstr "" + +#~ msgid "516" +#~ msgstr "" + +#~ msgid "631" +#~ msgstr "" + +#~ msgid "839" +#~ msgstr "" + +#~ msgid "2 stepper (200Mhz)" +#~ msgstr "" + +#~ msgid "838" +#~ msgstr "" + +#~ msgid "4 stepper (200Mhz)" +#~ msgstr "" + +#~ msgid "5 stepper (200Mhz)" +#~ msgstr "" + +#~ msgid "891" +#~ msgstr "" + +#~ msgid "42" +#~ msgstr "" + +#~ msgid "194" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `db0fb5d5` with gcc version `gcc (Raspbian " +#~ "6.3.0-18+rpi1+deb9u1) 6.3.0 20170516` on a Raspberry Pi 3 (revision a22082)." +#~ msgstr "" + +#~ msgid "349" +#~ msgstr "" + +#~ msgid "350" +#~ msgstr "" + +#~ msgid "400" +#~ msgstr "" + +#~ msgid "" +#~ "PINS arduino\n" +#~ "allocate_oids count=3\n" +#~ "config_stepper oid=0 step_pin=ar29 dir_pin=ar28 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=ar27 dir_pin=ar26 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=ar23 dir_pin=ar22 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=3\n" +#~ "config_stepper oid=0 step_pin=PB27 dir_pin=PA21 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=PB26 dir_pin=PC30 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=PA21 dir_pin=PC30 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=3\n" +#~ "config_stepper oid=0 step_pin=PC26 dir_pin=PC18 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=PC26 dir_pin=PA8 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=PC26 dir_pin=PB4 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=4\n" +#~ "config_stepper oid=0 step_pin=PD6 dir_pin=PD11 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=PD7 dir_pin=PD12 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=PD8 dir_pin=PD13 invert_step=0\n" +#~ "config_stepper oid=3 step_pin=PD5 dir_pin=PA1 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ "\n" +#~ msgstr "" + +#~ msgid "" +#~ "PINS beaglebone\n" +#~ "allocate_oids count=3\n" +#~ "config_stepper oid=0 step_pin=P8_13 dir_pin=P8_12 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=P8_15 dir_pin=P8_14 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=P8_19 dir_pin=P8_18 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=3\n" +#~ "config_stepper oid=0 step_pin=PA1 dir_pin=PA2 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=PA3 dir_pin=PA2 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=PB8 dir_pin=PA2 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=3\n" +#~ "config_stepper oid=0 step_pin=PC13 dir_pin=PB5 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=PB3 dir_pin=PB6 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=PA4 dir_pin=PB7 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=4\n" +#~ "config_stepper oid=0 step_pin=PA5 dir_pin=PB5 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=PB2 dir_pin=PB6 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=PB3 dir_pin=PB7 invert_step=0\n" +#~ "config_stepper oid=3 step_pin=PB3 dir_pin=PB8 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=3\n" +#~ "config_stepper oid=0 step_pin=P1.20 dir_pin=P1.18 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=P1.21 dir_pin=P1.18 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=P1.23 dir_pin=P1.18 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=3\n" +#~ "config_stepper oid=0 step_pin=PA27 dir_pin=PA20 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=PB3 dir_pin=PA21 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=PA17 dir_pin=PA21 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=5\n" +#~ "config_stepper oid=0 step_pin=PA22 dir_pin=PA20 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=PA22 dir_pin=PA21 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=PA22 dir_pin=PA19 invert_step=0\n" +#~ "config_stepper oid=3 step_pin=PA22 dir_pin=PA18 invert_step=0\n" +#~ "config_stepper oid=4 step_pin=PA23 dir_pin=PA17 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=3\n" +#~ "config_stepper oid=0 step_pin=gpio2 dir_pin=gpio3 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=gpio4 dir_pin=gpio5 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=gpio6 dir_pin=gpio7 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "allocate_oids count=4\n" +#~ "config_stepper oid=0 step_pin=gpio25 dir_pin=gpio3 invert_step=0\n" +#~ "config_stepper oid=1 step_pin=gpio26 dir_pin=gpio4 invert_step=0\n" +#~ "config_stepper oid=2 step_pin=gpio27 dir_pin=gpio5 invert_step=0\n" +#~ "config_stepper oid=3 step_pin=gpio28 dir_pin=gpio6 invert_step=0\n" +#~ "finalize_config crc=0\n" +#~ msgstr "" + +#~ msgid "" +#~ "The test was last run on commit `c5667193` with gcc version `arm-none-eabi-" +#~ "gcc (Fedora 10.2.0-4.fc34) 10.2.0` on a Raspberry Pi Pico board." +#~ msgstr "" + +#~ msgid "" +#~ "The test is performed using the console.py tool (described in " +#~ "[Debugging.md](Debugging.md)). The micro-controller is configured for the " +#~ "particular hardware platform (see below) and then the following is cut-and-" +#~ "paste into the console.py terminal window:" +#~ msgstr "" + +#~ msgid "" +#~ "The command dispatch benchmark tests how many \"dummy\" commands the micro-" +#~ "controller can process. It is primarily a test of the hardware communication" +#~ " mechanism. The test is run using the console.py tool (described in " +#~ "[Debugging.md](Debugging.md)). The following is cut-and-paste into the " +#~ "console.py terminal window:" +#~ msgstr "" + +#~ msgid "" +#~ "It is possible to run timing tests on the host software using the \"batch " +#~ "mode\" processing mechanism (described in [Debugging.md](Debugging.md)). " +#~ "This is typically done by choosing a large and complex G-Code file and " +#~ "timing how long it takes for the host software to process it. For example:" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Bootloader_Entry.po b/docs/locales/lt/LC_MESSAGES/Bootloader_Entry.po new file mode 100644 index 0000000000..d0a121a2c0 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Bootloader_Entry.po @@ -0,0 +1,219 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: docs/Bootloader_Entry.md:block 1 (header) +msgid "Bootloader Entry" +msgstr "" + +#: docs/Bootloader_Entry.md:block 2 (paragraph) +msgid "" +"Klipper can be instructed to reboot into a [Bootloader](Bootloaders.md) in " +"one of the following ways:" +msgstr "" + +#: docs/Bootloader_Entry.md:block 3 (header) +msgid "Requesting the bootloader" +msgstr "" + +#: docs/Bootloader_Entry.md:block 4 (header) +msgid "Virtual Serial" +msgstr "" + +#: docs/Bootloader_Entry.md:block 5 (paragraph) +msgid "" +"If a virtual (USB-ACM) serial port is in use, pulsing DTR while at 1200 baud" +" will request the bootloader." +msgstr "" + +#: docs/Bootloader_Entry.md:block 6 (header) +msgid "Python (with `flash_usb`)" +msgstr "" + +#: docs/Bootloader_Entry.md:block 7 (paragraph) +msgid "To enter the bootloader using python (using `flash_usb`):" +msgstr "" + +#: docs/Bootloader_Entry.md:block 8 (code) +msgid "" +"> cd klipper/scripts\n" +"> python3 -c 'import flash_usb as u; u.enter_bootloader(\"\")'\n" +"Entering bootloader on \n" +msgstr "" + +#: docs/Bootloader_Entry.md:block 9 (paragraph) +msgid "" +"Where `` is your serial device, such as `/dev/serial.by-id/usb-" +"Klipper[...]` or `/dev/ttyACM0`" +msgstr "" + +#: docs/Bootloader_Entry.md:block 10 (paragraph) +msgid "" +"Note that if this fails, no output will be printed, success is indicated by " +"printing `Entering bootloader on `." +msgstr "" + +#: docs/Bootloader_Entry.md:block 11 (header) +msgid "Picocom" +msgstr "" + +#: docs/Bootloader_Entry.md:block 12 (code) +msgid "" +"picocom -b 1200 \n" +"\n" +msgstr "" + +#: docs/Bootloader_Entry.md:block 14 (paragraph) +msgid "" +"`` means holding `Ctrl`, pressing and releasing `a`, " +"pressing and releasing `p`, then releasing `Ctrl`" +msgstr "" + +#: docs/Bootloader_Entry.md:block 15 (header) +msgid "Physical serial" +msgstr "" + +#: docs/Bootloader_Entry.md:block 16 (paragraph) +msgid "" +"If a physical serial port is being used on the MCU (even if a USB serial " +"adapter is being used to connect to it), sending the string " +"`Request Serial Bootloader!!~`." +msgstr "" + +#: docs/Bootloader_Entry.md:block 17 (paragraph) +msgid "`` is an ASCII literal space, 0x20." +msgstr "" + +#: docs/Bootloader_Entry.md:block 18 (paragraph) +msgid "`` is the ASCII File Separator, 0x1c." +msgstr "" + +#: docs/Bootloader_Entry.md:block 19 (paragraph) +msgid "" +"Note that this is not a valid message as per the [MCU " +"Protocol](Protocol.md#micro-controller-interface), but sync characters(`~`) " +"are still respected." +msgstr "" + +#: docs/Bootloader_Entry.md:block 20 (paragraph) +msgid "" +"Because this message must be the only thing in the \"block\" it is received " +"in, prefixing an extra sync character can increase reliability if other " +"tools were previously accessing the serial port." +msgstr "" + +#: docs/Bootloader_Entry.md:block 21 (header) +msgid "Shell" +msgstr "" + +#: docs/Bootloader_Entry.md:block 22 (code) +msgid "" +"stty < /dev/\n" +"echo $'~ \\x1c Request Serial Bootloader!! ~' >> /dev/\n" +msgstr "" + +#: docs/Bootloader_Entry.md:block 23 (paragraph) +msgid "" +"Where `` is your serial port, such as `/dev/ttyS0`, or " +"`/dev/serial/by-id/gpio-serial2`, and" +msgstr "" + +#: docs/Bootloader_Entry.md:block 24 (paragraph) +msgid "`` is the baud rate of the serial port, such as `115200`." +msgstr "" + +#: docs/Bootloader_Entry.md:block 25 (header) +msgid "CANBUS" +msgstr "" + +#: docs/Bootloader_Entry.md:block 26 (paragraph) +msgid "" +"If CANBUS is in use, a special [admin message](CANBUS_protocol.md#admin-" +"messages) will request the bootloader. This message will be respected even " +"if the device already has a nodeid, and will also be processed if the mcu is" +" shutdown." +msgstr "" + +#: docs/Bootloader_Entry.md:block 27 (paragraph) +msgid "" +"This method also applies to devices operating in [CANBridge](CANBUS.md#usb-" +"to-can-bus-bridge-mode) mode." +msgstr "" + +#: docs/Bootloader_Entry.md:block 28 (header) +msgid "Katapult's flashtool.py" +msgstr "" + +#: docs/Bootloader_Entry.md:block 29 (code) +msgid "python3 ./katapult/scripts/flashtool.py -i -u -r\n" +msgstr "" + +#: docs/Bootloader_Entry.md:block 30 (paragraph) +msgid "" +"Where `` is the can interface to use. If using `can0`, both the " +"`-i` and `` may be omitted." +msgstr "" + +#: docs/Bootloader_Entry.md:block 31 (paragraph) +msgid "`` is the UUID of your CAN device." +msgstr "" + +#: docs/Bootloader_Entry.md:block 32 (paragraph) +msgid "" +"See the [CANBUS Documentation](CANBUS.md#finding-the-canbus_uuid-for-new-" +"micro-controllers) for information on finding the CAN UUID of your devices." +msgstr "" + +#: docs/Bootloader_Entry.md:block 33 (header) +msgid "Entering the bootloader" +msgstr "" + +#: docs/Bootloader_Entry.md:block 34 (paragraph) +msgid "When klipper receives one of the above bootloader requests:" +msgstr "" + +#: docs/Bootloader_Entry.md:block 35 (paragraph) +msgid "" +"If Katapult (formerly known as CANBoot) is available, klipper will request " +"that Katapult stay active on the next boot, then reset the MCU (therefore " +"entering Katapult)." +msgstr "" + +#: docs/Bootloader_Entry.md:block 36 (paragraph) +msgid "" +"If Katapult is not available, klipper will then try to enter a platform-" +"specific bootloader, such as STM32's DFU mode([see note](#stm32-dfu-" +"warning))." +msgstr "" + +#: docs/Bootloader_Entry.md:block 37 (paragraph) +msgid "" +"In short, Klipper will reboot to Katapult if installed, then a hardware " +"specific bootloader if available." +msgstr "" + +#: docs/Bootloader_Entry.md:block 38 (paragraph) +msgid "" +"For details about the specific bootloaders on various platforms see " +"[Bootloaders](Bootloaders.md)" +msgstr "" + +#: docs/Bootloader_Entry.md:block 39 (header) +msgid "Notes" +msgstr "" + +#: docs/Bootloader_Entry.md:block 40 (header) +msgid "STM32 DFU Warning" +msgstr "" + +#: docs/Bootloader_Entry.md:block 41 (paragraph) +msgid "" +"Note that on some boards, like the Octopus Pro v1, entering DFU mode can " +"cause undesired actions (such as powering the heater while in DFU mode). It " +"is recommended to disconnect heaters, and otherwise prevent undesired " +"operations when using DFU mode. Consult the documentation for your board for" +" more details." +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/CANBUS.po b/docs/locales/lt/LC_MESSAGES/CANBUS.po new file mode 100644 index 0000000000..b4e1273f3b --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/CANBUS.po @@ -0,0 +1,324 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "This document describes Klipper's CAN bus support." +msgstr "" + +msgid "Device Hardware" +msgstr "" + +msgid "Host Hardware" +msgstr "" + +msgid "" +"It is also necessary to configure the host operating system to use the " +"adapter. This is typically done by creating a new file named " +"`/etc/network/interfaces.d/can0` with the following contents:" +msgstr "" + +msgid "Terminating Resistors" +msgstr "" + +msgid "" +"A CAN bus should have two 120 ohm resistors between the CANH and CANL wires." +" Ideally, one resistor located at each the end of the bus." +msgstr "" + +msgid "" +"To test that the resistors are correct, one can remove power to the printer " +"and use a multi-meter to check the resistance between the CANH and CANL " +"wires - it should report ~60 ohms on a correctly wired CAN bus." +msgstr "" + +msgid "Finding the canbus_uuid for new micro-controllers" +msgstr "" + +msgid "" +"Each micro-controller on the CAN bus is assigned a unique id based on the " +"factory chip identifier encoded into each micro-controller. To find each " +"micro-controller device id, make sure the hardware is powered and wired " +"correctly, and then run:" +msgstr "" + +msgid "" +"If uninitialized CAN devices are detected the above command will report " +"lines like the following:" +msgstr "" + +msgid "" +"Each device will have a unique identifier. In the above example, " +"`11aa22bb33cc` is the micro-controller's \"canbus_uuid\"." +msgstr "" + +msgid "" +"Note that the `canbus_query.py` tool will only report uninitialized devices " +"- if Klipper (or a similar tool) configures the device then it will no " +"longer appear in the list." +msgstr "" + +msgid "Configuring Klipper" +msgstr "" + +msgid "" +"Update the Klipper [mcu configuration](Config_Reference.md#mcu) to use the " +"CAN bus to communicate with the device - for example:" +msgstr "" + +msgid "~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0\n" +msgstr "" + +msgid "" +"[mcu my_can_mcu]\n" +"canbus_uuid: 11aa22bb33cc\n" +msgstr "" + +#: docs/CANBUS.md:block 1 (header) +msgid "CANBUS" +msgstr "" + +#: docs/CANBUS.md:block 5 (paragraph) +msgid "" +"To compile for CAN, run `make menuconfig` and select \"CAN bus\" as the " +"communication interface. Finally, compile the micro-controller code and " +"flash it to the target board." +msgstr "" + +#: docs/CANBUS.md:block 26 (header) +msgid "USB to CAN bus bridge mode" +msgstr "" + +#: docs/CANBUS.md:block 29 (paragraph) +msgid "Some important notes when using this mode:" +msgstr "" + +#: docs/CANBUS.md:block 30 (unordered list) +msgid "" +"It is necessary to configure the `can0` (or similar) interface in Linux in " +"order to communicate with the bus. However, Linux CAN bus speed and CAN bus " +"bit-timing options are ignored by Klipper. Currently, the CAN bus frequency " +"is specified during \"make menuconfig\" and the bus speed specified in Linux" +" is ignored." +msgstr "" + +#: docs/CANBUS.md:block 20 (code) +msgid "Found canbus_uuid=11aa22bb33cc, Application: Klipper\n" +msgstr "" + +#: docs/CANBUS.md:block 4 (paragraph) +msgid "" +"Klipper currently supports CAN on stm32, SAME5x, and rp2040 chips. In " +"addition, the micro-controller chip must be on a board that has a CAN " +"transceiver." +msgstr "" + +#: docs/CANBUS.md:block 7 (paragraph) +msgid "" +"In order to use a CAN bus, it is necessary to have a host adapter. It is " +"recommended to use a \"USB to CAN adapter\". There are many different USB to" +" CAN adapters available from different manufacturers. When choosing one, we " +"recommend verifying that the firmware can be updated on it. (Unfortunately, " +"we've found some USB adapters run defective firmware and are locked down, so" +" verify before purchasing.) Look for adapters that can run Klipper directly " +"(in its \"USB to CAN bridge mode\") or that run the [candlelight " +"firmware](https://github.com/candle-usb/candleLight_fw)." +msgstr "" + +#: docs/CANBUS.md:block 9 (code) +msgid "" +"allow-hotplug can0\n" +"iface can0 can static\n" +" bitrate 1000000\n" +" up ifconfig $IFACE txqueuelen 128\n" +msgstr "" + +#: docs/CANBUS.md:block 12 (paragraph) +msgid "" +"Note that some devices have a builtin 120 ohm resistor that can not be " +"easily removed. Some devices do not include a resistor at all. Other devices" +" have a mechanism to select the resistor (typically by connecting a \"pin " +"jumper\"). Be sure to check the schematics of all devices on the CAN bus to " +"verify that there are two and only two 120 Ohm resistors on the bus." +msgstr "" + +#: docs/CANBUS.md:block 25 (paragraph) +msgid "" +"Some micro-controllers support selecting \"USB to CAN bus bridge\" mode " +"during Klipper's \"make menuconfig\". This mode may allow one to use a " +"micro-controller as both a \"USB to CAN bus adapter\" and as a Klipper node." +msgstr "" + +#: docs/CANBUS.md:block 26 (paragraph) +msgid "" +"When Klipper uses this mode the micro-controller appears as a \"USB CAN bus " +"adapter\" under Linux. The \"Klipper bridge mcu\" itself will appear as if " +"it was on this CAN bus - it can be identified via `canbus_query.py` and it " +"must be configured like other CAN bus Klipper nodes." +msgstr "" + +#: docs/CANBUS.md:block 28 (unordered list) +msgid "" +"Whenever the \"bridge mcu\" is reset, Linux will disable the corresponding " +"`can0` interface. To ensure proper handling of FIRMWARE_RESTART and RESTART " +"commands, it is recommended to use `allow-hotplug` in the " +"`/etc/network/interfaces.d/can0` file. For example:" +msgstr "" + +#: docs/CANBUS.md:block 30 (unordered list) +msgid "" +"The \"bridge mcu\" is not actually on the CAN bus. Messages to and from the " +"bridge mcu will not be seen by other adapters that may be on the CAN bus." +msgstr "" + +#: docs/CANBUS.md:block 30 (unordered list) +msgid "" +"The available bandwidth to both the \"bridge mcu\" itself and all devices on" +" the CAN bus is effectively limited by the CAN bus frequency. As a result, " +"it is recommended to use a CAN bus frequency of 1000000 when using \"USB to " +"CAN bus bridge mode\"." +msgstr "" + +#: docs/CANBUS.md:block 30 (unordered list) +msgid "" +"Even at a CAN bus frequency of 1000000, there may not be sufficient " +"bandwidth to run a `SHAPER_CALIBRATE` test if both the XY steppers and the " +"accelerometer all communicate via a single \"USB to CAN bus\" interface." +msgstr "" + +#: docs/CANBUS.md:block 30 (unordered list) +msgid "" +"A USB to CAN bridge board will not appear as a USB serial device, it will " +"not show up when running `ls /dev/serial/by-id`, and it can not be " +"configured in Klipper's printer.cfg file with a `serial:` parameter. The " +"bridge board appears as a \"USB CAN adapter\" and it is configured in the " +"printer.cfg as a [CAN node](#configuring-klipper)." +msgstr "" + +#: docs/CANBUS.md:block 31 (header) +msgid "Tips for troubleshooting" +msgstr "" + +#: docs/CANBUS.md:block 32 (paragraph) +msgid "See the [CAN bus troubleshooting](CANBUS_Troubleshooting.md) document." +msgstr "" + +#~ msgid "" +#~ "In order to use a CAN bus, it is necessary to have a host adapter. There are" +#~ " currently two common options:" +#~ msgstr "" + +#~ msgid "" +#~ "Use a [Waveshare Raspberry Pi CAN hat](https://www.waveshare.com/rs485-can-" +#~ "hat.htm) or one of its many clones." +#~ msgstr "" + +#~ msgid "" +#~ "Note that the \"Raspberry Pi CAN hat\" also requires [changes to " +#~ "config.txt](https://www.waveshare.com/wiki/RS485_CAN_HAT)." +#~ msgstr "" + +#~ msgid "" +#~ "Note that some devices have a builtin 120 ohm resistor (for example, the " +#~ "\"Waveshare Raspberry Pi CAN hat\" has a soldered on resistor that can not " +#~ "be easily removed). Some devices do not include a resistor at all. Other " +#~ "devices have a mechanism to select the resistor (typically by connecting a " +#~ "\"pin jumper\"). Be sure to check the schematics of all devices on the CAN " +#~ "bus to verify that there are two and only two 120 Ohm resistors on the bus." +#~ msgstr "" + +#~ msgid "" +#~ "auto can0\n" +#~ "iface can0 can static\n" +#~ " bitrate 500000\n" +#~ " up ifconfig $IFACE txqueuelen 128\n" +#~ msgstr "" + +#~ msgid "" +#~ "Use a USB CAN adapter (for example ). There are many different USB" +#~ " to CAN adapters available - when choosing one, we recommend verifying it " +#~ "can run the [candlelight firmware](https://github.com/candle-" +#~ "usb/candleLight_fw). (Unfortunately, we've found some USB adapters run " +#~ "defective firmware and are locked down, so verify before purchasing.)" +#~ msgstr "" + +#~ msgid "" +#~ "Some micro-controllers support selecting \"USB to CAN bus bridge\" mode " +#~ "during \"make menuconfig\". This mode may allow one to use a micro-" +#~ "controller as both a \"USB to CAN bus adapter\" and as a Klipper node." +#~ msgstr "" + +#~ msgid "" +#~ "When Klipper uses this mode the micro-controller appears as a \"USB CAN bus " +#~ "adapter\" under Linux. The \"Klipper bridge mcu\" itself will appear as if " +#~ "was on this CAN bus - it can be identified via `canbus_query.py` and " +#~ "configured like other CAN bus Klipper nodes. It will appear alongside other " +#~ "devices that are actually on the CAN bus." +#~ msgstr "" + +#~ msgid "" +#~ "The \"bridge mcu\" is not actually on the CAN bus. Messages to and from it " +#~ "do not consume bandwidth on the CAN bus. The mcu can not be seen by other " +#~ "adapters that may be on the CAN bus." +#~ msgstr "" + +#~ msgid "" +#~ "Whenever the \"bridge mcu\" is reset, Linux will disable the corresponding " +#~ "`can0` interface. To ensure proper handling of FIRMWARE_RESTART and RESTART " +#~ "commands, it is recommended to replace `auto` with `allow-hotplug` in the " +#~ "`/etc/network/interfaces.d/can0` file. For example:" +#~ msgstr "" + +#~ msgid "" +#~ "allow-hotplug can0\n" +#~ "iface can0 can static\n" +#~ " bitrate 500000\n" +#~ " up ifconfig $IFACE txqueuelen 128\n" +#~ msgstr "" + +#~ msgid "" +#~ "Klipper currently supports CAN on stm32, same5x, and rp2040 chips. In " +#~ "addition, the micro-controller chip must be on a board that has a CAN " +#~ "transceiver." +#~ msgstr "" + +#~ msgid "" +#~ "Klipper currently supports CAN on stm32 and rp2040 chips. In addition, the " +#~ "micro-controller chip must be on a board that has a CAN transceiver." +#~ msgstr "" + +#~ msgid "" +#~ "Klipper currently only supports CAN on stm32 chips. In addition, the micro-" +#~ "controller chip must support CAN and it must be on a board that has a CAN " +#~ "transceiver." +#~ msgstr "" + +#~ msgid "Found canbus_uuid=11aa22bb33cc\n" +#~ msgstr "" + +#~ msgid "" +#~ "Whenever the \"bridge mcu\" is reset, Linux will disable the corresponding " +#~ "`can0` interface. Generally, this may require running commands such as \"ip " +#~ "up\" to restart the interface. Thus, Klipper FIRMWARE_RESTART commands (or " +#~ "regular RESTART after a config change) may require restarting the `can0` " +#~ "interface." +#~ msgstr "" + +#~ msgid "" +#~ "To compile for CAN, run \"make menuconfig\" and select \"CAN bus\" as the " +#~ "communication interface. Finally, compile the micro-controller code and " +#~ "flash it to the target board." +#~ msgstr "" + +#~ msgid "" +#~ "Use a USB CAN adapter (for example [https://hacker-" +#~ "gadgets.com/product/cantact-usb-can-adapter/](https://hacker-" +#~ "gadgets.com/product/cantact-usb-can-adapter/)). There are many different USB" +#~ " to CAN adapters available - when choosing one, we recommend verifying it " +#~ "can run the [candlelight firmware](https://github.com/candle-" +#~ "usb/candleLight_fw). (Unfortunately, we've found some USB adapters run " +#~ "defective firmware and are locked down, so verify before purchasing.)" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/CANBUS_Troubleshooting.po b/docs/locales/lt/LC_MESSAGES/CANBUS_Troubleshooting.po new file mode 100644 index 0000000000..c223f770ec --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/CANBUS_Troubleshooting.po @@ -0,0 +1,227 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: docs/CANBUS_Troubleshooting.md:block 1 (header) +msgid "CANBUS Troubleshooting" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 2 (paragraph) +msgid "" +"This document provides information on troubleshooting communication issues " +"when using [Klipper with CAN bus](CANBUS.md)." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 3 (header) +msgid "Verify CAN bus wiring" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 4 (paragraph) +msgid "" +"The first step in troubleshooting communication issues is to verify the CAN " +"bus wiring." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 5 (paragraph) +msgid "" +"Be sure there are exactly two 120 Ohm [terminating " +"resistors](CANBUS.md#terminating-resistors) on the CAN bus. If the resistors" +" are not properly installed then messages may not be able to be sent at all " +"or the connection may have sporadic instability." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 6 (paragraph) +msgid "" +"The CANH and CANL bus wiring should be twisted around each other. At a " +"minimum, the wiring should have a twist every few centimeters. Avoid " +"twisting the CANH and CANL wiring around power wires and ensure that power " +"wires that travel parallel to the CANH and CANL wires do not have the same " +"amount of twists." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 7 (paragraph) +msgid "" +"Verify that all plugs and wire crimps on the CAN bus wiring are fully " +"secured. Movement of the printer toolhead may jostle the CAN bus wiring " +"causing a bad wire crimp or unsecured plug to result in intermittent " +"communication errors." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 8 (header) +msgid "Check for incrementing bytes_invalid counter" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 9 (paragraph) +msgid "" +"The Klipper log file will report a `Stats` line once a second when the " +"printer is active. These \"Stats\" lines will have a `bytes_invalid` counter" +" for each micro-controller. This counter should not increment during normal " +"printer operation (it is normal for the counter to be non-zero after a " +"RESTART and it is not a concern if the counter increments once a month or " +"so). If this counter increments on a CAN bus micro-controller during normal " +"printing (it increments every few hours or more frequently) then it is an " +"indication of a severe problem." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 10 (paragraph) +msgid "" +"Incrementing `bytes_invalid` on a CAN bus connection is a symptom of " +"reordered messages on the CAN bus. There are two known causes of reordered " +"messages:" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 11 (ordered list) +msgid "" +"Old versions of the popular candlight_firmware for USB CAN adapters had a " +"bug that could cause reordered messages. If using a USB CAN adapter running " +"this firmware then make sure to update to the latest firmware if " +"incrementing `bytes_invalid` is observed." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 11 (ordered list) +msgid "" +"Some Linux kernel builds for embedded devices have been known to reorder CAN" +" bus messages. It may be necessary to use an alternative Linux kernel or to " +"use alternative hardware that supports mainstream Linux kernels that do not " +"exhibit this problem." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 12 (paragraph) +msgid "" +"Reordered messages is a severe problem that must be fixed. It will result in" +" unstable behavior and can lead to confusing errors at any part of a print." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 13 (header) +msgid "Obtaining candump logs" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 14 (paragraph) +msgid "" +"The CAN bus messages sent to and from the micro-controller are handled by " +"the Linux kernel. It is possible to capture these messages from the kernel " +"for debugging purposes. A log of these messages may be of use in " +"diagnostics." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 15 (paragraph) +msgid "" +"The Linux [can-utils](https://github.com/linux-can/can-utils) tool provides " +"the capture software. It is typically installed on a machine by running:" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 16 (code) +msgid "sudo apt-get update && sudo apt-get install can-utils\n" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 17 (paragraph) +msgid "" +"Once installed, one may obtain a capture of all CAN bus messages on an " +"interface with the following command:" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 18 (code) +msgid "candump -tz -Ddex can0,#FFFFFFFF > mycanlog\n" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 19 (paragraph) +msgid "" +"One can view the resulting log file (`mycanlog` in the example above) to see" +" each raw CAN bus message that was sent and received by Klipper. " +"Understanding the content of these messages will likely require low-level " +"knowledge of Klipper's [CANBUS protocol](CANBUS_protocol.md) and Klipper's " +"[MCU commands](MCU_Commands.md)." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 20 (header) +msgid "Parsing Klipper messages in a candump log" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 21 (paragraph) +msgid "" +"One may use the `parsecandump.py` tool to parse the low-level Klipper micro-" +"controller messages contained in a candump log. Using this tool is an " +"advanced topic that requires knowledge of Klipper [MCU " +"commands](MCU_Commands.md). For example:" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 22 (code) +msgid "./scripts/parsecandump.py mycanlog 108 ./out/klipper.dict\n" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 23 (paragraph) +msgid "" +"This tool produces output similar to the [parsedump " +"tool](Debugging.md#translating-gcode-files-to-micro-controller-commands). " +"See the documentation for that tool for information on generating the " +"Klipper micro-controller data dictionary." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 24 (paragraph) +msgid "" +"In the above example, `108` is the [CAN bus id](CANBUS_protocol.md#micro-" +"controller-id-assignment). It is a hexadecimal number. The id `108` is " +"assigned by Klipper to the first micro-controller. If the CAN bus has " +"multiple micro-controllers on it, then the second micro-controller would be " +"`10a`, the third would be `10c`, and so on." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 25 (paragraph) +msgid "" +"The candump log must be produced using the `-tz -Ddex` command-line " +"arguments (for example: `candump -tz -Ddex can0,#FFFFFFFF`) in order to use " +"the `parsecandump.py` tool." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 26 (header) +msgid "Using a logic analyzer on the canbus wiring" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 27 (paragraph) +msgid "" +"The [Sigrok Pulseview](https://sigrok.org/wiki/PulseView) software along " +"with a low-cost [logic " +"analyzer](https://en.wikipedia.org/wiki/Logic_analyzer) can be useful for " +"diagnosing CAN bus signaling. This is an advanced topic likely only of " +"interest to experts." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 28 (paragraph) +msgid "" +"One can often find \"USB logic analyzers\" for under $15 (US pricing as of " +"2023). These devices are often listed as \"Saleae logic clones\" or as " +"\"24MHz 8 channel USB logic analyzers\"." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 29 (paragraph) +msgid "![pulseview-canbus](img/pulseview-canbus.png)" +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 30 (paragraph) +msgid "" +"The above picture was taken while using Pulseview with a \"Saleae clone\" " +"logic analyzer. The Sigrok and Pulseview software was installed on a desktop" +" machine (also install the \"fx2lafw\" firmware if that is packaged " +"separately). The CH0 pin on the logic analyzer was routed to the CAN Rx " +"line, the CH1 pin was wired to the CAN Tx pin, and GND was wired to GND. " +"Pulseview was configured to only display the D0 and D1 lines (red \"probe\" " +"icon center top toolbar). The number of samples was set to 5 million (top " +"toolbar) and the sample rate was set to 24Mhz (top toolbar). The CAN decoder" +" was added (yellow and green \"bubble icon\" right top toolbar). The D0 " +"channel was labeled as RX and set to trigger on a falling edge (click on " +"black D0 label at left). The D1 channel was labeled as TX (click on brown D1" +" label at left). The CAN decoder was configured for 1Mbit rate (click on " +"green CAN label at left). The CAN decoder was moved to the top of the " +"display (click and drag green CAN label). Finally, the capture was started " +"(click \"Run\" at top left) and a packet was transmitted on the CAN bus " +"(`cansend can0 123#121212121212`)." +msgstr "" + +#: docs/CANBUS_Troubleshooting.md:block 31 (paragraph) +msgid "" +"The logic analyzer provides an independent tool for capturing packets and " +"verifying bit timing." +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/CONTRIBUTING.po b/docs/locales/lt/LC_MESSAGES/CONTRIBUTING.po new file mode 100644 index 0000000000..f984981cc0 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/CONTRIBUTING.po @@ -0,0 +1,676 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "Contributing to Klipper" +msgstr "" + +msgid "" +"It is important to have a \"Signed-off-by\" line on each commit - it " +"certifies that you agree to the [developer certificate of origin](developer-" +"certificate-of-origin). It must contain your real name (sorry, no pseudonyms" +" or anonymous contributions) and contain a current email address." +msgstr "" + +msgid "" +"module: Capitalized, short (50 chars or less) summary\n" +"\n" +"More detailed explanatory text, if necessary. Wrap it to about 75\n" +"characters or so. In some contexts, the first line is treated as the\n" +"subject of an email and the rest of the text as the body. The blank\n" +"line separating the summary from the body is critical (unless you omit\n" +"the body entirely); tools like rebase can get confused if you run the\n" +"two together.\n" +"\n" +"Further paragraphs come after blank lines..\n" +"\n" +"Signed-off-by: My Name \n" +msgstr "" + +#: docs/CONTRIBUTING.md:block 9 (header) +msgid "Contributing to Klipper Translations" +msgstr "" + +#: docs/CONTRIBUTING.md:block 11 (unordered list) +msgid "75% Total coverage" +msgstr "" + +#: docs/CONTRIBUTING.md:block 11 (unordered list) +msgid "An updated navigation hierarchy PR in klipper-translations." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (paragraph) +msgid "" +"To reduce the frustration of translating domain-specific terms and gain " +"awareness of the ongoing translations, you can submit a PR modifying the " +"[Klipper-translations Project](https://github.com/Klipper3d/klipper-" +"translations) `readme.md`. Once a translation is ready, the corresponding " +"modification to the Klipper project can be made." +msgstr "" + +#: docs/CONTRIBUTING.md:block 14 (paragraph) +msgid "" +"If a translation already exists in the Klipper repository and no longer " +"meets the checklist above, it will be marked out-of-date after a month " +"without updates." +msgstr "" + +#: docs/CONTRIBUTING.md:block 2 (paragraph) +msgid "" +"Thank you for contributing to Klipper! This document describes the process " +"for contributing changes to Klipper." +msgstr "" + +#: docs/CONTRIBUTING.md:block 3 (paragraph) +msgid "" +"Please see the [contact page](Contact.md) for information on reporting an " +"issue or for details on contacting the developers." +msgstr "" + +#: docs/CONTRIBUTING.md:block 4 (header) +msgid "Overview of Contribution Process" +msgstr "" + +#: docs/CONTRIBUTING.md:block 5 (paragraph) +msgid "Contributions to Klipper generally follow a high-level process:" +msgstr "" + +#: docs/CONTRIBUTING.md:block 6 (ordered list) +msgid "" +"A submitter starts by creating a [GitHub Pull " +"Request](https://github.com/Klipper3d/klipper/pulls) when a submission is " +"ready for widespread deployment." +msgstr "" + +#: docs/CONTRIBUTING.md:block 6 (ordered list) +msgid "" +"When a [reviewer](#reviewers) is available to [review](#what-to-expect-in-a-" +"review) the submission, they will assign themselves to the Pull Request on " +"GitHub. The goal of the review is to look for defects and to check that the " +"submission follows documented guidelines." +msgstr "" + +#: docs/CONTRIBUTING.md:block 6 (ordered list) +msgid "" +"After a successful review, the reviewer will \"approve the review\" on " +"GitHub and a [maintainer](#reviewers) will commit the change to the Klipper " +"master branch." +msgstr "" + +#: docs/CONTRIBUTING.md:block 7 (paragraph) +msgid "" +"When working on enhancements, consider starting (or contributing to) a topic" +" on [Klipper Discourse](Contact.md). An ongoing discussion on the forum can " +"improve visibility of development work and may attract others interested in " +"testing new work." +msgstr "" + +#: docs/CONTRIBUTING.md:block 8 (header) +msgid "What to expect in a review" +msgstr "" + +#: docs/CONTRIBUTING.md:block 9 (paragraph) +msgid "" +"Contributions to Klipper are reviewed before merging. The primary goal of " +"the review process is to check for defects and to check that the submission " +"follows guidelines specified in the Klipper documentation." +msgstr "" + +#: docs/CONTRIBUTING.md:block 10 (paragraph) +msgid "" +"It is understood that there are many ways to accomplish a task; it is not " +"the intent of the review to discuss the \"best\" implementation. Where " +"possible, review discussions focused on facts and measurements are " +"preferable." +msgstr "" + +#: docs/CONTRIBUTING.md:block 11 (paragraph) +msgid "" +"The majority of submissions will result in feedback from a review. Be " +"prepared to obtain feedback, provide further details, and to update the " +"submission if needed." +msgstr "" + +#: docs/CONTRIBUTING.md:block 12 (paragraph) +msgid "Common things a reviewer will look for:" +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Is the submission free of defects and is it ready to be widely deployed?" +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Submitters are expected to test their changes prior to submission. The " +"reviewers look for errors, but they don't, in general, test submissions. An " +"accepted submission is often deployed to thousands of printers within a few " +"weeks of acceptance. Quality of submissions is therefore considered a " +"priority." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"The main [Klipper3d/klipper](https://github.com/Klipper3d/klipper) GitHub " +"repository does not accept experimental work. Submitters should perform " +"experimentation, debugging, and testing in their own repositories. The " +"[Klipper Discourse](Contact.md) server is a good place to raise awareness of" +" new work and to find users interested in providing real-world feedback." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "Submissions must pass all [regression test cases](Debugging.md)." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Code submissions should not contain excessive debugging code, debugging " +"options, nor run-time debug logging." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Comments in code submissions should focus on enhancing code maintenance. " +"Submissions should not contain \"commented out code\" nor excessive comments" +" describing past implementations. There should not be excessive \"todo\" " +"comments." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Updates to documentation should not declare that they are a \"work in " +"progress\"." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Is the copyright of the submission clear, non-gratuitous, and compatible?" +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"New C files and Python files should have an unambiguous copyright statement." +" See the existing files for the preferred format. Declaring a copyright on " +"an existing file when making minor changes to that file is discouraged." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Code taken from 3rd party sources must be compatible with the Klipper " +"license (GNU GPLv3). Large 3rd party code additions should be added to the " +"`lib/` directory (and follow the format described in " +"[lib/README](../lib/README))." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Submitters must provide a [Signed-off-by line](#format-of-commit-messages) " +"using their full real name. It indicates the submitter agrees with the " +"[developer certificate of origin](developer-certificate-of-origin)." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Does the submission follow guidelines specified in the Klipper " +"documentation?" +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"In particular, code should follow the guidelines in and " +"config files should follow the guidelines in ." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "Is the Klipper documentation updated to reflect new changes?" +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"At a minimum, the reference documentation must be updated with corresponding" +" changes to the code:" +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"All commands and command parameters must be documented in ." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"All user facing modules and their config parameters must be documented in " +"." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"All exported \"status variables\" must be documented in " +"." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"All new \"webhooks\" and their parameters must be documented in " +"." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Any change that makes a non-backwards compatible change to a command or " +"config file setting must be documented in ." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"New documents should be added to and be added to the website " +"index [docs/_klipper3d/mkdocs.yml](../docs/_klipper3d/mkdocs.yml)." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Are commits well formed, address a single topic per commit, and independent?" +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Commit messages should follow the [preferred format](#format-of-commit-" +"messages)." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Commits must not have a merge conflict. New additions to the Klipper master " +"branch are always done via a \"rebase\" or \"squash and rebase\". It is " +"generally not necessary for submitters to re-merge their submission on every" +" update to the Klipper master repository. However, if there is a merge " +"conflict, then submitters are recommended to use `git rebase` to address the" +" conflict." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Each commit should address a single high-level change. Large changes should " +"be broken up into multiple independent commits. Each commit should \"stand " +"on its own\" so that tools like `git bisect` and `git revert` work reliably." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Whitespace changes should not be mixed with functional changes. In general, " +"gratuitous whitespace changes are not accepted unless they are from the " +"established \"owner\" of the code being modified." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Does the submission provide a \"high impact\" benefit to real-world users " +"performing real-world tasks?" +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Reviewers need to identify, at least in their own minds, roughly \"who the " +"target audience is\", a rough scale of \"the size of that audience\", the " +"\"benefit\" they will obtain, how the \"benefit is measured\", and the " +"\"results of those measurement tests\". In most cases this will be obvious " +"to both the submitter and the reviewer, and it is not explicitly stated " +"during a review." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"Submissions to the master Klipper branch are expected to have a noteworthy " +"target audience. As a general \"rule of thumb\", submissions should target a" +" user base of at least a 100 real-world users." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"If a reviewer asks for details on the \"benefit\" of a submission, please " +"don't consider it criticism. Being able to understand the real-world " +"benefits of a change is a natural part of a review." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"All new modules, config options, commands, command parameters, and documents" +" should have \"high impact\". We do not want to burden users with options " +"that they can not reasonably configure nor do we want to burden them with " +"options that don't provide a notable benefit." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"A reviewer may ask for clarification on how a user is to configure an option" +" - an ideal response will contain details on the process - for example, " +"\"users of the MegaX500 are expected to set option X to 99.3 while users of " +"the Elite100Y are expected to calibrate option X using procedure ...\"." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"If the goal of an option is to make the code more modular then prefer using " +"code constants instead of user facing config options." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"New modules, new options, and new parameters should not provide similar " +"functionality to existing modules - if the differences are arbitrary than " +"it's preferable to utilize the existing system or refactor the existing " +"code." +msgstr "" + +#: docs/CONTRIBUTING.md:block 14 (paragraph) +msgid "" +"Klipper does not implement a strict \"coding style guide\", but " +"modifications to existing code should follow the high-level code flow, code " +"indentation style, and format of that existing code. Submissions of new " +"modules and systems have more flexibility in coding style, but it is " +"preferable for that new code to follow an internally consistent style and to" +" generally follow industry wide coding norms." +msgstr "" + +#: docs/CONTRIBUTING.md:block 15 (paragraph) +msgid "" +"It is not a goal of a review to discuss \"better implementations\". However," +" if a reviewer struggles to understand the implementation of a submission, " +"then they may ask for changes to make the implementation more transparent. " +"In particular, if reviewers can not convince themselves that a submission is" +" free of defects then changes may be necessary." +msgstr "" + +#: docs/CONTRIBUTING.md:block 16 (paragraph) +msgid "" +"As part of a review, a reviewer may create an alternate Pull Request for a " +"topic. This may be done to avoid excessive \"back and forth\" on minor " +"procedural items and thus streamline the submission process. It may also be " +"done because the discussion inspires a reviewer to build an alternative " +"implementation. Both situations are a normal result of a review and should " +"not be considered criticism of the original submission." +msgstr "" + +#: docs/CONTRIBUTING.md:block 17 (header) +msgid "Helping with reviews" +msgstr "" + +#: docs/CONTRIBUTING.md:block 18 (paragraph) +msgid "" +"We appreciate help with reviews! It is not necessary to be a [listed " +"reviewer](#reviewers) to perform a review. Submitters of GitHub Pull " +"Requests are also encouraged to review their own submissions." +msgstr "" + +#: docs/CONTRIBUTING.md:block 19 (paragraph) +msgid "" +"To help with a review, follow the steps outlined in [what to expect in a " +"review](#what-to-expect-in-a-review) to verify the submission. After " +"completing the review, add a comment to the GitHub Pull Request with your " +"findings. If the submission passes the review then please state that " +"explicitly in the comment - for example something like \"I reviewed this " +"change according to the steps in the CONTRIBUTING document and everything " +"looks good to me\". If unable to complete some steps in the review then " +"please explicitly state which steps were reviewed and which steps were not " +"reviewed - for example something like \"I didn't check the code for defects," +" but I reviewed everything else in the CONTRIBUTING document and it looks " +"good\"." +msgstr "" + +#: docs/CONTRIBUTING.md:block 20 (paragraph) +msgid "" +"We also appreciate testing of submissions. If the code was tested then " +"please add a comment to the GitHub Pull Request with the results of your " +"test - success or failure. Please explicitly state that the code was tested " +"and the results - for example something like \"I tested this code on my " +"Acme900Z printer with a vase print and the results were good\"." +msgstr "" + +#: docs/CONTRIBUTING.md:block 21 (header) +msgid "Reviewers" +msgstr "" + +#: docs/CONTRIBUTING.md:block 22 (paragraph) +msgid "The Klipper \"reviewers\" are:" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "Name" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "GitHub Id" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "Areas of interest" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "Dmitry Butyugin" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "@dmbutyugin" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "Input shaping, resonance testing, kinematics" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "Eric Callahan" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "@Arksine" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "Bed leveling, MCU flashing" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "Kevin O'Connor" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "@KevinOConnor" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "Core motion system, Micro-controller code" +msgstr "" + +#: docs/CONTRIBUTING.md:block 24 (paragraph) +msgid "" +"Please do not \"ping\" any of the reviewers and please do not direct " +"submissions at them. All of the reviewers monitor the forums and PRs, and " +"will take on reviews when they have time to." +msgstr "" + +#: docs/CONTRIBUTING.md:block 25 (paragraph) +msgid "The Klipper \"maintainers\" are:" +msgstr "" + +#: docs/CONTRIBUTING.md:block 26 (table) +msgid "GitHub name" +msgstr "" + +#: docs/CONTRIBUTING.md:block 27 (header) +msgid "Format of commit messages" +msgstr "" + +#: docs/CONTRIBUTING.md:block 28 (paragraph) +msgid "" +"Each commit should have a commit message formatted similar to the following:" +msgstr "" + +#: docs/CONTRIBUTING.md:block 30 (paragraph) +msgid "" +"In the above example, `module` should be the name of a file or directory in " +"the repository (without a file extension). For example, `clocksync: Fix typo" +" in pause() call at connect time`. The purpose of specifying a module name " +"in the commit message is to help provide context for the commit comments." +msgstr "" + +#: docs/CONTRIBUTING.md:block 33 (paragraph) +msgid "" +"[Klipper-translations Project](https://github.com/Klipper3d/klipper-" +"translations) is a project dedicated to translating Klipper to different " +"languages. [Weblate](https://hosted.weblate.org/projects/klipper/) hosts all" +" the Gettext strings for translating and reviewing. Locales can be displayed" +" on [klipper3d.org](https://www.klipper3d.org) once they satisfy the " +"following requirements:" +msgstr "" + +#: docs/CONTRIBUTING.md:block 34 (unordered list) +msgid "All titles (H1) are translated" +msgstr "" + +#: docs/CONTRIBUTING.md:block 37 (paragraph) +msgid "Once the requirements are met, you need to:" +msgstr "" + +#: docs/CONTRIBUTING.md:block 38 (ordered list) +msgid "" +"update klipper-tranlations repository " +"[active_translations](https://github.com/Klipper3d/klipper-" +"translations/blob/translations/active_translations)" +msgstr "" + +#: docs/CONTRIBUTING.md:block 38 (ordered list) +msgid "" +"Optional: add a manual-index.md file in klipper-translations repository's " +"`docs\\locals\\` folder to replace the language specific index.md " +"(generated index.md does not render correctly)." +msgstr "" + +#: docs/CONTRIBUTING.md:block 39 (paragraph) +msgid "Known Issues:" +msgstr "" + +#: docs/CONTRIBUTING.md:block 40 (ordered list) +msgid "" +"Currently, there isn't a method for correctly translating pictures in the " +"documentation" +msgstr "" + +#: docs/CONTRIBUTING.md:block 40 (ordered list) +msgid "It is impossible to translate titles in mkdocs.yml." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"When discussing benefits it is preferable to discuss \"facts and " +"measurements\". In general, reviewers are not looking for responses of the " +"form \"someone may find option X useful\", nor are they looking for " +"responses of the form \"this submission adds a feature that firmware X " +"implements\". Instead, it is generally preferable to discuss details on how " +"the quality improvement was measured and what were the results of those " +"measurements - for example, \"tests on Acme X1000 printers show improved " +"corners as seen in picture ...\", or for example \"print time of real-world " +"object X on a Foomatic X900 printer went from 4 hours to 3.5 hours\". It is " +"understood that testing of this type can take significant time and effort. " +"Some of Klipper's most notable features took months of discussion, rework, " +"testing, and documentation prior to being merged into the master branch." +msgstr "" + +#: docs/CONTRIBUTING.md:block 13 (ordered list) +msgid "" +"When fixing a defect in the code, submitters should have a general " +"understanding of the root cause of that defect, and the fix should target " +"that root cause." +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "James Hartley" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "@JamesH1978" +msgstr "" + +#: docs/CONTRIBUTING.md:block 23 (table) +msgid "Configuration files" +msgstr "" + +#~ msgid "Paul McGowan" +#~ msgstr "" + +#~ msgid "@mental405" +#~ msgstr "" + +#~ msgid "Configuration files, documentation" +#~ msgstr "" + +#~ msgid "" +#~ "When discussing benefits it is preferable to discuss \"facts and " +#~ "measurements\" instead of \"opinions and theories\". In general, reviewers " +#~ "are not looking for responses of the form \"this submission may improve " +#~ "quality because of ...\", nor are they looking for responses of the form " +#~ "\"someone may find option X useful\", nor are they looking for responses of " +#~ "the form \"this submission adds a feature that firmware X implements\". " +#~ "Instead, it is generally preferable to discuss details on how the quality " +#~ "improvement was measured and what were the results of those measurements - " +#~ "for example, \"tests on Acme X1000 printers show improved corners as seen in" +#~ " picture ...\", or for example \"print time of real-world object X on a " +#~ "Foomatic X900 printer went from 4 hours to 3.5 hours\". It is understood " +#~ "that testing of this type can take significant time and effort. Some of " +#~ "Klipper's most notable features took years of discussion, rework, testing, " +#~ "and documentation prior to being merged into the master branch." +#~ msgstr "" + +#~ msgid "" +#~ "[Klipper-translations Project](https://github.com/Klipper3d/klipper-" +#~ "translations) is a project dedicated to translating Klipper to different " +#~ "languages. [Weblate](https://hosted.weblate.org/projects/klipper/) hosts all" +#~ " the Gettext strings for translating and reviewing. Locales can merge into " +#~ "the Klipper project once they satisfy the following requirements:" +#~ msgstr "" + +#~ msgid "All titles (H1) are covered" +#~ msgstr "" + +#~ msgid "The navigation hierarchy is in `docs\\_klipper3d\\mkdocs.yml`." +#~ msgstr "" + +#~ msgid "" +#~ "Please follow the following format for `mkdocs.yml` navigation hierarchy:" +#~ msgstr "" + +#~ msgid "" +#~ "nav:\n" +#~ " - existing hierachy\n" +#~ " - :\n" +#~ " - locales//md file\n" +#~ msgstr "" + +#~ msgid "" +#~ "Note: Currently, there isn't a method for correctly translating pictures in " +#~ "the documentation." +#~ msgstr "" + +#~ msgid "" +#~ "Thank you for contributing to Klipper! Please take a moment to read this " +#~ "document." +#~ msgstr "" + +#~ msgid "Creating a new issue" +#~ msgstr "" + +#~ msgid "" +#~ "Please see the [contact page](Contact.md) for information on creating an " +#~ "issue." +#~ msgstr "" + +#~ msgid "Submitting a pull request" +#~ msgstr "" + +#~ msgid "" +#~ "Contributions of Code and documentation are managed through github pull " +#~ "requests. Each commit should have a commit message formatted similar to the " +#~ "following:" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Code_Overview.po b/docs/locales/lt/LC_MESSAGES/Code_Overview.po new file mode 100644 index 0000000000..097c7b3d7f --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Code_Overview.po @@ -0,0 +1,832 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"This document describes the overall code layout and major code flow of " +"Klipper." +msgstr "" + +msgid "Directory Layout" +msgstr "" + +msgid "" +"The **src/** directory contains the C source for the micro-controller code. " +"The **src/atsam/**, **src/atsamd/**, **src/avr/**, **src/linux/**, " +"**src/lpc176x/**, **src/pru/**, and **src/stm32/** directories contain " +"architecture specific micro-controller code. The **src/simulator/** contains" +" code stubs that allow the micro-controller to be test compiled on other " +"architectures. The **src/generic/** directory contains helper code that may " +"be useful across different architectures. The build arranges for includes of" +" \"board/somefile.h\" to first look in the current architecture directory " +"(eg, src/avr/somefile.h) and then in the generic directory (eg, " +"src/generic/somefile.h)." +msgstr "" + +msgid "" +"The **klippy/** directory contains the host software. Most of the host " +"software is written in Python, however the **klippy/chelper/** directory " +"contains some C code helpers. The **klippy/kinematics/** directory contains " +"the robot kinematics code. The **klippy/extras/** directory contains the " +"host code extensible \"modules\"." +msgstr "" + +msgid "" +"The **lib/** directory contains external 3rd-party library code that is " +"necessary to build some targets." +msgstr "" + +msgid "" +"The **config/** directory contains example printer configuration files." +msgstr "" + +msgid "" +"The **scripts/** directory contains build-time scripts useful for compiling " +"the micro-controller code." +msgstr "" + +msgid "The **test/** directory contains automated test cases." +msgstr "" + +msgid "" +"During compilation, the build may create an **out/** directory. This " +"contains temporary build time objects. The final micro-controller object " +"that is built is **out/klipper.elf.hex** on AVR and **out/klipper.bin** on " +"ARM." +msgstr "" + +msgid "Micro-controller code flow" +msgstr "" + +msgid "" +"Execution of the micro-controller code starts in architecture specific code " +"(eg, **src/avr/main.c**) which ultimately calls sched_main() located in " +"**src/sched.c**. The sched_main() code starts by running all functions that " +"have been tagged with the DECL_INIT() macro. It then goes on to repeatedly " +"run all functions tagged with the DECL_TASK() macro." +msgstr "" + +msgid "" +"One of the main task functions is command_dispatch() located in " +"**src/command.c**. This function is called from the board specific " +"input/output code (eg, **src/avr/serial.c**, **src/generic/serial_irq.c**) " +"and it runs the command functions associated with the commands found in the " +"input stream. Command functions are declared using the DECL_COMMAND() macro " +"(see the [protocol](Protocol.md) document for more information)." +msgstr "" + +msgid "" +"Timer functions are scheduled by calling sched_add_timer() (located in " +"**src/sched.c**). The scheduler code will arrange for the given function to " +"be called at the requested clock time. Timer interrupts are initially " +"handled in an architecture specific interrupt handler (eg, " +"**src/avr/timer.c**) which calls sched_timer_dispatch() located in " +"**src/sched.c**. The timer interrupt leads to execution of schedule timer " +"functions. Timer functions always run with interrupts disabled. The timer " +"functions should always complete within a few micro-seconds. At completion " +"of the timer event, the function may choose to reschedule itself." +msgstr "" + +msgid "" +"In the event an error is detected the code can invoke shutdown() (a macro " +"which calls sched_shutdown() located in **src/sched.c**). Invoking " +"shutdown() causes all functions tagged with the DECL_SHUTDOWN() macro to be " +"run. Shutdown functions always run with interrupts disabled." +msgstr "" + +msgid "" +"Much of the functionality of the micro-controller involves working with " +"General-Purpose Input/Output pins (GPIO). In order to abstract the low-level" +" architecture specific code from the high-level task code, all GPIO events " +"are implemented in architecture specific wrappers (eg, **src/avr/gpio.c**). " +"The code is compiled with gcc's \"-flto -fwhole-program\" optimization which" +" does an excellent job of inlining functions across compilation units, so " +"most of these tiny gpio functions are inlined into their callers, and there " +"is no run-time cost to using them." +msgstr "" + +msgid "Klippy code overview" +msgstr "" + +msgid "" +"The host code (Klippy) is intended to run on a low-cost computer (such as a " +"Raspberry Pi) paired with the micro-controller. The code is primarily " +"written in Python, however it does use CFFI to implement some functionality " +"in C code." +msgstr "" + +msgid "" +"Initial execution starts in **klippy/klippy.py**. This reads the command-" +"line arguments, opens the printer config file, instantiates the main printer" +" objects, and starts the serial connection. The main execution of G-code " +"commands is in the process_commands() method in **klippy/gcode.py**. This " +"code translates the G-code commands into printer object calls, which " +"frequently translate the actions to commands to be executed on the micro-" +"controller (as declared via the DECL_COMMAND macro in the micro-controller " +"code)." +msgstr "" + +msgid "" +"There are four threads in the Klippy host code. The main thread handles " +"incoming gcode commands. A second thread (which resides entirely in the " +"**klippy/chelper/serialqueue.c** C code) handles low-level IO with the " +"serial port. The third thread is used to process response messages from the " +"micro-controller in the Python code (see **klippy/serialhdl.py**). The " +"fourth thread writes debug messages to the log (see " +"**klippy/queuelogger.py**) so that the other threads never block on log " +"writes." +msgstr "" + +msgid "Code flow of a move command" +msgstr "" + +msgid "" +"A typical printer movement starts when a \"G1\" command is sent to the " +"Klippy host and it completes when the corresponding step pulses are produced" +" on the micro-controller. This section outlines the code flow of a typical " +"move command. The [kinematics](Kinematics.md) document provides further " +"information on the mechanics of moves." +msgstr "" + +msgid "" +"Processing for a move command starts in gcode.py. The goal of gcode.py is to" +" translate G-code into internal calls. A G1 command will invoke cmd_G1() in " +"klippy/extras/gcode_move.py. The gcode_move.py code handles changes in " +"origin (eg, G92), changes in relative vs absolute positions (eg, G90), and " +"unit changes (eg, F6000=100mm/s). The code path for a move is: " +"`_process_data() -> _process_commands() -> cmd_G1()`. Ultimately the " +"ToolHead class is invoked to execute the actual request: `cmd_G1() -> " +"ToolHead.move()`" +msgstr "" + +msgid "" +"The ToolHead class (in toolhead.py) handles \"look-ahead\" and tracks the " +"timing of printing actions. The main codepath for a move is: " +"`ToolHead.move() -> MoveQueue.add_move() -> MoveQueue.flush() -> " +"Move.set_junction() -> ToolHead._process_moves()`." +msgstr "" + +msgid "" +"ToolHead.move() creates a Move() object with the parameters of the move (in " +"cartesian space and in units of seconds and millimeters)." +msgstr "" + +msgid "" +"The kinematics class is given the opportunity to audit each move " +"(`ToolHead.move() -> kin.check_move()`). The kinematics classes are located " +"in the klippy/kinematics/ directory. The check_move() code may raise an " +"error if the move is not valid. If check_move() completes successfully then " +"the underlying kinematics must be able to handle the move." +msgstr "" + +msgid "MoveQueue.add_move() places the move object on the \"look-ahead\" queue." +msgstr "" + +msgid "" +"MoveQueue.flush() determines the start and end velocities of each move." +msgstr "" + +msgid "" +"Move.set_junction() implements the \"trapezoid generator\" on a move. The " +"\"trapezoid generator\" breaks every move into three parts: a constant " +"acceleration phase, followed by a constant velocity phase, followed by a " +"constant deceleration phase. Every move contains these three phases in this " +"order, but some phases may be of zero duration." +msgstr "" + +msgid "" +"When ToolHead._process_moves() is called, everything about the move is known" +" - its start location, its end location, its acceleration, its " +"start/cruising/end velocity, and distance traveled during " +"acceleration/cruising/deceleration. All the information is stored in the " +"Move() class and is in cartesian space in units of millimeters and seconds." +msgstr "" + +msgid "" +"Klipper uses an [iterative solver](https://en.wikipedia.org/wiki/Root-" +"finding_algorithm) to generate the step times for each stepper. For " +"efficiency reasons, the stepper pulse times are generated in C code. The " +"moves are first placed on a \"trapezoid motion queue\": " +"`ToolHead._process_moves() -> trapq_append()` (in klippy/chelper/trapq.c). " +"The step times are then generated: `ToolHead._process_moves() -> " +"ToolHead._update_move_time() -> MCU_Stepper.generate_steps() -> " +"itersolve_generate_steps() -> itersolve_gen_steps_range()` (in " +"klippy/chelper/itersolve.c). The goal of the iterative solver is to find " +"step times given a function that calculates a stepper position from a time. " +"This is done by repeatedly \"guessing\" various times until the stepper " +"position formula returns the desired position of the next step on the " +"stepper. The feedback produced from each guess is used to improve future " +"guesses so that the process rapidly converges to the desired time. The " +"kinematic stepper position formulas are located in the klippy/chelper/ " +"directory (eg, kin_cart.c, kin_corexy.c, kin_delta.c, kin_extruder.c)." +msgstr "" + +msgid "" +"Note that the extruder is handled in its own kinematic class: " +"`ToolHead._process_moves() -> PrinterExtruder.move()`. Since the Move() " +"class specifies the exact movement time and since step pulses are sent to " +"the micro-controller with specific timing, stepper movements produced by the" +" extruder class will be in sync with head movement even though the code is " +"kept separate." +msgstr "" + +msgid "" +"After the iterative solver calculates the step times they are added to an " +"array: `itersolve_gen_steps_range() -> stepcompress_append()` (in " +"klippy/chelper/stepcompress.c). The array (struct stepcompress.queue) stores" +" the corresponding micro-controller clock counter times for every step. Here" +" the \"micro-controller clock counter\" value directly corresponds to the " +"micro-controller's hardware counter - it is relative to when the micro-" +"controller was last powered up." +msgstr "" + +msgid "" +"The next major step is to compress the steps: `stepcompress_flush() -> " +"compress_bisect_add()` (in klippy/chelper/stepcompress.c). This code " +"generates and encodes a series of micro-controller \"queue_step\" commands " +"that correspond to the list of stepper step times built in the previous " +"stage. These \"queue_step\" commands are then queued, prioritized, and sent " +"to the micro-controller (via stepcompress.c:steppersync and " +"serialqueue.c:serialqueue)." +msgstr "" + +msgid "" +"Processing of the queue_step commands on the micro-controller starts in " +"src/command.c which parses the command and calls `command_queue_step()`. The" +" command_queue_step() code (in src/stepper.c) just appends the parameters of" +" each queue_step command to a per stepper queue. Under normal operation the " +"queue_step command is parsed and queued at least 100ms before the time of " +"its first step. Finally, the generation of stepper events is done in " +"`stepper_event()`. It's called from the hardware timer interrupt at the " +"scheduled time of the first step. The stepper_event() code generates a step " +"pulse and then reschedules itself to run at the time of the next step pulse " +"for the given queue_step parameters. The parameters for each queue_step " +"command are \"interval\", \"count\", and \"add\". At a high-level, " +"stepper_event() runs the following, 'count' times: `do_step(); " +"next_wake_time = last_wake_time + interval; interval += add;`" +msgstr "" + +msgid "" +"The above may seem like a lot of complexity to execute a movement. However, " +"the only really interesting parts are in the ToolHead and kinematic classes." +" It's this part of the code which specifies the movements and their timings." +" The remaining parts of the processing is mostly just communication and " +"plumbing." +msgstr "" + +msgid "Adding a host module" +msgstr "" + +msgid "" +"The Klippy host code has a dynamic module loading capability. If a config " +"section named \"[my_module]\" is found in the printer config file then the " +"software will automatically attempt to load the python module " +"klippy/extras/my_module.py . This module system is the preferred method for " +"adding new functionality to Klipper." +msgstr "" + +msgid "" +"The easiest way to add a new module is to use an existing module as a " +"reference - see **klippy/extras/servo.py** as an example." +msgstr "" + +msgid "The following may also be useful:" +msgstr "" + +msgid "" +"Execution of the module starts in the module level `load_config()` function " +"(for config sections of the form [my_module]) or in `load_config_prefix()` " +"(for config sections of the form [my_module my_name]). This function is " +"passed a \"config\" object and it must return a new \"printer object\" " +"associated with the given config section." +msgstr "" + +msgid "" +"During the process of instantiating a new printer object, the config object " +"can be used to read parameters from the given config section. This is done " +"using `config.get()`, `config.getfloat()`, `config.getint()`, etc. methods. " +"Be sure to read all values from the config during the construction of the " +"printer object - if the user specifies a config parameter that is not read " +"during this phase then it will be assumed it is a typo in the config and an " +"error will be raised." +msgstr "" + +msgid "" +"Use the `config.get_printer()` method to obtain a reference to the main " +"\"printer\" class. This \"printer\" class stores references to all the " +"\"printer objects\" that have been instantiated. Use the " +"`printer.lookup_object()` method to find references to other printer " +"objects. Almost all functionality (even core kinematic modules) are " +"encapsulated in one of these printer objects. Note, though, that when a new " +"module is instantiated, not all other printer objects will have been " +"instantiated. The \"gcode\" and \"pins\" modules will always be available, " +"but for other modules it is a good idea to defer the lookup." +msgstr "" + +msgid "" +"Register event handlers using the `printer.register_event_handler()` method " +"if the code needs to be called during \"events\" raised by other printer " +"objects. Each event name is a string, and by convention it is the name of " +"the main source module that raises the event along with a short name for the" +" action that is occurring (eg, \"klippy:connect\"). The parameters passed to" +" each event handler are specific to the given event (as are exception " +"handling and execution context). Two common startup events are:" +msgstr "" + +msgid "" +"klippy:connect - This event is generated after all printer objects are " +"instantiated. It is commonly used to lookup other printer objects, to verify" +" config settings, and to perform an initial \"handshake\" with printer " +"hardware." +msgstr "" + +msgid "" +"klippy:ready - This event is generated after all connect handlers have " +"completed successfully. It indicates the printer is transitioning to a state" +" ready to handle normal operations. Do not raise an error in this callback." +msgstr "" + +msgid "" +"If there is an error in the user's config, be sure to raise it during the " +"`load_config()` or \"connect event\" phases. Use either `raise " +"config.error(\"my error\")` or `raise printer.config_error(\"my error\")` to" +" report the error." +msgstr "" + +msgid "" +"Use the \"pins\" module to configure a pin on a micro-controller. This is " +"typically done with something similar to " +"`printer.lookup_object(\"pins\").setup_pin(\"pwm\", " +"config.get(\"my_pin\"))`. The returned object can then be commanded at run-" +"time." +msgstr "" + +msgid "" +"If the module needs access to system timing or external file descriptors " +"then use `printer.get_reactor()` to obtain access to the global \"event " +"reactor\" class. This reactor class allows one to schedule timers, wait for " +"input on file descriptors, and to \"sleep\" the host code." +msgstr "" + +msgid "" +"Do not use global variables. All state should be stored in the printer " +"object returned from the `load_config()` function. This is important as " +"otherwise the RESTART command may not perform as expected. Also, for similar" +" reasons, if any external files (or sockets) are opened then be sure to " +"register a \"klippy:disconnect\" event handler and close them from that " +"callback." +msgstr "" + +msgid "" +"Avoid accessing the internal member variables (or calling methods that start" +" with an underscore) of other printer objects. Observing this convention " +"makes it easier to manage future changes." +msgstr "" + +msgid "" +"If submitting the module for inclusion in the main Klipper code, be sure to " +"place a copyright notice at the top of the module. See the existing modules " +"for the preferred format." +msgstr "" + +msgid "Adding new kinematics" +msgstr "" + +msgid "" +"This section provides some tips on adding support to Klipper for additional " +"types of printer kinematics. This type of activity requires excellent " +"understanding of the math formulas for the target kinematics. It also " +"requires software development skills - though one should only need to update" +" the host software." +msgstr "" + +msgid "Useful steps:" +msgstr "" + +msgid "" +"Start by studying the \"[code flow of a move](#code-flow-of-a-move-" +"command)\" section and the [Kinematics document](Kinematics.md)." +msgstr "" + +msgid "" +"Review the existing kinematic classes in the klippy/kinematics/ directory. " +"The kinematic classes are tasked with converting a move in cartesian " +"coordinates to the movement on each stepper. One should be able to copy one " +"of these files as a starting point." +msgstr "" + +msgid "" +"Implement the C stepper kinematic position functions for each stepper if " +"they are not already available (see kin_cart.c, kin_corexy.c, and " +"kin_delta.c in klippy/chelper/). The function should call `move_get_coord()`" +" to convert a given move time (in seconds) to a cartesian coordinate (in " +"millimeters), and then calculate the desired stepper position (in " +"millimeters) from that cartesian coordinate." +msgstr "" + +msgid "" +"Implement the `calc_position()` method in the new kinematics class. This " +"method calculates the position of the toolhead in cartesian coordinates from" +" the position of each stepper. It does not need to be efficient as it is " +"typically only called during homing and probing operations." +msgstr "" + +msgid "" +"Other methods. Implement the `check_move()`, `get_status()`, " +"`get_steppers()`, `home()`, and `set_position()` methods. These functions " +"are typically used to provide kinematic specific checks. However, at the " +"start of development one can use boiler-plate code here." +msgstr "" + +msgid "" +"Implement test cases. Create a g-code file with a series of moves that can " +"test important cases for the given kinematics. Follow the [debugging " +"documentation](Debugging.md) to convert this g-code file to micro-controller" +" commands. This is useful to exercise corner cases and to check for " +"regressions." +msgstr "" + +msgid "Porting to a new micro-controller" +msgstr "" + +msgid "" +"This section provides some tips on porting Klipper's micro-controller code " +"to a new architecture. This type of activity requires good knowledge of " +"embedded development and hands-on access to the target micro-controller." +msgstr "" + +msgid "" +"Start by identifying any 3rd party libraries that will be used during the " +"port. Common examples include \"CMSIS\" wrappers and manufacturer \"HAL\" " +"libraries. All 3rd party code needs to be GNU GPLv3 compatible. The 3rd " +"party code should be committed to the Klipper lib/ directory. Update the " +"lib/README file with information on where and when the library was obtained." +" It is preferable to copy the code into the Klipper repository unchanged, " +"but if any changes are required then those changes should be listed " +"explicitly in the lib/README file." +msgstr "" + +msgid "" +"Create a new architecture sub-directory in the src/ directory and add " +"initial Kconfig and Makefile support. Use the existing architectures as a " +"guide. The src/simulator provides a basic example of a minimum starting " +"point." +msgstr "" + +msgid "" +"Get familiar with the the console.py tool (as described in the [debugging " +"document](Debugging.md)) and verify connectivity to the micro-controller " +"with it. This tool translates the low-level micro-controller communication " +"protocol to a human readable form." +msgstr "" + +msgid "" +"Create a sample Klipper config file in the config/ directory. Test the " +"micro-controller with the main klippy.py program." +msgstr "" + +msgid "Consider adding build test cases in the test/ directory." +msgstr "" + +msgid "Coordinate Systems" +msgstr "" + +msgid "" +"Internally, Klipper primarily tracks the position of the toolhead in " +"cartesian coordinates that are relative to the coordinate system specified " +"in the config file. That is, most of the Klipper code will never experience " +"a change in coordinate systems. If the user makes a request to change the " +"origin (eg, a `G92` command) then that effect is obtained by translating " +"future commands to the primary coordinate system." +msgstr "" + +msgid "" +"However, in some cases it is useful to obtain the toolhead position in some " +"other coordinate system and Klipper has several tools to facilitate that. " +"This can be seen by running the GET_POSITION command. For example:" +msgstr "" + +msgid "" +"The \"stepper\" position (`stepper.get_commanded_position()`) is the " +"position of the given stepper as tracked by the kinematics code. This " +"generally corresponds to the position (in mm) of the carriage along its " +"rail, relative to the position_endstop specified in the config file. (Some " +"kinematics track stepper positions in radians instead of millimeters.) If " +"the robot is in motion when the query is issued then the reported value " +"includes moves buffered on the micro-controller, but does not include moves " +"on the look-ahead queue. One may use the `toolhead.flush_step_generation()` " +"or `toolhead.wait_moves()` calls to fully flush the look-ahead and step " +"generation code." +msgstr "" + +msgid "" +"The \"kinematic\" position (`kin.calc_position()`) is the cartesian position" +" of the toolhead as derived from \"stepper\" positions and is relative to " +"the coordinate system specified in the config file. This may differ from the" +" requested cartesian position due to the granularity of the stepper motors. " +"If the robot is in motion when the \"stepper\" positions are taken then the " +"reported value includes moves buffered on the micro-controller, but does not" +" include moves on the look-ahead queue. One may use the " +"`toolhead.flush_step_generation()` or `toolhead.wait_moves()` calls to fully" +" flush the look-ahead and step generation code." +msgstr "" + +msgid "" +"The \"toolhead\" position (`toolhead.get_position()`) is the last requested " +"position of the toolhead in cartesian coordinates relative to the coordinate" +" system specified in the config file. If the robot is in motion when the " +"query is issued then the reported value includes all requested moves (even " +"those in buffers waiting to be issued to the stepper motor drivers)." +msgstr "" + +msgid "" +"The \"gcode\" position is the last requested position from a `G1` (or `G0`) " +"command in cartesian coordinates relative to the coordinate system specified" +" in the config file. This may differ from the \"toolhead\" position if a " +"g-code transformation (eg, bed_mesh, bed_tilt, skew_correction) is in " +"effect. This may differ from the actual coordinates specified in the last " +"`G1` command if the g-code origin has been changed (eg, `G92`, " +"`SET_GCODE_OFFSET`, `M221`). The `M114` command " +"(`gcode_move.get_status()['gcode_position']`) will report the last g-code " +"position relative to the current g-code coordinate system." +msgstr "" + +msgid "" +"The \"gcode base\" is the location of the g-code origin in cartesian " +"coordinates relative to the coordinate system specified in the config file. " +"Commands such as `G92`, `SET_GCODE_OFFSET`, and `M221` alter this value." +msgstr "" + +msgid "" +"The \"gcode homing\" is the location to use for the g-code origin (in " +"cartesian coordinates relative to the coordinate system specified in the " +"config file) after a `G28` home command. The `SET_GCODE_OFFSET` command can " +"alter this value." +msgstr "" + +msgid "Time" +msgstr "" + +msgid "" +"Fundamental to the operation of Klipper is the handling of clocks, times, " +"and timestamps. Klipper executes actions on the printer by scheduling events" +" to occur in the near future. For example, to turn on a fan, the code might " +"schedule a change to a GPIO pin in a 100ms. It is rare for the code to " +"attempt to take an instantaneous action. Thus, the handling of time within " +"Klipper is critical to correct operation." +msgstr "" + +msgid "" +"There are three types of times tracked internally in the Klipper host " +"software:" +msgstr "" + +msgid "" +"System time. The system time uses the system's monotonic clock - it is a " +"floating point number stored as seconds and it is (generally) relative to " +"when the host computer was last started. System times have limited use in " +"the software - they are primarily used when interacting with the operating " +"system. Within the host code, system times are frequently stored in " +"variables named *eventtime* or *curtime*." +msgstr "" + +msgid "" +"Print time. The print time is synchronized to the main micro-controller " +"clock (the micro-controller defined in the \"[mcu]\" config section). It is " +"a floating point number stored as seconds and is relative to when the main " +"mcu was last restarted. It is possible to convert from a \"print time\" to " +"the main micro-controller's hardware clock by multiplying the print time by " +"the mcu's statically configured frequency rate. The high-level host code " +"uses print times to calculate almost all physical actions (eg, head " +"movement, heater changes, etc.). Within the host code, print times are " +"generally stored in variables named *print_time* or *move_time*." +msgstr "" + +msgid "" +"MCU clock. This is the hardware clock counter on each micro-controller. It " +"is stored as an integer and its update rate is relative to the frequency of " +"the given micro-controller. The host software translates its internal times " +"to clocks before transmission to the mcu. The mcu code only ever tracks time" +" in clock ticks. Within the host code, clock values are tracked as 64bit " +"integers, while the mcu code uses 32bit integers. Within the host code, " +"clocks are generally stored in variables with names containing *clock* or " +"*ticks*." +msgstr "" + +msgid "" +"Conversion between the different time formats is primarily implemented in " +"the **klippy/clocksync.py** code." +msgstr "" + +msgid "Some things to be aware of when reviewing the code:" +msgstr "" + +msgid "" +"32bit and 64bit clocks: To reduce bandwidth and to improve micro-controller " +"efficiency, clocks on the micro-controller are tracked as 32bit integers. " +"When comparing two clocks in the mcu code, the `timer_is_before()` function " +"must always be used to ensure integer rollovers are handled properly. The " +"host software converts 32bit clocks to 64bit clocks by appending the high-" +"order bits from the last mcu timestamp it has received - no message from the" +" mcu is ever more than 2^31 clock ticks in the future or past so this " +"conversion is never ambiguous. The host converts from 64bit clocks to 32bit " +"clocks by simply truncating the high-order bits. To ensure there is no " +"ambiguity in this conversion, the **klippy/chelper/serialqueue.c** code will" +" buffer messages until they are within 2^31 clock ticks of their target " +"time." +msgstr "" + +msgid "" +"Multiple micro-controllers: The host software supports using multiple micro-" +"controllers on a single printer. In this case, the \"MCU clock\" of each " +"micro-controller is tracked separately. The clocksync.py code handles clock " +"drift between micro-controllers by modifying the way it converts from " +"\"print time\" to \"MCU clock\". On secondary mcus, the mcu frequency that " +"is used in this conversion is regularly updated to account for measured " +"drift." +msgstr "" + +msgid "" +"Send: GET_POSITION\n" +"Recv: // mcu: stepper_a:-2060 stepper_b:-1169 stepper_c:-1613\n" +"Recv: // stepper: stepper_a:457.254159 stepper_b:466.085669 stepper_c:465.382132\n" +"Recv: // kinematic: X:8.339144 Y:-3.131558 Z:233.347121\n" +"Recv: // toolhead: X:8.338078 Y:-3.123175 Z:233.347878 E:0.000000\n" +"Recv: // gcode: X:8.338078 Y:-3.123175 Z:233.347878 E:0.000000\n" +"Recv: // gcode base: X:0.000000 Y:0.000000 Z:0.000000 E:0.000000\n" +"Recv: // gcode homing: X:0.000000 Y:0.000000 Z:0.000000\n" +msgstr "" + +#: docs/Code_Overview.md:block 1 (header) +msgid "Code overview" +msgstr "" + +#: docs/Code_Overview.md:block 43 (paragraph) +msgid "" +"The \"mcu\" position (`stepper.get_mcu_position()` in the code) is the total" +" number of steps the micro-controller has issued in a positive direction " +"minus the number of steps issued in a negative direction since the micro-" +"controller was last reset. If the robot is in motion when the query is " +"issued then the reported value includes moves buffered on the micro-" +"controller, but does not include moves on the look-ahead queue." +msgstr "" + +#: docs/Code_Overview.md:block 38 (ordered list) +msgid "" +"Add support for timer dispatch from hardware interrupts. See Klipper [commit" +" " +"970831ee](https://github.com/Klipper3d/klipper/commit/970831ee0d3b91897196e92270d98b2a3067427f)" +" as an example of steps 1-5 done for the LPC176x architecture." +msgstr "" + +#: docs/Code_Overview.md:block 38 (ordered list) +msgid "" +"Bring up basic GPIO input and output support. See Klipper [commit " +"c78b9076](https://github.com/Klipper3d/klipper/commit/c78b90767f19c9e8510c3155b89fb7ad64ca3c54)" +" as an example of this." +msgstr "" + +#: docs/Code_Overview.md:block 38 (ordered list) +msgid "" +"Bring up additional peripherals - for example see Klipper commit " +"[65613aed](https://github.com/Klipper3d/klipper/commit/65613aeddfb9ef86905cb1dade9e773a02ef3c27)," +" " +"[c812a40a](https://github.com/Klipper3d/klipper/commit/c812a40a3782415e454b04bf7bd2158a6f0ec8b5)," +" and " +"[c381d03a](https://github.com/Klipper3d/klipper/commit/c381d03aad5c3ee761169b7c7bced519cc14da29)." +msgstr "" + +#: docs/Code_Overview.md:block 30 (unordered list) +msgid "" +"If the printer object defines a `get_status()` method then the module can " +"export [status information](Status_Reference.md) via " +"[macros](Command_Templates.md) and via the [API Server](API_Server.md). The " +"`get_status()` method must return a Python dictionary with keys that are " +"strings and values that are integers, floats, strings, lists, dictionaries, " +"True, False, or None. Tuples (and named tuples) may also be used (these " +"appear as lists when accessed via the API Server). Lists and dictionaries " +"that are exported must be treated as \"immutable\" - if their contents " +"change then a new object must be returned from `get_status()`, otherwise the" +" API Server will not detect those changes." +msgstr "" + +#: docs/Code_Overview.md:block 30 (unordered list) +msgid "" +"It is recommended to assign a value to all member variables in the Python " +"constructor of Python classes. (And therefore avoid utilizing Python's " +"ability to dynamically create new member variables.)" +msgstr "" + +#: docs/Code_Overview.md:block 30 (unordered list) +msgid "" +"If a Python variable is to store a floating point value then it is " +"recommended to always assign and manipulate that variable with floating " +"point constants (and never use integer constants). For example, prefer " +"`self.speed = 1.` over `self.speed = 1`, and prefer `self.speed = 2. * x` " +"over `self.speed = 2 * x`. Consistent use of floating point values can avoid" +" hard to debug quirks in Python type conversions." +msgstr "" + +#: docs/Code_Overview.md:block 38 (ordered list) +msgid "" +"The first main coding task is to bring up communication support to the " +"target board. This is the most difficult step in a new port. Once basic " +"communication is working, the remaining steps tend to be much easier. It is " +"typical to use a UART type serial device during initial development as these" +" types of hardware devices are generally easier to enable and control. " +"During this phase, make liberal use of helper code from the src/generic/ " +"directory (check how src/simulator/Makefile includes the generic C code into" +" the build). It is also necessary to define timer_read_time() (which returns" +" the current system clock) in this phase, but it is not necessary to fully " +"support timer irq handling." +msgstr "" + +#: docs/Code_Overview.md:block 39 (paragraph) +msgid "Additional coding tips:" +msgstr "" + +#: docs/Code_Overview.md:block 40 (ordered list) +msgid "" +"Avoid using \"C bitfields\" to access IO registers; prefer direct read and " +"write operations of 32bit, 16bit, or 8bit integers. The C language " +"specifications don't clearly specify how the compiler must implement C " +"bitfields (eg, endianness, and bit layout), and it's difficult to determine " +"what IO operations will occur on a C bitfield read or write." +msgstr "" + +#: docs/Code_Overview.md:block 40 (ordered list) +msgid "" +"Prefer writing explicit values to IO registers instead of using read-modify-" +"write operations. That is, if updating a field in an IO register where the " +"other fields have known values, then it is preferable to explicitly write " +"the full contents of the register. Explicit writes produce code that is " +"smaller, faster, and easier to debug." +msgstr "" + +#: docs/Code_Overview.md:block 14 (paragraph) +msgid "" +"Task, init, and command functions always run with interrupts enabled " +"(however, they can temporarily disable interrupts if needed). These " +"functions should avoid long pauses, delays, or do work that lasts a " +"significant time. (Long delays in these \"task\" functions result in " +"scheduling jitter for other \"tasks\" - delays over 100us may become " +"noticeable, delays over 500us may result in command retransmissions, delays " +"over 100ms may result in watchdog reboots.) These functions schedule work at" +" specific times by scheduling timers." +msgstr "" + +#~ msgid "" +#~ "Task, init, and command functions always run with interrupts enabled " +#~ "(however, they can temporarily disable interrupts if needed). These " +#~ "functions should never pause, delay, or do any work that lasts more than a " +#~ "few micro-seconds. These functions schedule work at specific times by " +#~ "scheduling timers." +#~ msgstr "" + +#~ msgid "" +#~ "The first main coding task is to bring up communication support to the " +#~ "target board. This is the most difficult step in a new port. Once basic " +#~ "communication is working, the remaining steps tend to be much easier. It is " +#~ "typical to use an RS-232 style serial port during initial development as " +#~ "these types of hardware devices are generally easier to enable and control. " +#~ "During this phase, make liberal use of helper code from the src/generic/ " +#~ "directory (check how src/simulator/Makefile includes the generic C code into" +#~ " the build). It is also necessary to define timer_read_time() (which returns" +#~ " the current system clock) in this phase, but it is not necessary to fully " +#~ "support timer irq handling." +#~ msgstr "" + +#~ msgid "" +#~ "Add support for timer dispatch from hardware interrupts. See Klipper [commit" +#~ " " +#~ "970831ee](https://github.com/KevinOConnor/klipper/commit/970831ee0d3b91897196e92270d98b2a3067427f)" +#~ " as an example of steps 1-5 done for the LPC176x architecture." +#~ msgstr "" + +#~ msgid "" +#~ "Bring up basic GPIO input and output support. See Klipper [commit " +#~ "c78b9076](https://github.com/KevinOConnor/klipper/commit/c78b90767f19c9e8510c3155b89fb7ad64ca3c54)" +#~ " as an example of this." +#~ msgstr "" + +#~ msgid "" +#~ "Bring up additional peripherals - for example see Klipper commit " +#~ "[65613aed](https://github.com/KevinOConnor/klipper/commit/65613aeddfb9ef86905cb1dade9e773a02ef3c27)," +#~ " " +#~ "[c812a40a](https://github.com/KevinOConnor/klipper/commit/c812a40a3782415e454b04bf7bd2158a6f0ec8b5)," +#~ " and " +#~ "[c381d03a](https://github.com/KevinOConnor/klipper/commit/c381d03aad5c3ee761169b7c7bced519cc14da29)." +#~ msgstr "" + +#~ msgid "" +#~ "The \"mcu\" position (`stepper.get_mcu_position()` in the code) is the total" +#~ " number of steps the micro-controller has issued in a positive direction " +#~ "minus the number of steps issued in a negative direction since the micro-" +#~ "controller was last reset. The value reported is only valid after the " +#~ "stepper has been homed. If the robot is in motion when the query is issued " +#~ "then the reported value includes moves buffered on the micro-controller, but" +#~ " does not include moves on the look-ahead queue." +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Command_Templates.po b/docs/locales/lt/LC_MESSAGES/Command_Templates.po new file mode 100644 index 0000000000..5892ea38c0 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Command_Templates.po @@ -0,0 +1,511 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"This document provides information on implementing G-Code command sequences " +"in gcode_macro (and similar) config sections." +msgstr "" + +msgid "G-Code Macro Naming" +msgstr "" + +msgid "" +"Case is not important for the G-Code macro name - MY_MACRO and my_macro will" +" evaluate the same and may be called in either upper or lower case. If any " +"numbers are used in the macro name then they must all be at the end of the " +"name (eg, TEST_MACRO25 is valid, but MACRO25_TEST3 is not)." +msgstr "" + +msgid "Formatting of G-Code in the config" +msgstr "" + +msgid "" +"Indentation is important when defining a macro in the config file. To " +"specify a multi-line G-Code sequence it is important for each line to have " +"proper indentation. For example:" +msgstr "" + +msgid "" +"Note how the `gcode:` config option always starts at the beginning of the " +"line and subsequent lines in the G-Code macro never start at the beginning." +msgstr "" + +msgid "Add a description to your macro" +msgstr "" + +msgid "" +"To help identify the functionality a short description can be added. Add " +"`description:` with a short text to describe the functionality. Default is " +"\"G-Code macro\" if not specified. For example:" +msgstr "" + +msgid "Save/Restore state for G-Code moves" +msgstr "" + +msgid "" +"Unfortunately, the G-Code command language can be challenging to use. The " +"standard mechanism to move the toolhead is via the `G1` command (the `G0` " +"command is an alias for `G1` and it can be used interchangeably with it). " +"However, this command relies on the \"G-Code parsing state\" setup by `M82`," +" `M83`, `G90`, `G91`, `G92`, and previous `G1` commands. When creating a " +"G-Code macro it is a good idea to always explicitly set the G-Code parsing " +"state prior to issuing a `G1` command. (Otherwise, there is a risk the `G1` " +"command will make an undesirable request.)" +msgstr "" + +msgid "" +"A common way to accomplish that is to wrap the `G1` moves in " +"`SAVE_GCODE_STATE`, `G91`, and `RESTORE_GCODE_STATE`. For example:" +msgstr "" + +msgid "" +"The `G91` command places the G-Code parsing state into \"relative move " +"mode\" and the `RESTORE_GCODE_STATE` command restores the state to what it " +"was prior to entering the macro. Be sure to specify an explicit speed (via " +"the `F` parameter) on the first `G1` command." +msgstr "" + +msgid "Template expansion" +msgstr "" + +msgid "" +"The gcode_macro `gcode:` config section is evaluated using the Jinja2 " +"template language. One can evaluate expressions at run-time by wrapping them" +" in `{ }` characters or use conditional statements wrapped in `{% %}`. See " +"the [Jinja2 documentation](http://jinja.pocoo.org/docs/2.10/templates/) for " +"further information on the syntax." +msgstr "" + +msgid "An example of a complex macro:" +msgstr "" + +msgid "Macro parameters" +msgstr "" + +msgid "" +"It is often useful to inspect parameters passed to the macro when it is " +"called. These parameters are available via the `params` pseudo-variable. For" +" example, if the macro:" +msgstr "" + +msgid "" +"were invoked as `SET_PERCENT VALUE=.2` it would evaluate to `M117 Now at " +"20%`. Note that parameter names are always in upper-case when evaluated in " +"the macro and are always passed as strings. If performing math then they " +"must be explicitly converted to integers or floats." +msgstr "" + +msgid "" +"It's common to use the Jinja2 `set` directive to use a default parameter and" +" assign the result to a local name. For example:" +msgstr "" + +msgid "The \"printer\" Variable" +msgstr "" + +msgid "" +"It is possible to inspect (and alter) the current state of the printer via " +"the `printer` pseudo-variable. For example:" +msgstr "" + +msgid "" +"Available fields are defined in the [Status Reference](Status_Reference.md) " +"document." +msgstr "" + +msgid "" +"Important! Macros are first evaluated in entirety and only then are the " +"resulting commands executed. If a macro issues a command that alters the " +"state of the printer, the results of that state change will not be visible " +"during the evaluation of the macro. This can also result in subtle behavior " +"when a macro generates commands that call other macros, as the called macro " +"is evaluated when it is invoked (which is after the entire evaluation of the" +" calling macro)." +msgstr "" + +msgid "" +"By convention, the name immediately following `printer` is the name of a " +"config section. So, for example, `printer.fan` refers to the fan object " +"created by the `[fan]` config section. There are some exceptions to this " +"rule - notably the `gcode_move` and `toolhead` objects. If the config " +"section contains spaces in it, then one can access it via the `[ ]` accessor" +" - for example: `printer[\"generic_heater my_chamber_heater\"].temperature`." +msgstr "" + +msgid "" +"Note that the Jinja2 `set` directive can assign a local name to an object in" +" the `printer` hierarchy. This can make macros more readable and reduce " +"typing. For example:" +msgstr "" + +msgid "Actions" +msgstr "" + +msgid "" +"There are some commands available that can alter the state of the printer. " +"For example, `{ action_emergency_stop() }` would cause the printer to go " +"into a shutdown state. Note that these actions are taken at the time that " +"the macro is evaluated, which may be a significant amount of time before the" +" generated g-code commands are executed." +msgstr "" + +msgid "Available \"action\" commands:" +msgstr "" + +msgid "" +"`action_respond_info(msg)`: Write the given `msg` to the /tmp/printer " +"pseudo-terminal. Each line of `msg` will be sent with a \"// \" prefix." +msgstr "" + +msgid "" +"`action_raise_error(msg)`: Abort the current macro (and any calling macros) " +"and write the given `msg` to the /tmp/printer pseudo-terminal. The first " +"line of `msg` will be sent with a \"!! \" prefix and subsequent lines will " +"have a \"// \" prefix." +msgstr "" + +msgid "" +"`action_emergency_stop(msg)`: Transition the printer to a shutdown state. " +"The `msg` parameter is optional, it may be useful to describe the reason for" +" the shutdown." +msgstr "" + +msgid "" +"`action_call_remote_method(method_name)`: Calls a method registered by a " +"remote client. If the method takes parameters they should be provided via " +"keyword arguments, ie: `action_call_remote_method(\"print_stuff\", " +"my_arg=\"hello_world\")`" +msgstr "" + +msgid "Variables" +msgstr "" + +msgid "" +"The SET_GCODE_VARIABLE command may be useful for saving state between macro " +"calls. Variable names may not contain any upper case characters. For " +"example:" +msgstr "" + +msgid "" +"Be sure to take the timing of macro evaluation and command execution into " +"account when using SET_GCODE_VARIABLE." +msgstr "" + +msgid "Delayed Gcodes" +msgstr "" + +msgid "" +"The [delayed_gcode] configuration option can be used to execute a delayed " +"gcode sequence:" +msgstr "" + +msgid "" +"When the `load_filament` macro above executes, it will display a \"Load " +"Complete!\" message after the extrusion is finished. The last line of gcode " +"enables the \"clear_display\" delayed_gcode, set to execute in 10 seconds." +msgstr "" + +msgid "" +"The `initial_duration` config option can be set to execute the delayed_gcode" +" on printer startup. The countdown begins when the printer enters the " +"\"ready\" state. For example, the below delayed_gcode will execute 5 seconds" +" after the printer is ready, initializing the display with a \"Welcome!\" " +"message:" +msgstr "" + +msgid "" +"Its possible for a delayed gcode to repeat by updating itself in the gcode " +"option:" +msgstr "" + +msgid "" +"The above delayed_gcode will send \"// Extruder Temp: [ex0_temp]\" to " +"Octoprint every 2 seconds. This can be canceled with the following gcode:" +msgstr "" + +msgid "Menu templates" +msgstr "" + +msgid "" +"If a [display config section](Config_Reference.md#display) is enabled, then " +"it is possible to customize the menu with [menu](Config_Reference.md#menu) " +"config sections." +msgstr "" + +msgid "The following read-only attributes are available in menu templates:" +msgstr "" + +msgid "`menu.width` - element width (number of display columns)" +msgstr "" + +msgid "`menu.ns` - element namespace" +msgstr "" + +msgid "`menu.event` - name of the event that triggered the script" +msgstr "" + +msgid "`menu.input` - input value, only available in input script context" +msgstr "" + +msgid "The following actions are available in menu templates:" +msgstr "" + +msgid "" +"`menu.back(force, update)`: will execute menu back command, optional boolean" +" parameters `` and ``." +msgstr "" + +msgid "" +"When `` is set True then it will also stop editing. Default value is " +"False." +msgstr "" + +msgid "" +"When `` is set False then parent container items are not updated. " +"Default value is True." +msgstr "" + +msgid "" +"`menu.exit(force)` - will execute menu exit command, optional boolean " +"parameter `` default value False." +msgstr "" + +msgid "Save Variables to disk" +msgstr "" + +msgid "" +"If a [save_variables config section](Config_Reference.md#save_variables) has" +" been enabled, `SAVE_VARIABLE VARIABLE= VALUE=` can be used to " +"save the variable to disk so that it can be used across restarts. All stored" +" variables are loaded into the `printer.save_variables.variables` dict at " +"startup and can be used in gcode macros. to avoid overly long lines you can " +"add the following at the top of the macro:" +msgstr "" + +msgid "" +"As an example, it could be used to save the state of 2-in-1-out hotend and " +"when starting a print ensure that the active extruder is used, instead of " +"T0:" +msgstr "" + +msgid "" +"[gcode_macro blink_led]\n" +"gcode:\n" +" SET_PIN PIN=my_led VALUE=1\n" +" G4 P2000\n" +" SET_PIN PIN=my_led VALUE=0\n" +msgstr "" + +msgid "" +"[gcode_macro blink_led]\n" +"description: Blink my_led one time\n" +"gcode:\n" +" SET_PIN PIN=my_led VALUE=1\n" +" G4 P2000\n" +" SET_PIN PIN=my_led VALUE=0\n" +msgstr "" + +msgid "" +"[gcode_macro MOVE_UP]\n" +"gcode:\n" +" SAVE_GCODE_STATE NAME=my_move_up_state\n" +" G91\n" +" G1 Z10 F300\n" +" RESTORE_GCODE_STATE NAME=my_move_up_state\n" +msgstr "" + +msgid "" +"[gcode_macro SET_PERCENT]\n" +"gcode:\n" +" M117 Now at { params.VALUE|float * 100 }%\n" +msgstr "" + +msgid "" +"[gcode_macro SET_BED_TEMPERATURE]\n" +"gcode:\n" +" {% set bed_temp = params.TEMPERATURE|default(40)|float %}\n" +" M140 S{bed_temp}\n" +msgstr "" + +msgid "" +"[gcode_macro slow_fan]\n" +"gcode:\n" +" M106 S{ printer.fan.speed * 0.9 * 255}\n" +msgstr "" + +msgid "" +"[gcode_macro QUERY_HTU21D]\n" +"gcode:\n" +" {% set sensor = printer[\"htu21d my_sensor\"] %}\n" +" M117 Temp:{sensor.temperature} Humidity:{sensor.humidity}\n" +msgstr "" + +msgid "" +"[gcode_macro start_probe]\n" +"variable_bed_temp: 0\n" +"gcode:\n" +" # Save target temperature to bed_temp variable\n" +" SET_GCODE_VARIABLE MACRO=start_probe VARIABLE=bed_temp VALUE={printer.heater_bed.target}\n" +" # Disable bed heater\n" +" M140\n" +" # Perform probe\n" +" PROBE\n" +" # Call finish_probe macro at completion of probe\n" +" finish_probe\n" +"\n" +"[gcode_macro finish_probe]\n" +"gcode:\n" +" # Restore temperature\n" +" M140 S{printer[\"gcode_macro start_probe\"].bed_temp}\n" +msgstr "" + +msgid "" +"[delayed_gcode clear_display]\n" +"gcode:\n" +" M117\n" +"\n" +"[gcode_macro load_filament]\n" +"gcode:\n" +" G91\n" +" G1 E50\n" +" G90\n" +" M400\n" +" M117 Load Complete!\n" +" UPDATE_DELAYED_GCODE ID=clear_display DURATION=10\n" +msgstr "" + +msgid "" +"[delayed_gcode welcome]\n" +"initial_duration: 5.\n" +"gcode:\n" +" M117 Welcome!\n" +msgstr "" + +msgid "" +"[delayed_gcode report_temp]\n" +"initial_duration: 2.\n" +"gcode:\n" +" {action_respond_info(\"Extruder Temp: %.1f\" % (printer.extruder0.temperature))}\n" +" UPDATE_DELAYED_GCODE ID=report_temp DURATION=2\n" +msgstr "" + +msgid "UPDATE_DELAYED_GCODE ID=report_temp DURATION=0\n" +msgstr "" + +msgid "{% set svv = printer.save_variables.variables %}\n" +msgstr "" + +msgid "" +"[gcode_macro T1]\n" +"gcode:\n" +" ACTIVATE_EXTRUDER extruder=extruder1\n" +" SAVE_VARIABLE VARIABLE=currentextruder VALUE='\"extruder1\"'\n" +"\n" +"[gcode_macro T0]\n" +"gcode:\n" +" ACTIVATE_EXTRUDER extruder=extruder\n" +" SAVE_VARIABLE VARIABLE=currentextruder VALUE='\"extruder\"'\n" +"\n" +"[gcode_macro START_GCODE]\n" +"gcode:\n" +" {% set svv = printer.save_variables.variables %}\n" +" ACTIVATE_EXTRUDER extruder={svv.currentextruder}\n" +msgstr "" + +#: docs/Command_Templates.md:block 1 (header) +msgid "Commands templates" +msgstr "" + +#: docs/Command_Templates.md:block 28 (header) +msgid "The \"rawparams\" variable" +msgstr "" + +#: docs/Command_Templates.md:block 29 (paragraph) +msgid "" +"The full unparsed parameters for the running macro can be access via the " +"`rawparams` pseudo-variable." +msgstr "" + +#: docs/Command_Templates.md:block 21 (code) +msgid "" +"[gcode_macro clean_nozzle]\n" +"gcode:\n" +" {% set wipe_count = 8 %}\n" +" SAVE_GCODE_STATE NAME=clean_nozzle_state\n" +" G90\n" +" G0 Z15 F300\n" +" {% for wipe in range(wipe_count) %}\n" +" {% for coordinate in [(275, 4),(235, 4)] %}\n" +" G0 X{coordinate[0]} Y{coordinate[1] + 0.25 * wipe} Z9.7 F12000\n" +" {% endfor %}\n" +" {% endfor %}\n" +" RESTORE_GCODE_STATE NAME=clean_nozzle_state\n" +msgstr "" + +#: docs/Command_Templates.md:block 12 (paragraph) +msgid "" +"The terminal will display the description when you use the `HELP` command or" +" the autocomplete function." +msgstr "" + +#: docs/Command_Templates.md:block 30 (paragraph) +msgid "" +"Note that this will include any comments that were part of the original " +"command." +msgstr "" + +#: docs/Command_Templates.md:block 31 (paragraph) +msgid "" +"See the [sample-macros.cfg](../config/sample-macros.cfg) file for an example" +" showing how to override the `M117` command using `rawparams`." +msgstr "" + +#~ msgid "" +#~ "This is quite useful if you want to change the behavior of certain commands " +#~ "like the `M117`. For example:" +#~ msgstr "" + +#~ msgid "" +#~ "[gcode_macro M117]\n" +#~ "rename_existing: M117.1\n" +#~ "gcode:\n" +#~ " {% if rawparams %}\n" +#~ " {% set escaped_msg = rawparams|replace('\"', '\\\\\"') %}\n" +#~ " SET_DISPLAY_TEXT MSG=\"{escaped_msg}\"\n" +#~ " RESPOND TYPE=command MSG=\"{escaped_msg}\"\n" +#~ " {% else %}\n" +#~ " SET_DISPLAY_TEXT\n" +#~ " {% endif %}\n" +#~ msgstr "" + +#~ msgid "" +#~ "[gcode_macro M117]\n" +#~ "rename_existing: M117.1\n" +#~ "gcode:\n" +#~ " M117.1 { rawparams }\n" +#~ " M118 { rawparams }\n" +#~ msgstr "" + +#~ msgid "" +#~ "This will be showing is you use the `HELP` command or use the autocomplete " +#~ "function." +#~ msgstr "" + +#~ msgid "" +#~ "[gcode_macro clean_nozzle]\n" +#~ "gcode:\n" +#~ " {% set wipe_count = 8 %}\n" +#~ " SAVE_GCODE_STATE NAME=clean_nozzle_state\n" +#~ " G90\n" +#~ " G0 Z15 F300\n" +#~ " {% for wipe in range(wipe_count) %}\n" +#~ " {% for coordinate in [(275,4),(235,4)] %}\n" +#~ " G0 X{coordinate[0]} Y{coordinate[1] + 0.25 * wipe} Z9.7 F12000\n" +#~ " {% endfor %}\n" +#~ " {% endfor %}\n" +#~ " RESTORE_GCODE_STATE NAME=clean_nozzle_state\n" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Config_Changes.po b/docs/locales/lt/LC_MESSAGES/Config_Changes.po new file mode 100644 index 0000000000..9b234a7807 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Config_Changes.po @@ -0,0 +1,758 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"This document covers recent software changes to the config file that are not" +" backwards compatible. It is a good idea to review this document when " +"upgrading the Klipper software." +msgstr "" + +msgid "All dates in this document are approximate." +msgstr "" + +msgid "Changes" +msgstr "" + +msgid "" +"20210612: The `pid_integral_max` config option in heater and temperature_fan" +" sections is deprecated. The option will be removed in the near future." +msgstr "" + +msgid "" +"20210430: The SET_VELOCITY_LIMIT (and M204) command may now set a velocity, " +"acceleration, and square_corner_velocity larger than the specified values in" +" the config file." +msgstr "" + +msgid "" +"20210325: Support for the `pin_map` config option is deprecated. Use the " +"[sample-aliases.cfg](../config/sample-aliases.cfg) file to translate to the " +"actual micro-controller pin names. The `pin_map` config option will be " +"removed in the near future." +msgstr "" + +msgid "" +"20210313: Klipper's support for micro-controllers that communicate with CAN " +"bus has changed. If using CAN bus then all micro-controllers must be " +"reflashed and the [Klipper configuration must be updated](CANBUS.md)." +msgstr "" + +msgid "" +"20210310: The TMC2660 default for driver_SFILT has been changed from 1 to 0." +msgstr "" + +msgid "" +"20210227: TMC stepper motor drivers in UART or SPI mode are now queried once" +" per second whenever they are enabled - if the driver can not be contacted " +"or if the driver reports an error, then Klipper will transition to a " +"shutdown state." +msgstr "" + +msgid "" +"20210219: The `rpi_temperature` module has been renamed to " +"`temperature_host`. Replace any occurrences of `sensor_type: " +"rpi_temperature` with `sensor_type: temperature_host`. The path to the " +"temperature file may be specified in the `sensor_path` config variable. The " +"`rpi_temperature` name is deprecated and will be removed in the near future." +msgstr "" + +msgid "" +"20210201: The `TEST_RESONANCES` command will now disable input shaping if it" +" was previously enabled (and re-enable it after the test). In order to " +"override this behavior and keep the input shaping enabled, one can pass an " +"additional parameter `INPUT_SHAPING=1` to the command." +msgstr "" + +msgid "" +"20210201: The `ACCELEROMETER_MEASURE` command will now append the name of " +"the accelerometer chip to the output file name if the chip was given a name " +"in the corresponding adxl345 section of the printer.cfg." +msgstr "" + +msgid "" +"20201222: The `step_distance` setting in the stepper config sections is " +"deprecated. It is advised to update the config to use the " +"[`rotation_distance`](Rotation_Distance.md) setting. Support for " +"`step_distance` will be removed in the near future." +msgstr "" + +msgid "" +"20201218: The `endstop_phase` setting in the endstop_phase module has been " +"replaced with `trigger_phase`. If using the endstop phases module then it " +"will be necessary to convert to [`rotation_distance`](Rotation_Distance.md) " +"and recalibrate any endstop phases by running the ENDSTOP_PHASE_CALIBRATE " +"command." +msgstr "" + +msgid "" +"20201218: Rotary delta and polar printers must now specify a `gear_ratio` " +"for their rotary steppers, and they may no longer specify a `step_distance` " +"parameter. See the [config reference](Config_Reference.md#stepper) for the " +"format of the new gear_ratio paramter." +msgstr "" + +msgid "" +"20201213: It is not valid to specify a Z \"position_endstop\" when using " +"\"probe:z_virtual_endstop\". An error will now be raised if a Z " +"\"position_endstop\" is specified with \"probe:z_virtual_endstop\". Remove " +"the Z \"position_endstop\" definition to fix the error." +msgstr "" + +msgid "" +"20201120: The `[board_pins]` config section now specifies the mcu name in an" +" explicit `mcu:` parameter. If using board_pins for a secondary mcu, then " +"the config must be updated to specify that name. See the [config " +"reference](Config_Reference.md#board_pins) for further details." +msgstr "" + +msgid "" +"20201112: The time reported by `print_stats.print_duration` has changed. The" +" duration prior to the first detected extrusion is now excluded." +msgstr "" + +msgid "" +"20201029: The neopixel `color_order_GRB` config option has been removed. If " +"necessary, update the config to set the new `color_order` option to RGB, " +"GRB, RGBW, or GRBW." +msgstr "" + +msgid "" +"20201029: The serial option in the mcu config section no longer defaults to " +"/dev/ttyS0. In the rare situation where /dev/ttyS0 is the desired serial " +"port, it must be specified explicitly." +msgstr "" + +msgid "20201020: Klipper v0.9.0 released." +msgstr "" + +msgid "" +"20200902: The RTD resistance-to-temperature calculation for MAX31865 " +"converters has been corrected to not read low. If you are using such a " +"device, you should recalibrate your print temperature and PID settings." +msgstr "" + +msgid "" +"20200816: The gcode macro `printer.gcode` object has been renamed to " +"`printer.gcode_move`. Several undocumented variables in `printer.toolhead` " +"and `printer.gcode` have been removed. See docs/Command_Templates.md for a " +"list of available template variables." +msgstr "" + +msgid "" +"20200816: The gcode macro \"action_\" system has changed. Replace any calls " +"to `printer.gcode.action_emergency_stop()` with `action_emergency_stop()`, " +"`printer.gcode.action_respond_info()` with `action_respond_info()`, and " +"`printer.gcode.action_respond_error()` with `action_raise_error()`." +msgstr "" + +msgid "" +"20200809: The menu system has been rewritten. If the menu has been " +"customized then it will be necessary to update to the new configuration. See" +" config/example-menu.cfg for configuration details and see " +"klippy/extras/display/menu.cfg for examples." +msgstr "" + +msgid "" +"20200731: The behavior of the `progress` attribute reported by the " +"`virtual_sdcard` printer object has changed. Progress is no longer reset to " +"0 when a print is paused. It will now always report progress based on the " +"internal file position, or 0 if no file is currently loaded." +msgstr "" + +msgid "" +"20200725: The servo `enable` config parameter and the SET_SERVO `ENABLE` " +"parameter have been removed. Update any macros to use `SET_SERVO " +"SERVO=my_servo WIDTH=0` to disable a servo." +msgstr "" + +msgid "" +"20200608: The LCD display support has changed the name of some internal " +"\"glyphs\". If a custom display layout was implemented it may be necessary " +"to update to the latest glyph names (see klippy/extras/display/display.cfg " +"for a list of available glyphs)." +msgstr "" + +msgid "" +"20200606: The pin names on linux mcu have changed. Pins now have names of " +"the form `gpiochip/gpio`. For gpiochip0 you can also use a " +"short `gpio`. For example, what was previously referred to as `P20` " +"now becomes `gpio20` or `gpiochip0/gpio20`." +msgstr "" + +msgid "" +"20200603: The default 16x4 LCD layout will no longer show the estimated time" +" remaining in a print. (Only the elapsed time will be shown.) If the old " +"behavior is desired one can customize the menu display with that information" +" (see the description of display_data in config/example-extras.cfg for " +"details)." +msgstr "" + +msgid "" +"20200531: The default USB vendor/product id is now 0x1d50/0x614e. These new " +"ids are reserved for Klipper (thanks to the openmoko project). This change " +"should not require any config changes, but the new ids may appear in system " +"logs." +msgstr "" + +msgid "" +"20200524: The default value for the tmc5160 pwm_freq field is now zero " +"(instead of one)." +msgstr "" + +msgid "" +"20200425: The gcode_macro command template variable `printer.heater` was " +"renamed to `printer.heaters`." +msgstr "" + +msgid "" +"20200313: The default lcd layout for multi-extruder printers with a 16x4 " +"screen has changed. The single extruder screen layout is now the default and" +" it will show the currently active extruder. To use the previous display " +"layout set \"display_group: _multiextruder_16x4\" in the [display] section " +"of the printer.cfg file." +msgstr "" + +msgid "" +"20200308: The default `__test` menu item was removed. If the config file has" +" a custom menu then be sure to remove all references to this `__test` menu " +"item." +msgstr "" + +msgid "" +"20200308: The menu \"deck\" and \"card\" options were removed. To customize " +"the layout of an lcd screen use the new display_data config sections (see " +"config/example-extras.cfg for the details)." +msgstr "" + +msgid "" +"20200109: The bed_mesh module now references the probe's location in for the" +" mesh configuration. As such, some configuration options have been renamed " +"to more accurately reflect their intended functionality. For rectangular " +"beds, `min_point` and `max_point` have been renamed to `mesh_min` and " +"`mesh_max` respectively. For round beds, `bed_radius` has been renamed to " +"`mesh_radius`. A new `mesh_origin` option has also been added for round " +"beds. Note that these changes are also incompatible with previously saved " +"mesh profiles. If an incompatible profile is detected it will be ignored and" +" scheduled for removal. The removal process can be completed by issuing the " +"SAVE_CONFIG command. The user will need to re-calibrate each profile." +msgstr "" + +msgid "" +"20191218: The display config section no longer supports \"lcd_type: " +"st7567\". Use the \"uc1701\" display type instead - set \"lcd_type: uc1701\"" +" and change the \"rs_pin: some_pin\" to \"rst_pin: some_pin\". It may also " +"be necessary to add a \"contrast: 60\" config setting." +msgstr "" + +msgid "" +"20191210: The builtin T0, T1, T2, ... commands have been removed. The " +"extruder activate_gcode and deactivate_gcode config options have been " +"removed. If these commands (and scripts) are needed then define individual " +"[gcode_macro T0] style macros that call the ACTIVATE_EXTRUDER command. See " +"the config/sample-idex.cfg and sample-multi-extruder.cfg files for examples." +msgstr "" + +msgid "" +"20191210: Support for the M206 command has been removed. Replace with calls " +"to SET_GCODE_OFFSET. If support for M206 is needed, add a [gcode_macro M206]" +" config section that calls SET_GCODE_OFFSET. (For example \"SET_GCODE_OFFSET" +" Z=-{params.Z}\".)" +msgstr "" + +msgid "" +"20191202: Support for the undocumented \"S\" parameter of the \"G4\" command" +" has been removed. Replace any occurrences of S with the standard \"P\" " +"parameter (the delay specified in milliseconds)." +msgstr "" + +msgid "" +"20191126: The USB names have changed on micro-controllers with native USB " +"support. They now use a unique chip id by default (where available). If an " +"\"mcu\" config section uses a \"serial\" setting that starts with " +"\"/dev/serial/by-id/\" then it may be necessary to update the config. Run " +"\"ls /dev/serial/by-id/*\" in an ssh terminal to determine the new id." +msgstr "" + +msgid "" +"20191121: The pressure_advance_lookahead_time parameter has been removed. " +"See example.cfg for alternate configuration settings." +msgstr "" + +msgid "" +"20191112: The tmc stepper driver virtual enable capability is now " +"automatically enabled if the stepper does not have a dedicated stepper " +"enable pin. Remove references to tmcXXXX:virtual_enable from the config. The" +" ability to control multiple pins in the stepper enable_pin config has been " +"removed. If multiple pins are needed then use a multi_pin config section." +msgstr "" + +msgid "" +"20191107: The primary extruder config section must be specified as " +"\"extruder\" and may no longer be specified as \"extruder0\". Gcode command " +"templates that query the extruder status are now accessed via " +"\"{printer.extruder}\"." +msgstr "" + +msgid "20191021: Klipper v0.8.0 released" +msgstr "" + +msgid "" +"20191003: The move_to_previous option in [safe_z_homing] now defaults to " +"False. (It was effectively False prior to 20190918.)" +msgstr "" + +msgid "" +"20190918: The zhop option in [safe_z_homing] is always re-applied after Z " +"axis homing completed. This might need users to update custom scripts based " +"on this module." +msgstr "" + +msgid "20190806: The SET_NEOPIXEL command has been renamed to SET_LED." +msgstr "" + +msgid "" +"20190726: The mcp4728 digital-to-analog code has changed. The default " +"i2c_address is now 0x60 and the voltage reference is now relative to the " +"mcp4728's internal 2.048 volt reference." +msgstr "" + +msgid "" +"20190710: The z_hop option was removed from the [firmware_retract] config " +"section. The z_hop support was incomplete and could cause incorrect behavior" +" with several common slicers." +msgstr "" + +msgid "" +"20190710: The optional parameters of the PROBE_ACCURACY command have " +"changed. It may be necessary to update any macros or scripts that use that " +"command." +msgstr "" + +msgid "" +"20190607: The \"variable_X\" parameters of gcode_macro (along with the VALUE" +" parameter of SET_GCODE_VARIABLE) are now parsed as Python literals. If a " +"value needs to be assigned a string then wrap the value in quotes so that it" +" is evaluated as a string." +msgstr "" + +msgid "" +"20190606: The \"samples\", \"samples_result\", and \"sample_retract_dist\" " +"config options have been moved to the \"probe\" config section. These " +"options are no longer supported in the \"delta_calibrate\", \"bed_tilt\", " +"\"bed_mesh\", \"screws_tilt_adjust\", \"z_tilt\", or \"quad_gantry_level\" " +"config sections." +msgstr "" + +msgid "" +"20190528: The magic \"status\" variable in gcode_macro template evaluation " +"has been renamed to \"printer\"." +msgstr "" + +msgid "" +"20190520: The SET_GCODE_OFFSET command has changed; update any g-code macros" +" accordingly. The command will no longer apply the requested offset to the " +"next G1 command. The old behavior may be approximated by using the new " +"\"MOVE=1\" parameter." +msgstr "" + +msgid "" +"20190404: The Python host software packages were updated. Users will need to" +" rerun the ~/klipper/scripts/install-octopi.sh script (or otherwise upgrade " +"the python dependencies if not using a standard OctoPi installation)." +msgstr "" + +msgid "" +"20190404: The i2c_bus and spi_bus parameters (in various config sections) " +"now take a bus name instead of a number." +msgstr "" + +msgid "" +"20190404: The sx1509 config parameters have changed. The 'address' parameter" +" is now 'i2c_address' and it must be specified as a decimal number. Where " +"0x3E was previously used, specify 62." +msgstr "" + +msgid "" +"20190328: The min_speed value in [temperature_fan] config will now be " +"respected and the fan will always run at this speed or higher in PID mode." +msgstr "" + +msgid "" +"20190322: The default value for \"driver_HEND\" in [tmc2660] config sections" +" was changed from 6 to 3. The \"driver_VSENSE\" field was removed (it is now" +" automatically calculated from run_current)." +msgstr "" + +msgid "" +"20190310: The [controller_fan] config section now always takes a name (such " +"as [controller_fan my_controller_fan])." +msgstr "" + +msgid "" +"20190308: The \"driver_BLANK_TIME_SELECT\" field in [tmc2130] and [tmc2208] " +"config sections has been renamed to \"driver_TBL\"." +msgstr "" + +msgid "" +"20190308: The [tmc2660] config section has changed. A new sense_resistor " +"config parameter must now be provided. The meaning of several of the " +"driver_XXX parameters has changed." +msgstr "" + +msgid "" +"20190228: Users of SPI or I2C on SAMD21 boards must now specify the bus pins" +" via a [samd_sercom] config section." +msgstr "" + +msgid "" +"20190224: The bed_shape option has been removed from bed_mesh. The radius " +"option has been renamed to bed_radius. Users with round beds should supply " +"the bed_radius and round_probe_count options." +msgstr "" + +msgid "" +"20190107: The i2c_address parameter in the mcp4451 config section changed. " +"This is a common setting on Smoothieboards. The new value is half the old " +"value (88 should be changed to 44, and 90 should be changed to 45)." +msgstr "" + +msgid "20181220: Klipper v0.7.0 released" +msgstr "" + +msgid "" +"20210703: A `samd_sercom` config section must now specify the sercom bus it " +"is configuring via the `sercom` option." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20210720: A controller_fan section now monitors all stepper motors by " +"default (not just the kinematic stepper motors). If the previous behavior is" +" desired, see the `stepper` config option in the [config " +"reference](Config_Reference.md#controller_fan)." +msgstr "" + +#: docs/Config_Changes.md:block 1 (header) +msgid "Configuration Changes" +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20210819: In some cases, a `G28` homing move may end in a position that is " +"nominally outside the valid movement range. In rare situations this may " +"result in confusing \"Move out of range\" errors after homing. If this " +"occurs, change your start scripts to move the toolhead to a valid position " +"immediately after homing." +msgstr "" + +#: docs/Config_Changes.md:block 6 (paragraph) +msgid "" +"20210814: The analog only pseudo-pins on the atmega168 and atmega328 have " +"been renamed from PE0/PE1 to PE2/PE3." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20210903: The default [`smooth_time`](Config_Reference.md#extruder) for " +"heaters has changed to 1 second (from 2 seconds). For most printers this " +"will result in more stable temperature control." +msgstr "" + +#: docs/Config_Changes.md:block 6 (paragraph) +msgid "" +"20210830: The default adxl345 name is now \"adxl345\". The default CHIP " +"parameter for the `ACCELEROMETER_MEASURE` and `ACCELEROMETER_QUERY` is now " +"also \"adxl345\"." +msgstr "" + +#: docs/Config_Changes.md:block 7 (paragraph) +msgid "" +"20210830: The adxl345 ACCELEROMETER_MEASURE command no longer supports a " +"RATE parameter. To alter the query rate, update the printer.cfg file and " +"issue a RESTART command." +msgstr "" + +#: docs/Config_Changes.md:block 8 (paragraph) +msgid "" +"20210821: Several config settings in `printer.configfile.settings` will now " +"be reported as lists instead of raw strings. If the actual raw string is " +"desired, use `printer.configfile.config` instead." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20211110: The \"NTC 100K beta 3950\" temperature sensor is deprecated. This " +"sensor will be removed in the near future. Most users will find the " +"\"Generic 3950\" temperature sensor more accurate. To continue to use the " +"older (typically less accurate) definition, define a custom " +"[thermistor](Config_Reference.md#thermistor) with `temperature1: 25`, " +"`resistance1: 100000`, and `beta: 3950`." +msgstr "" + +#: docs/Config_Changes.md:block 7 (paragraph) +msgid "" +"20211102: Several deprecated features have been removed. The stepper " +"`step_distance` option has been removed (deprecated on 20201222). The " +"`rpi_temperature` sensor alias has been removed (deprecated on 20210219). " +"The mcu `pin_map` option has been removed (deprecated on 20210325). The " +"gcode_macro `default_parameter_` and macro access to command " +"parameters other than via the `params` pseudo-variable has been removed " +"(deprecated on 20210503). The heater `pid_integral_max` option has been " +"removed (deprecated on 20210612)." +msgstr "" + +#: docs/Config_Changes.md:block 8 (paragraph) +msgid "20210929: Klipper v0.10.0 released." +msgstr "" + +#: docs/Config_Changes.md:block 18 (paragraph) +msgid "" +"20210503: The gcode_macro `default_parameter_` config option is " +"deprecated. Use the `params` pseudo-variable to access macro parameters. " +"Other methods for accessing macro parameters will be removed in the near " +"future. Most users can replace a `default_parameter_NAME: VALUE` config " +"option with a line like the following in the start of the macro: ` {% set " +"NAME = params.NAME|default(VALUE)|float %}`. See the [Command Templates " +"document](Command_Templates.md#macro-parameters) for examples." +msgstr "" + +#: docs/Config_Changes.md:block 67 (paragraph) +msgid "" +"20190628: All configuration options have been removed from the " +"[skew_correction] section. Configuration for skew_correction is now done via" +" the SET_SKEW gcode. See [Skew Correction](Skew_Correction.md) for " +"recommended usage." +msgstr "" + +#: docs/Config_Changes.md:block 6 (paragraph) +msgid "" +"20211104: The \"step pulse duration\" option in \"make menuconfig\" has been" +" removed. The default step duration for TMC drivers configured in UART or " +"SPI mode is now 100ns. A new `step_pulse_duration` setting in the [stepper " +"config section](Config_Reference.md#stepper) should be set for all steppers " +"that need a custom pulse duration." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20220116: The tmc2130, tmc2208, tmc2209, and tmc2660 `run_current` " +"calculation code has changed. For some `run_current` settings the drivers " +"may now be configured differently. This new configuration should be more " +"accurate, but it may invalidate previous tmc driver tuning." +msgstr "" + +#: docs/Config_Changes.md:block 6 (paragraph) +msgid "" +"20211230: Scripts to tune input shaper (`scripts/calibrate_shaper.py` and " +"`scripts/graph_accelerometer.py`) were migrated to use Python3 by default. " +"As a result, users must install Python3 versions of certain packages (e.g. " +"`sudo apt install python3-numpy python3-matplotlib`) to continue using these" +" scripts. For more details, refer to [Software " +"installation](Measuring_Resonances.md#software-installation). Alternatively," +" users can temporarily force the execution of these scripts under Python 2 " +"by explicitly calling Python2 interpretor in the console: `python2 " +"~/klipper/scripts/calibrate_shaper.py ...`" +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20220210: The `SYNC_STEPPER_TO_EXTRUDER` command is deprecated; the " +"`SET_EXTRUDER_STEP_DISTANCE` command is deprecated; the " +"[extruder](Config_Reference.md#extruder) `shared_heater` config option is " +"deprecated. These features will be removed in the near future. Replace " +"`SET_EXTRUDER_STEP_DISTANCE` with `SET_EXTRUDER_ROTATION_DISTANCE`. Replace " +"`SYNC_STEPPER_TO_EXTRUDER` with `SYNC_EXTRUDER_MOTION`. Replace extruder " +"config sections using `shared_heater` with " +"[extruder_stepper](Config_Reference.md#extruder_stepper) config sections and" +" update any activation macros to use " +"[SYNC_EXTRUDER_MOTION](G-Codes.md#sync_extruder_motion)." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20220304: There is no longer a default for the `extruder` parameter of " +"[extruder_stepper](Config_Reference.md#extruder_stepper) config sections. If" +" desired, specify `extruder: extruder` explicitly to associate the stepper " +"motor with the \"extruder\" motion queue at startup." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20220307: `M73` will no longer set print progress to 0 if `P` is missing." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20220407: The temperature_fan `pid_integral_max` config option has been " +"removed (it was deprecated on 20210612)." +msgstr "" + +#: docs/Config_Changes.md:block 6 (paragraph) +msgid "" +"20220407: The default color order for pca9632 LEDs is now \"RGBW\". Add an " +"explicit `color_order: RBGW` setting to the pca9632 config section to obtain" +" the previous behavior." +msgstr "" + +#: docs/Config_Changes.md:block 7 (paragraph) +msgid "" +"20220330: The format of the `printer.neopixel.color_data` status information" +" for neopixel and dotstar modules has changed. The information is now stored" +" as a list of color lists (instead of a list of dictionaries). See the " +"[status reference](Status_Reference.md#led) for details." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20220616: It was previously possible to flash an rp2040 in bootloader mode " +"by running `make flash FLASH_DEVICE=first`. The equivalent command is now " +"`make flash FLASH_DEVICE=2e8a:0003`." +msgstr "" + +#: docs/Config_Changes.md:block 6 (paragraph) +msgid "" +"20220612: The rp2040 micro-controller now has a workaround for the " +"\"rp2040-e5\" USB errata. This should make initial USB connections more " +"reliable. However, it may result in a change in behavior for the gpio15 pin." +" It is unlikely the gpio15 behavior change will be noticeable." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20221122: Previously, with safe_z_home, it was possible that the z_hop after" +" the g28 homing would go in the negative z direction. Now, a z_hop is " +"performed after g28 only if it results in a positive hop, mirroring the " +"behavior of the z_hop that occurs before the g28 homing." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20230201: The `[bed_mesh]` module no longer loads the `default` profile on " +"startup. It is recommended that users who use the `default` profile add " +"`BED_MESH_PROFILE LOAD=default` to their `START_PRINT` macro (or to their " +"slicer's \"Start G-Code\" configuration when applicable)." +msgstr "" + +#: docs/Config_Changes.md:block 6 (paragraph) +msgid "" +"20230103: It is now possible with the flash-sdcard.sh script to flash both " +"variants of the Bigtreetech SKR-2, STM32F407 and STM32F429. This means that " +"the original tag of btt-skr2 now has changed to either btt-skr-2-f407 or " +"btt-skr-2-f429." +msgstr "" + +#: docs/Config_Changes.md:block 7 (paragraph) +msgid "20221128: Klipper v0.11.0 released." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20230304: The `SET_TMC_CURRENT` command now properly adjusts the " +"globalscaler register for drivers that have it. This removes a limitation " +"where on tmc5160, the currents could not be raised higher with " +"`SET_TMC_CURRENT` than the `run_current` value set in the config file. " +"However, this has a side effect: After running `SET_TMC_CURRENT`, the " +"stepper must be held at standstill for >130ms in case StealthChop2 is used " +"so that the AT#1 calibration gets executed by the driver." +msgstr "" + +#: docs/Config_Changes.md:block 6 (paragraph) +msgid "" +"20230202: The format of the `printer.screws_tilt_adjust` status information " +"has changed. The information is now stored as a dictionary of screws with " +"the resulting measurements. See the [status " +"reference](Status_Reference.md#screws_tilt_adjust) for details." +msgstr "" + +#: docs/Config_Changes.md:block 5 (paragraph) +msgid "" +"20230826: If `safe_distance` is set or calculated to be 0 in " +"`[dual_carriage]`, the carriages proximity checks will be disabled as per " +"documentation. A user may wish to configure `safe_distance` explicitly to " +"prevent accidental crashes of the carriages with each other. Additionally, " +"the homing order of the primary and the dual carriage is changed in some " +"configurations (certain configurations when both carriages home in the same " +"direction, see [[dual_carriage] configuration " +"reference](./Config_Reference.md#dual_carriage) for more details)." +msgstr "" + +#: docs/Config_Changes.md:block 6 (paragraph) +msgid "" +"20230810: The flash-sdcard.sh script now supports both variants of the " +"Bigtreetech SKR-3, STM32H743 and STM32H723. For this, the original tag of " +"btt-skr-3 now has changed to be either btt-skr-3-h743 or btt-skr-3-h723." +msgstr "" + +#: docs/Config_Changes.md:block 7 (paragraph) +msgid "" +"20230729: The exported status for `dual_carriage` is changed. Instead of " +"exporting `mode` and `active_carriage`, the individual modes for each " +"carriage are exported as `printer.dual_carriage.carriage_0` and " +"`printer.dual_carriage.carriage_1`." +msgstr "" + +#: docs/Config_Changes.md:block 8 (paragraph) +msgid "" +"20230619: The `relative_reference_index` option has been deprecated and " +"superceded by the `zero_reference_position` option. Refer to the [Bed Mesh " +"Documentation](./Bed_Mesh.md#the-deprecated-relative_reference_index) for " +"details on how to update the configuration. With this deprecation the " +"`RELATIVE_REFERENCE_INDEX` is no longer available as a parameter for the " +"`BED_MESH_CALIBRATE` gcode command." +msgstr "" + +#: docs/Config_Changes.md:block 9 (paragraph) +msgid "" +"20230530: The default canbus frequency in \"make menuconfig\" is now " +"1000000. If using canbus and using canbus with some other frequency is " +"required, then be sure to select \"Enable extra low-level configuration " +"options\" and specify the desired \"CAN bus speed\" in \"make menuconfig\" " +"when compiling and flashing the micro-controller." +msgstr "" + +#: docs/Config_Changes.md:block 10 (paragraph) +msgid "" +"20230525: `SHAPER_CALIBRATE` command immediately applies input shaper " +"parameters if `[input_shaper]` was enabled already." +msgstr "" + +#: docs/Config_Changes.md:block 11 (paragraph) +msgid "" +"20230407: The `stalled_bytes` counter in the log and in the " +"`printer.mcu.last_stats` field has been renamed to `upcoming_bytes`." +msgstr "" + +#: docs/Config_Changes.md:block 12 (paragraph) +msgid "" +"20230323: On tmc5160 drivers `multistep_filt` is now enabled by default. Set" +" `driver_MULTISTEP_FILT: False` in the tmc5160 config for the previous " +"behavior." +msgstr "" + +#~ msgid "" +#~ "20211104: The \"step pulse duration\" option in \"make menuconfig\" has been" +#~ " removed. A new `step_pulse_duration` setting in the [stepper config " +#~ "section](Config_Reference.md#stepper) should be set for all steppers that " +#~ "need a custom pulse duration." +#~ msgstr "" + +#~ msgid "" +#~ "20190628: All configuration options have been removed from the " +#~ "[skew_correction] section. Configuration for skew_correction is now done via" +#~ " the SET_SKEW gcode. See skew_correction.md for recommended usage." +#~ msgstr "" + +#~ msgid "" +#~ "20210503: The gcode_macro `default_parameter_` config option is " +#~ "deprecated. Use the `params` pseudo-variable to access macro parameters. " +#~ "Other methods for accessing macro parameters will be removed in the near " +#~ "future. See the [Command Templates document](Command_Templates.md#macro-" +#~ "parameters) for examples." +#~ msgstr "" + +#~ msgid "Configuration changes" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Contact.po b/docs/locales/lt/LC_MESSAGES/Contact.po new file mode 100644 index 0000000000..8c6c224c12 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Contact.po @@ -0,0 +1,362 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "This document provides contact information for Klipper." +msgstr "" + +msgid "[Community Forum](#community-forum)" +msgstr "" + +msgid "[Discord Chat](#discord-chat)" +msgstr "" + +msgid "[I have a question about Klipper](#i-have-a-question-about-klipper)" +msgstr "" + +msgid "[I have a feature request](#i-have-a-feature-request)" +msgstr "" + +msgid "[Help! It doesn't work!](#help-it-doesnt-work)" +msgstr "" + +msgid "" +"[I am making changes that I'd like to include in Klipper](#i-am-making-" +"changes-that-id-like-to-include-in-klipper)" +msgstr "" + +msgid "Community Forum" +msgstr "" + +msgid "" +"There is a [Klipper Community Discourse " +"server](https://community.klipper3d.org) for discussions on Klipper." +msgstr "" + +msgid "Discord Chat" +msgstr "" + +msgid "" +"This server is run by a community of Klipper enthusiasts dedicated to " +"discussions on Klipper. It allows users to chat with other users in real-" +"time." +msgstr "" + +msgid "I have a question about Klipper" +msgstr "" + +msgid "" +"Many questions we receive are already answered in the [Klipper " +"documentation](Overview.md). Please be sure to to read the documentation and" +" follow the directions provided there." +msgstr "" + +msgid "" +"It is also possible to search for similar questions in the [Klipper " +"Community Forum](#community-forum)." +msgstr "" + +msgid "" +"If you are interested in sharing your knowledge and experience with other " +"Klipper users then you can join the [Klipper Community Forum](#community-" +"forum) or [Klipper Discord Chat](#discord-chat). Both are communities where " +"Klipper users can discuss Klipper with other users." +msgstr "" + +msgid "" +"Many questions we receive are general 3d-printing questions that are not " +"specific to Klipper. If you have a general question or are experiencing " +"general printing problems, then you will likely get a better response by " +"asking in a general 3d-printing forum or a forum dedicated to your printer " +"hardware." +msgstr "" + +msgid "I have a feature request" +msgstr "" + +msgid "" +"All new features require someone interested and able to implement that " +"feature. If you are interested in helping to implement or test a new " +"feature, you can search for ongoing developments in the [Klipper Community " +"Forum](#community-forum). There is also [Klipper Discord Chat](#discord-" +"chat) for discussions between collaborators." +msgstr "" + +msgid "Help! It doesn't work!" +msgstr "" + +msgid "" +"Unfortunately, we receive many more requests for help than we could possibly" +" answer. Most problem reports we see are eventually tracked down to:" +msgstr "" + +msgid "Subtle errors in the hardware, or" +msgstr "" + +msgid "Not following all the steps described in the Klipper documentation." +msgstr "" + +msgid "" +"If you are experiencing problems we recommend you carefully read the " +"[Klipper documentation](Overview.md) and double check that all steps were " +"followed." +msgstr "" + +msgid "" +"If you are experiencing a printing problem, then we recommend carefully " +"inspecting the printer hardware (all joints, wires, screws, etc.) and verify" +" nothing is abnormal. We find most printing problems are not related to the " +"Klipper software. If you do find a problem with the printer hardware then " +"you will likely get a better response by searching in a general 3d-printing " +"forum or in a forum dedicated to your printer hardware." +msgstr "" + +msgid "" +"It is also possible to search for similar issues in the [Klipper Community " +"Forum](#community-forum)." +msgstr "" + +msgid "" +"Klipper is an open-source project and we appreciate when collaborators " +"diagnose errors in the software." +msgstr "" + +msgid "" +"There is important information that will be needed in order to fix a bug. " +"Please follow these steps:" +msgstr "" + +msgid "" +"Obtain the Klipper log file from the event. The log file has been engineered" +" to answer common questions the Klipper developers have about the software " +"and its environment (software version, hardware type, configuration, event " +"timing, and hundreds of other questions)." +msgstr "" + +msgid "" +"The Klipper log file is located in `/tmp/klippy.log` on the Klipper \"host\"" +" computer (the Raspberry Pi)." +msgstr "" + +msgid "" +"An \"scp\" or \"sftp\" utility is needed to copy this log file to your " +"desktop computer. The \"scp\" utility comes standard with Linux and MacOS " +"desktops. There are freely available scp utilities for other desktops (eg, " +"WinSCP). If using a graphical scp utility that can not directly copy " +"`/tmp/klippy.log` then repeatedly click on `..` or `parent folder` until you" +" get to the root directory, click on the `tmp` folder, and then select the " +"`klippy.log` file." +msgstr "" + +msgid "" +"Copy the log file to your desktop so that it can be attached to an issue " +"report." +msgstr "" + +msgid "" +"Do not modify the log file in any way; do not provide a snippet of the log. " +"Only the full unmodified log file provides the necessary information." +msgstr "" + +msgid "I am making changes that I'd like to include in Klipper" +msgstr "" + +msgid "Klipper is open-source software and we appreciate new contributions." +msgstr "" + +msgid "" +"New contributions (for both code and documentation) are submitted via Github" +" Pull Requests. See the [CONTRIBUTING document](CONTRIBUTING.md) for " +"important information." +msgstr "" + +#: docs/Contact.md:block 1 (header) +msgid "Contact" +msgstr "" + +#: docs/Contact.md:block 7 (paragraph) +msgid "" +"There is a Discord server dedicated to Klipper at: " +"." +msgstr "" + +#: docs/Contact.md:block 3 (ordered list) +msgid "" +"[I found a bug in the Klipper software](#i-found-a-bug-in-the-klipper-" +"software)" +msgstr "" + +#: docs/Contact.md:block 3 (ordered list) +msgid "[Klipper github](#klipper-github)" +msgstr "" + +#: docs/Contact.md:block 23 (header) +msgid "I found a bug in the Klipper software" +msgstr "" + +#: docs/Contact.md:block 25 (paragraph) +msgid "" +"Problems should be reported in the [Klipper Community Forum](#community-" +"forum)." +msgstr "" + +#: docs/Contact.md:block 27 (ordered list) +msgid "" +"Make sure you are running unmodified code from " +". If the code has been modified or is " +"obtained from another source, then you should reproduce the problem on the " +"unmodified code from prior to " +"reporting." +msgstr "" + +#: docs/Contact.md:block 27 (ordered list) +msgid "" +"If possible, run an `M112` command immediately after the undesirable event " +"occurs. This causes Klipper to go into a \"shutdown state\" and it will " +"cause additional debugging information to be written to the log file." +msgstr "" + +#: docs/Contact.md:block 27 (ordered list) +msgid "It is a good idea to compress the log file with zip or gzip." +msgstr "" + +#: docs/Contact.md:block 27 (ordered list) +msgid "" +"Open a new topic on the [Klipper Community Forum](#community-forum) and " +"provide a clear description of the problem. Other Klipper contributors will " +"need to understand what steps were taken, what the desired outcome was, and " +"what outcome actually occurred. The compressed Klipper log file should be " +"attached to that topic." +msgstr "" + +#: docs/Contact.md:block 31 (paragraph) +msgid "" +"There are several [documents for developers](Overview.md#developer-" +"documentation). If you have questions on the code then you can also ask in " +"the [Klipper Community Forum](#community-forum) or on the [Klipper Community" +" Discord](#discord-chat)." +msgstr "" + +#: docs/Contact.md:block 32 (header) +msgid "Klipper github" +msgstr "" + +#: docs/Contact.md:block 33 (paragraph) +msgid "" +"Klipper github may be used by contributors to share the status of their work" +" to improve Klipper. It is expected that the person opening a github ticket " +"is actively working on the given task and will be the one performing all the" +" work necessary to accomplish it. The Klipper github is not used for " +"requests, nor to report bugs, nor to ask questions. Use the [Klipper " +"Community Forum](#community-forum) or the [Klipper Community " +"Discord](#discord-chat) instead." +msgstr "" + +#~ msgid "" +#~ "[I have diagnosed a defect in the Klipper software](#i-have-diagnosed-a-" +#~ "defect-in-the-klipper-software)" +#~ msgstr "" + +#~ msgid "Do not open a Klipper github issue to ask a question." +#~ msgstr "" + +#~ msgid "Do not open a Klipper github issue to request a feature." +#~ msgstr "" + +#~ msgid "Do not open a Klipper github issue to request help." +#~ msgstr "" + +#~ msgid "I have diagnosed a defect in the Klipper software" +#~ msgstr "" + +#~ msgid "" +#~ "Be sure the bug is in the Klipper software. If you are thinking \"there is a" +#~ " problem, I can't figure out why, and therefore it is a Klipper bug\", then " +#~ "**do not** open a github issue. In that case, someone interested and able " +#~ "will need to first research and diagnose the root cause of the problem. If " +#~ "you would like to share the results of your research or check if other users" +#~ " are experiencing similar issues then you can search the [Klipper Community " +#~ "Forum](#community-forum)." +#~ msgstr "" + +#~ msgid "" +#~ "If possible, run an `M112` command in the OctoPrint terminal window " +#~ "immediately after the undesirable event occurs. This causes Klipper to go " +#~ "into a \"shutdown state\" and it will cause additional debugging information" +#~ " to be written to the log file." +#~ msgstr "" + +#~ msgid "" +#~ "If the log file is very large (eg, greater than 2MB) then one may need to " +#~ "compress the log with zip or gzip." +#~ msgstr "" + +#~ msgid "![attach-issue](img/attach-issue.png)" +#~ msgstr "" + +#~ msgid "" +#~ "There are several [documents for developers](Overview.md#developer-" +#~ "documentation). If you have questions on the code then you can also ask in " +#~ "the [Klipper Community Forum](#community-forum) or on the [Klipper Community" +#~ " Discord](#discord-chat). If you would like to provide an update on your " +#~ "current progress then you can open a Github issue with the location of your " +#~ "code, an overview of the changes, and a description of its current status." +#~ msgstr "" + +#~ msgid "" +#~ "Make sure you are running unmodified code from " +#~ ". If the code has been modified or is " +#~ "obtained from another source, then you will need to reproduce the problem on" +#~ " the unmodified code from prior to " +#~ "reporting an issue." +#~ msgstr "" + +#~ msgid "" +#~ "Open a new github issue at and" +#~ " provide a clear description of the problem. The Klipper developers need to " +#~ "understand what steps were taken, what the desired outcome was, and what " +#~ "outcome actually occurred. The Klipper log file **must be attached** to that" +#~ " ticket:" +#~ msgstr "" + +#~ msgid "" +#~ "Make sure you are running unmodified code from " +#~ ". If the code has been modified or " +#~ "is obtained from another source, then you will need to reproduce the problem" +#~ " on the unmodified code from prior" +#~ " to reporting an issue." +#~ msgstr "" + +#~ msgid "" +#~ "Open a new github issue at " +#~ "and provide a clear description of the problem. The Klipper developers need " +#~ "to understand what steps were taken, what the desired outcome was, and what " +#~ "outcome actually occurred. The Klipper log file **must be attached** to that" +#~ " ticket:" +#~ msgstr "" + +#~ msgid "" +#~ "There is a Discord server dedicated to Klipper at: " +#~ "[https://discord.klipper3d.org](https://discord.klipper3d.org)." +#~ msgstr "" + +#~ msgid "" +#~ "Make sure you are running unmodified code from " +#~ "[https://github.com/KevinOConnor/klipper](https://github.com/KevinOConnor/klipper)." +#~ " If the code has been modified or is obtained from another source, then you " +#~ "will need to reproduce the problem on the unmodified code from " +#~ "[https://github.com/KevinOConnor/klipper](https://github.com/KevinOConnor/klipper)" +#~ " prior to reporting an issue." +#~ msgstr "" + +#~ msgid "" +#~ "Open a new github issue at " +#~ "[https://github.com/KevinOConnor/klipper/issues](https://github.com/KevinOConnor/klipper/issues)" +#~ " and provide a clear description of the problem. The Klipper developers need" +#~ " to understand what steps were taken, what the desired outcome was, and what" +#~ " outcome actually occurred. The Klipper log file **must be attached** to " +#~ "that ticket:" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Endstop_Phase.po b/docs/locales/lt/LC_MESSAGES/Endstop_Phase.po new file mode 100644 index 0000000000..4088564769 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Endstop_Phase.po @@ -0,0 +1,155 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"This document describes Klipper's stepper phase adjusted endstop system. " +"This functionality can improve the accuracy of traditional endstop switches." +" It is most useful when using a Trinamic stepper motor driver that has run-" +"time configuration." +msgstr "" + +msgid "" +"A typical endstop switch has an accuracy of around 100 microns. (Each time " +"an axis is homed the switch may trigger slightly earlier or slightly later.)" +" Although this is a relatively small error, it can result in unwanted " +"artifacts. In particular, this positional deviation may be noticeable when " +"printing the first layer of an object. In contrast, typical stepper motors " +"can obtain significantly higher precision." +msgstr "" + +msgid "" +"The stepper phase adjusted endstop mechanism can use the precision of the " +"stepper motors to improve the precision of the endstop switches. A stepper " +"motor moves by cycling through a series of phases until in completes four " +"\"full steps\". So, a stepper motor using 16 micro-steps would have 64 " +"phases and when moving in a positive direction it would cycle through " +"phases: 0, 1, 2, ... 61, 62, 63, 0, 1, 2, etc. Crucially, when the stepper " +"motor is at a particular position on a linear rail it should always be at " +"the same stepper phase. Thus, when a carriage triggers the endstop switch " +"the stepper controlling that carriage should always be at the same stepper " +"motor phase. Klipper's endstop phase system combines the stepper phase with " +"the endstop trigger to improve the accuracy of the endstop." +msgstr "" + +msgid "" +"In order to use this functionality it is necessary to be able to identify " +"the phase of the stepper motor. If one is using Trinamic TMC2130, TMC2208, " +"TMC2224 or TMC2660 drivers in run-time configuration mode (ie, not stand-" +"alone mode) then Klipper can query the stepper phase from the driver. (It is" +" also possible to use this system on traditional stepper drivers if one can " +"reliably reset the stepper drivers - see below for details.)" +msgstr "" + +msgid "Calibrating endstop phases" +msgstr "" + +msgid "" +"If using Trinamic stepper motor drivers with run-time configuration then one" +" can calibrate the endstop phases using the ENDSTOP_PHASE_CALIBRATE command." +" Start by adding the following to the config file:" +msgstr "" + +msgid "" +"Then RESTART the printer and run a `G28` command followed by an " +"`ENDSTOP_PHASE_CALIBRATE` command. Then move the toolhead to a new location " +"and run `G28` again. Try moving the toolhead to several different locations " +"and rerun `G28` from each position. Run at least five `G28` commands." +msgstr "" + +msgid "" +"After performing the above, the `ENDSTOP_PHASE_CALIBRATE` command will often" +" report the same (or nearly the same) phase for the stepper. This phase can " +"be saved in the config file so that all future G28 commands use that phase. " +"(So, in future homing operations, Klipper will obtain the same position even" +" if the endstop triggers a little earlier or a little later.)" +msgstr "" + +msgid "" +"To save the endstop phase for a particular stepper motor, run something like" +" the following:" +msgstr "" + +msgid "" +"Run the above for all the steppers one wishes to save. Typically, one would " +"use this on stepper_z for cartesian and corexy printers, and for stepper_a, " +"stepper_b, and stepper_c on delta printers. Finally, run the following to " +"update the configuration file with the data:" +msgstr "" + +msgid "Additional notes" +msgstr "" + +msgid "" +"This feature is most useful on delta printers and on the Z endstop of " +"cartesian/corexy printers. It is possible to use this feature on the XY " +"endstops of cartesian printers, but that isn't particularly useful as a " +"minor error in X/Y endstop position is unlikely to impact print quality. It " +"is not valid to use this feature on the XY endstops of corexy printers (as " +"the XY position is not determined by a single stepper on corexy kinematics)." +" It is not valid to use this feature on a printer using a " +"\"probe:z_virtual_endstop\" Z endstop (as the stepper phase is only stable " +"if the endstop is at a static location on a rail)." +msgstr "" + +msgid "" +"After calibrating the endstop phase, if the endstop is later moved or " +"adjusted then it will be necessary to recalibrate the endstop. Remove the " +"calibration data from the config file and rerun the steps above." +msgstr "" + +msgid "" +"In order to use this system the endstop must be accurate enough to identify " +"the stepper position within two \"full steps\". So, for example, if a " +"stepper is using 16 micro-steps with a step distance of 0.005mm then the " +"endstop must have an accuracy of at least 0.160mm. If one gets \"Endstop " +"stepper_z incorrect phase\" type error messages than in may be due to an " +"endstop that is not sufficiently accurate. If recalibration does not help " +"then disable endstop phase adjustments by removing them from the config " +"file." +msgstr "" + +msgid "" +"If one is using a traditional stepper controlled Z axis (as on a cartesian " +"or corexy printer) along with traditional bed leveling screws then it is " +"also possible to use this system to arrange for each print layer to be " +"performed on a \"full step\" boundary. To enable this feature be sure the " +"G-Code slicer is configured with a layer height that is a multiple of a " +"\"full step\", manually enable the endstop_align_zero option in the " +"endstop_phase config section (see [config " +"reference](Config_Reference.md#endstop_phase) for further details), and then" +" re-level the bed screws." +msgstr "" + +msgid "" +"It is possible to use this system with traditional (non-Trinamic) stepper " +"motor drivers. However, doing this requires making sure that the stepper " +"motor drivers are reset every time the micro-controller is reset. (If the " +"two are always reset together then Klipper can determine the stepper phase " +"by tracking the total number of steps it has commanded the stepper to move.)" +" Currently, the only way to do this reliably is if both the micro-controller" +" and stepper motor drivers are powered solely from USB and that USB power is" +" provided from a host running on a Raspberry Pi. In this situation one can " +"specify an mcu config with \"restart_method: rpi_usb\" - that option will " +"arrange for the micro-controller to always be reset via a USB power reset, " +"which would arrange for both the micro-controller and stepper motor drivers " +"to be reset together. If using this mechanism, one would then need to " +"manually configure the \"trigger_phase\" config sections (see [config " +"reference](Config_Reference.md#endstop_phase) for the details)." +msgstr "" + +msgid "[endstop_phase]\n" +msgstr "" + +msgid "ENDSTOP_PHASE_CALIBRATE STEPPER=stepper_z\n" +msgstr "" + +msgid "SAVE_CONFIG\n" +msgstr "" + +#: docs/Endstop_Phase.md:block 1 (header) +msgid "Endstop phase" +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Example_Configs.po b/docs/locales/lt/LC_MESSAGES/Example_Configs.po new file mode 100644 index 0000000000..f95dd9cd67 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Example_Configs.po @@ -0,0 +1,221 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"This document contains guidelines for contributing an example Klipper " +"configuration to the Klipper github repository (located in the [config " +"directory](../config/))." +msgstr "" + +msgid "" +"Note that the [Klipper Community Discourse " +"server](https://community.klipper3d.org) is also a useful resource for " +"finding and sharing config files." +msgstr "" + +msgid "Guidelines" +msgstr "" + +msgid "" +"The `generic` prefix is used for a 3d printer board that may be used in many" +" different types of printers." +msgstr "" + +msgid "" +"The `kit` prefix is for 3d printers that are assembled according to a widely" +" used specification. These \"kit\" printers are generally distinct from " +"normal \"printers\" in that they are not sold by a manufacturer." +msgstr "" + +msgid "" +"The `sample` prefix is used for config \"snippets\" that one may copy-and-" +"paste into the main config file." +msgstr "" + +msgid "" +"The `example` prefix is used to describe printer kinematics. This type of " +"config is typically only added along with code for a new type of printer " +"kinematics." +msgstr "" + +msgid "" +"Klipper must be able to start `printer`, `generic`, and `kit` example config" +" file without error. These config files should be added to the " +"[test/klippy/printers.test](../test/klippy/printers.test) regression test " +"case. Add new config files to that test case in the appropriate section and " +"in alphabetical order within that section." +msgstr "" + +msgid "" +"The example configuration should be for the \"stock\" configuration of the " +"printer. (There are too many \"customized\" configurations to track in the " +"main Klipper repository.) Similarly, we only add example config files for " +"printers, kits, and boards that have mainstream popularity (eg, there should" +" be at least a 100 of them in active use). Consider using the [Klipper " +"Community Discourse server](https://community.klipper3d.org) for other " +"configs." +msgstr "" + +msgid "" +"Only specify those devices present on the given printer or board. Do not " +"specify settings specific to your particular setup.For `generic` config " +"files, only those devices on the mainboard should be described. For example," +" it would not make sense to add a display config section to a \"generic\" " +"config as there is no way to know if the board will be attached to that type" +" of display. If the board has a specific hardware port to facilitate an " +"optional peripheral (eg, a bltouch port) then one can add a \"commented " +"out\" config section for the given device." +msgstr "" + +msgid "" +"Do not specify `pressure_advance` in an example config, as that value is " +"specific to the filament, not the printer hardware. Similarly, do not " +"specify `max_extrude_only_velocity` nor `max_extrude_only_accel` settings." +msgstr "" + +msgid "" +"Do not specify a config section containing a host path or host hardware. For" +" example, do not specify `[virtual_sdcard]` nor `[temperature_host]` config " +"sections." +msgstr "" + +msgid "" +"Only define macros that utilize functionality specific to the given printer " +"or to define g-codes that are commonly emitted by slicers configured for the" +" given printer." +msgstr "" + +msgid "" +"Where possible, it is best to use the same wording, phrasing, indentation, " +"and section ordering as the existing config files.The top of each config " +"file should list the type of micro-controller the user should select during " +"\"make menuconfig\". It should also have a reference to " +"\"docs/Config_Reference.md\"." +msgstr "" + +msgid "" +"Do not copy the field documentation into the example config files. (Doing so" +" creates a maintenance burden as an update to the documentation would then " +"require changing it in many places.)" +msgstr "" + +msgid "" +"Example config files should not contain a \"SAVE_CONFIG\" section. If " +"necessary, copy the relevant fields from the SAVE_CONFIG section to the " +"appropriate section in the main config area." +msgstr "" + +msgid "Use `field: value` syntax instead of `field=value`." +msgstr "" + +msgid "" +"Avoid defining field values that are set to their default value. For " +"example, one should not specify `min_extrude_temp: 170` as that is already " +"the default value." +msgstr "" + +msgid "Where possible, lines should not exceed 80 columns." +msgstr "" + +msgid "" +"Avoid adding attribution or revision messages to the config files. (For " +"example, avoid adding lines like \"this file was created by ...\".) Place " +"attribution and change history in the git commit message." +msgstr "" + +msgid "" +"Do not disable a default safety system in an example config file. For " +"example, a config should not specify a custom `max_extrude_cross_section`. " +"Do not enable debugging features. For example there should not be a " +"`force_move` config section." +msgstr "" + +msgid "" +"Example config files are submitted by creating a github \"pull request\". " +"Please also follow the directions in the [contributing " +"document](CONTRIBUTING.md)." +msgstr "" + +#: docs/Example_Configs.md:block 4 (ordered list) +msgid "" +"The `printer` prefix is used for stock printers sold by a mainstream " +"manufacturer." +msgstr "" + +#: docs/Example_Configs.md:block 1 (header) +msgid "Example configurations" +msgstr "" + +#: docs/Example_Configs.md:block 5 (ordered list) +msgid "Select the appropriate config filename prefix:" +msgstr "" + +#: docs/Example_Configs.md:block 5 (ordered list) +msgid "" +"All configuration files must end in a `.cfg` suffix. The `printer` config " +"files must end in a year followed by `.cfg` (eg, `-2019.cfg`). In this case," +" the year is an approximate year the given printer was sold." +msgstr "" + +#: docs/Example_Configs.md:block 5 (ordered list) +msgid "" +"Do not use spaces or special characters in the config filename. The filename" +" should contain only characters `A-Z`, `a-z`, `0-9`, `-`, and `.`." +msgstr "" + +#: docs/Example_Configs.md:block 7 (ordered list) +msgid "Do not use any deprecated features in the example config file." +msgstr "" + +#: docs/Example_Configs.md:block 7 (ordered list) +msgid "" +"When adding an extruder `rotation_distance` it is preferable to specify a " +"`gear_ratio` if the extruder has a gearing mechanism. We expect the " +"rotation_distance in the example configs to correlate with the circumference" +" of the hobbed gear in the extruder - it is normally in the range of 20 to " +"35mm. When specifying a `gear_ratio` it is preferable to specify the actual " +"gears on the mechanism (eg, prefer `gear_ratio: 80:20` over `gear_ratio: " +"4:1`). See the [rotation distance document](Rotation_Distance.md#using-a-" +"gear_ratio) for more information." +msgstr "" + +#: docs/Example_Configs.md:block 7 (ordered list) +msgid "" +"All known boards that Klipper supports can use the default serial baud rate " +"of 250000. Do not recommend a different baud rate in an example config file." +msgstr "" + +#~ msgid "" +#~ "When adding an extruder `rotation_distance` it is preferable to specify a " +#~ "`gear_ratio` if the extruder has a gearing mechanism. We expect the " +#~ "rotation_distance in the example configs to correlate with the circumference" +#~ " of the hobbed gear in the extruder - it is normally in the range of 20 to " +#~ "35mm. When specifying a `gear_ratio` it is preferable to specify the actual " +#~ "gears on the mechanism (eg, prefer `gear_ratio: 80:20` over `gear_ratio: " +#~ "4:1`)." +#~ msgstr "" + +#~ msgid "" +#~ "Use the appropriate filename suffix. The `printer` config files must end in " +#~ "a year followed by `.cfg` (eg, `-2019.cfg`). In this case, the year is an " +#~ "approximate year the given printer was sold. All example configuration files" +#~ " must end in `.cfg`." +#~ msgstr "" + +#~ msgid "" +#~ "Do not use any deprecated features in the example config file. The " +#~ "`step_distance` and `pin_map` parameters are deprecated and should not be in" +#~ " any example config file." +#~ msgstr "" + +#~ msgid "Select the appropriate config filename prefix." +#~ msgstr "" + +#~ msgid "" +#~ "Select the appropriate config filename prefix.The `printer` prefix is used " +#~ "for stock printers sold by a mainstream manufacturer." +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/FAQ.po b/docs/locales/lt/LC_MESSAGES/FAQ.po new file mode 100644 index 0000000000..d8ffe5f73b --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/FAQ.po @@ -0,0 +1,821 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "How can I donate to the project?" +msgstr "" + +msgid "How do I calculate the rotation_distance config parameter?" +msgstr "" + +msgid "See the [rotation distance document](Rotation_Distance.md)." +msgstr "" + +msgid "Where's my serial port?" +msgstr "" + +msgid "" +"The general way to find a USB serial port is to run `ls /dev/serial/by-id/*`" +" from an ssh terminal on the host machine. It will likely produce output " +"similar to the following:" +msgstr "" + +msgid "" +"The name found in the above command is stable and it is possible to use it " +"in the config file and while flashing the micro-controller code. For " +"example, a flash command might look similar to:" +msgstr "" + +msgid "and the updated config might look like:" +msgstr "" + +msgid "" +"Be sure to copy-and-paste the name from the \"ls\" command that you ran " +"above as the name will be different for each printer." +msgstr "" + +msgid "" +"If you are using multiple micro-controllers and they do not have unique ids " +"(common on boards with a CH340 USB chip) then follow the directions above " +"using the command `ls /dev/serial/by-path/*` instead." +msgstr "" + +msgid "When the micro-controller restarts the device changes to /dev/ttyUSB1" +msgstr "" + +msgid "" +"Follow the directions in the \"[Where's my serial port?](#wheres-my-serial-" +"port)\" section to prevent this from occurring." +msgstr "" + +msgid "The \"make flash\" command doesn't work" +msgstr "" + +msgid "" +"The code attempts to flash the device using the most common method for each " +"platform. Unfortunately, there is a lot of variance in flashing methods, so " +"the \"make flash\" command may not work on all boards." +msgstr "" + +msgid "" +"If you're having an intermittent failure or you do have a standard setup, " +"then double check that Klipper isn't running when flashing (sudo service " +"klipper stop), make sure OctoPrint isn't trying to connect directly to the " +"device (open the Connection tab in the web page and click Disconnect if the " +"Serial Port is set to the device), and make sure FLASH_DEVICE is set " +"correctly for your board (see the [question above](#wheres-my-serial-port))." +msgstr "" + +msgid "" +"However, if \"make flash\" just doesn't work for your board, then you will " +"need to manually flash. See if there is a config file in the [config " +"directory](../config) with specific instructions for flashing the device. " +"Also, check the board manufacturer's documentation to see if it describes " +"how to flash the device. Finally, it may be possible to manually flash the " +"device using tools such as \"avrdude\" or \"bossac\" - see the [bootloader " +"document](Bootloaders.md) for additional information." +msgstr "" + +msgid "How do I change the serial baud rate?" +msgstr "" + +msgid "" +"The recommended baud rate for Klipper is 250000. This baud rate works well " +"on all micro-controller boards that Klipper supports. If you've found an " +"online guide recommending a different baud rate, then ignore that part of " +"the guide and continue with the default value of 250000." +msgstr "" + +msgid "" +"If you want to change the baud rate anyway, then the new rate will need to " +"be configured in the micro-controller (during **make menuconfig**) and that " +"updated code will need to be compiled and flashed to the micro-controller. " +"The Klipper printer.cfg file will also need to be updated to match that baud" +" rate (see the [config reference](Config_Reference.md#mcu) for details). For" +" example:" +msgstr "" + +msgid "" +"The baud rate shown on the OctoPrint web page has no impact on the internal " +"Klipper micro-controller baud rate. Always set the OctoPrint baud rate to " +"250000 when using Klipper." +msgstr "" + +msgid "" +"The Klipper micro-controller baud rate is not related to the baud rate of " +"the micro-controller's bootloader. See the [bootloader " +"document](Bootloaders.md) for additional information on bootloaders." +msgstr "" + +msgid "Can I run Klipper on something other than a Raspberry Pi 3?" +msgstr "" + +msgid "" +"The recommended hardware is a Raspberry Pi 2, Raspberry Pi 3, or Raspberry " +"Pi 4." +msgstr "" + +msgid "" +"Klipper will run on a Raspberry Pi 1 and on the Raspberry Pi Zero, but these" +" boards don't have enough processing power to run OctoPrint well. It is " +"common for print stalls to occur on these slower machines when printing " +"directly from OctoPrint. (The printer may move faster than OctoPrint can " +"send movement commands.) If you wish to run on one one of these slower " +"boards anyway, consider using the \"virtual_sdcard\" feature when printing " +"(see [config reference](Config_Reference.md#virtual_sdcard) for details)." +msgstr "" + +msgid "" +"Klipper has been run on other machines. The Klipper host software only " +"requires Python running on a Linux (or similar) computer. However, if you " +"wish to run it on a different machine you will need Linux admin knowledge to" +" install the system prerequisites for that particular machine. See the " +"[install-octopi.sh](../scripts/install-octopi.sh) script for further " +"information on the necessary Linux admin steps." +msgstr "" + +msgid "" +"If you are looking to run the Klipper host software on a low-end chip, then " +"be aware that, at a minimum, a machine with \"double precision floating " +"point\" hardware is required." +msgstr "" + +msgid "" +"If you are looking to run the Klipper host software on a shared general-" +"purpose desktop or server class machine, then note that Klipper has some " +"real-time scheduling requirements. If, during a print, the host computer " +"also performs an intensive general-purpose computing task (such as " +"defragmenting a hard drive, 3d rendering, heavy swapping, etc.), then it may" +" cause Klipper to report print errors." +msgstr "" + +msgid "" +"Note: If you are not using an OctoPi image, be aware that several Linux " +"distributions enable a \"ModemManager\" (or similar) package that can " +"disrupt serial communication. (Which can cause Klipper to report seemingly " +"random \"Lost communication with MCU\" errors.) If you install Klipper on " +"one of these distributions you may need to disable that package." +msgstr "" + +msgid "Can I run multiple instances of Klipper on the same host machine?" +msgstr "" + +msgid "" +"It is possible to run multiple instances of the Klipper host software, but " +"doing so requires Linux admin knowledge. The Klipper installation scripts " +"ultimately cause the following Unix command to be run:" +msgstr "" + +msgid "" +"One can run multiple instances of the above command as long as each instance" +" has its own printer config file, its own log file, and its own pseudo-tty. " +"For example:" +msgstr "" + +msgid "" +"If you choose to do this, you will need to implement the necessary start, " +"stop, and installation scripts (if any). The [install-" +"octopi.sh](../scripts/install-octopi.sh) script and the [klipper-" +"start.sh](../scripts/klipper-start.sh) script may be useful as examples." +msgstr "" + +msgid "Do I have to use OctoPrint?" +msgstr "" + +msgid "" +"The Klipper software is not dependent on OctoPrint. It is possible to use " +"alternative software to send commands to Klipper, but doing so requires " +"Linux admin knowledge." +msgstr "" + +msgid "" +"Klipper creates a \"virtual serial port\" via the \"/tmp/printer\" file, and" +" it emulates a classic 3d-printer serial interface via that file. In " +"general, alternative software may work with Klipper as long as it can be " +"configured to use \"/tmp/printer\" for the printer serial port." +msgstr "" + +msgid "Why can't I move the stepper before homing the printer?" +msgstr "" + +msgid "" +"The code does this to reduce the chance of accidentally commanding the head " +"into the bed or a wall. Once the printer is homed the software attempts to " +"verify each move is within the position_min/max defined in the config file. " +"If the motors are disabled (via an M84 or M18 command) then the motors will " +"need to be homed again prior to movement." +msgstr "" + +msgid "" +"If you want to move the head after canceling a print via OctoPrint, consider" +" changing the OctoPrint cancel sequence to do that for you. It's configured " +"in OctoPrint via a web browser under: Settings->GCODE Scripts" +msgstr "" + +msgid "" +"If you want to move the head after a print finishes, consider adding the " +"desired movement to the \"custom g-code\" section of your slicer." +msgstr "" + +msgid "" +"If the printer requires some additional movement as part of the homing " +"process itself (or fundamentally does not have a homing process) then " +"consider using a safe_z_home or homing_override section in the config file. " +"If you need to move a stepper for diagnostic or debugging purposes then " +"consider adding a force_move section to the config file. See [config " +"reference](Config_Reference.md#customized_homing) for further details on " +"these options." +msgstr "" + +msgid "Why is the Z position_endstop set to 0.5 in the default configs?" +msgstr "" + +msgid "" +"For cartesian style printers the Z position_endstop specifies how far the " +"nozzle is from the bed when the endstop triggers. If possible, it is " +"recommended to use a Z-max endstop and home away from the bed (as this " +"reduces the potential for bed collisions). However, if one must home towards" +" the bed then it is recommended to position the endstop so it triggers when " +"the nozzle is still a small distance away from the bed. This way, when " +"homing the axis, it will stop before the nozzle touches the bed. See the " +"[bed level document](Bed_Level.md) for more information." +msgstr "" + +msgid "" +"I converted my config from Marlin and the X/Y axes work fine, but I just get" +" a screeching noise when homing the Z axis" +msgstr "" + +msgid "" +"Short answer: First, make sure you have verified the stepper configuration " +"as described in the [config check document](Config_checks.md). If the " +"problem persists, try reducing the max_z_velocity setting in the printer " +"config." +msgstr "" + +msgid "" +"Long answer: In practice Marlin can typically only step at a rate of around " +"10000 steps per second. If it is requested to move at a speed that would " +"require a higher step rate then Marlin will generally just step as fast as " +"it can. Klipper is able to achieve much higher step rates, but the stepper " +"motor may not have sufficient torque to move at a higher speed. So, for a Z " +"axis with a high gearing ratio or high microsteps setting the actual " +"obtainable max_z_velocity may be smaller than what is configured in Marlin." +msgstr "" + +msgid "My TMC motor driver turns off in the middle of a print" +msgstr "" + +msgid "" +"If using the TMC2208 (or TMC2224) driver in \"standalone mode\" then make " +"sure to use the [latest version of Klipper](#how-do-i-upgrade-to-the-latest-" +"software). A workaround for a TMC2208 \"stealthchop\" driver problem was " +"added to Klipper in mid-March of 2020." +msgstr "" + +msgid "I keep getting random \"Lost communication with MCU\" errors" +msgstr "" + +msgid "" +"This is commonly caused by hardware errors on the USB connection between the" +" host machine and the micro-controller. Things to look for:" +msgstr "" + +msgid "" +"Use a good quality USB cable between the host machine and micro-controller. " +"Make sure the plugs are secure." +msgstr "" + +msgid "" +"Make sure the printer's power supply is not being overloaded. (Power " +"fluctuations to the micro-controller's USB chip may result in resets of that" +" chip.)" +msgstr "" + +msgid "" +"Verify stepper, heater, and other printer wires are not crimped or frayed. " +"(Printer movement may place stress on a faulty wire causing it to lose " +"contact, briefly short, or generate excessive noise.)" +msgstr "" + +msgid "" +"There have been reports of high USB noise when both the printer's power " +"supply and the host's 5V power supply are mixed. (If you find that the " +"micro-controller powers on when either the printer's power supply is on or " +"the USB cable is plugged in, then it indicates the 5V power supplies are " +"being mixed.) It may help to configure the micro-controller to use power " +"from only one source. (Alternatively, if the micro-controller board can not " +"configure its power source, one may modify a USB cable so that it does not " +"carry 5V power between the host and micro-controller.)" +msgstr "" + +msgid "My Raspberry Pi keeps rebooting during prints" +msgstr "" + +msgid "" +"This is most likely do to voltage fluctuations. Follow the same " +"troubleshooting steps for a [\"Lost communication with MCU\"](#i-keep-" +"getting-random-lost-communication-with-mcu-errors) error." +msgstr "" + +msgid "" +"Some old versions of the AVR bootloader have a known bug in watchdog event " +"handling. This typically manifests when the printer.cfg file has " +"restart_method set to \"command\". When the bug occurs, the AVR device will " +"be unresponsive until power is removed and reapplied to the device (the " +"power or status LEDs may also blink repeatedly until the power is removed)." +msgstr "" + +msgid "" +"The workaround is to use a restart_method other than \"command\" or to flash" +" an updated bootloader to the AVR device. Flashing a new bootloader is a one" +" time step that typically requires an external programmer - see " +"[Bootloaders](Bootloaders.md) for further details." +msgstr "" + +msgid "Will the heaters be left on if the Raspberry Pi crashes?" +msgstr "" + +msgid "" +"The software has been designed to prevent that. Once the host enables a " +"heater, the host software needs to confirm that enablement every 5 seconds. " +"If the micro-controller does not receive a confirmation every 5 seconds it " +"goes into a \"shutdown\" state which is designed to turn off all heaters and" +" stepper motors." +msgstr "" + +msgid "" +"See the \"config_digital_out\" command in the [MCU " +"commands](MCU_Commands.md) document for further details." +msgstr "" + +msgid "" +"In addition, the micro-controller software is configured with a minimum and " +"maximum temperature range for each heater at startup (see the min_temp and " +"max_temp parameters in the [config reference](Config_Reference.md#extruder) " +"for details). If the micro-controller detects that the temperature is " +"outside of that range then it will also enter a \"shutdown\" state." +msgstr "" + +msgid "" +"Separately, the host software also implements code to check that heaters and" +" temperature sensors are functioning correctly. See the [config " +"reference](Config_Reference.md#verify_heater) for further details." +msgstr "" + +msgid "How do I convert a Marlin pin number to a Klipper pin name?" +msgstr "" + +msgid "" +"Short answer: A mapping is available in the [sample-" +"aliases.cfg](../config/sample-aliases.cfg) file. Use that file as a guide to" +" finding the actual micro-controller pin names. (It is also possible to copy" +" the relevant [board_pins](Config_Reference.md#board_pins) config section " +"into your config file and use the aliases in your config, but it is " +"preferable to translate and use the actual micro-controller pin names.) Note" +" that the sample-aliases.cfg file uses pin names that start with the prefix " +"\"ar\" instead of \"D\" (eg, Arduino pin `D23` is Klipper alias `ar23`) and " +"the prefix \"analog\" instead of \"A\" (eg, Arduino pin `A14` is Klipper " +"alias `analog14`)." +msgstr "" + +msgid "" +"Long answer: Klipper uses the standard pin names defined by the micro-" +"controller. On the Atmega chips these hardware pins have names like `PA4`, " +"`PC7`, or `PD2`." +msgstr "" + +msgid "" +"Long ago, the Arduino project decided to avoid using the standard hardware " +"names in favor of their own pin names based on incrementing numbers - these " +"Arduino names generally look like `D23` or `A14`. This was an unfortunate " +"choice that has lead to a great deal of confusion. In particular the Arduino" +" pin numbers frequently don't translate to the same hardware names. For " +"example, `D21` is `PD0` on one common Arduino board, but is `PC7` on another" +" common Arduino board." +msgstr "" + +msgid "" +"To avoid this confusion, the core Klipper code uses the standard pin names " +"defined by the micro-controller." +msgstr "" + +msgid "" +"Do I have to wire my device to a specific type of micro-controller pin?" +msgstr "" + +msgid "It depends on the type of device and type of pin:" +msgstr "" + +msgid "" +"ADC pins (or Analog pins): For thermistors and similar \"analog\" sensors, " +"the device must be wired to an \"analog\" or \"ADC\" capable pin on the " +"micro-controller. If you configure Klipper to use a pin that is not analog " +"capable, Klipper will report a \"Not a valid ADC pin\" error." +msgstr "" + +msgid "" +"PWM pins (or Timer pins): Klipper does not use hardware PWM by default for " +"any device. So, in general, one may wire heaters, fans, and similar devices " +"to any general purpose IO pin. However, fans and output_pin devices may be " +"optionally configured to use `hardware_pwm: True`, in which case the micro-" +"controller must support hardware PWM on the pin (otherwise, Klipper will " +"report a \"Not a valid PWM pin\" error)." +msgstr "" + +msgid "" +"IRQ pins (or Interrupt pins): Klipper does not use hardware interrupts on IO" +" pins, so it is never necessary to wire a device to one of these micro-" +"controller pins." +msgstr "" + +msgid "" +"SPI pins: When using hardware SPI it is necessary to wire the pins to the " +"micro-controller's SPI capable pins. However, most devices can be configured" +" to use \"software SPI\", in which case any general purpose IO pins may be " +"used." +msgstr "" + +msgid "" +"I2C pins: When using I2C it is necessary to wire the pins to the micro-" +"controller's I2C capable pins." +msgstr "" + +msgid "" +"Other devices may be wired to any general purpose IO pin. For example, " +"steppers, heaters, fans, Z probes, servos, LEDs, common hd44780/st7920 LCD " +"displays, the Trinamic UART control line may be wired to any general purpose" +" IO pin." +msgstr "" + +msgid "How do I cancel an M109/M190 \"wait for temperature\" request?" +msgstr "" + +msgid "" +"Navigate to the OctoPrint terminal tab and issue an M112 command in the " +"terminal box. The M112 command will cause Klipper to enter into a " +"\"shutdown\" state, and it will cause OctoPrint to disconnect from Klipper. " +"Navigate to the OctoPrint connection area and click on \"Connect\" to cause " +"OctoPrint to reconnect. Navigate back to the terminal tab and issue a " +"FIRMWARE_RESTART command to clear the Klipper error state. After completing " +"this sequence, the previous heating request will be canceled and a new print" +" may be started." +msgstr "" + +msgid "Can I find out whether the printer has lost steps?" +msgstr "" + +msgid "" +"In a way, yes. Home the printer, issue a `GET_POSITION` command, run your " +"print, home again and issue another `GET_POSITION`. Then compare the values " +"in the `mcu:` line." +msgstr "" + +msgid "" +"This might be helpful to tune settings like stepper motor currents, " +"accelerations and speeds without needing to actually print something and " +"waste filament: just run some high-speed moves in between the `GET_POSITION`" +" commands." +msgstr "" + +msgid "" +"Note that endstop switches themselves tend to trigger at slightly different " +"positions, so a difference of a couple of microsteps is likely the result of" +" endstop inaccuracies. A stepper motor itself can only lose steps in " +"increments of 4 full steps. (So, if one is using 16 microsteps, then a lost " +"step on the stepper would result in the \"mcu:\" step counter being off by a" +" multiple of 64 microsteps.)" +msgstr "" + +msgid "Why does Klipper report errors? I lost my print!" +msgstr "" + +msgid "" +"Short answer: We want to know if our printers detect a problem so that the " +"underlying issue can be fixed and we can obtain great quality prints. We " +"definitely do not want our printers to silently produce low quality prints." +msgstr "" + +msgid "" +"Long answer: Klipper has been engineered to automatically workaround many " +"transient problems. For example, it automatically detects communication " +"errors and will retransmit; it schedules actions in advance and buffers " +"commands at multiple layers to enable precise timing even with intermittent " +"interference. However, should the software detect an error that it can not " +"recover from, if it is commanded to take an invalid action, or if it detects" +" it is hopelessly unable to perform its commanded task, then Klipper will " +"report an error. In these situations there is a high risk of producing a " +"low-quality print (or worse). It is hoped that alerting the user will " +"empower them to fix the underlying issue and improve the overall quality of " +"their prints." +msgstr "" + +msgid "" +"There are some related questions: Why doesn't Klipper pause the print " +"instead? Report a warning instead? Check for errors before the print? Ignore" +" errors in user typed commands? etc? Currently Klipper reads commands using " +"the G-Code protocol, and unfortunately the G-Code command protocol is not " +"flexible enough to make these alternatives practical today. There is " +"developer interest in improving the user experience during abnormal events, " +"but it is expected that will require notable infrastructure work (including " +"a shift away from G-Code)." +msgstr "" + +msgid "How do I upgrade to the latest software?" +msgstr "" + +msgid "" +"The first step to upgrading the software is to review the latest [config " +"changes](Config_Changes.md) document. On occasion, changes are made to the " +"software that require users to update their settings as part of a software " +"upgrade. It is a good idea to review this document prior to upgrading." +msgstr "" + +msgid "" +"When ready to upgrade, the general method is to ssh into the Raspberry Pi " +"and run:" +msgstr "" + +msgid "" +"Then one can recompile and flash the micro-controller code. For example:" +msgstr "" + +msgid "" +"However, it's often the case that only the host software changes. In this " +"case, one can update and restart just the host software with:" +msgstr "" + +msgid "" +"If after using this shortcut the software warns about needing to reflash the" +" micro-controller or some other unusual error occurs, then follow the full " +"upgrade steps outlined above." +msgstr "" + +msgid "" +"If any errors persist then double check the [config " +"changes](Config_Changes.md) document, as you may need to modify the printer " +"configuration." +msgstr "" + +msgid "" +"Note that the RESTART and FIRMWARE_RESTART g-code commands do not load new " +"software - the above \"sudo service klipper restart\" and \"make flash\" " +"commands are needed for a software change to take effect." +msgstr "" + +msgid "How do I uninstall Klipper?" +msgstr "" + +msgid "" +"On the firmware end, nothing special needs to happen. Just follow the " +"flashing directions for the new firmware." +msgstr "" + +msgid "" +"On the raspberry pi end, an uninstall script is available in " +"[scripts/klipper-uninstall.sh](../scripts/klipper-uninstall.sh). For " +"example:" +msgstr "" + +msgid "/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0\n" +msgstr "" + +msgid "" +"sudo service klipper stop\n" +"make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0\n" +"sudo service klipper start\n" +msgstr "" + +msgid "" +"[mcu]\n" +"serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0\n" +msgstr "" + +msgid "" +"[mcu]\n" +"baud: 250000\n" +msgstr "" + +msgid "" +"~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer.cfg -l " +"/tmp/klippy.log\n" +msgstr "" + +msgid "" +"~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer2.cfg -l " +"/tmp/klippy2.log -I /tmp/printer2\n" +msgstr "" + +msgid "" +"cd ~/klipper\n" +"git pull\n" +"~/klipper/scripts/install-octopi.sh\n" +msgstr "" + +msgid "" +"make menuconfig\n" +"make clean\n" +"make\n" +"\n" +"sudo service klipper stop\n" +"make flash FLASH_DEVICE=/dev/ttyACM0\n" +"sudo service klipper start\n" +msgstr "" + +msgid "" +"cd ~/klipper\n" +"git pull\n" +"sudo service klipper restart\n" +msgstr "" + +msgid "" +"sudo ~/klipper/scripts/klipper-uninstall.sh\n" +"rm -rf ~/klippy-env ~/klipper\n" +msgstr "" + +#: docs/FAQ.md:block 1 (header) +msgid "Frequently Asked Questions" +msgstr "" + +#: docs/FAQ.md:block 31 (paragraph) +msgid "" +"For running on the Beaglebone, see the [Beaglebone specific installation " +"instructions](Beaglebone.md)." +msgstr "" + +#: docs/FAQ.md:block 59 (unordered list) +msgid "" +"If using a Raspberry Pi, use a [good quality power " +"supply](https://www.raspberrypi.com/documentation/computers/raspberry-" +"pi.html#power-supply) for the Raspberry Pi and use a [good quality USB " +"cable](https://forums.raspberrypi.com/viewtopic.php?p=589877#p589877) to " +"connect that power supply to the Pi. If you get \"under voltage\" warnings " +"from OctoPrint, this is related to the power supply and it must be fixed." +msgstr "" + +#: docs/FAQ.md:block 62 (header) +msgid "" +"When I set `restart_method=command` my AVR device just hangs on a restart" +msgstr "" + +#: docs/FAQ.md:block 3 (paragraph) +msgid "" +"Thank you for your support. See the [Sponsors page](Sponsors.md) for " +"information." +msgstr "" + +#~ msgid "" +#~ "Thanks. Kevin has a Patreon page at: " +#~ msgstr "" + +#~ msgid "[How can I donate to the project?](#how-can-i-donate-to-the-project)" +#~ msgstr "" + +#~ msgid "" +#~ "[How do I calculate the rotation_distance config parameter?](#how-do-i-" +#~ "calculate-the-rotation_distance-config-parameter)" +#~ msgstr "" + +#~ msgid "[Where's my serial port?](#wheres-my-serial-port)" +#~ msgstr "" + +#~ msgid "" +#~ "[When the micro-controller restarts the device changes to " +#~ "/dev/ttyUSB1](#when-the-micro-controller-restarts-the-device-changes-to-" +#~ "devttyusb1)" +#~ msgstr "" + +#~ msgid "" +#~ "[The \"make flash\" command doesn't work](#the-make-flash-command-doesnt-" +#~ "work)" +#~ msgstr "" + +#~ msgid "" +#~ "[How do I change the serial baud rate?](#how-do-i-change-the-serial-baud-" +#~ "rate)" +#~ msgstr "" + +#~ msgid "" +#~ "[Can I run Klipper on something other than a Raspberry Pi 3?](#can-i-run-" +#~ "klipper-on-something-other-than-a-raspberry-pi-3)" +#~ msgstr "" + +#~ msgid "" +#~ "[Can I run multiple instances of Klipper on the same host machine?](#can-i-" +#~ "run-multiple-instances-of-klipper-on-the-same-host-machine)" +#~ msgstr "" + +#~ msgid "[Do I have to use OctoPrint?](#do-i-have-to-use-octoprint)" +#~ msgstr "" + +#~ msgid "" +#~ "[Why can't I move the stepper before homing the printer?](#why-cant-i-move-" +#~ "the-stepper-before-homing-the-printer)" +#~ msgstr "" + +#~ msgid "" +#~ "[Why is the Z position_endstop set to 0.5 in the default configs?](#why-is-" +#~ "the-z-position_endstop-set-to-05-in-the-default-configs)" +#~ msgstr "" + +#~ msgid "" +#~ "[I converted my config from Marlin and the X/Y axes work fine, but I just " +#~ "get a screeching noise when homing the Z axis](#i-converted-my-config-from-" +#~ "marlin-and-the-xy-axes-work-fine-but-i-just-get-a-screeching-noise-when-" +#~ "homing-the-z-axis)" +#~ msgstr "" + +#~ msgid "" +#~ "[My TMC motor driver turns off in the middle of a print](#my-tmc-motor-" +#~ "driver-turns-off-in-the-middle-of-a-print)" +#~ msgstr "" + +#~ msgid "" +#~ "[I keep getting random \"Lost communication with MCU\" errors](#i-keep-" +#~ "getting-random-lost-communication-with-mcu-errors)" +#~ msgstr "" + +#~ msgid "" +#~ "[My Raspberry Pi keeps rebooting during prints](#my-raspberry-pi-keeps-" +#~ "rebooting-during-prints)" +#~ msgstr "" + +#~ msgid "" +#~ "[Will the heaters be left on if the Raspberry Pi crashes?](#will-the-" +#~ "heaters-be-left-on-if-the-raspberry-pi-crashes)" +#~ msgstr "" + +#~ msgid "" +#~ "[How do I convert a Marlin pin number to a Klipper pin name?](#how-do-i-" +#~ "convert-a-marlin-pin-number-to-a-klipper-pin-name)" +#~ msgstr "" + +#~ msgid "" +#~ "[Do I have to wire my device to a specific type of micro-controller " +#~ "pin?](#do-i-have-to-wire-my-device-to-a-specific-type-of-micro-controller-" +#~ "pin)" +#~ msgstr "" + +#~ msgid "" +#~ "[How do I cancel an M109/M190 \"wait for temperature\" request?](#how-do-i-" +#~ "cancel-an-m109m190-wait-for-temperature-request)" +#~ msgstr "" + +#~ msgid "" +#~ "[Can I find out whether the printer has lost steps?](#can-i-find-out-" +#~ "whether-the-printer-has-lost-steps)" +#~ msgstr "" + +#~ msgid "" +#~ "[Why does Klipper report errors? I lost my print!](#why-does-klipper-report-" +#~ "errors-i-lost-my-print)" +#~ msgstr "" + +#~ msgid "" +#~ "[How do I upgrade to the latest software?](#how-do-i-upgrade-to-the-latest-" +#~ "software)" +#~ msgstr "" + +#~ msgid "[How do I uninstall klipper?](#how-do-i-uninstall-klipper)" +#~ msgstr "" + +#~ msgid "" +#~ "[When I set `restart_method=command` my AVR device just hangs on a " +#~ "restart](#when-i-set-restart_methodcommand-my-avr-device-just-hangs-on-a-" +#~ "restart)" +#~ msgstr "" + +#~ msgid "" +#~ "[When I set \"restart_method=command\" my AVR device just hangs on a " +#~ "restart](#when-i-set-restart_methodcommand-my-avr-device-just-hangs-on-a-" +#~ "restart)" +#~ msgstr "" + +#~ msgid "" +#~ "When I set \"restart_method=command\" my AVR device just hangs on a restart" +#~ msgstr "" + +#~ msgid "" +#~ "If using a Raspberry Pi, use a [good quality power " +#~ "supply](https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md)" +#~ " for the Raspberry Pi and use a [good quality USB " +#~ "cable](https://www.raspberrypi.org/forums/viewtopic.php?p=589877#p589877) to" +#~ " connect that power supply to the Pi. If you get \"under voltage\" warnings " +#~ "from OctoPrint, this is related to the power supply and it must be fixed." +#~ msgstr "" + +#~ msgid "" +#~ "For running on the Beaglebone, see the [Beaglebone specific installation " +#~ "instructions](beaglebone.md)." +#~ msgstr "" + +#~ msgid "" +#~ "Thanks. Kevin has a Patreon page at: " +#~ "[https://www.patreon.com/koconnor](https://www.patreon.com/koconnor)" +#~ msgstr "" + +#~ msgid "Frequently asked questions" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Features.po b/docs/locales/lt/LC_MESSAGES/Features.po new file mode 100644 index 0000000000..daf7bc0095 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Features.po @@ -0,0 +1,658 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "Klipper has several compelling features:" +msgstr "" + +msgid "" +"Klipper supports printers with multiple micro-controllers. For example, one " +"micro-controller could be used to control an extruder, while another " +"controls the printer's heaters, while a third controls the rest of the " +"printer. The Klipper host software implements clock synchronization to " +"account for clock drift between micro-controllers. No special code is needed" +" to enable multiple micro-controllers - it just requires a few extra lines " +"in the config file." +msgstr "" + +msgid "" +"Configuration via simple config file. There's no need to reflash the micro-" +"controller to change a setting. All of Klipper's configuration is stored in " +"a standard config file which can be easily edited. This makes it easier to " +"setup and maintain the hardware." +msgstr "" + +msgid "" +"Klipper supports \"Smooth Pressure Advance\" - a mechanism to account for " +"the effects of pressure within an extruder. This reduces extruder \"ooze\" " +"and improves the quality of print corners. Klipper's implementation does not" +" introduce instantaneous extruder speed changes, which improves overall " +"stability and robustness." +msgstr "" + +msgid "" +"Klipper supports \"Input Shaping\" to reduce the impact of vibrations on " +"print quality. This can reduce or eliminate \"ringing\" (also known as " +"\"ghosting\", \"echoing\", or \"rippling\") in prints. It may also allow one" +" to obtain faster printing speeds while still maintaining high print " +"quality." +msgstr "" + +msgid "" +"Klipper uses an \"iterative solver\" to calculate precise step times from " +"simple kinematic equations. This makes porting Klipper to new types of " +"robots easier and it keeps timing precise even with complex kinematics (no " +"\"line segmentation\" is needed)." +msgstr "" + +msgid "" +"Portable code. Klipper works on ARM, AVR, and PRU based micro-controllers. " +"Existing \"reprap\" style printers can run Klipper without hardware " +"modification - just add a Raspberry Pi. Klipper's internal code layout makes" +" it easier to support other micro-controller architectures as well." +msgstr "" + +msgid "" +"Simpler code. Klipper uses a very high level language (Python) for most " +"code. The kinematics algorithms, the G-code parsing, the heating and " +"thermistor algorithms, etc. are all written in Python. This makes it easier " +"to develop new functionality." +msgstr "" + +msgid "" +"Custom programmable macros. New G-Code commands can be defined in the " +"printer config file (no code changes are necessary). Those commands are " +"programmable - allowing them to produce different actions depending on the " +"state of the printer." +msgstr "" + +msgid "" +"Builtin API server. In addition to the standard G-Code interface, Klipper " +"supports a rich JSON based application interface. This enables programmers " +"to build external applications with detailed control of the printer." +msgstr "" + +msgid "Additional features" +msgstr "" + +msgid "Klipper supports many standard 3d printer features:" +msgstr "" + +msgid "" +"Support for multiple extruders. Extruders with shared heaters and extruders " +"on independent carriages (IDEX) are also supported." +msgstr "" + +msgid "" +"Automatic bed leveling support. Klipper can be configured for basic bed tilt" +" detection or full mesh bed leveling. If the bed uses multiple Z steppers " +"then Klipper can also level by independently manipulating the Z steppers. " +"Most Z height probes are supported, including BL-Touch probes and servo " +"activated probes." +msgstr "" + +msgid "" +"Automatic delta calibration support. The calibration tool can perform basic " +"height calibration as well as an enhanced X and Y dimension calibration. The" +" calibration can be done with a Z height probe or via manual probing." +msgstr "" + +msgid "Basic thermal heater protection enabled by default." +msgstr "" + +msgid "" +"Support for common LCD displays attached directly to the printer. A default " +"menu is also available. The contents of the display and menu can be fully " +"customized via the config file." +msgstr "" + +msgid "" +"Constant acceleration and \"look-ahead\" support. All printer moves will " +"gradually accelerate from standstill to cruising speed and then decelerate " +"back to a standstill. The incoming stream of G-Code movement commands are " +"queued and analyzed - the acceleration between movements in a similar " +"direction will be optimized to reduce print stalls and improve overall print" +" time." +msgstr "" + +msgid "" +"Klipper implements a \"stepper phase endstop\" algorithm that can improve " +"the accuracy of typical endstop switches. When properly tuned it can improve" +" a print's first layer bed adhesion." +msgstr "" + +msgid "" +"Support for limiting the top speed of short \"zigzag\" moves to reduce " +"printer vibration and noise. See the [kinematics](Kinematics.md) document " +"for more information." +msgstr "" + +msgid "" +"Sample configuration files are available for many common printers. Check the" +" [config directory](../config/) for a list." +msgstr "" + +msgid "" +"To get started with Klipper, read the [installation](Installation.md) guide." +msgstr "" + +msgid "Step Benchmarks" +msgstr "" + +msgid "" +"Below are the results of stepper performance tests. The numbers shown " +"represent total number of steps per second on the micro-controller." +msgstr "" + +msgid "Micro-controller" +msgstr "" + +msgid "3 steppers active" +msgstr "" + +msgid "16Mhz AVR" +msgstr "" + +msgid "20Mhz AVR" +msgstr "" + +msgid "Beaglebone PRU" +msgstr "" + +msgid "686K" +msgstr "" + +#: docs/Features.md:block 1 (header) +msgid "Features" +msgstr "" + +#: docs/Features.md:block 6 (unordered list) +msgid "" +"Standard G-Code support. Common g-code commands that are produced by typical" +" \"slicers\" (SuperSlicer, Cura, PrusaSlicer, etc.) are supported." +msgstr "" + +#: docs/Features.md:block 6 (unordered list) +msgid "" +"Support for common temperature sensors (eg, common thermistors, AD595, " +"AD597, AD849x, PT100, PT1000, MAX6675, MAX31855, MAX31856, MAX31865, BME280," +" HTU21D, DS18B20, and LM75). Custom thermistors and custom analog " +"temperature sensors can also be configured. One can monitor the internal " +"micro-controller temperature sensor and the internal temperature sensor of a" +" Raspberry Pi." +msgstr "" + +#: docs/Features.md:block 6 (unordered list) +msgid "" +"Support for standard fans, nozzle fans, and temperature controlled fans. No " +"need to keep fans running when the printer is idle. Fan speed can be " +"monitored on fans that have a tachometer." +msgstr "" + +#: docs/Features.md:block 6 (unordered list) +msgid "" +"Support for filament presence sensors, filament motion sensors, and filament" +" width sensors." +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1 stepper active" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "157K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "99K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "196K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "123K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "471K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "STM32F042" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "814K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "578K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "866K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "708K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1180K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "818K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1273K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "981K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1690K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1385K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1923K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1351K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "2353K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1622K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "2400K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1636K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "2500K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1674K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "3077K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1885K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "3652K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "2459K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "3913K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "2634K" +msgstr "" + +#: docs/Features.md:block 11 (paragraph) +msgid "" +"Further details on the benchmarks are available in the [Benchmarks " +"document](Benchmarks.md)." +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "STM32G0B1" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "1103K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "790K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "SAMD21" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "STM32F103" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "SAM3X8E" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "SAM4S8C" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "LPC1768" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "LPC1769" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "RP2040" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "SAM4E8E" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "SAMD51" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "STM32F407" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "STM32F446" +msgstr "" + +#: docs/Features.md:block 11 (paragraph) +msgid "" +"If unsure of the micro-controller on a particular board, find the " +"appropriate [config file](../config/), and look for the micro-controller " +"name in the comments at the top of that file." +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "STM32H743" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "9091K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "6061K" +msgstr "" + +#: docs/Features.md:block 3 (unordered list) +msgid "" +"High precision stepper movement. Klipper utilizes an application processor " +"(such as a low-cost Raspberry Pi) when calculating printer movements. The " +"application processor determines when to step each stepper motor, it " +"compresses those events, transmits them to the micro-controller, and then " +"the micro-controller executes each event at the requested time. Each stepper" +" event is scheduled with a precision of 25 micro-seconds or better. The " +"software does not use kinematic estimations (such as the Bresenham " +"algorithm) - instead it calculates precise step times based on the physics " +"of acceleration and the physics of the machine kinematics. More precise " +"stepper movement provides quieter and more stable printer operation." +msgstr "" + +#: docs/Features.md:block 3 (unordered list) +msgid "" +"Klipper is hardware agnostic. One should get the same precise timing " +"independent of the low-level electronics hardware. The Klipper micro-" +"controller code is designed to faithfully follow the schedule provided by " +"the Klipper host software (or prominently alert the user if it is unable " +"to). This makes it easier to use available hardware, to upgrade to new " +"hardware, and to have confidence in the hardware." +msgstr "" + +#: docs/Features.md:block 6 (unordered list) +msgid "" +"Several web interfaces available. Works with Mainsail, Fluidd, OctoPrint and" +" others. This allows the printer to be controlled using a regular web-" +"browser. The same Raspberry Pi that runs Klipper can also run the web " +"interface." +msgstr "" + +#: docs/Features.md:block 6 (unordered list) +msgid "" +"Support for cartesian, delta, corexy, corexz, hybrid-corexy, hybrid-corexz, " +"deltesian, rotary delta, polar, and cable winch style printers." +msgstr "" + +#: docs/Features.md:block 6 (unordered list) +msgid "" +"Run-time \"exclude object\" support. When configured, this module may " +"facilitate canceling of just one object in a multi-part print." +msgstr "" + +#: docs/Features.md:block 6 (unordered list) +msgid "" +"Support for run-time configuration of TMC2130, TMC2208/TMC2224, TMC2209, " +"TMC2660, and TMC5160 stepper motor drivers. There is also support for " +"current control of traditional stepper drivers via AD5206, DAC084S085, " +"MCP4451, MCP4728, MCP4018, and PWM pins." +msgstr "" + +#: docs/Features.md:block 6 (unordered list) +msgid "" +"Support for measuring and recording acceleration using an adxl345, mpu9250, " +"and mpu6050 accelerometers." +msgstr "" + +#: docs/Features.md:block 3 (unordered list) +msgid "" +"Best in class performance. Klipper is able to achieve high stepping rates on" +" both new and old micro-controllers. Even old 8-bit micro-controllers can " +"obtain rates over 175K steps per second. On more recent micro-controllers, " +"several million steps per second are possible. Higher stepper rates enable " +"higher print velocities. The stepper event timing remains precise even at " +"high speeds which improves overall stability." +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "AR100" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "3529K" +msgstr "" + +#: docs/Features.md:block 10 (table) +msgid "2507K" +msgstr "" + +#~ msgid "" +#~ "Best in class performance. Klipper is able to achieve high stepping rates on" +#~ " both new and old micro-controllers. Even old 8bit micro-controllers can " +#~ "obtain rates over 175K steps per second. On more recent micro-controllers, " +#~ "several million steps per second are possible. Higher stepper rates enable " +#~ "higher print velocities. The stepper event timing remains precise even at " +#~ "high speeds which improves overall stability." +#~ msgstr "" + +#~ msgid "" +#~ "High precision stepper movement. Klipper utilizes an application processor " +#~ "(such as a low-cost Raspberry Pi) when calculating printer movements. The " +#~ "application processor determines when to step each stepper motor, it " +#~ "compresses those events, transmits them to the micro-controller, and then " +#~ "the micro-controller executes each event at the requested time. Each stepper" +#~ " event is scheduled with a precision of 25 micro-seconds or better. The " +#~ "software does not use kinematic estimations (such as the Bresenham " +#~ "algorithm) - instead it calculates precise step times based on the physics " +#~ "of acceleration and the physics of the machine kinematics. More precise " +#~ "stepper movement translates to quieter and more stable printer operation." +#~ msgstr "" + +#~ msgid "" +#~ "Works with Octoprint. This allows the printer to be controlled using a " +#~ "regular web-browser. The same Raspberry Pi that runs Klipper can also run " +#~ "Octoprint." +#~ msgstr "" + +#~ msgid "" +#~ "Support for run-time configuration of TMC2130, TMC2208/TMC2224, TMC2209, " +#~ "TMC2660, and TMC5160 stepper motor drivers. There is also support for " +#~ "current control of traditional stepper drivers via AD5206, MCP4451, MCP4728," +#~ " MCP4018, and PWM pins." +#~ msgstr "" + +#~ msgid "" +#~ "Support for measuring and recording acceleration using an adxl345 " +#~ "accelerometer." +#~ msgstr "" + +#~ msgid "" +#~ "Support for cartesian, delta, corexy, corexz, hybrid-corexy, hybrid-corexz, " +#~ "rotary delta, polar, and cable winch style printers." +#~ msgstr "" + +#~ msgid "Arduino Zero (SAMD21)" +#~ msgstr "" + +#~ msgid "\"Blue Pill\" (STM32F103)" +#~ msgstr "" + +#~ msgid "Arduino Due (SAM3X8E)" +#~ msgstr "" + +#~ msgid "Duet2 Maestro (SAM4S8C)" +#~ msgstr "" + +#~ msgid "Smoothieboard (LPC1768)" +#~ msgstr "" + +#~ msgid "Smoothieboard (LPC1769)" +#~ msgstr "" + +#~ msgid "Duet2 Wifi/Eth (SAM4E8E)" +#~ msgstr "" + +#~ msgid "Adafruit Metro M4 (SAMD51)" +#~ msgstr "" + +#~ msgid "BigTreeTech SKR Pro (STM32F407)" +#~ msgstr "" + +#~ msgid "Raspberry Pi Pico (RP2040)" +#~ msgstr "" + +#~ msgid "Fysetc Spider (STM32F446)" +#~ msgstr "" + +#~ msgid "" +#~ "Best in class performance. Klipper is able to achieve high stepping rates on" +#~ " both new and old micro-controllers. Even old 8bit micro-controllers can " +#~ "obtain rates over 175K steps per second. On more recent micro-controllers, " +#~ "rates over 500K steps per second are possible. Higher stepper rates enable " +#~ "higher print velocities. The stepper event timing remains precise even at " +#~ "high speeds which improves overall stability." +#~ msgstr "" + +#~ msgid "Fastest step rate" +#~ msgstr "" + +#~ msgid "154K" +#~ msgstr "" + +#~ msgid "102K" +#~ msgstr "" + +#~ msgid "192K" +#~ msgstr "" + +#~ msgid "127K" +#~ msgstr "" + +#~ msgid "234K" +#~ msgstr "" + +#~ msgid "217K" +#~ msgstr "" + +#~ msgid "387K" +#~ msgstr "" + +#~ msgid "360K" +#~ msgstr "" + +#~ msgid "438K" +#~ msgstr "" + +#~ msgid "564K" +#~ msgstr "" + +#~ msgid "574K" +#~ msgstr "" + +#~ msgid "661K" +#~ msgstr "" + +#~ msgid "680K" +#~ msgstr "" + +#~ msgid "761K" +#~ msgstr "" + +#~ msgid "692K" +#~ msgstr "" + +#~ msgid "922K" +#~ msgstr "" + +#~ msgid "711K" +#~ msgstr "" + +#~ msgid "" +#~ "On AVR platforms, the highest achievable step rate is with just one stepper " +#~ "stepping. On the SAMD21 and STM32F103 the highest step rate is with two " +#~ "simultaneous steppers stepping. On the SAM3X8E, SAM4S8C, SAM4E8E, LPC176x, " +#~ "and PRU the highest step rate is with three simultaneous steppers. On the " +#~ "SAMD51 and STM32F4 the highest step rate is with four simultaneous steppers." +#~ " (Further details on the benchmarks are available in the [Benchmarks " +#~ "document](Benchmarks.md).)" +#~ msgstr "" + +#~ msgid "" +#~ "Standard G-Code support. Common g-code commands that are produced by typical" +#~ " \"slicers\" are supported. One may continue to use Slic3r, Cura, etc. with " +#~ "Klipper." +#~ msgstr "" + +#~ msgid "" +#~ "Support for cartesian, delta, corexy, corexz, rotary delta, polar, and cable" +#~ " winch style printers." +#~ msgstr "" + +#~ msgid "" +#~ "Support for common temperature sensors (eg, common thermistors, AD595, " +#~ "AD597, AD849x, PT100, PT1000, MAX6675, MAX31855, MAX31856, MAX31865, BME280," +#~ " HTU21D, and LM75). Custom thermistors and custom analog temperature sensors" +#~ " can also be configured." +#~ msgstr "" + +#~ msgid "" +#~ "Support for standard fans, nozzle fans, and temperature controlled fans. No " +#~ "need to keep fans running when the printer is idle." +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Kinematics.po b/docs/locales/lt/LC_MESSAGES/Kinematics.po new file mode 100644 index 0000000000..cdb66ad963 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Kinematics.po @@ -0,0 +1,388 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"This document provides an overview of how Klipper implements robot motion " +"(its [kinematics](https://en.wikipedia.org/wiki/Kinematics)). The contents " +"may be of interest to both developers interested in working on the Klipper " +"software as well as users interested in better understanding the mechanics " +"of their machines." +msgstr "" + +msgid "Acceleration" +msgstr "" + +msgid "" +"Klipper implements a constant acceleration scheme whenever the print head " +"changes velocity - the velocity is gradually changed to the new speed " +"instead of suddenly jerking to it. Klipper always enforces acceleration " +"between the tool head and the print. The filament leaving the extruder can " +"be quite fragile - rapid jerks and/or extruder flow changes lead to poor " +"quality and poor bed adhesion. Even when not extruding, if the print head is" +" at the same level as the print then rapid jerking of the head can cause " +"disruption of recently deposited filament. Limiting speed changes of the " +"print head (relative to the print) reduces risks of disrupting the print." +msgstr "" + +msgid "" +"It is also important to limit acceleration so that the stepper motors do not" +" skip or put excessive stress on the machine. Klipper limits the torque on " +"each stepper by virtue of limiting the acceleration of the print head. " +"Enforcing acceleration at the print head naturally also limits the torque of" +" the steppers that move the print head (the inverse is not always true)." +msgstr "" + +msgid "" +"Klipper implements constant acceleration. The key formula for constant " +"acceleration is:" +msgstr "" + +msgid "Trapezoid generator" +msgstr "" + +msgid "" +"Klipper uses a traditional \"trapezoid generator\" to model the motion of " +"each move - each move has a start speed, it accelerates to a cruising speed " +"at constant acceleration, it cruises at a constant speed, and then " +"decelerates to the end speed using constant acceleration." +msgstr "" + +msgid "![trapezoid](img/trapezoid.svg.png)" +msgstr "" + +msgid "" +"It's called a \"trapezoid generator\" because a velocity diagram of the move" +" looks like a trapezoid." +msgstr "" + +msgid "" +"The cruising speed is always greater than or equal to both the start speed " +"and the end speed. The acceleration phase may be of zero duration (if the " +"start speed is equal to the cruising speed), the cruising phase may be of " +"zero duration (if the move immediately starts decelerating after " +"acceleration), and/or the deceleration phase may be of zero duration (if the" +" end speed is equal to the cruising speed)." +msgstr "" + +msgid "![trapezoids](img/trapezoids.svg.png)" +msgstr "" + +msgid "Look-ahead" +msgstr "" + +msgid "" +"The \"look-ahead\" system is used to determine cornering speeds between " +"moves." +msgstr "" + +msgid "Consider the following two moves contained on an XY plane:" +msgstr "" + +msgid "![corner](img/corner.svg.png)" +msgstr "" + +msgid "" +"In the above situation it is possible to fully decelerate after the first " +"move and then fully accelerate at the start of the next move, but that is " +"not ideal as all that acceleration and deceleration would greatly increase " +"the print time and the frequent changes in extruder flow would result in " +"poor print quality." +msgstr "" + +msgid "" +"To solve this, the \"look-ahead\" mechanism queues multiple incoming moves " +"and analyzes the angles between moves to determine a reasonable speed that " +"can be obtained during the \"junction\" between two moves. If the next move " +"is nearly in the same direction then the head need only slow down a little " +"(if at all)." +msgstr "" + +msgid "![lookahead](img/lookahead.svg.png)" +msgstr "" + +msgid "" +"However, if the next move forms an acute angle (the head is going to travel " +"in nearly a reverse direction on the next move) then only a small junction " +"speed is permitted." +msgstr "" + +msgid "![lookahead](img/lookahead-slow.svg.png)" +msgstr "" + +msgid "" +"The junction speeds are determined using \"approximated centripetal " +"acceleration\". Best [described by the " +"author](https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/)." +" However, in Klipper, junction speeds are configured by specifying the " +"desired speed that a 90° corner should have (the \"square corner " +"velocity\"), and the junction speeds for other angles are derived from that." +msgstr "" + +msgid "Key formula for look-ahead:" +msgstr "" + +msgid "Smoothed look-ahead" +msgstr "" + +msgid "" +"Klipper also implements a mechanism for smoothing out the motions of short " +"\"zigzag\" moves. Consider the following moves:" +msgstr "" + +msgid "![zigzag](img/zigzag.svg.png)" +msgstr "" + +msgid "" +"In the above, the frequent changes from acceleration to deceleration can " +"cause the machine to vibrate which causes stress on the machine and " +"increases the noise. To reduce this, Klipper tracks both regular move " +"acceleration as well as a virtual \"acceleration to deceleration\" rate. " +"Using this system, the top speed of these short \"zigzag\" moves are limited" +" to smooth out the printer motion:" +msgstr "" + +msgid "![smoothed](img/smoothed.svg.png)" +msgstr "" + +msgid "" +"Specifically, the code calculates what the velocity of each move would be if" +" it were limited to this virtual \"acceleration to deceleration\" rate (half" +" the normal acceleration rate by default). In the above picture the dashed " +"gray lines represent this virtual acceleration rate for the first move. If a" +" move can not reach its full cruising speed using this virtual acceleration " +"rate then its top speed is reduced to the maximum speed it could obtain at " +"this virtual acceleration rate. For most moves the limit will be at or above" +" the move's existing limits and no change in behavior is induced. For short " +"zigzag moves, however, this limit reduces the top speed. Note that it does " +"not change the actual acceleration within the move - the move continues to " +"use the normal acceleration scheme up to its adjusted top-speed." +msgstr "" + +msgid "Generating steps" +msgstr "" + +msgid "" +"Once the look-ahead process completes, the print head movement for the given" +" move is fully known (time, start position, end position, velocity at each " +"point) and it is possible to generate the step times for the move. This " +"process is done within \"kinematic classes\" in the Klipper code. Outside of" +" these kinematic classes, everything is tracked in millimeters, seconds, and" +" in cartesian coordinate space. It's the task of the kinematic classes to " +"convert from this generic coordinate system to the hardware specifics of the" +" particular printer." +msgstr "" + +msgid "" +"Klipper uses an [iterative solver](https://en.wikipedia.org/wiki/Root-" +"finding_algorithm) to generate the step times for each stepper. The code " +"contains the formulas to calculate the ideal cartesian coordinates of the " +"head at each moment in time, and it has the kinematic formulas to calculate " +"the ideal stepper positions based on those cartesian coordinates. With these" +" formulas, Klipper can determine the ideal time that the stepper should be " +"at each step position. The given steps are then scheduled at these " +"calculated times." +msgstr "" + +msgid "" +"The key formula to determine how far a move should travel under constant " +"acceleration is:" +msgstr "" + +msgid "and the key formula for movement with constant velocity is:" +msgstr "" + +msgid "" +"The key formulas for determining the cartesian coordinate of a move given a " +"move distance is:" +msgstr "" + +msgid "Cartesian Robots" +msgstr "" + +msgid "" +"Generating steps for cartesian printers is the simplest case. The movement " +"on each axis is directly related to the movement in cartesian space." +msgstr "" + +msgid "Key formulas:" +msgstr "" + +msgid "CoreXY Robots" +msgstr "" + +msgid "" +"Generating steps on a CoreXY machine is only a little more complex than " +"basic cartesian robots. The key formulas are:" +msgstr "" + +msgid "Delta Robots" +msgstr "" + +msgid "Step generation on a delta robot is based on Pythagoras's theorem:" +msgstr "" + +msgid "Stepper motor acceleration limits" +msgstr "" + +msgid "" +"With delta kinematics it is possible for a move that is accelerating in " +"cartesian space to require an acceleration on a particular stepper motor " +"greater than the move's acceleration. This can occur when a stepper arm is " +"more horizontal than vertical and the line of movement passes near that " +"stepper's tower. Although these moves could require a stepper motor " +"acceleration greater than the printer's maximum configured move " +"acceleration, the effective mass moved by that stepper would be smaller. " +"Thus the higher stepper acceleration does not result in significantly higher" +" stepper torque and it is therefore considered harmless." +msgstr "" + +msgid "" +"However, to avoid extreme cases, Klipper enforces a maximum ceiling on " +"stepper acceleration of three times the printer's configured maximum move " +"acceleration. (Similarly, the maximum velocity of the stepper is limited to " +"three times the maximum move velocity.) In order to enforce this limit, " +"moves at the extreme edge of the build envelope (where a stepper arm may be " +"nearly horizontal) will have a lower maximum acceleration and velocity." +msgstr "" + +msgid "Extruder kinematics" +msgstr "" + +msgid "" +"Klipper implements extruder motion in its own kinematic class. Since the " +"timing and speed of each print head movement is fully known for each move, " +"it's possible to calculate the step times for the extruder independently " +"from the step time calculations of the print head movement." +msgstr "" + +msgid "" +"Basic extruder movement is simple to calculate. The step time generation " +"uses the same formulas that cartesian robots use:" +msgstr "" + +msgid "Pressure advance" +msgstr "" + +msgid "" +"Experimentation has shown that it's possible to improve the modeling of the " +"extruder beyond the basic extruder formula. In the ideal case, as an " +"extrusion move progresses, the same volume of filament should be deposited " +"at each point along the move and there should be no volume extruded after " +"the move. Unfortunately, it's common to find that the basic extrusion " +"formulas cause too little filament to exit the extruder at the start of " +"extrusion moves and for excess filament to extrude after extrusion ends. " +"This is often referred to as \"ooze\"." +msgstr "" + +msgid "![ooze](img/ooze.svg.png)" +msgstr "" + +msgid "" +"The \"pressure advance\" system attempts to account for this by using a " +"different model for the extruder. Instead of naively believing that each " +"mm^3 of filament fed into the extruder will result in that amount of mm^3 " +"immediately exiting the extruder, it uses a model based on pressure. " +"Pressure increases when filament is pushed into the extruder (as in [Hooke's" +" law](https://en.wikipedia.org/wiki/Hooke%27s_law)) and the pressure " +"necessary to extrude is dominated by the flow rate through the nozzle " +"orifice (as in [Poiseuille's " +"law](https://en.wikipedia.org/wiki/Poiseuille_law)). The key idea is that " +"the relationship between filament, pressure, and flow rate can be modeled " +"using a linear coefficient:" +msgstr "" + +msgid "" +"See the [pressure advance](Pressure_Advance.md) document for information on " +"how to find this pressure advance coefficient." +msgstr "" + +msgid "" +"The basic pressure advance formula can cause the extruder motor to make " +"sudden velocity changes. Klipper implements \"smoothing\" of the extruder " +"movement to avoid this." +msgstr "" + +msgid "![pressure-advance](img/pressure-velocity.png)" +msgstr "" + +msgid "" +"The above graph shows an example of two extrusion moves with a non-zero " +"cornering velocity between them. Note that the pressure advance system " +"causes additional filament to be pushed into the extruder during " +"acceleration. The higher the desired filament flow rate, the more filament " +"must be pushed in during acceleration to account for pressure. During head " +"deceleration the extra filament is retracted (the extruder will have a " +"negative velocity)." +msgstr "" + +msgid "" +"The \"smoothing\" is implemented using a weighted average of the extruder " +"position over a small time period (as specified by the " +"`pressure_advance_smooth_time` config parameter). This averaging can span " +"multiple g-code moves. Note how the extruder motor will start moving prior " +"to the nominal start of the first extrusion move and will continue to move " +"after the nominal end of the last extrusion move." +msgstr "" + +msgid "Key formula for \"smoothed pressure advance\":" +msgstr "" + +msgid "velocity(time) = start_velocity + accel*time\n" +msgstr "" + +msgid "end_velocity^2 = start_velocity^2 + 2*accel*move_distance\n" +msgstr "" + +msgid "move_distance = (start_velocity + .5 * accel * move_time) * move_time\n" +msgstr "" + +msgid "move_distance = cruise_velocity * move_time\n" +msgstr "" + +msgid "" +"cartesian_x_position = start_x + move_distance * total_x_movement / total_movement\n" +"cartesian_y_position = start_y + move_distance * total_y_movement / total_movement\n" +"cartesian_z_position = start_z + move_distance * total_z_movement / total_movement\n" +msgstr "" + +msgid "" +"stepper_x_position = cartesian_x_position\n" +"stepper_y_position = cartesian_y_position\n" +"stepper_z_position = cartesian_z_position\n" +msgstr "" + +msgid "" +"stepper_a_position = cartesian_x_position + cartesian_y_position\n" +"stepper_b_position = cartesian_x_position - cartesian_y_position\n" +"stepper_z_position = cartesian_z_position\n" +msgstr "" + +msgid "" +"stepper_position = (sqrt(arm_length^2\n" +" - (cartesian_x_position - tower_x_position)^2\n" +" - (cartesian_y_position - tower_y_position)^2)\n" +" + cartesian_z_position)\n" +msgstr "" + +msgid "stepper_position = requested_e_position\n" +msgstr "" + +msgid "" +"pa_position = nominal_position + pressure_advance_coefficient * " +"nominal_velocity\n" +msgstr "" + +msgid "" +"smooth_pa_position(t) =\n" +" ( definitive_integral(pa_position(x) * (smooth_time/2 - abs(t - x)) * dx,\n" +" from=t-smooth_time/2, to=t+smooth_time/2)\n" +" / (smooth_time/2)^2 )\n" +msgstr "" + +#: docs/Kinematics.md:block 1 (header) +msgid "Kinematics" +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Manual_Level.po b/docs/locales/lt/LC_MESSAGES/Manual_Level.po new file mode 100644 index 0000000000..c83bcb1a03 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Manual_Level.po @@ -0,0 +1,354 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"This document describes tools for calibrating a Z endstop and for performing" +" adjustments to bed leveling screws." +msgstr "" + +msgid "Calibrating a Z endstop" +msgstr "" + +msgid "" +"An accurate Z endstop position is critical to obtaining high quality prints." +msgstr "" + +msgid "" +"Note, though, the accuracy of the Z endstop switch itself can be a limiting " +"factor. If one is using Trinamic stepper motor drivers then consider " +"enabling [endstop phase](Endstop_Phase.md) detection to improve the accuracy" +" of the switch." +msgstr "" + +msgid "" +"To perform a Z endstop calibration, home the printer, command the head to " +"move to a Z position that is at least five millimeters above the bed (if it " +"is not already), command the head to move to an XY position near the center " +"of the bed, then navigate to the OctoPrint terminal tab and run:" +msgstr "" + +msgid "" +"Then follow the steps described at [\"the paper test\"](Bed_Level.md#the-" +"paper-test) to determine the actual distance between the nozzle and bed at " +"the given location. Once those steps are complete one can `ACCEPT` the " +"position and save the results to the config file with:" +msgstr "" + +msgid "" +"It's preferable to use a Z endstop switch on the opposite end of the Z axis " +"from the bed. (Homing away from the bed is more robust as then it is " +"generally always safe to home the Z.) However, if one must home towards the " +"bed it is recommended to adjust the endstop so that it triggers a small " +"distance (eg, .5mm) above the bed. Almost all endstop switches can safely be" +" depressed a small distance beyond their trigger point. When this is done, " +"one should find that the `Z_ENDSTOP_CALIBRATE` command reports a small " +"positive value (eg, .5mm) for the Z position_endstop. Triggering the endstop" +" while it is still some distance from the bed reduces the risk of " +"inadvertent bed crashes." +msgstr "" + +msgid "" +"Some printers have the ability to manually adjust the location of the " +"physical endstop switch. However, it's recommended to perform Z endstop " +"positioning in software with Klipper - once the physical location of the " +"endstop is in a convenient location, one can make any further adjustments by" +" running Z_ENDSTOP_CALIBRATE or by manually updating the Z position_endstop " +"in the configuration file." +msgstr "" + +msgid "Adjusting bed leveling screws" +msgstr "" + +msgid "" +"The secret to getting good bed leveling with bed leveling screws is to " +"utilize the printer's high precision motion system during the bed leveling " +"process itself. This is done by commanding the nozzle to a position near " +"each bed screw and then adjusting that screw until the bed is a set distance" +" from the nozzle. Klipper has a tool to assist with this. In order to use " +"the tool it is necessary to specify each screw XY location." +msgstr "" + +msgid "" +"This is done by creating a `[bed_screws]` config section. For example, it " +"might look something similar to:" +msgstr "" + +msgid "" +"If a bed screw is under the bed, then specify the XY position directly above" +" the screw. If the screw is outside the bed then specify an XY position " +"closest to the screw that is still within the range of the bed." +msgstr "" + +msgid "" +"Once the config file is ready, run `RESTART` to load that config, and then " +"one can start the tool by running:" +msgstr "" + +msgid "" +"This tool will move the printer's nozzle to each screw XY location and then " +"move the nozzle to a Z=0 height. At this point one can use the \"paper " +"test\" to adjust the bed screw directly under the nozzle. See the " +"information described in [\"the paper test\"](Bed_Level.md#the-paper-test), " +"but adjust the bed screw instead of commanding the nozzle to different " +"heights. Adjust the bed screw until there is a small amount of friction when" +" pushing the paper back and forth." +msgstr "" + +msgid "" +"Once the screw is adjusted so that a small amount of friction is felt, run " +"either the `ACCEPT` or `ADJUSTED` command. Use the `ADJUSTED` command if the" +" bed screw needed an adjustment (typically anything more than about 1/8th of" +" a turn of the screw). Use the `ACCEPT` command if no significant adjustment" +" is necessary. Both commands will cause the tool to proceed to the next " +"screw. (When an `ADJUSTED` command is used, the tool will schedule an " +"additional cycle of bed screw adjustments; the tool completes successfully " +"when all bed screws are verified to not require any significant " +"adjustments.) One can use the `ABORT` command to exit the tool early." +msgstr "" + +msgid "" +"This system works best when the printer has a flat printing surface (such as" +" glass) and has straight rails. Upon successful completion of the bed " +"leveling tool the bed should be ready for printing." +msgstr "" + +msgid "Fine grained bed screw adjustments" +msgstr "" + +msgid "" +"If the printer uses three bed screws and all three screws are under the bed," +" then it may be possible to perform a second \"high precision\" bed leveling" +" step. This is done by commanding the nozzle to locations where the bed " +"moves a larger distance with each bed screw adjustment." +msgstr "" + +msgid "For example, consider a bed with screws at locations A, B, and C:" +msgstr "" + +msgid "![bed_screws](img/bed_screws.svg.png)" +msgstr "" + +msgid "" +"For each adjustment made to the bed screw at location C, the bed will swing " +"along a pendulum defined by the remaining two bed screws (shown here as a " +"green line). In this situation, each adjustment to the bed screw at C will " +"move the bed at position D a further amount than directly at C. It is thus " +"possible to make an improved C screw adjustment when the nozzle is at " +"position D." +msgstr "" + +msgid "" +"To enable this feature, one would determine the additional nozzle " +"coordinates and add them to the config file. For example, it might look " +"like:" +msgstr "" + +msgid "" +"When this feature is enabled, the `BED_SCREWS_ADJUST` tool will first prompt" +" for coarse adjustments directly above each screw position, and once those " +"are accepted, it will prompt for fine adjustments at the additional " +"locations. Continue to use `ACCEPT` and `ADJUSTED` at each position." +msgstr "" + +msgid "Adjusting bed leveling screws using the bed probe" +msgstr "" + +msgid "" +"This is another way to calibrate the bed level using the bed probe. To use " +"it you must have a Z probe (BL Touch, Inductive sensor, etc)." +msgstr "" + +msgid "" +"To enable this feature, one would determine the nozzle coordinates such that" +" the Z probe is above the screws, and then add them to the config file. For " +"example, it might look like:" +msgstr "" + +msgid "This means that:" +msgstr "" + +msgid "" +"Repeat the process several times until you get a good level bed - normally " +"when all adjustments are below 6 minutes." +msgstr "" + +msgid "" +"If using a probe that is mounted on the side of the hotend (that is, it has " +"an X or Y offset) then note that adjusting the bed tilt will invalidate any " +"previous probe calibration that was performed with a tilted bed. Be sure to " +"run [probe calibration](Probe_Calibrate.md) after the bed screws have been " +"adjusted." +msgstr "" + +msgid "" +"The `MAX_DEVIATION` parameter is useful when a saved bed mesh is used, to " +"ensure that the bed level has not drifted too far from where it was when the" +" mesh was created. For example, `SCREWS_TILT_CALCULATE MAX_DEVIATION=0.01` " +"can be added to the custom start gcode of the slicer before the mesh is " +"loaded. It will abort the print if the configured limit is exceeded (0.01mm " +"in this example), giving the user a chance to adjust the screws and restart " +"the print." +msgstr "" + +msgid "Z_ENDSTOP_CALIBRATE\n" +msgstr "" + +msgid "SAVE_CONFIG\n" +msgstr "" + +msgid "BED_SCREWS_ADJUST\n" +msgstr "" + +msgid "" +"The screw1 is always the reference point for the others, so the system " +"assumes that screw1 is at the correct height. Always run `G28` first and " +"then run `SCREWS_TILT_CALCULATE` - it should produce output similar to:" +msgstr "" + +msgid "" +"Send: G28\n" +"Recv: ok\n" +"Send: SCREWS_TILT_CALCULATE\n" +"Recv: // 01:20 means 1 full turn and 20 minutes, CW=clockwise, CCW=counter-clockwise\n" +"Recv: // front left screw (base) : x=-5.0, y=30.0, z=2.48750\n" +"Recv: // front right screw : x=155.0, y=30.0, z=2.36000 : adjust CW 01:15\n" +"Recv: // rear right screw : y=155.0, y=190.0, z=2.71500 : adjust CCW 00:50\n" +"Recv: // read left screw : x=-5.0, y=190.0, z=2.47250 : adjust CW 00:02\n" +"Recv: ok\n" +msgstr "" + +msgid "" +"The `DIRECTION` parameter is useful if you can turn your bed adjustment " +"screws in one direction only. For example, you might have screws that start " +"tightened in their lowest (or highest) possible position, which can only be " +"turned in a single direction, to raise (or lower) the bed. If you can only " +"turn the screws clockwise, run `SCREWS_TILT_CALCULATE DIRECTION=CW`. If you " +"can only turn them counter-clockwise, run `SCREWS_TILT_CALCULATE " +"DIRECTION=CCW`. A suitable reference point will be chosen such that the bed " +"can be leveled by turning all the screws in the given direction." +msgstr "" + +#: docs/Manual_Level.md:block 1 (header) +msgid "Manual leveling" +msgstr "" + +#: docs/Manual_Level.md:block 37 (unordered list) +msgid "front left screw is the reference point you must not change it." +msgstr "" + +#: docs/Manual_Level.md:block 37 (unordered list) +msgid "" +"front right screw must be turned clockwise 1 full turn and a quarter turn" +msgstr "" + +#: docs/Manual_Level.md:block 37 (unordered list) +msgid "rear right screw must be turned counter-clockwise 50 minutes" +msgstr "" + +#: docs/Manual_Level.md:block 15 (code) +msgid "" +"[bed_screws]\n" +"screw1: 100, 50\n" +"screw2: 100, 150\n" +"screw3: 150, 100\n" +msgstr "" + +#: docs/Manual_Level.md:block 28 (code) +msgid "" +"[bed_screws]\n" +"screw1: 100, 50\n" +"screw1_fine_adjust: 0, 0\n" +"screw2: 100, 150\n" +"screw2_fine_adjust: 300, 300\n" +"screw3: 150, 100\n" +"screw3_fine_adjust: 0, 100\n" +msgstr "" + +#: docs/Manual_Level.md:block 33 (code) +msgid "" +"[screws_tilt_adjust]\n" +"screw1: -5, 30\n" +"screw1_name: front left screw\n" +"screw2: 155, 30\n" +"screw2_name: front right screw\n" +"screw3: 155, 190\n" +"screw3_name: rear right screw\n" +"screw4: -5, 190\n" +"screw4_name: rear left screw\n" +"horizontal_move_z: 10.\n" +"speed: 50.\n" +"screw_thread: CW-M3\n" +msgstr "" + +#: docs/Manual_Level.md:block 37 (unordered list) +msgid "rear left screw must be turned clockwise 2 minutes (not need it's ok)" +msgstr "" + +#: docs/Manual_Level.md:block 38 (paragraph) +msgid "" +"Note that \"minutes\" refers to \"minutes of a clock face\". So, for " +"example, 15 minutes is a quarter of a full turn." +msgstr "" + +#~ msgid "read left screw must be turned clockwise 2 minutes (not need it's ok)" +#~ msgstr "" + +#~ msgid "" +#~ "[bed_screws]\n" +#~ "screw1: 100,50\n" +#~ "screw2: 100,150\n" +#~ "screw3: 150,100\n" +#~ msgstr "" + +#~ msgid "" +#~ "[bed_screws]\n" +#~ "screw1: 100,50\n" +#~ "screw1_fine_adjust: 0,0\n" +#~ "screw2: 100,150\n" +#~ "screw2_fine_adjust: 300,300\n" +#~ "screw3: 150,100\n" +#~ "screw3_fine_adjust: 0,100\n" +#~ msgstr "" + +#~ msgid "" +#~ "[screws_tilt_adjust]\n" +#~ "screw1: -5,30\n" +#~ "screw1_name: front left screw\n" +#~ "screw2: 155,30\n" +#~ "screw2_name: front right screw\n" +#~ "screw3: 155,190\n" +#~ "screw3_name: rear right screw\n" +#~ "screw4: -5,190\n" +#~ "screw4_name: rear left screw\n" +#~ "horizontal_move_z: 10.\n" +#~ "speed: 50.\n" +#~ "screw_thread: CW-M3\n" +#~ msgstr "" + +#~ msgid "" +#~ "- front left screw is the reference point you must not change it.\n" +#~ "- front right screw must be turned clockwise 1 full turn and a quarter turn\n" +#~ "- rear right screw must be turned counter-clockwise 50 minutes\n" +#~ "- read left screw must be turned clockwise 2 minutes (not need it's ok)\n" +#~ msgstr "" + +#~ msgid "" +#~ "The screw1 is always the reference point for the others, so the system " +#~ "assumes that screw1 is in the correct height. Always run `G28` first and " +#~ "then run `SCREWS_TILT_CALCULATE` - it should produce output similar to:" +#~ msgstr "" + +#~ msgid "" +#~ "Send: G28\n" +#~ "Recv: ok\n" +#~ "Send: SCREWS_TILT_CALCULATE\n" +#~ "Recv: // front left screw (Base): X -5.0, Y 30.0, Z 2.48750\n" +#~ "Recv: // front right screw : X 155.0, Y 30.0, Z 2.36000 : Adjust -> CW 01:15\n" +#~ "Recv: // rear right screw : X 155.0, Y 190.0, Z 2.71500 : Adjust -> CCW 00:50\n" +#~ "Recv: // read left screw : X -5.0, Y 190.0, Z 2.47250 : Adjust -> CW 00:02\n" +#~ "Recv: ok\n" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Measuring_Resonances.po b/docs/locales/lt/LC_MESSAGES/Measuring_Resonances.po new file mode 100644 index 0000000000..ba2c870e2d --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Measuring_Resonances.po @@ -0,0 +1,1684 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "Measuring Resonances" +msgstr "" + +msgid "Installation instructions" +msgstr "" + +msgid "Wiring" +msgstr "" + +msgid "" +"You need to connect ADXL345 to your Raspberry Pi via SPI. Note that the I2C " +"connection, which is suggested by ADXL345 documentation, has too low " +"throughput and **will not work**. The recommended connection scheme:" +msgstr "" + +msgid "ADXL345 pin" +msgstr "" + +msgid "RPi pin" +msgstr "" + +msgid "RPi pin name" +msgstr "" + +msgid "3V3 (or VCC)" +msgstr "" + +msgid "01" +msgstr "" + +msgid "3.3v DC power" +msgstr "" + +msgid "GND" +msgstr "" + +msgid "06" +msgstr "" + +msgid "Ground" +msgstr "" + +msgid "CS" +msgstr "" + +msgid "24" +msgstr "" + +msgid "GPIO08 (SPI0_CE0_N)" +msgstr "" + +msgid "SDO" +msgstr "" + +msgid "21" +msgstr "" + +msgid "GPIO09 (SPI0_MISO)" +msgstr "" + +msgid "SDA" +msgstr "" + +msgid "19" +msgstr "" + +msgid "GPIO10 (SPI0_MOSI)" +msgstr "" + +msgid "SCL" +msgstr "" + +msgid "23" +msgstr "" + +msgid "GPIO11 (SPI0_SCLK)" +msgstr "" + +msgid "Fritzing wiring diagrams for some of the ADXL345 boards:" +msgstr "" + +msgid "![ADXL345-Rpi](img/adxl345-fritzing.png)" +msgstr "" + +msgid "Mounting the accelerometer" +msgstr "" + +msgid "" +"The accelerometer must be attached to the toolhead. One needs to design a " +"proper mount that fits their own 3D printer. It is better to align the axes " +"of the accelerometer with the printer's axes (but if it makes it more " +"convenient, axes can be swapped - i.e. no need to align X axis with X and so" +" forth - it should be fine even if Z axis of accelerometer is X axis of the " +"printer, etc.)." +msgstr "" + +msgid "An example of mounting ADXL345 on the SmartEffector:" +msgstr "" + +msgid "![ADXL345 on SmartEffector](img/adxl345-mount.jpg)" +msgstr "" + +msgid "" +"Note that on a bed slinger printer one must design 2 mounts: one for the " +"toolhead and one for the bed, and run the measurements twice. See the " +"corresponding [section](#bed-slinger-printers) for more details." +msgstr "" + +msgid "" +"**Attention:** make sure the accelerometer and any screws that hold it in " +"place do not touch any metal parts of the printer. Basically, the mount must" +" be designed such as to ensure the electrical isolation of the accelerometer" +" from the printer frame. Failing to ensure that can create a ground loop in " +"the system that may damage the electronics." +msgstr "" + +msgid "Software installation" +msgstr "" + +msgid "" +"Make sure the Linux SPI driver is enabled by running `sudo raspi-config` and" +" enabling SPI under the \"Interfacing options\" menu." +msgstr "" + +msgid "" +"It is advised to start with 1 probe point, in the middle of the print bed, " +"slightly above it." +msgstr "" + +msgid "Restart Klipper via the `RESTART` command." +msgstr "" + +msgid "Measuring the resonances" +msgstr "" + +msgid "Checking the setup" +msgstr "" + +msgid "Now you can test a connection." +msgstr "" + +msgid "" +"For \"non bed-slingers\" (e.g. one accelerometer), in Octoprint, enter " +"`ACCELEROMETER_QUERY`" +msgstr "" + +msgid "" +"For \"bed-slingers\" (e.g. more than one accelerometer), enter " +"`ACCELEROMETER_QUERY CHIP=` where `` is the name of the chip as-" +"entered, e.g. `CHIP=bed` (see: [bed-slinger](#bed-slinger-printers)) for all" +" installed accelerometer chips." +msgstr "" + +msgid "" +"You should see the current measurements from the accelerometer, including " +"the free-fall acceleration, e.g." +msgstr "" + +msgid "" +"Next, try running `MEASURE_AXES_NOISE` in Octoprint, you should get some " +"baseline numbers for the noise of accelerometer on the axes (should be " +"somewhere in the range of ~1-100). Too high axes noise (e.g. 1000 and more) " +"can be indicative of the sensor issues, problems with its power, or too " +"noisy imbalanced fans on a 3D printer." +msgstr "" + +msgid "Now you can run some real-life tests. Run the following command:" +msgstr "" + +msgid "" +"Note that it will create vibrations on X axis. It will also disable input " +"shaping if it was enabled previously, as it is not valid to run the " +"resonance testing with the input shaper enabled." +msgstr "" + +msgid "" +"**Attention!** Be sure to observe the printer for the first time, to make " +"sure the vibrations do not become too violent (`M112` command can be used to" +" abort the test in case of emergency; hopefully it will not come to this " +"though). If the vibrations do get too strong, you can attempt to specify a " +"lower than the default value for `accel_per_hz` parameter in " +"`[resonance_tester]` section, e.g." +msgstr "" + +msgid "If it works for X axis, run for Y axis as well:" +msgstr "" + +msgid "" +"This script will generate the charts `/tmp/shaper_calibrate_x.png` and " +"`/tmp/shaper_calibrate_y.png` with frequency responses. You will also get " +"the suggested frequencies for each input shaper, as well as which input " +"shaper is recommended for your setup. For example:" +msgstr "" + +msgid "![Resonances](img/calibrate-y.png)" +msgstr "" + +msgid "" +"The suggested configuration can be added to `[input_shaper]` section of " +"`printer.cfg`, e.g.:" +msgstr "" + +msgid "" +"or you can choose some other configuration yourself based on the generated " +"charts: peaks in the power spectral density on the charts correspond to the " +"resonance frequencies of the printer." +msgstr "" + +msgid "Bed-slinger printers" +msgstr "" + +msgid "" +"If your printer is a bed slinger printer, you will need to change the " +"location of the accelerometer between the measurements for X and Y axes: " +"measure the resonances of X axis with the accelerometer attached to the " +"toolhead and the resonances of Y axis - to the bed (the usual bed slinger " +"setup)." +msgstr "" + +msgid "" +"Then the commands `TEST_RESONANCES AXIS=X` and `TEST_RESONANCES AXIS=Y` will" +" use the correct accelerometer for each axis." +msgstr "" + +msgid "Max smoothing" +msgstr "" + +msgid "" +"Keep in mind that the input shaper can create some smoothing in parts. " +"Automatic tuning of the input shaper performed by `calibrate_shaper.py` " +"script or `SHAPER_CALIBRATE` command tries not to exacerbate the smoothing, " +"but at the same time they try to minimize the resulting vibrations. " +"Sometimes they can make a sub-optimal choice of the shaper frequency, or " +"maybe you simply prefer to have less smoothing in parts at the expense of a " +"larger remaining vibrations. In these cases, you can request to limit the " +"maximum smoothing from the input shaper." +msgstr "" + +msgid "Let's consider the following results from the automatic tuning:" +msgstr "" + +msgid "![Resonances](img/calibrate-x.png)" +msgstr "" + +msgid "" +"Note that the reported `smoothing` values are some abstract projected " +"values. These values can be used to compare different configurations: the " +"higher the value, the more smoothing a shaper will create. However, these " +"smoothing scores do not represent any real measure of smoothing, because the" +" actual smoothing depends on [`max_accel`](#selecting-max-accel) and " +"`square_corner_velocity` parameters. Therefore, you should print some test " +"prints to see how much smoothing exactly a chosen configuration creates." +msgstr "" + +msgid "" +"In the example above the suggested shaper parameters are not bad, but what " +"if you want to get less smoothing on the X axis? You can try to limit the " +"maximum shaper smoothing using the following command:" +msgstr "" + +msgid "" +"which limits the smoothing to 0.2 score. Now you can get the following " +"result:" +msgstr "" + +msgid "![Resonances](img/calibrate-x-max-smoothing.png)" +msgstr "" + +msgid "" +"If you compare to the previously suggested parameters, the vibrations are a " +"bit larger, but the smoothing is significantly smaller than previously, " +"allowing larger maximum acceleration." +msgstr "" + +msgid "" +"When deciding which `max_smoothing` parameter to choose, you can use a " +"trial-and-error approach. Try a few different values and see which results " +"you get. Note that the actual smoothing produced by the input shaper " +"depends, primarily, on the lowest resonance frequency of the printer: the " +"higher the frequency of the lowest resonance - the smaller the smoothing. " +"Therefore, if you request the script to find a configuration of the input " +"shaper with the unrealistically small smoothing, it will be at the expense " +"of increased ringing at the lowest resonance frequencies (which are, " +"typically, also more prominently visible in prints). So, always double-check" +" the projected remaining vibrations reported by the script and make sure " +"they are not too high." +msgstr "" + +msgid "" +"Note that if you chose a good `max_smoothing` value for both of your axes, " +"you can store it in the `printer.cfg` as" +msgstr "" + +msgid "" +"Then, if you [rerun](#input-shaper-re-calibration) the input shaper auto-" +"tuning using `SHAPER_CALIBRATE` Klipper command in the future, it will use " +"the stored `max_smoothing` value as a reference." +msgstr "" + +msgid "Selecting max_accel" +msgstr "" + +msgid "" +"Since the input shaper can create some smoothing in parts, especially at " +"high accelerations, you will still need to choose the `max_accel` value that" +" does not create too much smoothing in the printed parts. A calibration " +"script provides an estimate for `max_accel` parameter that should not create" +" too much smoothing. Note that the `max_accel` as displayed by the " +"calibration script is only a theoretical maximum at which the respective " +"shaper is still able to work without producing too much smoothing. It is by " +"no means a recommendation to set this acceleration for printing. The maximum" +" acceleration your printer is able to sustain depends on its mechanical " +"properties and the maximum torque of the used stepper motors. Therefore, it " +"is suggested to set `max_accel` in `[printer]` section that does not exceed " +"the estimated values for X and Y axes, likely with some conservative safety " +"margin." +msgstr "" + +msgid "" +"Alternatively, follow [this](Resonance_Compensation.md#selecting-max_accel) " +"part of the input shaper tuning guide and print the test model to choose " +"`max_accel` parameter experimentally." +msgstr "" + +msgid "" +"The same notice applies to the input shaper [auto-calibration](#input-" +"shaper-auto-calibration) with `SHAPER_CALIBRATE` command: it is still " +"necessary to choose the right `max_accel` value after the auto-calibration, " +"and the suggested acceleration limits will not be applied automatically." +msgstr "" + +msgid "" +"If you are doing a shaper re-calibration and the reported smoothing for the " +"suggested shaper configuration is almost the same as what you got during the" +" previous calibration, this step can be skipped." +msgstr "" + +msgid "Input Shaper auto-calibration" +msgstr "" + +msgid "" +"Besides manually choosing the appropriate parameters for the input shaper " +"feature, it is also possible to run the auto-tuning for the input shaper " +"directly from Klipper. Run the following command via Octoprint terminal:" +msgstr "" + +msgid "" +"This will run the full test for both axes and generate the csv output " +"(`/tmp/calibration_data_*.csv` by default) for the frequency response and " +"the suggested input shapers. You will also get the suggested frequencies for" +" each input shaper, as well as which input shaper is recommended for your " +"setup, on Octoprint console. For example:" +msgstr "" + +msgid "" +"If you agree with the suggested parameters, you can execute `SAVE_CONFIG` " +"now to save them and restart the Klipper. Note that this will not update " +"`max_accel` value in `[printer]` section. You should update it manually " +"following the considerations in [Selecting max_accel](#selecting-max_accel) " +"section." +msgstr "" + +msgid "" +"If your printer is a bed slinger printer, you can specify which axis to " +"test, so that you can change the accelerometer mounting point between the " +"tests (by default the test is performed for both axes):" +msgstr "" + +msgid "You can execute `SAVE_CONFIG` twice - after calibrating each axis." +msgstr "" + +msgid "" +"However, if you connected two accelerometers simultaneously, you simply run " +"`SHAPER_CALIBRATE` without specifying an axis to calibrate the input shaper " +"for both axes in one go." +msgstr "" + +msgid "Input Shaper re-calibration" +msgstr "" + +msgid "" +"`SHAPER_CALIBRATE` command can be also used to re-calibrate the input shaper" +" in the future, especially if some changes to the printer that can affect " +"its kinematics are made. One can either re-run the full calibration using " +"`SHAPER_CALIBRATE` command, or restrict the auto-calibration to a single " +"axis by supplying `AXIS=` parameter, like" +msgstr "" + +msgid "" +"Also, due to some noise in measurements, it is possible that the tuning " +"results will be slightly different from one calibration run to another one. " +"Still, it is not expected that the noise will affect the print quality too " +"much. However, it is still advised to double-check the suggested parameters," +" and print some test prints before using them to confirm they are good." +msgstr "" + +msgid "Offline processing of the accelerometer data" +msgstr "" + +msgid "" +"It is possible to generate the raw accelerometer data and process it offline" +" (e.g. on a host machine), for example to find resonances. In order to do " +"so, run the following commands via Octoprint terminal:" +msgstr "" + +msgid "" +"ignoring any errors for `SET_INPUT_SHAPER` command. For `TEST_RESONANCES` " +"command, specify the desired test axis. The raw data will be written into " +"`/tmp` directory on the RPi." +msgstr "" + +msgid "" +"The data can be processed later by the following scripts: " +"`scripts/graph_accelerometer.py` and `scripts/calibrate_shaper.py`. Both of " +"them accept one or several raw csv files as the input depending on the mode." +" The graph_accelerometer.py script supports several modes of operation:" +msgstr "" + +msgid "" +"plotting raw accelerometer data (use `-r` parameter), only 1 input is " +"supported;" +msgstr "" + +msgid "" +"plotting a frequency response (no extra parameters required), if multiple " +"inputs are specified, the average frequency response is computed;" +msgstr "" + +msgid "" +"comparison of the frequency response between several inputs (use `-c` " +"parameter); you can additionally specify which accelerometer axis to " +"consider via `-a x`, `-a y` or `-a z` parameter (if none specified, the sum " +"of vibrations for all axes is used);" +msgstr "" + +msgid "" +"plotting the spectrogram (use `-s` parameter), only 1 input is supported; " +"you can additionally specify which accelerometer axis to consider via `-a " +"x`, `-a y` or `-a z` parameter (if none specified, the sum of vibrations for" +" all axes is used)." +msgstr "" + +msgid "" +"Note that graph_accelerometer.py script supports only the raw_data\\*.csv " +"files and not resonances\\*.csv or calibration_data\\*.csv files." +msgstr "" + +msgid "For example," +msgstr "" + +msgid "" +"will plot the comparison of several `/tmp/raw_data_x_*.csv` files for Z axis" +" to `/tmp/resonances_x.png` file." +msgstr "" + +msgid "" +"The shaper_calibrate.py script accepts 1 or several inputs and can run " +"automatic tuning of the input shaper and suggest the best parameters that " +"work well for all provided inputs. It prints the suggested parameters to the" +" console, and can additionally generate the chart if `-o output.png` " +"parameter is provided, or the CSV file if `-c output.csv` parameter is " +"specified." +msgstr "" + +msgid "" +"Providing several inputs to shaper_calibrate.py script can be useful if " +"running some advanced tuning of the input shapers, for example:" +msgstr "" + +msgid "" +"Running `TEST_RESONANCES AXIS=X OUTPUT=raw_data` (and `Y` axis) for a single" +" axis twice on a bed slinger printer with the accelerometer attached to the " +"toolhead the first time, and the accelerometer attached to the bed the " +"second time in order to detect axes cross-resonances and attempt to cancel " +"them with input shapers." +msgstr "" + +msgid "" +"Running `TEST_RESONANCES AXIS=Y OUTPUT=raw_data` twice on a bed slinger with" +" a glass bed and a magnetic surfaces (which is lighter) to find the input " +"shaper parameters that work well for any print surface configuration." +msgstr "" + +msgid "Combining the resonance data from multiple test points." +msgstr "" + +msgid "" +"Combining the resonance data from 2 axis (e.g. on a bed slinger printer to " +"configure X-axis input_shaper from both X and Y axes resonances to cancel " +"vibrations of the *bed* in case the nozzle 'catches' a print when moving in " +"X axis direction)." +msgstr "" + +msgid "~/klippy-env/bin/pip install -v numpy\n" +msgstr "" + +msgid "Recv: // adxl345 values (x, y, z): 470.719200, 941.438400, 9728.196800\n" +msgstr "" + +msgid "TEST_RESONANCES AXIS=X\n" +msgstr "" + +msgid "" +"[resonance_tester]\n" +"accel_chip: adxl345\n" +"accel_per_hz: 50 # default is 75\n" +"probe_points: ...\n" +msgstr "" + +msgid "TEST_RESONANCES AXIS=Y\n" +msgstr "" + +msgid "" +"~/klipper/scripts/calibrate_shaper.py /tmp/resonances_x_*.csv -o /tmp/shaper_calibrate_x.png\n" +"~/klipper/scripts/calibrate_shaper.py /tmp/resonances_y_*.csv -o /tmp/shaper_calibrate_y.png\n" +msgstr "" + +msgid "" +"Fitted shaper 'zv' frequency = 34.4 Hz (vibrations = 4.0%, smoothing ~= 0.132)\n" +"To avoid too much smoothing with 'zv', suggested max_accel <= 4500 mm/sec^2\n" +"Fitted shaper 'mzv' frequency = 34.6 Hz (vibrations = 0.0%, smoothing ~= 0.170)\n" +"To avoid too much smoothing with 'mzv', suggested max_accel <= 3500 mm/sec^2\n" +"Fitted shaper 'ei' frequency = 41.4 Hz (vibrations = 0.0%, smoothing ~= 0.188)\n" +"To avoid too much smoothing with 'ei', suggested max_accel <= 3200 mm/sec^2\n" +"Fitted shaper '2hump_ei' frequency = 51.8 Hz (vibrations = 0.0%, smoothing ~= 0.201)\n" +"To avoid too much smoothing with '2hump_ei', suggested max_accel <= 3000 mm/sec^2\n" +"Fitted shaper '3hump_ei' frequency = 61.8 Hz (vibrations = 0.0%, smoothing ~= 0.215)\n" +"To avoid too much smoothing with '3hump_ei', suggested max_accel <= 2800 mm/sec^2\n" +"Recommended shaper is mzv @ 34.6 Hz\n" +msgstr "" + +msgid "" +"[input_shaper]\n" +"shaper_freq_x: ...\n" +"shaper_type_x: ...\n" +"shaper_freq_y: 34.6\n" +"shaper_type_y: mzv\n" +"\n" +"[printer]\n" +"max_accel: 3000 # should not exceed the estimated max_accel for X and Y axes\n" +msgstr "" + +msgid "" +"[adxl345 hotend]\n" +"# Assuming `hotend` chip is connected to an RPi\n" +"cs_pin: rpi:None\n" +"\n" +"[adxl345 bed]\n" +"# Assuming `bed` chip is connected to a printer MCU board\n" +"cs_pin: ... # Printer board SPI chip select (CS) pin\n" +"\n" +"[resonance_tester]\n" +"# Assuming the typical setup of the bed slinger printer\n" +"accel_chip_x: adxl345 hotend\n" +"accel_chip_y: adxl345 bed\n" +"probe_points: ...\n" +msgstr "" + +msgid "" +"Fitted shaper 'zv' frequency = 57.8 Hz (vibrations = 20.3%, smoothing ~= 0.053)\n" +"To avoid too much smoothing with 'zv', suggested max_accel <= 13000 mm/sec^2\n" +"Fitted shaper 'mzv' frequency = 34.8 Hz (vibrations = 3.6%, smoothing ~= 0.168)\n" +"To avoid too much smoothing with 'mzv', suggested max_accel <= 3600 mm/sec^2\n" +"Fitted shaper 'ei' frequency = 48.8 Hz (vibrations = 4.9%, smoothing ~= 0.135)\n" +"To avoid too much smoothing with 'ei', suggested max_accel <= 4400 mm/sec^2\n" +"Fitted shaper '2hump_ei' frequency = 45.2 Hz (vibrations = 0.1%, smoothing ~= 0.264)\n" +"To avoid too much smoothing with '2hump_ei', suggested max_accel <= 2200 mm/sec^2\n" +"Fitted shaper '3hump_ei' frequency = 48.0 Hz (vibrations = 0.0%, smoothing ~= 0.356)\n" +"To avoid too much smoothing with '3hump_ei', suggested max_accel <= 1500 mm/sec^2\n" +"Recommended shaper is 2hump_ei @ 45.2 Hz\n" +msgstr "" + +msgid "" +"~/klipper/scripts/calibrate_shaper.py /tmp/resonances_x_*.csv -o " +"/tmp/shaper_calibrate_x.png --max_smoothing=0.2\n" +msgstr "" + +msgid "" +"Fitted shaper 'zv' frequency = 55.4 Hz (vibrations = 19.7%, smoothing ~= 0.057)\n" +"To avoid too much smoothing with 'zv', suggested max_accel <= 12000 mm/sec^2\n" +"Fitted shaper 'mzv' frequency = 34.6 Hz (vibrations = 3.6%, smoothing ~= 0.170)\n" +"To avoid too much smoothing with 'mzv', suggested max_accel <= 3500 mm/sec^2\n" +"Fitted shaper 'ei' frequency = 48.2 Hz (vibrations = 4.8%, smoothing ~= 0.139)\n" +"To avoid too much smoothing with 'ei', suggested max_accel <= 4300 mm/sec^2\n" +"Fitted shaper '2hump_ei' frequency = 52.0 Hz (vibrations = 2.7%, smoothing ~= 0.200)\n" +"To avoid too much smoothing with '2hump_ei', suggested max_accel <= 3000 mm/sec^2\n" +"Fitted shaper '3hump_ei' frequency = 72.6 Hz (vibrations = 1.4%, smoothing ~= 0.155)\n" +"To avoid too much smoothing with '3hump_ei', suggested max_accel <= 3900 mm/sec^2\n" +"Recommended shaper is 3hump_ei @ 72.6 Hz\n" +msgstr "" + +msgid "" +"[resonance_tester]\n" +"accel_chip: ...\n" +"probe_points: ...\n" +"max_smoothing: 0.25 # an example\n" +msgstr "" + +msgid "SHAPER_CALIBRATE\n" +msgstr "" + +msgid "" +"Calculating the best input shaper parameters for y axis\n" +"Fitted shaper 'zv' frequency = 39.0 Hz (vibrations = 13.2%, smoothing ~= 0.105)\n" +"To avoid too much smoothing with 'zv', suggested max_accel <= 5900 mm/sec^2\n" +"Fitted shaper 'mzv' frequency = 36.8 Hz (vibrations = 1.7%, smoothing ~= 0.150)\n" +"To avoid too much smoothing with 'mzv', suggested max_accel <= 4000 mm/sec^2\n" +"Fitted shaper 'ei' frequency = 36.6 Hz (vibrations = 2.2%, smoothing ~= 0.240)\n" +"To avoid too much smoothing with 'ei', suggested max_accel <= 2500 mm/sec^2\n" +"Fitted shaper '2hump_ei' frequency = 48.0 Hz (vibrations = 0.0%, smoothing ~= 0.234)\n" +"To avoid too much smoothing with '2hump_ei', suggested max_accel <= 2500 mm/sec^2\n" +"Fitted shaper '3hump_ei' frequency = 59.0 Hz (vibrations = 0.0%, smoothing ~= 0.235)\n" +"To avoid too much smoothing with '3hump_ei', suggested max_accel <= 2500 mm/sec^2\n" +"Recommended shaper_type_y = mzv, shaper_freq_y = 36.8 Hz\n" +msgstr "" + +msgid "SHAPER_CALIBRATE AXIS=Y\n" +msgstr "" + +msgid "SHAPER_CALIBRATE AXIS=X\n" +msgstr "" + +msgid "" +"SET_INPUT_SHAPER SHAPER_FREQ_X=0 SHAPER_FREQ_Y=0\n" +"TEST_RESONANCES AXIS=X OUTPUT=raw_data\n" +msgstr "" + +msgid "" +"~/klipper/scripts/graph_accelerometer.py /tmp/raw_data_x_*.csv -o " +"/tmp/resonances_x.png -c -a z\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 80 (header) +msgid "Testing custom axes" +msgstr "" + +#: docs/Measuring_Resonances.md:block 81 (paragraph) +msgid "" +"`TEST_RESONANCES` command supports custom axes. While this is not really " +"useful for input shaper calibration, it can be used to study printer " +"resonances in-depth and to check, for example, belt tension." +msgstr "" + +#: docs/Measuring_Resonances.md:block 82 (paragraph) +msgid "To check the belt tension on CoreXY printers, execute" +msgstr "" + +#: docs/Measuring_Resonances.md:block 83 (code) +msgid "" +"TEST_RESONANCES AXIS=1,1 OUTPUT=raw_data\n" +"TEST_RESONANCES AXIS=1,-1 OUTPUT=raw_data\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 84 (paragraph) +msgid "and use `graph_accelerometer.py` to process the generated files, e.g." +msgstr "" + +#: docs/Measuring_Resonances.md:block 85 (code) +msgid "" +"~/klipper/scripts/graph_accelerometer.py -c /tmp/raw_data_axis*.csv -o " +"/tmp/resonances.png\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 86 (paragraph) +msgid "which will generate `/tmp/resonances.png` comparing the resonances." +msgstr "" + +#: docs/Measuring_Resonances.md:block 87 (paragraph) +msgid "" +"For Delta printers with the default tower placement (tower A ~= 210 degrees," +" B ~= 330 degrees, and C ~= 90 degrees), execute" +msgstr "" + +#: docs/Measuring_Resonances.md:block 88 (code) +msgid "" +"TEST_RESONANCES AXIS=0,1 OUTPUT=raw_data\n" +"TEST_RESONANCES AXIS=-0.866025404,-0.5 OUTPUT=raw_data\n" +"TEST_RESONANCES AXIS=0.866025404,-0.5 OUTPUT=raw_data\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 89 (paragraph) +msgid "and then use the same command" +msgstr "" + +#: docs/Measuring_Resonances.md:block 91 (paragraph) +msgid "to generate `/tmp/resonances.png` comparing the resonances." +msgstr "" + +#: docs/Measuring_Resonances.md:block 26 (code) +msgid "" +"[mcu rpi]\n" +"serial: /tmp/klipper_host_mcu\n" +"\n" +"[adxl345]\n" +"cs_pin: rpi:None\n" +"\n" +"[resonance_tester]\n" +"accel_chip: adxl345\n" +"probe_points:\n" +" 100, 100, 20 # an example\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 45 (paragraph) +msgid "" +"This will generate 2 CSV files (`/tmp/resonances_x_*.csv` and " +"`/tmp/resonances_y_*.csv`). These files can be processed with the stand-" +"alone script on a Raspberry Pi. To do that, run the following commands:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 111 (paragraph) +msgid "" +"The raw data can also be obtained by running the command " +"`ACCELEROMETER_MEASURE` command twice during some normal printer activity - " +"first to start the measurements, and then to stop them and write the output " +"file. Refer to [G-Codes](G-Codes.md#adxl345) for more details." +msgstr "" + +#: docs/Measuring_Resonances.md:block 9 (table) +msgid "MPU-9250 pin" +msgstr "" + +#: docs/Measuring_Resonances.md:block 9 (table) +msgid "09" +msgstr "" + +#: docs/Measuring_Resonances.md:block 9 (table) +msgid "03" +msgstr "" + +#: docs/Measuring_Resonances.md:block 9 (table) +msgid "GPIO02 (SDA1)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 9 (table) +msgid "05" +msgstr "" + +#: docs/Measuring_Resonances.md:block 9 (table) +msgid "GPIO03 (SCL1)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 20 (paragraph) +msgid "" +"Note that resonance measurements and shaper auto-calibration require " +"additional software dependencies not installed by default. First, run on " +"your Raspberry Pi the following commands:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 21 (code) +msgid "" +"sudo apt update\n" +"sudo apt install python3-numpy python3-matplotlib libatlas-base-dev\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (paragraph) +msgid "" +"Next, in order to install NumPy in the Klipper environment, run the command:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 24 (paragraph) +msgid "" +"Note that, depending on the performance of the CPU, it may take *a lot* of " +"time, up to 10-20 minutes. Be patient and wait for the completion of the " +"installation. On some occasions, if the board has too little RAM the " +"installation may fail and you will need to enable swap." +msgstr "" + +#: docs/Measuring_Resonances.md:block 31 (code) +msgid "" +"[mcu rpi]\n" +"serial: /tmp/klipper_host_mcu\n" +"\n" +"[mpu9250]\n" +"i2c_mcu: rpi\n" +"i2c_bus: i2c.1\n" +"\n" +"[resonance_tester]\n" +"accel_chip: mpu9250\n" +"probe_points:\n" +" 100, 100, 20 # an example\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 8 (paragraph) +msgid "" +"***Double-check your wiring before powering up to prevent damaging your " +"MCU/Raspberry Pi or the accelerometer.***" +msgstr "" + +#: docs/Measuring_Resonances.md:block 9 (header) +msgid "SPI Accelerometers" +msgstr "" + +#: docs/Measuring_Resonances.md:block 11 (code) +msgid "" +"GND+MISO\n" +"3.3V+MOSI\n" +"SCLK+CS\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 12 (header) +msgid "ADXL345" +msgstr "" + +#: docs/Measuring_Resonances.md:block 18 (header) +msgid "I2C Accelerometers" +msgstr "" + +#: docs/Measuring_Resonances.md:block 20 (code) +msgid "" +"3.3V+SDA\n" +"GND+SCL\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 21 (header) +msgid "MPU-9250/MPU-9255/MPU-6515/MPU-6050/MPU-6500" +msgstr "" + +#: docs/Measuring_Resonances.md:block 23 (paragraph) +msgid "Recommended connection scheme for I2C on the Raspberry Pi:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 24 (table) +msgid "VCC" +msgstr "" + +#: docs/Measuring_Resonances.md:block 27 (table) +msgid "RP2040 pin" +msgstr "" + +#: docs/Measuring_Resonances.md:block 27 (table) +msgid "39" +msgstr "" + +#: docs/Measuring_Resonances.md:block 27 (table) +msgid "3v3" +msgstr "" + +#: docs/Measuring_Resonances.md:block 27 (table) +msgid "38" +msgstr "" + +#: docs/Measuring_Resonances.md:block 27 (table) +msgid "GP0 (I2C0 SDA)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 27 (table) +msgid "02" +msgstr "" + +#: docs/Measuring_Resonances.md:block 27 (table) +msgid "GP1 (I2C0 SCL)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 42 (header) +msgid "Configure ADXL345 With RPi" +msgstr "" + +#: docs/Measuring_Resonances.md:block 44 (paragraph) +msgid "Add the following to the printer.cfg file:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 47 (header) +msgid "Configure MPU-6000/9000 series With RPi" +msgstr "" + +#: docs/Measuring_Resonances.md:block 48 (paragraph) +msgid "" +"Make sure the Linux I2C driver is enabled and the baud rate is set to 400000" +" (see [Enabling I2C](RPi_microcontroller.md#optional-enabling-i2c) section " +"for more details). Then, add the following to the printer.cfg:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 13 (header) +msgid "Direct to Raspberry Pi" +msgstr "" + +#: docs/Measuring_Resonances.md:block 16 (table) +msgid "3.3V DC power" +msgstr "" + +#: docs/Measuring_Resonances.md:block 19 (header) +msgid "Using Raspberry Pi Pico" +msgstr "" + +#: docs/Measuring_Resonances.md:block 20 (paragraph) +msgid "" +"You may connect the ADXL345 to your Raspberry Pi Pico and then connect the " +"Pico to your Raspberry Pi via USB. This makes it easy to reuse the " +"accelerometer on other Klipper devices, as you can connect via USB instead " +"of GPIO. The Pico does not have much processing power, so make sure it is " +"only running the accelerometer and not performing any other duties." +msgstr "" + +#: docs/Measuring_Resonances.md:block 21 (paragraph) +msgid "" +"In order to avoid damage to your RPi make sure to connect the ADXL345 to " +"3.3V only. Depending on the board's layout, a level shifter may be present, " +"which makes 5V dangerous for your RPi." +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "Pico pin" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "Pico pin name" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "36" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "2" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "GP1 (SPI0_CSn)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "1" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "GP0 (SPI0_RX)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "5" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "GP3 (SPI0_TX)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "4" +msgstr "" + +#: docs/Measuring_Resonances.md:block 22 (table) +msgid "GP2 (SPI0_SCK)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 23 (paragraph) +msgid "Wiring diagrams for some of the ADXL345 boards:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 24 (paragraph) +msgid "![ADXL345-Pico](img/adxl345-pico.png)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 54 (header) +msgid "Configure ADXL345 With Pi Pico" +msgstr "" + +#: docs/Measuring_Resonances.md:block 55 (header) +msgid "Flash the Pico Firmware" +msgstr "" + +#: docs/Measuring_Resonances.md:block 56 (paragraph) +msgid "On your Raspberry Pi, compile the firmware for the Pico." +msgstr "" + +#: docs/Measuring_Resonances.md:block 57 (code) +msgid "" +"cd ~/klipper\n" +"make clean\n" +"make menuconfig\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 58 (paragraph) +msgid "![Pico menuconfig](img/klipper_pico_menuconfig.png)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 59 (paragraph) +msgid "" +"Now, while holding down the `BOOTSEL` button on the Pico, connect the Pico " +"to the Raspberry Pi via USB. Compile and flash the firmware." +msgstr "" + +#: docs/Measuring_Resonances.md:block 60 (code) +msgid "make flash FLASH_DEVICE=first\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 61 (paragraph) +msgid "" +"If that fails, you will be told which `FLASH_DEVICE` to use. In this " +"example, that's `make flash FLASH_DEVICE=2e8a:0003`. ![Determine flash " +"device](img/flash_rp2040_FLASH_DEVICE.png)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 62 (header) +msgid "Configure the Connection" +msgstr "" + +#: docs/Measuring_Resonances.md:block 63 (paragraph) +msgid "" +"The Pico will now reboot with the new firmware and should show up as a " +"serial device. Find the pico serial device with `ls /dev/serial/by-id/*`. " +"You can now add an `adxl.cfg` file with the following settings:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 64 (code) +msgid "" +"[mcu adxl]\n" +"# Change to whatever you found above. For example,\n" +"# usb-Klipper_rp2040_E661640843545B2E-if00\n" +"serial: /dev/serial/by-id/usb-Klipper_rp2040_\n" +"\n" +"[adxl345]\n" +"cs_pin: adxl:gpio1\n" +"spi_bus: spi0a\n" +"axes_map: x,z,y\n" +"\n" +"[resonance_tester]\n" +"accel_chip: adxl345\n" +"probe_points:\n" +" # Somewhere slightly above the middle of your print bed\n" +" 147,154, 20\n" +"\n" +"[output_pin power_mode] # Improve power stability\n" +"pin: adxl:gpio23\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 65 (paragraph) +msgid "" +"If setting up the ADXL345 configuration in a separate file, as shown above, " +"you'll also want to modify your `printer.cfg` file to include this:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 66 (code) +msgid "" +"[include adxl.cfg] # Comment this out when you disconnect the " +"accelerometer\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 81 (paragraph) +msgid "" +"If you get an error like `Invalid adxl345 id (got xx vs e5)`, where `xx` is " +"some other ID, immediately try again. There's an issue with SPI " +"initialization. If you still get an error, it is indicative of the " +"connection problem with ADXL345, or the faulty sensor. Double-check the " +"power, the wiring (that it matches the schematics, no wire is broken or " +"loose, etc.), and soldering quality." +msgstr "" + +#: docs/Measuring_Resonances.md:block 100 (paragraph) +msgid "" +"Note that alternatively you can run the input shaper auto-calibration from " +"Klipper [directly](#input-shaper-auto-calibration), which can be convenient," +" for example, for the input shaper [re-calibration](#input-shaper-re-" +"calibration)." +msgstr "" + +#: docs/Measuring_Resonances.md:block 152 (paragraph) +msgid "" +"**Warning!** It is not advisable to run the shaper auto-calibration very " +"frequently (e.g. before every print, or every day). In order to determine " +"resonance frequencies, auto-calibration creates intensive vibrations on each" +" of the axes. Generally, 3D printers are not designed to withstand a " +"prolonged exposure to vibrations near the resonance frequencies. Doing so " +"may increase wear of the printer components and reduce their lifespan. There" +" is also an increased risk of some parts unscrewing or becoming loose. " +"Always check that all parts of the printer (including the ones that may " +"normally not move) are securely fixed in place after each auto-tuning." +msgstr "" + +#: docs/Measuring_Resonances.md:block 2 (paragraph) +msgid "" +"Klipper has built-in support for the ADXL345, MPU-9250 and LIS2DW compatible" +" accelerometers which can be used to measure resonance frequencies of the " +"printer for different axes, and auto-tune [input " +"shapers](Resonance_Compensation.md) to compensate for resonances. Note that " +"using accelerometers requires some soldering and crimping. The " +"ADXL345/LIS2DW can be connected to the SPI interface of a Raspberry Pi or " +"MCU board (it needs to be reasonably fast). The MPU family can be connected " +"to the I2C interface of a Raspberry Pi directly, or to an I2C interface of " +"an MCU board that supports 400kbit/s *fast mode* in Klipper." +msgstr "" + +#: docs/Measuring_Resonances.md:block 3 (paragraph) +msgid "" +"When sourcing accelerometers, be aware that there are a variety of different" +" PCB board designs and different clones of them. If it is going to be " +"connected to a 5V printer MCU ensure it has a voltage regulator and level " +"shifters." +msgstr "" + +#: docs/Measuring_Resonances.md:block 4 (paragraph) +msgid "" +"For ADXL345s/LIS2DWs, make sure that the board supports SPI mode (a small " +"number of boards appear to be hard-configured for I2C by pulling SDO to " +"GND)." +msgstr "" + +#: docs/Measuring_Resonances.md:block 5 (paragraph) +msgid "" +"For MPU-9250/MPU-9255/MPU-6515/MPU-6050/MPU-6500s there are also a variety " +"of board designs and clones with different I2C pull-up resistors which will " +"need supplementing." +msgstr "" + +#: docs/Measuring_Resonances.md:block 6 (header) +msgid "MCUs with Klipper I2C *fast-mode* Support" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "MCU Family" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "MCU(s) Tested" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "MCU(s) with Support" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "Raspberry Pi" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "3B+, Pico" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "3A, 3A+, 3B, 4" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "AVR ATmega" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "ATmega328p" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "" +"ATmega32u4, ATmega128, ATmega168, ATmega328, ATmega644p, ATmega1280, " +"ATmega1284, ATmega2560" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "AVR AT90" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "-" +msgstr "" + +#: docs/Measuring_Resonances.md:block 7 (table) +msgid "AT90usb646, AT90usb1286" +msgstr "" + +#: docs/Measuring_Resonances.md:block 10 (paragraph) +msgid "" +"An ethernet cable with shielded twisted pairs (cat5e or better) is " +"recommended for signal integrity over a long distance. If you still " +"experience signal integrity issues (SPI/I2C errors):" +msgstr "" + +#: docs/Measuring_Resonances.md:block 11 (unordered list) +msgid "Double check the wiring with a digital multimeter for:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 11 (unordered list) +msgid "Correct connections when turned off (continuity)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 11 (unordered list) +msgid "Correct power and ground voltages" +msgstr "" + +#: docs/Measuring_Resonances.md:block 11 (unordered list) +msgid "I2C only:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 11 (unordered list) +msgid "" +"Check the SCL and SDA lines' resistances to 3.3V are in the range of 900 " +"ohms to 1.8K" +msgstr "" + +#: docs/Measuring_Resonances.md:block 11 (unordered list) +msgid "" +"For full technical details consult [chapter 7 of the I2C-bus specification " +"and user manual UM10204](https://www.pololu.com/file/0J435/UM10204.pdf) for " +"*fast-mode*" +msgstr "" + +#: docs/Measuring_Resonances.md:block 11 (unordered list) +msgid "Shorten the cable" +msgstr "" + +#: docs/Measuring_Resonances.md:block 12 (paragraph) +msgid "Connect ethernet cable shielding only to the MCU board/Pi ground." +msgstr "" + +#: docs/Measuring_Resonances.md:block 15 (paragraph) +msgid "Suggested twisted pair order for three twisted pairs:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 17 (paragraph) +msgid "Note that unlike a cable shield, GND must be connected at both ends." +msgstr "" + +#: docs/Measuring_Resonances.md:block 20 (paragraph) +msgid "" +"**Note: Many MCUs will work with an ADXL345 in SPI mode (e.g. Pi Pico), " +"wiring and configuration will vary according to your specific board and " +"available pins.**" +msgstr "" + +#: docs/Measuring_Resonances.md:block 32 (paragraph) +msgid "Suggested twisted pair order for three pairs (preferred):" +msgstr "" + +#: docs/Measuring_Resonances.md:block 33 (code) +msgid "" +"3.3V+GND\n" +"SDA+GND\n" +"SCL+GND\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 34 (paragraph) +msgid "or for two pairs:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 36 (paragraph) +msgid "" +"Note that unlike a cable shield, any GND(s) should be connected at both " +"ends." +msgstr "" + +#: docs/Measuring_Resonances.md:block 38 (paragraph) +msgid "" +"These accelerometers have been tested to work over I2C on the RPi, RP2040 " +"(Pico) and AVR at 400kbit/s (*fast mode*). Some MPU accelerometer modules " +"include pull-ups, but some are too large at 10K and must be changed or " +"supplemented by smaller parallel resistors." +msgstr "" + +#: docs/Measuring_Resonances.md:block 41 (paragraph) +msgid "The RPi has buit-in 1.8K pull-ups on both SCL and SDA." +msgstr "" + +#: docs/Measuring_Resonances.md:block 42 (paragraph) +msgid "![MPU-9250 connected to Pi](img/mpu9250-PI-fritzing.png)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 43 (paragraph) +msgid "Recommended connection scheme for I2C (i2c0a) on the RP2040:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 44 (table) +msgid "RP2040 pin name" +msgstr "" + +#: docs/Measuring_Resonances.md:block 45 (paragraph) +msgid "The Pico does not include any built-in I2C pull-up resistors." +msgstr "" + +#: docs/Measuring_Resonances.md:block 46 (paragraph) +msgid "![MPU-9250 connected to Pico](img/mpu9250-PICO-fritzing.png)" +msgstr "" + +#: docs/Measuring_Resonances.md:block 47 (header) +msgid "" +"Recommended connection scheme for I2C(TWI) on the AVR ATmega328P Arduino " +"Nano:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 48 (table) +msgid "Atmega328P TQFP32 pin" +msgstr "" + +#: docs/Measuring_Resonances.md:block 48 (table) +msgid "Atmega328P pin name" +msgstr "" + +#: docs/Measuring_Resonances.md:block 48 (table) +msgid "Arduino Nano pin" +msgstr "" + +#: docs/Measuring_Resonances.md:block 48 (table) +msgid "27" +msgstr "" + +#: docs/Measuring_Resonances.md:block 48 (table) +msgid "A4" +msgstr "" + +#: docs/Measuring_Resonances.md:block 48 (table) +msgid "28" +msgstr "" + +#: docs/Measuring_Resonances.md:block 48 (table) +msgid "A5" +msgstr "" + +#: docs/Measuring_Resonances.md:block 49 (paragraph) +msgid "" +"The Arduino Nano does not include any built-in pull-up resistors nor a 3.3V " +"power pin." +msgstr "" + +#: docs/Measuring_Resonances.md:block 63 (paragraph) +msgid "" +"First, check and follow the instructions in the [RPi Microcontroller " +"document](RPi_microcontroller.md) to setup the \"linux mcu\" on the " +"Raspberry Pi. This will configure a second Klipper instance that runs on " +"your Pi." +msgstr "" + +#: docs/Measuring_Resonances.md:block 82 (header) +msgid "Configure LIS2DW series" +msgstr "" + +#: docs/Measuring_Resonances.md:block 83 (code) +msgid "" +"[mcu lis]\n" +"# Change to whatever you found above. For example,\n" +"# usb-Klipper_rp2040_E661640843545B2E-if00\n" +"serial: /dev/serial/by-id/usb-Klipper_rp2040_\n" +"\n" +"[lis2dw]\n" +"cs_pin: lis:gpio1\n" +"spi_bus: spi0a\n" +"axes_map: x,z,y\n" +"\n" +"[resonance_tester]\n" +"accel_chip: lis2dw\n" +"probe_points:\n" +" # Somewhere slightly above the middle of your print bed\n" +" 147,154, 20\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 87 (header) +msgid "Configure MPU-9520 Compatibles With Pico" +msgstr "" + +#: docs/Measuring_Resonances.md:block 88 (paragraph) +msgid "" +"Pico I2C is set to 400000 on default. Simply add the following to the " +"printer.cfg:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 89 (code) +msgid "" +"[mcu pico]\n" +"serial: /dev/serial/by-id/\n" +"\n" +"[mpu9250]\n" +"i2c_mcu: pico\n" +"i2c_bus: i2c0a\n" +"\n" +"[resonance_tester]\n" +"accel_chip: mpu9250\n" +"probe_points:\n" +" 100, 100, 20 # an example\n" +"\n" +"[static_digital_output pico_3V3pwm] # Improve power stability\n" +"pins: pico:gpio23\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 90 (header) +msgid "Configure MPU-9520 Compatibles with AVR" +msgstr "" + +#: docs/Measuring_Resonances.md:block 91 (paragraph) +msgid "" +"AVR I2C will be set to 400000 by the mpu9250 option. Simply add the " +"following to the printer.cfg:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 92 (code) +msgid "" +"[mcu nano]\n" +"serial: /dev/serial/by-id/\n" +"\n" +"[mpu9250]\n" +"i2c_mcu: nano\n" +"\n" +"[resonance_tester]\n" +"accel_chip: mpu9250\n" +"probe_points:\n" +" 100, 100, 20 # an example\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 101 (paragraph) +msgid "" +"**If you are using a MPU-9250 compatible accelerometer and it shows up as " +"`mpu-unknown`, use with caution! They are probably refurbished chips!**" +msgstr "" + +#: docs/Measuring_Resonances.md:block 122 (paragraph) +msgid "" +"However, you can also connect two accelerometers simultaneously, though the " +"ADXL345 must be connected to different boards (say, to an RPi and printer " +"MCU board), or to two different physical SPI interfaces on the same board " +"(rarely available). Then they can be configured in the following manner:" +msgstr "" + +#: docs/Measuring_Resonances.md:block 124 (paragraph) +msgid "" +"Two MPUs can share one I2C bus, but they **cannot** measure simultaneously " +"as the 400kbit/s I2C bus is not fast enough. One must have its AD0 pin " +"pulled-down to 0V (address 104) and the other its AD0 pin pulled-up to 3.3V " +"(address 105):" +msgstr "" + +#: docs/Measuring_Resonances.md:block 125 (code) +msgid "" +"[mpu9250 hotend]\n" +"i2c_mcu: rpi\n" +"i2c_bus: i2c.1\n" +"i2c_address: 104 # This MPU has pin AD0 pulled low\n" +"\n" +"[mpu9250 bed]\n" +"i2c_mcu: rpi\n" +"i2c_bus: i2c.1\n" +"i2c_address: 105 # This MPU has pin AD0 pulled high\n" +"\n" +"[resonance_tester]\n" +"# Assuming the typical setup of the bed slinger printer\n" +"accel_chip_x: mpu9250 hotend\n" +"accel_chip_y: mpu9250 bed\n" +"probe_points: ...\n" +msgstr "" + +#: docs/Measuring_Resonances.md:block 126 (paragraph) +msgid "" +"[Test with each MPU individually before connecting both to the bus for easy " +"debugging.]" +msgstr "" + +#~ msgid "" +#~ "Klipper has built-in support for ADXL345 accelerometer, which can be used to" +#~ " measure resonance frequencies of the printer for different axes, and auto-" +#~ "tune [input shapers](Resonance_Compensation.md) to compensate for " +#~ "resonances. Note that using ADXL345 requires some soldering and crimping. " +#~ "ADXL345 can be connected to a Raspberry Pi directly, or to an SPI interface " +#~ "of an MCU board (it needs to be reasonably fast)." +#~ msgstr "" + +#~ msgid "" +#~ "Afterwards, check and follow the instructions in the [RPi Microcontroller " +#~ "document](RPi_microcontroller.md) to setup the \"linux mcu\" on the " +#~ "Raspberry Pi." +#~ msgstr "" + +#~ msgid "" +#~ "However, you can also connect two accelerometers simultaneously, though they" +#~ " must be connected to different boards (say, to an RPi and printer MCU " +#~ "board), or to two different physical SPI interfaces on the same board " +#~ "(rarely available). Then they can be configured in the following manner:" +#~ msgstr "" + +#~ msgid "" +#~ "When sourcing ADXL345, be aware that there is a variety of different PCB " +#~ "board designs and different clones of them. Make sure that the board " +#~ "supports SPI mode (small number of boards appear to be hard-configured for " +#~ "I2C by pulling SDO to GND), and, if it is going to be connected to a 5V " +#~ "printer MCU, that it has a voltage regulator and a level shifter." +#~ msgstr "" + +#~ msgid "Connect ethernet cable shielding to the controller board/RPI ground." +#~ msgstr "" + +#~ msgid "Suggested twisted pair order:" +#~ msgstr "" + +#~ msgid "" +#~ "Alternatives to the ADXL345 are " +#~ "MPU-9250/MPU-9255/MPU-6515/MPU-6050/MPU-6500. These accelerometers have been" +#~ " tested to work over I2C on the RPi or RP2040(pico) at 400kbaud." +#~ msgstr "" + +#~ msgid "![MPU-9250 connected to RPI](img/mpu9250-PI-fritzing.png)" +#~ msgstr "" + +#~ msgid "Recommended connection scheme for I2C(i2c0a) on the RP2040:" +#~ msgstr "" + +#~ msgid "![MPU-9250 connected to PICO](img/mpu9250-PICO-fritzing.png)" +#~ msgstr "" + +#~ msgid "Configure MPU-6000/9000 series With PICO" +#~ msgstr "" + +#~ msgid "" +#~ "PICO I2C is set to 400000 on default. Simply add the following to the " +#~ "printer.cfg:" +#~ msgstr "" + +#~ msgid "" +#~ "**If you are using MPU-6000/9000 series accelerometer and it show up as " +#~ "`mpu-unknown`, use with caution! They are probably refurbished chips!**" +#~ msgstr "" + +#~ msgid "" +#~ "An ethernet cable with shielded twisted pairs (cat5e or better) is " +#~ "recommended for signal integrity over a long distance. If you still " +#~ "experience signal integrity issues (SPI/I2C errors), shorten the cable." +#~ msgstr "" + +#~ msgid "" +#~ "**Note: Many MCUs will work with an ADXL345 in SPI mode(eg Pi Pico), wiring " +#~ "and configuration will vary according to your specific board and available " +#~ "pins.**" +#~ msgstr "" + +#~ msgid "" +#~ "[mcu pico]\n" +#~ "serial: /dev/serial/by-id/\n" +#~ "\n" +#~ "[mpu9250]\n" +#~ "i2c_mcu: pico\n" +#~ "i2c_bus: i2c0a\n" +#~ "\n" +#~ "[resonance_tester]\n" +#~ "accel_chip: mpu9250\n" +#~ "probe_points:\n" +#~ " 100, 100, 20 # an example\n" +#~ "\n" +#~ "[static_digital_output pico_3V3pwm] # Improve power stability\n" +#~ "pin: pico:gpio23\n" +#~ msgstr "" + +#~ msgid "" +#~ "If you get an error like `Invalid adxl345 id (got xx vs e5)`, where `xx` is " +#~ "some other ID, it is indicative of the connection problem with ADXL345, or " +#~ "the faulty sensor. Double-check the power, the wiring (that it matches the " +#~ "schematics, no wire is broken or loose, etc.), and soldering quality." +#~ msgstr "" + +#~ msgid "" +#~ "Note that alternatively you can run the input shaper autocalibration from " +#~ "Klipper [directly](#input-shaper-auto-calibration), which can be convenient," +#~ " for example, for the input shaper [re-calibration](#input-shaper-re-" +#~ "calibration)." +#~ msgstr "" + +#~ msgid "" +#~ "**Warning!** It is not advisable to run the shaper autocalibration very " +#~ "frequently (e.g. before every print, or every day). In order to determine " +#~ "resonance frequencies, autocalibration creates intensive vibrations on each " +#~ "of the axes. Generally, 3D printers are not designed to withstand a " +#~ "prolonged exposure to vibrations near the resonance frequencies. Doing so " +#~ "may increase wear of the printer components and reduce their lifespan. There" +#~ " is also an increased risk of some parts unscrewing or becoming loose. " +#~ "Always check that all parts of the printer (including the ones that may " +#~ "normally not move) are securely fixed in place after each auto-tuning." +#~ msgstr "" + +#~ msgid "" +#~ "An ethernet cable with shielded twisted pairs (cat5e or better) is " +#~ "recommended for signal integrety over a long distance. If you still " +#~ "experience signal integrity issues (SPI/I2C errors), shorten the cable." +#~ msgstr "" + +#~ msgid "" +#~ "**Note: Many MCUs will work with an ADXL345 in SPI mode(eg Pi Pico), wiring " +#~ "and configuration will vary according to your specific board and avaliable " +#~ "pins.**" +#~ msgstr "" + +#~ msgid "" +#~ "[mcu pico]\n" +#~ "serial: /dev/serial/by-id/\n" +#~ "\n" +#~ "[mpu9250]\n" +#~ "i2c_mcu: pico\n" +#~ "i2c_bus: i2c1a\n" +#~ "\n" +#~ "[resonance_tester]\n" +#~ "accel_chip: mpu9250\n" +#~ "probe_points:\n" +#~ " 100, 100, 20 # an example\n" +#~ "\n" +#~ "[static_digital_output pico_3V3pwm] # Improve power stability\n" +#~ "pin: pico:gpio23\n" +#~ msgstr "" + +#~ msgid "" +#~ "Double-check your wiring before powering up the Raspberry Pi to prevent " +#~ "damaging it or the accelerometer." +#~ msgstr "" + +#~ msgid "" +#~ "An alternative to the ADXL345 is the MPU-9250 (or MPU-6050). This " +#~ "accelerometer has been tested to work over I2C on the RPi at 400kbaud. " +#~ "Recommended connection scheme for I2C:" +#~ msgstr "" + +#~ msgid "For the ADXL345, add the following to the printer.cfg file:" +#~ msgstr "" + +#~ msgid "" +#~ "For the MPU-9250, make sure the Linux I2C driver is enabled and the baud " +#~ "rate is set to 400000 (see [Enabling I2C](RPi_microcontroller.md#optional-" +#~ "enabling-i2c) section for more details). Then, add the following to the " +#~ "printer.cfg:" +#~ msgstr "" + +#~ msgid "" +#~ "Note that resonance measurements and shaper auto-calibration require " +#~ "additional software dependencies not installed by default. First, you will " +#~ "have to run on your Raspberry Pi the following command:" +#~ msgstr "" + +#~ msgid "" +#~ "to install `numpy` package. Note that, depending on the performance of the " +#~ "CPU, it may take *a lot* of time, up to 10-20 minutes. Be patient and wait " +#~ "for the completion of the installation. On some occasions, if the board has " +#~ "too little RAM, the installation may fail and you will need to enable swap." +#~ msgstr "" + +#~ msgid "" +#~ "Next, run the following commands to install the additional dependencies:" +#~ msgstr "" + +#~ msgid "" +#~ "sudo apt update\n" +#~ "sudo apt install python3-numpy python3-matplotlib\n" +#~ msgstr "" + +#~ msgid "" +#~ "This will generate 2 CSV files (`/tmp/resonances_x_*.csv` and " +#~ "`/tmp/resonances_y_*.csv`). These files can be processed with the stand-" +#~ "alone script on a Raspberry Pi. To do that, run running the following " +#~ "commands:" +#~ msgstr "" + +#~ msgid "" +#~ "The raw data can also be obtained by running the command " +#~ "`ACCELEROMETER_MEASURE` command twice during some normal printer activity - " +#~ "first to start the measurements, and then to stop them and write the output " +#~ "file. Refer to [G-Codes](G-Codes.md#adxl345-accelerometer-commands) for more" +#~ " details." +#~ msgstr "" + +#~ msgid "" +#~ "[mcu rpi]\n" +#~ "serial: /tmp/klipper_host_mcu\n" +#~ "\n" +#~ "[adxl345]\n" +#~ "cs_pin: rpi:None\n" +#~ "\n" +#~ "[resonance_tester]\n" +#~ "accel_chip: adxl345\n" +#~ "probe_points:\n" +#~ " 100,100,20 # an example\n" +#~ msgstr "" + +#~ msgid "" +#~ "sudo apt update\n" +#~ "sudo apt install python-numpy python-matplotlib\n" +#~ msgstr "" + +#~ msgid "" +#~ "When sourcing ADLX345, be aware that there is a variety of different PCB " +#~ "board designs and different clones of them. Make sure that the board " +#~ "supports SPI mode (small number of boards appear to be hard-configured for " +#~ "I2C by pulling SDO to GND), and, if it is going to be connected to a 5V " +#~ "printer MCU, that it has a voltage regulator and a level shifter." +#~ msgstr "" + +#~ msgid "" +#~ "Next, run the following command to install the additional dependencies:" +#~ msgstr "" + +#~ msgid "sudo apt install python-numpy python-matplotlib\n" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Multi_MCU_Homing.po b/docs/locales/lt/LC_MESSAGES/Multi_MCU_Homing.po new file mode 100644 index 0000000000..e3b735496d --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Multi_MCU_Homing.po @@ -0,0 +1,70 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: docs/Multi_MCU_Homing.md:block 1 (header) +msgid "Multiple Micro-controller Homing and Probing" +msgstr "" + +#: docs/Multi_MCU_Homing.md:block 2 (paragraph) +msgid "" +"Klipper supports a mechanism for homing with an endstop attached to one " +"micro-controller while its stepper motors are on a different micro-" +"controller. This support is referred to as \"multi-mcu homing\". This " +"feature is also used when a Z probe is on a different micro-controller than " +"the Z stepper motors." +msgstr "" + +#: docs/Multi_MCU_Homing.md:block 3 (paragraph) +msgid "" +"This feature can be useful to simplify wiring, as it may be more convenient " +"to attach an endstop or probe to a closer micro-controller. However, using " +"this feature may result in \"overshoot\" of the stepper motors during homing" +" and probing operations." +msgstr "" + +#: docs/Multi_MCU_Homing.md:block 4 (paragraph) +msgid "" +"The overshoot occurs due to possible message transmission delays between the" +" micro-controller monitoring the endstop and the micro-controllers moving " +"the stepper motors. The Klipper code is designed to limit this delay to no " +"more than 25ms. (When multi-mcu homing is activated, the micro-controllers " +"send periodic status messages and check that corresponding status messages " +"are received within 25ms.)" +msgstr "" + +#: docs/Multi_MCU_Homing.md:block 5 (paragraph) +msgid "" +"So, for example, if homing at 10mm/s then it is possible for an overshoot of" +" up to 0.250mm (10mm/s * .025s == 0.250mm). Care should be taken when " +"configuring multi-mcu homing to account for this type of overshoot. Using " +"slower homing or probing speeds can reduce the overshoot." +msgstr "" + +#: docs/Multi_MCU_Homing.md:block 6 (paragraph) +msgid "" +"Stepper motor overshoot should not adversely impact the precision of the " +"homing and probing procedure. The Klipper code will detect the overshoot and" +" account for it in its calculations. However, it is important that the " +"hardware design is capable of handling overshoot without causing damage to " +"the machine." +msgstr "" + +#: docs/Multi_MCU_Homing.md:block 7 (paragraph) +msgid "" +"Should Klipper detect a communication issue between micro-controllers during" +" multi-mcu homing then it will raise a \"Communication timeout during " +"homing\" error." +msgstr "" + +#: docs/Multi_MCU_Homing.md:block 8 (paragraph) +msgid "" +"Note that an axis with multiple steppers (eg, `stepper_z` and `stepper_z1`) " +"need to be on the same micro-controller in order to use multi-mcu homing. " +"For example, if an endstop is on a separate micro-controller from " +"`stepper_z` then `stepper_z1` must be on the same micro-controller as " +"`stepper_z`." +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Packaging.po b/docs/locales/lt/LC_MESSAGES/Packaging.po new file mode 100644 index 0000000000..e69fe40a12 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Packaging.po @@ -0,0 +1,73 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"Klipper is somewhat of a packaging anomaly among python programs, as it " +"doesn't use setuptools to build and install. Some notes regarding how best " +"to package it are as follows:" +msgstr "" + +msgid "C modules" +msgstr "" + +msgid "" +"Klipper uses a C module to handle some kinematics calculations more quickly." +" This module needs to be compiled at packaging time to avoid introducing a " +"runtime dependency on a compiler. To compile the C module, run `python2 " +"klippy/chelper/__init__.py`." +msgstr "" + +msgid "Compiling python code" +msgstr "" + +msgid "" +"Many distributions have a policy of compiling all python code before " +"packaging to improve startup time. You can do this by running `python2 -m " +"compileall klippy`." +msgstr "" + +msgid "Versioning" +msgstr "" + +msgid "" +"If you are building a package of Klipper from git, it is usual practice not " +"to ship a .git directory, so the versioning must be handled without git. To " +"do this, use the script shipped in `scripts/make_version.py` which should be" +" run as follows: `python2 scripts/make_version.py YOURDISTRONAME > " +"klippy/.version`." +msgstr "" + +msgid "Sample packaging script" +msgstr "" + +#: docs/Packaging.md:block 1 (header) +msgid "Packaging Klipper" +msgstr "" + +#: docs/Packaging.md:block 10 (paragraph) +msgid "" +"klipper-git is packaged for Arch Linux, and has a PKGBUILD (package build " +"script) available at [Arch User " +"Repository](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=klipper-" +"git)." +msgstr "" + +#~ msgid "" +#~ "klipper-git is packaged for Arch Linux, and has a PKGBUILD (package build " +#~ "script) available at [Arch User " +#~ "Repositiory](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=klipper-" +#~ "git)." +#~ msgstr "" + +#~ msgid "Packaging klipper" +#~ msgstr "" + +#~ msgid "" +#~ "klipper-git is packaged for Arch Linux, and has a PKGBUILD (package build " +#~ "script) available at " +#~ "https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=klipper-git." +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Pressure_Advance.po b/docs/locales/lt/LC_MESSAGES/Pressure_Advance.po new file mode 100644 index 0000000000..8031298f2a --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Pressure_Advance.po @@ -0,0 +1,201 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"This document provides information on tuning the \"pressure advance\" " +"configuration variable for a particular nozzle and filament. The pressure " +"advance feature can be helpful in reducing ooze. For more information on how" +" pressure advance is implemented see the [kinematics](Kinematics.md) " +"document." +msgstr "" + +msgid "Tuning pressure advance" +msgstr "" + +msgid "" +"Pressure advance does two useful things - it reduces ooze during non-extrude" +" moves and it reduces blobbing during cornering. This guide uses the second " +"feature (reducing blobbing during cornering) as a mechanism for tuning." +msgstr "" + +msgid "" +"In order to calibrate pressure advance the printer must be configured and " +"operational as the tuning test involves printing and inspecting a test " +"object. It is a good idea to read this document in full prior to running the" +" test." +msgstr "" + +msgid "" +"Use a slicer to generate g-code for the large hollow square found in " +"[docs/prints/square_tower.stl](prints/square_tower.stl). Use a high speed " +"(eg, 100mm/s), zero infill, and a coarse layer height (the layer height " +"should be around 75% of the nozzle diameter). Make sure any \"dynamic " +"acceleration control\" is disabled in the slicer." +msgstr "" + +msgid "Prepare for the test by issuing the following G-Code command:" +msgstr "" + +msgid "" +"This command makes the nozzle travel slower through corners to emphasize the" +" effects of extruder pressure. Then for printers with a direct drive " +"extruder run the command:" +msgstr "" + +msgid "For long bowden extruders use:" +msgstr "" + +msgid "Then print the object. When fully printed the test print looks like:" +msgstr "" + +msgid "![tuning_tower](img/tuning_tower.jpg)" +msgstr "" + +msgid "" +"The above TUNING_TOWER command instructs Klipper to alter the " +"pressure_advance setting on each layer of the print. Higher layers in the " +"print will have a larger pressure advance value set. Layers below the ideal " +"pressure_advance setting will have blobbing at the corners, and layers above" +" the ideal setting can lead to rounded corners and poor extrusion leading up" +" to the corner." +msgstr "" + +msgid "" +"One can cancel the print early if one observes that the corners are no " +"longer printing well (and thus one can avoid printing layers that are known " +"to be above the ideal pressure_advance value)." +msgstr "" + +msgid "" +"Inspect the print and then use a digital calipers to find the height that " +"has the best quality corners. When in doubt, prefer a lower height." +msgstr "" + +msgid "![tune_pa](img/tune_pa.jpg)" +msgstr "" + +msgid "" +"The pressure_advance value can then be calculated as `pressure_advance = " +" + * `. (For example, `0 + 12.90 * .020` " +"would be `.258`.)" +msgstr "" + +msgid "" +"It is possible to choose custom settings for START and FACTOR if that helps " +"identify the best pressure advance setting. When doing this, be sure to " +"issue the TUNING_TOWER command at the start of each test print." +msgstr "" + +msgid "" +"Typical pressure advance values are between 0.050 and 1.000 (the high end " +"usually only with bowden extruders). If there is no significant improvement " +"with a pressure advance up to 1.000, then pressure advance is unlikely to " +"improve the quality of prints. Return to a default configuration with " +"pressure advance disabled." +msgstr "" + +msgid "" +"Although this tuning exercise directly improves the quality of corners, it's" +" worth remembering that a good pressure advance configuration also reduces " +"ooze throughout the print." +msgstr "" + +msgid "" +"At the completion of this test, set `pressure_advance = ` " +"in the `[extruder]` section of the configuration file and issue a RESTART " +"command. The RESTART command will clear the test state and return the " +"acceleration and cornering speeds to their normal values." +msgstr "" + +msgid "Important Notes" +msgstr "" + +msgid "" +"The pressure advance value is dependent on the extruder, the nozzle, and the" +" filament. It is common for filament from different manufactures or with " +"different pigments to require significantly different pressure advance " +"values. Therefore, one should calibrate pressure advance on each printer and" +" with each spool of filament." +msgstr "" + +msgid "" +"Printing temperature and extrusion rates can impact pressure advance. Be " +"sure to tune the [extruder " +"rotation_distance](Rotation_Distance.md#calibrating-rotation_distance-on-" +"extruders) and [nozzle " +"temperature](http://reprap.org/wiki/Triffid_Hunter%27s_Calibration_Guide#Nozzle_Temperature)" +" prior to tuning pressure advance." +msgstr "" + +msgid "" +"The test print is designed to run with a high extruder flow rate, but " +"otherwise \"normal\" slicer settings. A high flow rate is obtained by using " +"a high printing speed (eg, 100mm/s) and a coarse layer height (typically " +"around 75% of the nozzle diameter). Other slicer settings should be similar " +"to their defaults (eg, perimeters of 2 or 3 lines, normal retraction " +"amount). It can be useful to set the external perimeter speed to be the same" +" speed as the rest of the print, but it is not a requirement." +msgstr "" + +msgid "" +"It is common for the test print to show different behavior on each corner. " +"Often the slicer will arrange to change layers at one corner which can " +"result in that corner being significantly different from the remaining three" +" corners. If this occurs, then ignore that corner and tune pressure advance " +"using the other three corners. It is also common for the remaining corners " +"to vary slightly. (This can occur due to small differences in how the " +"printer's frame reacts to cornering in certain directions.) Try to choose a " +"value that works well for all the remaining corners. If in doubt, prefer a " +"lower pressure advance value." +msgstr "" + +msgid "" +"If a high pressure advance value (eg, over 0.200) is used then one may find " +"that the extruder skips when returning to the printer's normal acceleration." +" The pressure advance system accounts for pressure by pushing in extra " +"filament during acceleration and retracting that filament during " +"deceleration. With a high acceleration and high pressure advance the " +"extruder may not have enough torque to push the required filament. If this " +"occurs, either use a lower acceleration value or disable pressure advance." +msgstr "" + +msgid "" +"Once pressure advance is tuned in Klipper, it may still be useful to " +"configure a small retract value in the slicer (eg, 0.75mm) and to utilize " +"the slicer's \"wipe on retract option\" if available. These slicer settings " +"may help counteract ooze caused by filament cohesion (filament pulled out of" +" the nozzle due to the stickiness of the plastic). It is recommended to " +"disable the slicer's \"z-lift on retract\" option." +msgstr "" + +msgid "" +"The pressure advance system does not change the timing or path of the " +"toolhead. A print with pressure advance enabled will take the same amount of" +" time as a print without pressure advance. Pressure advance also does not " +"change the total amount of filament extruded during a print. Pressure " +"advance results in extra extruder movement during move acceleration and " +"deceleration. A very high pressure advance setting will result in a very " +"large amount of extruder movement during acceleration and deceleration, and " +"no configuration setting places a limit on the amount of that movement." +msgstr "" + +msgid "SET_VELOCITY_LIMIT SQUARE_CORNER_VELOCITY=1 ACCEL=500\n" +msgstr "" + +msgid "" +"TUNING_TOWER COMMAND=SET_PRESSURE_ADVANCE PARAMETER=ADVANCE START=0 " +"FACTOR=.005\n" +msgstr "" + +msgid "" +"TUNING_TOWER COMMAND=SET_PRESSURE_ADVANCE PARAMETER=ADVANCE START=0 " +"FACTOR=.020\n" +msgstr "" + +#: docs/Pressure_Advance.md:block 1 (header) +msgid "Pressure advance" +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Protocol.po b/docs/locales/lt/LC_MESSAGES/Protocol.po new file mode 100644 index 0000000000..e0407f3b82 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Protocol.po @@ -0,0 +1,471 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"The Klipper messaging protocol is used for low-level communication between " +"the Klipper host software and the Klipper micro-controller software. At a " +"high level the protocol can be thought of as a series of command and " +"response strings that are compressed, transmitted, and then processed at the" +" receiving side. An example series of commands in uncompressed human-" +"readable format might look like:" +msgstr "" + +msgid "" +"See the [mcu commands](MCU_Commands.md) document for information on " +"available commands. See the [debugging](Debugging.md) document for " +"information on how to translate a G-Code file into its corresponding human-" +"readable micro-controller commands." +msgstr "" + +msgid "" +"This page provides a high-level description of the Klipper messaging " +"protocol itself. It describes how messages are declared, encoded in binary " +"format (the \"compression\" scheme), and transmitted." +msgstr "" + +msgid "" +"The goal of the protocol is to enable an error-free communication channel " +"between the host and micro-controller that is low-latency, low-bandwidth, " +"and low-complexity for the micro-controller." +msgstr "" + +msgid "Micro-controller Interface" +msgstr "" + +msgid "" +"The Klipper transmission protocol can be thought of as a " +"[RPC](https://en.wikipedia.org/wiki/Remote_procedure_call) mechanism between" +" micro-controller and host. The micro-controller software declares the " +"commands that the host may invoke along with the response messages that it " +"can generate. The host uses that information to command the micro-controller" +" to perform actions and to interpret the results." +msgstr "" + +msgid "Declaring commands" +msgstr "" + +msgid "" +"The micro-controller software declares a \"command\" by using the " +"DECL_COMMAND() macro in the C code. For example:" +msgstr "" + +msgid "" +"The above declares a command named \"update_digital_out\". This allows the " +"host to \"invoke\" this command which would cause the " +"command_update_digital_out() C function to be executed in the micro-" +"controller. The above also indicates that the command takes two integer " +"parameters. When the command_update_digital_out() C code is executed, it " +"will be passed an array containing these two integers - the first " +"corresponding to the 'oid' and the second corresponding to the 'value'." +msgstr "" + +msgid "" +"In general, the parameters are described with printf() style syntax (eg, " +"\"%u\"). The formatting directly corresponds to the human-readable view of " +"commands (eg, \"update_digital_out oid=7 value=1\"). In the above example, " +"\"value=\" is a parameter name and \"%c\" indicates the parameter is an " +"integer. Internally, the parameter name is only used as documentation. In " +"this example, the \"%c\" is also used as documentation to indicate the " +"expected integer is 1 byte in size (the declared integer size does not " +"impact the parsing or encoding)." +msgstr "" + +msgid "" +"The micro-controller build will collect all commands declared with " +"DECL_COMMAND(), determine their parameters, and arrange for them to be " +"callable." +msgstr "" + +msgid "Declaring responses" +msgstr "" + +msgid "" +"To send information from the micro-controller to the host a \"response\" is " +"generated. These are both declared and transmitted using the sendf() C " +"macro. For example:" +msgstr "" + +msgid "" +"The above transmits a \"status\" response message that contains two integer " +"parameters (\"clock\" and \"status\"). The micro-controller build " +"automatically finds all sendf() calls and generates encoders for them. The " +"first parameter of the sendf() function describes the response and it is in " +"the same format as command declarations." +msgstr "" + +msgid "" +"The host can arrange to register a callback function for each response. So, " +"in effect, commands allow the host to invoke C functions in the micro-" +"controller and responses allow the micro-controller software to invoke code " +"in the host." +msgstr "" + +msgid "" +"The sendf() macro should only be invoked from command or task handlers, and " +"it should not be invoked from interrupts or timers. The code does not need " +"to issue a sendf() in response to a received command, it is not limited in " +"the number of times sendf() may be invoked, and it may invoke sendf() at any" +" time from a task handler." +msgstr "" + +msgid "Output responses" +msgstr "" + +msgid "" +"To simplify debugging, there is also an output() C function. For example:" +msgstr "" + +msgid "" +"The output() function is similar in usage to printf() - it is intended to " +"generate and format arbitrary messages for human consumption." +msgstr "" + +msgid "Declaring enumerations" +msgstr "" + +msgid "" +"Enumerations allow the host code to use string identifiers for parameters " +"that the micro-controller handles as integers. They are declared in the " +"micro-controller code - for example:" +msgstr "" + +msgid "" +"If the first example, the DECL_ENUMERATION() macro defines an enumeration " +"for any command/response message with a parameter name of \"spi_bus\" or " +"parameter name with a suffix of \"_spi_bus\". For those parameters the " +"string \"spi\" is a valid value and it will be transmitted with an integer " +"value of zero." +msgstr "" + +msgid "" +"It's also possible to declare an enumeration range. In the second example, a" +" \"pin\" parameter (or any parameter with a suffix of \"_pin\") would accept" +" PC0, PC1, PC2, ..., PC7 as valid values. The strings will be transmitted " +"with integers 16, 17, 18, ..., 23." +msgstr "" + +msgid "Declaring constants" +msgstr "" + +msgid "Constants can also be exported. For example, the following:" +msgstr "" + +msgid "" +"would export a constant named \"SERIAL_BAUD\" with a value of 250000 from " +"the micro-controller to the host. It is also possible to declare a constant " +"that is a string - for example:" +msgstr "" + +msgid "Low-level message encoding" +msgstr "" + +msgid "" +"To accomplish the above RPC mechanism, each command and response is encoded " +"into a binary format for transmission. This section describes the " +"transmission system." +msgstr "" + +msgid "Message Blocks" +msgstr "" + +msgid "" +"All data sent from host to micro-controller and vice-versa are contained in " +"\"message blocks\". A message block has a two byte header and a three byte " +"trailer. The format of a message block is:" +msgstr "" + +msgid "" +"The length byte contains the number of bytes in the message block including " +"the header and trailer bytes (thus the minimum message length is 5 bytes). " +"The maximum message block length is currently 64 bytes. The sequence byte " +"contains a 4 bit sequence number in the low-order bits and the high-order " +"bits always contain 0x10 (the high-order bits are reserved for future use). " +"The content bytes contain arbitrary data and its format is described in the " +"following section. The crc bytes contain a 16bit CCITT " +"[CRC](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) of the message " +"block including the header bytes but excluding the trailer bytes. The sync " +"byte is 0x7e." +msgstr "" + +msgid "" +"The format of the message block is inspired by " +"[HDLC](https://en.wikipedia.org/wiki/High-Level_Data_Link_Control) message " +"frames. Like in HDLC, the message block may optionally contain an additional" +" sync character at the start of the block. Unlike in HDLC, a sync character " +"is not exclusive to the framing and may be present in the message block " +"content." +msgstr "" + +msgid "Message Block Contents" +msgstr "" + +msgid "" +"Each message block sent from host to micro-controller contains a series of " +"zero or more message commands in its contents. Each command starts with a " +"[Variable Length Quantity](#variable-length-quantities) (VLQ) encoded " +"integer command-id followed by zero or more VLQ parameters for the given " +"command." +msgstr "" + +msgid "" +"As an example, the following four commands might be placed in a single " +"message block:" +msgstr "" + +msgid "and encoded into the following eight VLQ integers:" +msgstr "" + +msgid "" +"In order to encode and parse the message contents, both the host and micro-" +"controller must agree on the command ids and the number of parameters each " +"command has. So, in the above example, both the host and micro-controller " +"would know that \"id_update_digital_out\" is always followed by two " +"parameters, and \"id_get_config\" and \"id_get_clock\" have zero parameters." +" The host and micro-controller share a \"data dictionary\" that maps the " +"command descriptions (eg, \"update_digital_out oid=%c value=%c\") to their " +"integer command-ids. When processing the data, the parser will know to " +"expect a specific number of VLQ encoded parameters following a given command" +" id." +msgstr "" + +msgid "" +"The message contents for blocks sent from micro-controller to host follow " +"the same format. The identifiers in these messages are \"response ids\", but" +" they serve the same purpose and follow the same encoding rules. In " +"practice, message blocks sent from the micro-controller to the host never " +"contain more than one response in the message block contents." +msgstr "" + +msgid "Variable Length Quantities" +msgstr "" + +msgid "" +"See the [wikipedia article](https://en.wikipedia.org/wiki/Variable-" +"length_quantity) for more information on the general format of VLQ encoded " +"integers. Klipper uses an encoding scheme that supports both positive and " +"negative integers. Integers close to zero use less bytes to encode and " +"positive integers typically encode using less bytes than negative integers. " +"The following table shows the number of bytes each integer takes to encode:" +msgstr "" + +msgid "Integer" +msgstr "" + +msgid "Encoded size" +msgstr "" + +msgid "-32 .. 95" +msgstr "" + +msgid "1" +msgstr "" + +msgid "-4096 .. 12287" +msgstr "" + +msgid "2" +msgstr "" + +msgid "-524288 .. 1572863" +msgstr "" + +msgid "3" +msgstr "" + +msgid "-67108864 .. 201326591" +msgstr "" + +msgid "4" +msgstr "" + +msgid "-2147483648 .. 4294967295" +msgstr "" + +msgid "5" +msgstr "" + +msgid "Variable length strings" +msgstr "" + +msgid "" +"As an exception to the above encoding rules, if a parameter to a command or " +"response is a dynamic string then the parameter is not encoded as a simple " +"VLQ integer. Instead it is encoded by transmitting the length as a VLQ " +"encoded integer followed by the contents itself:" +msgstr "" + +msgid "" +"The command descriptions found in the data dictionary allow both the host " +"and micro-controller to know which command parameters use simple VLQ " +"encoding and which parameters use string encoding." +msgstr "" + +msgid "Data Dictionary" +msgstr "" + +msgid "" +"In order for meaningful communications to be established between micro-" +"controller and host, both sides must agree on a \"data dictionary\". This " +"data dictionary contains the integer identifiers for commands and responses " +"along with their descriptions." +msgstr "" + +msgid "" +"The micro-controller build uses the contents of DECL_COMMAND() and sendf() " +"macros to generate the data dictionary. The build automatically assigns " +"unique identifiers to each command and response. This system allows both the" +" host and micro-controller code to seamlessly use descriptive human-readable" +" names while still using minimal bandwidth." +msgstr "" + +msgid "" +"The host queries the data dictionary when it first connects to the micro-" +"controller. Once the host downloads the data dictionary from the micro-" +"controller, it uses that data dictionary to encode all commands and to parse" +" all responses from the micro-controller. The host must therefore handle a " +"dynamic data dictionary. However, to keep the micro-controller software " +"simple, the micro-controller always uses its static (compiled in) data " +"dictionary." +msgstr "" + +msgid "" +"The data dictionary is queried by sending \"identify\" commands to the " +"micro-controller. The micro-controller will respond to each identify command" +" with an \"identify_response\" message. Since these two commands are needed " +"prior to obtaining the data dictionary, their integer ids and parameter " +"types are hard-coded in both the micro-controller and the host. The " +"\"identify_response\" response id is 0, the \"identify\" command id is 1. " +"Other than having hard-coded ids the identify command and its response are " +"declared and transmitted the same way as other commands and responses. No " +"other command or response is hard-coded." +msgstr "" + +msgid "" +"The format of the transmitted data dictionary itself is a zlib compressed " +"JSON string. The micro-controller build process generates the string, " +"compresses it, and stores it in the text section of the micro-controller " +"flash. The data dictionary can be much larger than the maximum message block" +" size - the host downloads it by sending multiple identify commands " +"requesting progressive chunks of the data dictionary. Once all chunks are " +"obtained the host will assemble the chunks, uncompress the data, and parse " +"the contents." +msgstr "" + +msgid "" +"In addition to information on the communication protocol, the data " +"dictionary also contains the software version, enumerations (as defined by " +"DECL_ENUMERATION), and constants (as defined by DECL_CONSTANT)." +msgstr "" + +msgid "Message flow" +msgstr "" + +msgid "" +"Message commands sent from host to micro-controller are intended to be " +"error-free. The micro-controller will check the CRC and sequence numbers in " +"each message block to ensure the commands are accurate and in-order. The " +"micro-controller always processes message blocks in-order - should it " +"receive a block out-of-order it will discard it and any other out-of-order " +"blocks until it receives blocks with the correct sequencing." +msgstr "" + +msgid "" +"The low-level host code implements an automatic retransmission system for " +"lost and corrupt message blocks sent to the micro-controller. To facilitate " +"this, the micro-controller transmits an \"ack message block\" after each " +"successfully received message block. The host schedules a timeout after " +"sending each block and it will retransmit should the timeout expire without " +"receiving a corresponding \"ack\". In addition, if the micro-controller " +"detects a corrupt or out-of-order block it may transmit a \"nak message " +"block\" to facilitate fast retransmission." +msgstr "" + +msgid "" +"An \"ack\" is a message block with empty content (ie, a 5 byte message " +"block) and a sequence number greater than the last received host sequence " +"number. A \"nak\" is a message block with empty content and a sequence " +"number less than the last received host sequence number." +msgstr "" + +msgid "" +"The protocol facilitates a \"window\" transmission system so that the host " +"can have many outstanding message blocks in-flight at a time. (This is in " +"addition to the many commands that may be present in a given message block.)" +" This allows maximum bandwidth utilization even in the event of transmission" +" latency. The timeout, retransmit, windowing, and ack mechanism are inspired" +" by similar mechanisms in " +"[TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)." +msgstr "" + +msgid "" +"In the other direction, message blocks sent from micro-controller to host " +"are designed to be error-free, but they do not have assured transmission. " +"(Responses should not be corrupt, but they may go missing.) This is done to " +"keep the implementation in the micro-controller simple. There is no " +"automatic retransmission system for responses - the high-level code is " +"expected to be capable of handling an occasional missing response (usually " +"by re-requesting the content or setting up a recurring schedule of response " +"transmission). The sequence number field in message blocks sent to the host " +"is always one greater than the last received sequence number of message " +"blocks received from the host. It is not used to track sequences of response" +" message blocks." +msgstr "" + +msgid "" +"set_digital_out pin=PA3 value=1\n" +"set_digital_out pin=PA7 value=1\n" +"schedule_digital_out oid=8 clock=4000000 value=0\n" +"queue_step oid=7 interval=7458 count=10 add=331\n" +"queue_step oid=7 interval=11717 count=4 add=1281\n" +msgstr "" + +msgid "" +"DECL_COMMAND(command_update_digital_out, \"update_digital_out oid=%c " +"value=%c\");\n" +msgstr "" + +msgid "" +"sendf(\"status clock=%u status=%c\", sched_read_time(), " +"sched_is_shutdown());\n" +msgstr "" + +msgid "output(\"The value of %u is %s with size %u.\", x, buf, buf_len);\n" +msgstr "" + +msgid "" +"DECL_ENUMERATION(\"spi_bus\", \"spi\", 0);\n" +"\n" +"DECL_ENUMERATION_RANGE(\"pin\", \"PC0\", 16, 8);\n" +msgstr "" + +msgid "DECL_CONSTANT(\"SERIAL_BAUD\", 250000);\n" +msgstr "" + +msgid "DECL_CONSTANT_STR(\"MCU\", \"pru\");\n" +msgstr "" + +msgid "" +"<1 byte length><1 byte sequence><2 byte crc><1 byte sync>\n" +msgstr "" + +msgid "" +"update_digital_out oid=6 value=1\n" +"update_digital_out oid=5 value=0\n" +"get_config\n" +"get_clock\n" +msgstr "" + +msgid "" +"<6><1><5><0>\n" +msgstr "" + +msgid "\n" +msgstr "" + +#: docs/Protocol.md:block 1 (header) +msgid "Protocol" +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Releases.po b/docs/locales/lt/LC_MESSAGES/Releases.po new file mode 100644 index 0000000000..f1fbc7fc9f --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Releases.po @@ -0,0 +1,606 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"History of Klipper releases. Please see [installation](Installation.md) for " +"information on installing Klipper." +msgstr "" + +msgid "Klipper 0.9.0" +msgstr "" + +msgid "Available on 20201020. Major changes in this release:" +msgstr "" + +msgid "" +"Support for \"Input Shaping\" - a mechanism to counteract printer resonance." +" It can reduce or eliminate \"ringing\" in prints." +msgstr "" + +msgid "" +"New \"Smooth Pressure Advance\" system. This implements \"Pressure Advance\"" +" without introducing instantaneous velocity changes. It is also now possible" +" to tune pressure advance using a \"Tuning Tower\" method." +msgstr "" + +msgid "" +"New \"webhooks\" API server. This provides a programmable JSON interface to " +"Klipper." +msgstr "" + +msgid "" +"The LCD display and menu are now configurable using the Jinja2 template " +"language." +msgstr "" + +msgid "" +"The TMC2208 stepper motor drivers can now be used in \"standalone\" mode " +"with Klipper." +msgstr "" + +msgid "Improved BL-Touch v3 support." +msgstr "" + +msgid "" +"Improved USB identification. Klipper now has its own USB identification code" +" and micro-controllers can now report their unique serial numbers during USB" +" identification." +msgstr "" + +msgid "New kinematic support for \"Rotary Delta\" and \"CoreXZ\" printers." +msgstr "" + +msgid "" +"Micro-controller improvements: support for stm32f070, support for stm32f207," +" support for GPIO pins on \"Linux MCU\", stm32 \"HID bootloader\" support, " +"Chitu bootloader support, MKS Robin bootloader support." +msgstr "" + +msgid "Improved handling of Python \"garbage collection\" events." +msgstr "" + +msgid "" +"Many additional modules added: adc_scaled, adxl345, bme280, display_status, " +"extruder_stepper, fan_generic, hall_filament_width_sensor, htu21d, " +"homing_heaters, input_shaper, lm75, print_stats, resonance_tester, " +"shaper_calibrate, query_adc, graph_accelerometer, graph_extruder, " +"graph_motion, graph_shaper, graph_temp_sensor, whconsole" +msgstr "" + +msgid "Several bug fixes and code cleanups." +msgstr "" + +msgid "Klipper 0.9.1" +msgstr "" + +msgid "Available on 20201028. Release containing only bug fixes." +msgstr "" + +msgid "Klipper 0.8.0" +msgstr "" + +msgid "Available on 20191021. Major changes in this release:" +msgstr "" + +msgid "" +"New G-Code command template support. G-Code in the config file is now " +"evaluated with the Jinja2 template language." +msgstr "" + +msgid "Improvements to Trinamic stepper drivers:" +msgstr "" + +msgid "New support for TMC2209 and TMC5160 drivers." +msgstr "" + +msgid "Improved DUMP_TMC, SET_TMC_CURRENT, and INIT_TMC G-Code commands." +msgstr "" + +msgid "Improved support for TMC UART handling with an analog mux." +msgstr "" + +msgid "Improved homing, probing, and bed leveling support:" +msgstr "" + +msgid "" +"New manual_probe, bed_screws, screws_tilt_adjust, skew_correction, " +"safe_z_home modules added." +msgstr "" + +msgid "Enhanced multi-sample probing with median, average, and retry logic." +msgstr "" + +msgid "" +"Improved documentation for BL-Touch, probe calibration, endstop calibration," +" delta calibration, sensorless homing, and endstop phase calibration." +msgstr "" + +msgid "Improved homing support on a large Z axis." +msgstr "" + +msgid "Many Klipper micro-controller improvements:" +msgstr "" + +msgid "Klipper ported to: SAM3X8C, SAM4S8C, SAMD51, STM32F042, STM32F4" +msgstr "" + +msgid "New USB CDC driver implementations on SAM3X, SAM4, STM32F4." +msgstr "" + +msgid "Enhanced support for flashing Klipper over USB." +msgstr "" + +msgid "Software SPI support." +msgstr "" + +msgid "Greatly improved temperature filtering on the LPC176x." +msgstr "" + +msgid "Early output pin settings can be configured in the micro-controller." +msgstr "" + +msgid "New website with the Klipper documentation: http://klipper3d.org/" +msgstr "" + +msgid "Klipper now has a logo." +msgstr "" + +msgid "Experimental support for polar and \"cable winch\" kinematics." +msgstr "" + +msgid "The config file can now include other config files." +msgstr "" + +msgid "" +"Many additional modules added: board_pins, controller_fan, delayed_gcode, " +"dotstar, filament_switch_sensor, firmware_retraction, gcode_arcs, " +"gcode_button, heater_generic, manual_stepper, mcp4018, mcp4728, neopixel, " +"pause_resume, respond, temperature_sensor tsl1401cl_filament_width_sensor, " +"tuning_tower" +msgstr "" + +msgid "" +"Many additional commands added: RESTORE_GCODE_STATE, SAVE_GCODE_STATE, " +"SET_GCODE_VARIABLE, SET_HEATER_TEMPERATURE, SET_IDLE_TIMEOUT, " +"SET_TEMPERATURE_FAN_TARGET" +msgstr "" + +msgid "Klipper 0.7.0" +msgstr "" + +msgid "Available on 20181220. Major changes in this release:" +msgstr "" + +msgid "Klipper now supports \"mesh\" bed leveling" +msgstr "" + +msgid "" +"New support for \"enhanced\" delta calibration (calibrates print x/y " +"dimensions on delta printers)" +msgstr "" + +msgid "" +"Support for run-time configuration of Trinamic stepper motor drivers " +"(tmc2130, tmc2208, tmc2660)" +msgstr "" + +msgid "" +"Improved temperature sensor support: MAX6675, MAX31855, MAX31856, MAX31865, " +"custom thermistors, common pt100 style sensors" +msgstr "" + +msgid "" +"Several new modules: temperature_fan, sx1509, force_move, mcp4451, z_tilt, " +"quad_gantry_level, endstop_phase, bltouch" +msgstr "" + +msgid "" +"Several new commands added: SAVE_CONFIG, SET_PRESSURE_ADVANCE, " +"SET_GCODE_OFFSET, SET_VELOCITY_LIMIT, STEPPER_BUZZ, TURN_OFF_HEATERS, M204, " +"custom g-code macros" +msgstr "" + +msgid "Expanded LCD display support:" +msgstr "" + +msgid "Support for run-time menus" +msgstr "" + +msgid "New display icons" +msgstr "" + +msgid "Support for \"uc1701\" and \"ssd1306\" displays" +msgstr "" + +msgid "Additional micro-controller support:" +msgstr "" + +msgid "" +"Klipper ported to: LPC176x (Smoothieboards), SAM4E8E (Duet2), SAMD21 " +"(Arduino Zero), STM32F103 (\"Blue pill\" devices), atmega32u4" +msgstr "" + +msgid "" +"New Generic USB CDC driver implemented on AVR, LPC176x, SAMD21, and " +"STM32F103" +msgstr "" + +msgid "Performance improvements on ARM processors" +msgstr "" + +msgid "The kinematics code was rewritten to use an \"iterative solver\"" +msgstr "" + +msgid "New automatic test cases for the Klipper host software" +msgstr "" + +msgid "Many new example config files for common off-the-shelf printers" +msgstr "" + +msgid "" +"Documentation updates for bootloaders, benchmarking, micro-controller " +"porting, config checks, pin mapping, slicer settings, packaging, and more" +msgstr "" + +msgid "Several bug fixes and code cleanups" +msgstr "" + +msgid "Klipper 0.6.0" +msgstr "" + +msgid "Available on 20180331. Major changes in this release:" +msgstr "" + +msgid "Enhanced heater and thermistor hardware failure checks" +msgstr "" + +msgid "Support for Z probes" +msgstr "" + +msgid "" +"Initial support for automatic parameter calibration on deltas (via a new " +"delta_calibrate command)" +msgstr "" + +msgid "" +"Initial support for bed tilt compensation (via bed_tilt_calibrate command)" +msgstr "" + +msgid "Initial support for \"safe homing\" and homing overrides" +msgstr "" + +msgid "" +"Initial support for displaying status on RepRapDiscount style 2004 and 12864" +" displays" +msgstr "" + +msgid "New multi-extruder improvements:" +msgstr "" + +msgid "Support for shared heaters" +msgstr "" + +msgid "Initial support for dual carriages" +msgstr "" + +msgid "Support for configuring multiple steppers per axis (eg, dual Z)" +msgstr "" + +msgid "" +"Support for custom digital and pwm output pins (with a new SET_PIN command)" +msgstr "" + +msgid "" +"Initial support for a \"virtual sdcard\" that allows printing directly from " +"Klipper (helps on machines too slow to run OctoPrint well)" +msgstr "" + +msgid "Support for setting different arm lengths on each tower of a delta" +msgstr "" + +msgid "" +"Support for G-Code M220/M221 commands (speed factor override / extrude " +"factor override)" +msgstr "" + +msgid "Several documentation updates:" +msgstr "" + +msgid "New multiple MCU config example" +msgstr "" + +msgid "New bltouch sensor config example" +msgstr "" + +msgid "New FAQ, config check, and G-Code documents" +msgstr "" + +msgid "" +"Initial support for continuous integration testing on all github commits" +msgstr "" + +msgid "Klipper 0.5.0" +msgstr "" + +msgid "Available on 20171025. Major changes in this release:" +msgstr "" + +msgid "Support for printers with multiple extruders." +msgstr "" + +msgid "" +"Initial support for running on the Beaglebone PRU. Initial support for the " +"Replicape board." +msgstr "" + +msgid "" +"Initial support for running the micro-controller code in a real-time Linux " +"process." +msgstr "" + +msgid "" +"Support for multiple micro-controllers. (For example, one could control an " +"extruder with one micro-controller and the rest of the printer with " +"another.) Software clock synchronization is implemented to coordinate " +"actions between micro-controllers." +msgstr "" + +msgid "" +"Stepper performance improvements (20Mhz AVRs up to 189K steps per second)." +msgstr "" + +msgid "" +"Support for controlling servos and support for defining nozzle cooling fans." +msgstr "" + +msgid "Klipper 0.4.0" +msgstr "" + +msgid "Available on 20170503. Major changes in this release:" +msgstr "" + +msgid "" +"Improved installation on Raspberry Pi machines. Most of the install is now " +"scripted." +msgstr "" + +msgid "Support for corexy kinematics" +msgstr "" + +msgid "" +"Documentation updates: New Kinematics document, new Pressure Advance tuning " +"guide, new example config files, and more" +msgstr "" + +msgid "" +"Stepper performance improvements (20Mhz AVRs over 175K steps per second, " +"Arduino Due over 460K)" +msgstr "" + +msgid "" +"Support for automatic micro-controller resets. Support for resets via " +"toggling USB power on Raspberry Pi." +msgstr "" + +msgid "" +"The pressure advance algorithm now works with look-ahead to reduce pressure " +"changes during cornering." +msgstr "" + +msgid "Support for limiting the top speed of short zigzag moves" +msgstr "" + +msgid "Support for AD595 sensors" +msgstr "" + +msgid "Klipper 0.3.0" +msgstr "" + +msgid "Available on 20161223. Major changes in this release:" +msgstr "" + +msgid "Improved documentation" +msgstr "" + +msgid "Support for robots with delta kinematics" +msgstr "" + +msgid "Support for Arduino Due micro-controller (ARM cortex-M3)" +msgstr "" + +msgid "Support for USB based AVR micro-controllers" +msgstr "" + +msgid "" +"Support for \"pressure advance\" algorithm - it reduces ooze during prints." +msgstr "" + +msgid "" +"New \"stepper phased based endstop\" feature - enables higher precision on " +"endstop homing." +msgstr "" + +msgid "" +"Support for \"extended g-code\" commands such as \"help\", \"restart\", and " +"\"status\"." +msgstr "" + +msgid "" +"Support for reloading the Klipper config and restarting the host software by" +" issuing a \"restart\" command from the terminal." +msgstr "" + +msgid "" +"Stepper performance improvements (20Mhz AVRs up to 158K steps per second)." +msgstr "" + +msgid "" +"Improved error reporting. Most errors now shown via the terminal along with " +"help on how to resolve." +msgstr "" + +msgid "Klipper 0.2.0" +msgstr "" + +msgid "" +"Initial release of Klipper. Available on 20160525. Major features available " +"in the initial release include:" +msgstr "" + +msgid "" +"Basic support for cartesian printers (steppers, extruder, heated bed, " +"cooling fan)." +msgstr "" + +msgid "" +"Support for common g-code commands. Support for interfacing with OctoPrint." +msgstr "" + +msgid "Acceleration and lookahead handling" +msgstr "" + +msgid "Support for AVR micro-controllers via standard serial ports" +msgstr "" + +#: docs/Releases.md:block 1 (header) +msgid "Releases" +msgstr "" + +#: docs/Releases.md:block 3 (header) +msgid "Klipper 0.10.0" +msgstr "" + +#: docs/Releases.md:block 4 (paragraph) +msgid "Available on 20210929. Major changes in this release:" +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"Support for \"Multi-MCU Homing\". It is now possible for a stepper motor and" +" its endstop to be wired to separate micro-controllers. This simplifies " +"wiring of Z probes on \"toolhead boards\"." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"Klipper now has a [Community Discord Server](https://discord.klipper3d.org) " +"and a [Community Discourse Server](https://community.klipper3d.org)." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"The [Klipper website](https://www.klipper3d.org) now uses the \"mkdocs\" " +"infrastructure. There is also a [Klipper " +"Translations](https://github.com/Klipper3d/klipper-translations) project." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "Automated support for flashing firmware via sdcard on many boards." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "New kinematic support for \"Hybrid CoreXY\" and \"Hybrid CoreXZ\" printers." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"Klipper now uses `rotation_distance` to configure stepper motor travel " +"distances." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"The main Klipper host code can now directly communicate with micro-" +"controllers using CAN bus." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"New \"motion analysis\" system. Klipper's internal motion updates and sensor" +" results can be tracked and logged for analysis." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"Trinamic stepper motor drivers are now continuously monitored for error " +"conditions." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "Support for the rp2040 micro-controller (Raspberry Pi Pico boards)." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "The \"make menuconfig\" system now utilizes kconfiglib." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"Many additional modules added: ds18b20, duplicate_pin_override, " +"filament_motion_sensor, palette2, motion_report, pca9533, pulse_counter, " +"save_variables, sdcard_loop, temperature_host, temperature_mcu" +msgstr "" + +#: docs/Releases.md:block 3 (header) +msgid "Klipper 0.11.0" +msgstr "" + +#: docs/Releases.md:block 4 (paragraph) +msgid "Available on 20221128. Major changes in this release:" +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "Trinamic stepper motor driver \"step on both edges\" optimization." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"Support for Python3. The Klipper host code will run with either Python2 or " +"Python3." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"Enhanced CAN bus support. Support for CAN bus on rp2040, stm32g0, stm32h7, " +"same51, and same54 chips. Support for \"USB to CAN bus bridge\" mode." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "Support for CanBoot bootloader." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "Support for mpu9250 and mpu6050 accelerometers." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"Improved error handling for max31856, max31855, max31865, and max6675 " +"temperature sensors." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"It is now possible to configure LEDs to update during long running G-Code " +"commands using LED \"template\" support." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"Several micro-controller improvements. New support for stm32h743, stm32h750," +" stm32l412, stm32g0b1, same70, same51, and same54 chips. Support for i2c " +"reads on atsamd and stm32f0. Hardware pwm support on stm32. Linux mcu signal" +" based event dispatch. New rp2040 support for \"make flash\", i2c, and " +"rp2040-e5 USB errata." +msgstr "" + +#: docs/Releases.md:block 5 (unordered list) +msgid "" +"New modules added: angle, dac084S085, exclude_object, led, mpu9250, pca9632," +" smart_effector, z_thermal_adjust. New deltesian kinematics added. New " +"dump_mcu tool added." +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Resonance_Compensation.po b/docs/locales/lt/LC_MESSAGES/Resonance_Compensation.po new file mode 100644 index 0000000000..ef8d15a373 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Resonance_Compensation.po @@ -0,0 +1,1073 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "Resonance Compensation" +msgstr "" + +msgid "" +"Klipper supports Input Shaping - a technique that can be used to reduce " +"ringing (also known as echoing, ghosting or rippling) in prints. Ringing is " +"a surface printing defect when, typically, elements like edges repeat " +"themselves on a printed surface as a subtle 'echo':" +msgstr "" + +msgid "" +"|![Ringing test](img/ringing-test.jpg)|![3D " +"Benchy](img/ringing-3dbenchy.jpg)|" +msgstr "" + +msgid "" +"Ringing is caused by mechanical vibrations in the printer due to quick " +"changes of the printing direction. Note that ringing usually has mechanical " +"origins: insufficiently rigid printer frame, non-tight or too springy belts," +" alignment issues of mechanical parts, heavy moving mass, etc. Those should " +"be checked and fixed first, if possible." +msgstr "" + +msgid "" +"[Input shaping](https://en.wikipedia.org/wiki/Input_shaping) is an open-loop" +" control technique which creates a commanding signal that cancels its own " +"vibrations. Input shaping requires some tuning and measurements before it " +"can be enabled. Besides ringing, Input Shaping typically reduces the " +"vibrations and shaking of the printer in general, and may also improve the " +"reliability of the stealthChop mode of Trinamic stepper drivers." +msgstr "" + +msgid "Tuning" +msgstr "" + +msgid "" +"Slice the ringing test model, which can be found in " +"[docs/prints/ringing_tower.stl](prints/ringing_tower.stl), in the slicer:" +msgstr "" + +msgid "Suggested layer height is 0.2 or 0.25 mm." +msgstr "" + +msgid "Infill and top layers can be set to 0." +msgstr "" + +msgid "" +"Use 1-2 perimeters, or even better the smooth vase mode with 1-2 mm base." +msgstr "" + +msgid "" +"Use sufficiently high speed, around 80-100 mm/sec, for **external** " +"perimeters." +msgstr "" + +msgid "Make sure that the minimum layer time is **at most** 3 seconds." +msgstr "" + +msgid "Make sure any \"dynamic acceleration control\" is disabled in the slicer." +msgstr "" + +msgid "" +"Do not turn the model. The model has X and Y marks at the back of the model." +" Note the unusual location of the marks vs. the axes of the printer - it is " +"not a mistake. The marks can be used later in the tuning process as a " +"reference, because they show which axis the measurements correspond to." +msgstr "" + +msgid "Ringing frequency" +msgstr "" + +msgid "First, measure the **ringing frequency**." +msgstr "" + +msgid "" +"If you have already added `[input_shaper]` section to the printer.cfg, " +"execute `SET_INPUT_SHAPER SHAPER_FREQ_X=0 SHAPER_FREQ_Y=0` command. If you " +"get \"Unknown command\" error, you can safely ignore it at this point and " +"continue with the measurements." +msgstr "" + +msgid "Print the test model sliced with the suggested parameters." +msgstr "" + +msgid "" +"You can stop the print earlier if the ringing is clearly visible and you see" +" that acceleration gets too high for your printer (e.g. printer shakes too " +"much or starts skipping steps)." +msgstr "" + +msgid "" +"Use X and Y marks at the back of the model for reference. The measurements " +"from the side with X mark should be used for X axis *configuration*, and Y " +"mark - for Y axis configuration. Measure the distance *D* (in mm) between " +"several oscillations on the part with X mark, near the notches, preferably " +"skipping the first oscillation or two. To measure the distance between " +"oscillations more easily, mark the oscillations first, then measure the " +"distance between the marks with a ruler or calipers:" +msgstr "" + +msgid "" +"|![Mark ringing](img/ringing-mark.jpg)|![Measure ringing](img/ringing-" +"measure.jpg)|" +msgstr "" + +msgid "" +"Count how many oscillations *N* the measured distance *D* corresponds to. If" +" you are unsure how to count the oscillations, refer to the picture above, " +"which shows *N* = 6 oscillations." +msgstr "" + +msgid "" +"Compute the ringing frequency of X axis as *V* · *N* / *D* (Hz), " +"where *V* is the velocity for outer perimeters (mm/sec). For the example " +"above, we marked 6 oscillations, and the test was printed at 100 mm/sec " +"velocity, so the frequency is 100 * 6 / 12.14 ≈ 49.4 Hz." +msgstr "" + +msgid "" +"Note that ringing on the test print should follow the pattern of the curved " +"notches, as in the picture above. If it doesn't, then this defect is not " +"really a ringing and has a different origin - either mechanical, or an " +"extruder issue. It should be fixed first before enabling and tuning input " +"shapers." +msgstr "" + +msgid "" +"If the measurements are not reliable because, say, the distance between the " +"oscillations is not stable, it might mean that the printer has several " +"resonance frequencies on the same axis. One may try to follow the tuning " +"process described in [Unreliable measurements of ringing " +"frequencies](#unreliable-measurements-of-ringing-frequencies) section " +"instead and still get something out of the input shaping technique." +msgstr "" + +msgid "" +"Ringing frequency can depend on the position of the model within the " +"buildplate and Z height, *especially on delta printers*; you can check if " +"you see the differences in frequencies at different positions along the " +"sides of the test model and at different heights. You can calculate the " +"average ringing frequencies over X and Y axes if that is the case." +msgstr "" + +msgid "" +"If the measured ringing frequency is very low (below approx 20-25 Hz), it " +"might be a good idea to invest into stiffening the printer or decreasing the" +" moving mass - depending on what is applicable in your case - before " +"proceeding with further input shaping tuning, and re-measuring the " +"frequencies afterwards. For many popular printer models there are often some" +" solutions available already." +msgstr "" + +msgid "" +"Note that the ringing frequencies can change if the changes are made to the " +"printer that affect the moving mass or change the stiffness of the system, " +"for example:" +msgstr "" + +msgid "" +"Some tools are installed, removed or replaced on the toolhead that change " +"its mass, e.g. a new (heavier or lighter) stepper motor for direct extruder " +"or a new hotend is installed, heavy fan with a duct is added, etc." +msgstr "" + +msgid "Belts are tightened." +msgstr "" + +msgid "Some addons to increase frame rigidity are installed." +msgstr "" + +msgid "" +"Different bed is installed on a bed-slinger printer, or glass added, etc." +msgstr "" + +msgid "" +"If such changes are made, it is a good idea to at least measure the ringing " +"frequencies to see if they have changed." +msgstr "" + +msgid "Input shaper configuration" +msgstr "" + +msgid "" +"After the ringing frequencies for X and Y axes are measured, you can add the" +" following section to your `printer.cfg`:" +msgstr "" + +msgid "For the example above, we get shaper_freq_x/y = 49.4." +msgstr "" + +msgid "Choosing input shaper" +msgstr "" + +msgid "" +"Klipper supports several input shapers. They differ in their sensitivity to " +"errors determining the resonance frequency and how much smoothing they cause" +" in the printed parts. Also, some of the shapers like 2HUMP_EI and 3HUMP_EI " +"should usually not be used with shaper_freq = resonance frequency - they are" +" configured from different considerations to reduce several resonances at " +"once." +msgstr "" + +msgid "" +"For most of the printers, either MZV or EI shapers can be recommended. This " +"section describes a testing process to choose between them, and figure out a" +" few other related parameters." +msgstr "" + +msgid "" +"If you see no ringing at this point, then MZV shaper can be recommended for " +"use." +msgstr "" + +msgid "" +"If you do see some ringing, re-measure the frequencies using steps (8)-(10) " +"described in [Ringing frequency](#ringing-frequency) section. If the " +"frequencies differ significantly from the values you obtained earlier, a " +"more complex input shaper configuration is needed. You can refer to " +"Technical details of [Input shapers](#input-shapers) section. Otherwise, " +"proceed to the next step." +msgstr "" + +msgid "" +"Compare two prints with MZV and EI input shaper. If EI shows noticeably " +"better results than MZV, use EI shaper, otherwise prefer MZV. Note that EI " +"shaper will cause more smoothing in printed parts (see the next section for " +"further details). Add `shaper_type: mzv` (or ei) parameter to [input_shaper]" +" section, e.g.:" +msgstr "" + +msgid "A few notes on shaper selection:" +msgstr "" + +msgid "" +"EI shaper may be more suited for bed slinger printers (if the resonance " +"frequency and resulting smoothing allows): as more filament is deposited on " +"the moving bed, the mass of the bed increases and the resonance frequency " +"will decrease. Since EI shaper is more robust to resonance frequency " +"changes, it may work better when printing large parts." +msgstr "" + +msgid "" +"Due to the nature of delta kinematics, resonance frequencies can differ a " +"lot in different parts of the build volume. Therefore, EI shaper can be a " +"better fit for delta printers rather than MZV or ZV, and should be " +"considered for the use. If the resonance frequency is sufficiently large " +"(more than 50-60 Hz), then one can even attempt to test 2HUMP_EI shaper (by " +"running the suggested test above with `SET_INPUT_SHAPER " +"SHAPER_TYPE=2HUMP_EI`), but check the considerations in the [section " +"below](#selecting-max_accel) before enabling it." +msgstr "" + +msgid "Selecting max_accel" +msgstr "" + +msgid "" +"In order to select a suitable max_accel value, inspect the model for the " +"chosen input shaper. First, take a note at which acceleration ringing is " +"still small - that you are comfortable with it." +msgstr "" + +msgid "" +"Next, check the smoothing. To help with that, the test model has a small gap" +" in the wall (0.15 mm):" +msgstr "" + +msgid "![Test gap](img/smoothing-test.png)" +msgstr "" + +msgid "" +"As the acceleration increases, so does the smoothing, and the actual gap in " +"the print widens:" +msgstr "" + +msgid "![Shaper smoothing](img/shaper-smoothing.jpg)" +msgstr "" + +msgid "" +"In this picture, the acceleration increases left to right, and the gap " +"starts to grow starting from 3500 mm/sec^2 (5-th band from the left). So the" +" good value for max_accel = 3000 (mm/sec^2) in this case to avoid the " +"excessive smoothing." +msgstr "" + +msgid "" +"Note the acceleration when the gap is still very small in your test print. " +"If you see bulges, but no gap in the wall at all, even at high " +"accelerations, it may be due to disabled Pressure Advance, especially on " +"Bowden extruders. If that is the case, you may need to repeat the print with" +" the PA enabled. It may also be a result of a miscalibrated (too high) " +"filament flow, so it is a good idea to check that too." +msgstr "" + +msgid "" +"As a note, it may happen - especially at low ringing frequencies - that EI " +"shaper will cause too much smoothing even at lower accelerations. In this " +"case, MZV may be a better choice, because it may allow higher acceleration " +"values." +msgstr "" + +msgid "" +"At very low ringing frequencies (~25 Hz and below) even MZV shaper may " +"create too much smoothing. If that is the case, you can also try to repeat " +"the steps in [Choosing input shaper](#choosing-input-shaper) section with ZV" +" shaper, by using `SET_INPUT_SHAPER SHAPER_TYPE=ZV` command instead. ZV " +"shaper should show even less smoothing than MZV, but is more sensitive to " +"errors in measuring the ringing frequencies." +msgstr "" + +msgid "" +"Another consideration is that if a resonance frequency is too low (below " +"20-25 Hz), it might be a good idea to increase the printer stiffness or " +"reduce the moving mass. Otherwise, acceleration and printing speed may be " +"limited due too much smoothing now instead of ringing." +msgstr "" + +msgid "Fine-tuning resonance frequencies" +msgstr "" + +msgid "" +"Note that the precision of the resonance frequencies measurements using the " +"ringing test model is sufficient for most purposes, so further tuning is not" +" advised. If you still want to try to double-check your results (e.g. if you" +" still see some ringing after printing a test model with an input shaper of " +"your choice with the same frequencies as you have measured earlier), you can" +" follow the steps in this section. Note that if you see ringing at different" +" frequencies after enabling [input_shaper], this section will not help with " +"that." +msgstr "" + +msgid "" +"Calculate the necessary parameters for the `TUNING_TOWER` command to tune " +"`shaper_freq_x` parameter as follows: start = shaper_freq_x * 83 / 132 and " +"factor = shaper_freq_x / 66, where `shaper_freq_x` here is the current value" +" in `printer.cfg`." +msgstr "" + +msgid "Print the test model." +msgstr "" + +msgid "" +"Reset the original frequency value: `SET_INPUT_SHAPER SHAPER_FREQ_X=...`." +msgstr "" + +msgid "" +"Find the band which shows ringing the least and count its number from the " +"bottom starting at 1." +msgstr "" + +msgid "" +"Calculate the new shaper_freq_x value via old shaper_freq_x * (39 + 5 * " +"#band-number) / 66." +msgstr "" + +msgid "" +"Repeat these steps for the Y axis in the same manner, replacing references " +"to X axis with the axis Y (e.g. replace `shaper_freq_x` with `shaper_freq_y`" +" in the formulae and in the `TUNING_TOWER` command)." +msgstr "" + +msgid "" +"As an example, let's assume you have had measured the ringing frequency for " +"one of the axis equal to 45 Hz. This gives start = 45 * 83 / 132 = 28.30 and" +" factor = 45 / 66 = 0.6818 values for `TUNING_TOWER` command. Now let's " +"assume that after printing the test model, the fourth band from the bottom " +"gives the least ringing. This gives the updated shaper_freq_? value equal to" +" 45 * (39 + 5 * 4) / 66 ≈ 40.23." +msgstr "" + +msgid "" +"After both new `shaper_freq_x` and `shaper_freq_y` parameters have been " +"calculated, you can update `[input_shaper]` section in `printer.cfg` with " +"the new `shaper_freq_x` and `shaper_freq_y` values." +msgstr "" + +msgid "Pressure Advance" +msgstr "" + +msgid "Unreliable measurements of ringing frequencies" +msgstr "" + +msgid "" +"If you are unable to measure the ringing frequencies, e.g. if the distance " +"between the oscillations is not stable, you may still be able to take " +"advantage of input shaping techniques, but the results may not be as good as" +" with proper measurements of the frequencies, and will require a bit more " +"tuning and printing the test model. Note that another possibility is to " +"purchase and install an accelerometer and measure the resonances with it " +"(refer to the [docs](Measuring_Resonances.md) describing the required " +"hardware and the setup process) - but this option requires some crimping and" +" soldering." +msgstr "" + +msgid "`RESTART`" +msgstr "" + +msgid "" +"and print the model. Then print the model again, but before printing run " +"instead" +msgstr "" + +msgid "Then print the model for the 3rd time, but now run" +msgstr "" + +msgid "" +"Essentially, we are printing the ringing test model with TUNING_TOWER using " +"2HUMP_EI shaper with shaper_freq = 60 Hz, 50 Hz, and 40 Hz." +msgstr "" + +msgid "" +"If none of the models demonstrate improvements in ringing, then, " +"unfortunately, it does not look like the input shaping techniques can help " +"with your case." +msgstr "" + +msgid "" +"Otherwise, it may be that all models show no ringing, or some show the " +"ringing and some - not so much. Choose the test model with the highest " +"frequency that still shows good improvements in ringing. For example, if 40 " +"Hz and 50 Hz models show almost no ringing, and 60 Hz model already shows " +"some more ringing, stick with 50 Hz." +msgstr "" + +msgid "" +"Now check if EI shaper would be good enough in your case. Choose EI shaper " +"frequency based on the frequency of 2HUMP_EI shaper you chose:" +msgstr "" + +msgid "For 2HUMP_EI 60 Hz shaper, use EI shaper with shaper_freq = 50 Hz." +msgstr "" + +msgid "For 2HUMP_EI 50 Hz shaper, use EI shaper with shaper_freq = 40 Hz." +msgstr "" + +msgid "For 2HUMP_EI 40 Hz shaper, use EI shaper with shaper_freq = 33 Hz." +msgstr "" + +msgid "Now print the test model one more time, running" +msgstr "" + +msgid "" +"providing the shaper_freq_x=... and shaper_freq_y=... as determined " +"previously." +msgstr "" + +msgid "" +"If EI shaper shows very comparable good results as 2HUMP_EI shaper, stick " +"with EI shaper and the frequency determined earlier, otherwise use 2HUMP_EI " +"shaper with the corresponding frequency. Add the results to `printer.cfg` " +"as, e.g." +msgstr "" + +msgid "" +"Continue the tuning with [Selecting max_accel](#selecting-max_accel) " +"section." +msgstr "" + +msgid "Troubleshooting and FAQ" +msgstr "" + +msgid "I cannot get reliable measurements of resonance frequencies" +msgstr "" + +msgid "" +"First, make sure it is not some other problem with the printer instead of " +"ringing. If the measurements are not reliable because, say, the distance " +"between the oscillations is not stable, it might mean that the printer has " +"several resonance frequencies on the same axis. One may try to follow the " +"tuning process described in [Unreliable measurements of ringing " +"frequencies](#unreliable-measurements-of-ringing-frequencies) section and " +"still get something out of the input shaping technique. Another possibility " +"is to install an accelerometer, [measure](Measuring_Resonances.md) the " +"resonances with it, and auto-tune the input shaper using the results of " +"those measurements." +msgstr "" + +msgid "" +"After enabling [input_shaper], I get too smoothed printed parts and fine " +"details are lost" +msgstr "" + +msgid "" +"Check the considerations in [Selecting max_accel](#selecting-max_accel) " +"section. If the resonance frequency is low, one should not set too high " +"max_accel or increase square_corner_velocity parameters. It might also be " +"better to choose MZV or even ZV input shapers over EI (or 2HUMP_EI and " +"3HUMP_EI shapers)." +msgstr "" + +msgid "" +"After successfully printing for some time without ringing, it appears to " +"come back" +msgstr "" + +msgid "" +"It is possible that after some time the resonance frequencies have changed. " +"E.g. maybe the belts tension has changed (belts got more loose), etc. It is " +"a good idea to check and re-measure the ringing frequencies as described in " +"[Ringing frequency](#ringing-frequency) section and update your config file " +"if necessary." +msgstr "" + +msgid "Is dual carriage setup supported with input shapers?" +msgstr "" + +msgid "Does input_shaper affect print time?" +msgstr "" + +msgid "" +"No, `input_shaper` feature has pretty much no impact on the print times by " +"itself. However, the value of `max_accel` certainly does (tuning of this " +"parameter described in [this section](#selecting-max_accel))." +msgstr "" + +msgid "Technical details" +msgstr "" + +msgid "Input shapers" +msgstr "" + +msgid "" +"Input shapers used in Klipper are rather standard, and one can find more in-" +"depth overview in the articles describing the corresponding shapers. This " +"section contains a brief overview of some technical aspects of the supported" +" input shapers. The table below shows some (usually approximate) parameters " +"of each shaper." +msgstr "" + +msgid "Input
shaper" +msgstr "" + +msgid "Shaper
duration" +msgstr "" + +msgid "Vibration reduction 20x
(5% vibration tolerance)" +msgstr "" + +msgid "Vibration reduction 10x
(10% vibration tolerance)" +msgstr "" + +msgid "ZV" +msgstr "" + +msgid "0.5 / shaper_freq" +msgstr "" + +msgid "N/A" +msgstr "" + +msgid "± 5% shaper_freq" +msgstr "" + +msgid "MZV" +msgstr "" + +msgid "0.75 / shaper_freq" +msgstr "" + +msgid "± 4% shaper_freq" +msgstr "" + +msgid "-10%...+15% shaper_freq" +msgstr "" + +msgid "ZVD" +msgstr "" + +msgid "1 / shaper_freq" +msgstr "" + +msgid "± 15% shaper_freq" +msgstr "" + +msgid "± 22% shaper_freq" +msgstr "" + +msgid "EI" +msgstr "" + +msgid "± 20% shaper_freq" +msgstr "" + +msgid "± 25% shaper_freq" +msgstr "" + +msgid "2HUMP_EI" +msgstr "" + +msgid "1.5 / shaper_freq" +msgstr "" + +msgid "± 35% shaper_freq" +msgstr "" + +msgid "± 40 shaper_freq" +msgstr "" + +msgid "3HUMP_EI" +msgstr "" + +msgid "2 / shaper_freq" +msgstr "" + +msgid "-45...+50% shaper_freq" +msgstr "" + +msgid "-50%...+55% shaper_freq" +msgstr "" + +msgid "" +"A note on vibration reduction: the values in the table above are " +"approximate. If the damping ratio of the printer is known for each axis, the" +" shaper can be configured more precisely and it will then reduce the " +"resonances in a bit wider range of frequencies. However, the damping ratio " +"is usually unknown and is hard to estimate without a special equipment, so " +"Klipper uses 0.1 value by default, which is a good all-round value. The " +"frequency ranges in the table cover a number of different possible damping " +"ratios around that value (approx. from 0.05 to 0.2)." +msgstr "" + +msgid "" +"Also note that EI, 2HUMP_EI, and 3HUMP_EI are tuned to reduce vibrations to " +"5%, so the values for 10% vibration tolerance are provided only for the " +"reference." +msgstr "" + +msgid "**How to use this table:**" +msgstr "" + +msgid "" +"Shaper duration affects the smoothing in parts - the larger it is, the more " +"smooth the parts are. This dependency is not linear, but can give a sense of" +" which shapers 'smooth' more for the same frequency. The ordering by " +"smoothing is like this: ZV < MZV < ZVD ≈ EI < 2HUMP_EI < 3HUMP_EI. Also, it " +"is rarely practical to set shaper_freq = resonance freq for shapers 2HUMP_EI" +" and 3HUMP_EI (they should be used to reduce vibrations for several " +"frequencies)." +msgstr "" + +msgid "" +"One can estimate a range of frequencies in which the shaper reduces " +"vibrations. For example, MZV with shaper_freq = 35 Hz reduces vibrations to " +"5% for frequencies [33.6, 36.4] Hz. 3HUMP_EI with shaper_freq = 50 Hz " +"reduces vibrations to 5% in range [27.5, 75] Hz." +msgstr "" + +msgid "" +"One can use this table to check which shaper they should be using if they " +"need to reduce vibrations at several frequencies. For example, if one has " +"resonances at 35 Hz and 60 Hz on the same axis: a) EI shaper needs to have " +"shaper_freq = 35 / (1 - 0.2) = 43.75 Hz, and it will reduce resonances until" +" 43.75 * (1 + 0.2) = 52.5 Hz, so it is not sufficient; b) 2HUMP_EI shaper " +"needs to have shaper_freq = 35 / (1 - 0.35) = 53.85 Hz and will reduce " +"vibrations until 53.85 * (1 + 0.35) = 72.7 Hz - so this is an acceptable " +"configuration. Always try to use as high shaper_freq as possible for a given" +" shaper (perhaps with some safety margin, so in this example shaper_freq ≈ " +"50-52 Hz would work best), and try to use a shaper with as small shaper " +"duration as possible." +msgstr "" + +msgid "" +"If one needs to reduce vibrations at several very different frequencies " +"(say, 30 Hz and 100 Hz), they may see that the table above does not provide " +"enough information. In this case one may have more luck with " +"[scripts/graph_shaper.py](../scripts/graph_shaper.py) script, which is more " +"flexible." +msgstr "" + +msgid "" +"[input_shaper]\n" +"shaper_freq_x: ... # frequency for the X mark of the test model\n" +"shaper_freq_y: ... # frequency for the Y mark of the test model\n" +msgstr "" + +msgid "" +"[input_shaper]\n" +"shaper_freq_x: ...\n" +"shaper_freq_y: ...\n" +"shaper_type: mzv\n" +msgstr "" + +msgid "" +"[input_shaper]\n" +"shaper_freq_x: 50\n" +"shaper_freq_y: 50\n" +"shaper_type: 2hump_ei\n" +msgstr "" + +#: docs/Resonance_Compensation.md:block 7 (paragraph) +msgid "" +"Basic tuning requires measuring the ringing frequencies of the printer by " +"printing a test model." +msgstr "" + +#: docs/Resonance_Compensation.md:block 12 (ordered list) +msgid "" +"If `square_corner_velocity` parameter was changed, revert it back to 5.0. It" +" is not advised to increase it when using input shaper because it can cause " +"more smoothing in parts - it is better to use higher acceleration value " +"instead." +msgstr "" + +#: docs/Resonance_Compensation.md:block 12 (ordered list) +msgid "" +"Increase `max_accel_to_decel` by issuing the following command: " +"`SET_VELOCITY_LIMIT ACCEL_TO_DECEL=7000`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 12 (ordered list) +msgid "Disable Pressure Advance: `SET_PRESSURE_ADVANCE ADVANCE=0`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 12 (ordered list) +msgid "" +"Execute the command: `TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT " +"PARAMETER=ACCEL START=1500 STEP_DELTA=500 STEP_HEIGHT=5` Basically, we try " +"to make ringing more pronounced by setting different large values for " +"acceleration. This command will increase the acceleration every 5 mm " +"starting from 1500 mm/sec^2: 1500 mm/sec^2, 2000 mm/sec^2, 2500 mm/sec^2 and" +" so forth up until 7000 mm/sec^2 at the last band." +msgstr "" + +#: docs/Resonance_Compensation.md:block 12 (ordered list) +msgid "Do (8) - (10) for Y mark as well." +msgstr "" + +#: docs/Resonance_Compensation.md:block 27 (paragraph) +msgid "Print the ringing test model as follows:" +msgstr "" + +#: docs/Resonance_Compensation.md:block 28 (ordered list) +msgid "Restart the firmware: `RESTART`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 28 (ordered list) +msgid "Prepare for test: `SET_VELOCITY_LIMIT ACCEL_TO_DECEL=7000`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 28 (ordered list) +msgid "Execute: `SET_INPUT_SHAPER SHAPER_TYPE=MZV`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 28 (ordered list) +msgid "" +"Execute the command: `TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT " +"PARAMETER=ACCEL START=1500 STEP_DELTA=500 STEP_HEIGHT=5`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 31 (paragraph) +msgid "" +"Now try EI input shaper. To try it, repeat steps (1)-(6) from above, but " +"executing at step 4 the following command instead: `SET_INPUT_SHAPER " +"SHAPER_TYPE=EI`." +msgstr "" + +#: docs/Resonance_Compensation.md:block 37 (paragraph) +msgid "" +"You should have a printed test for the shaper you chose from the previous " +"step (if you don't, print the test model sliced with the [suggested " +"parameters](#tuning) with the pressure advance disabled " +"`SET_PRESSURE_ADVANCE ADVANCE=0` and with the tuning tower enabled as " +"`TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1500 " +"STEP_DELTA=500 STEP_HEIGHT=5`). Note that at very high accelerations, " +"depending on the resonance frequency and the input shaper you chose (e.g. EI" +" shaper creates more smoothing than MZV), input shaping may cause too much " +"smoothing and rounding of the parts. So, max_accel should be chosen such as " +"to prevent that. Another parameter that can impact smoothing is " +"`square_corner_velocity`, so it is not advisable to increase it above the " +"default 5 mm/sec to prevent increased smoothing." +msgstr "" + +#: docs/Resonance_Compensation.md:block 45 (paragraph) +msgid "" +"Choose the minimum out of the two acceleration values (from ringing and " +"smoothing), and put it as `max_accel` into printer.cfg." +msgstr "" + +#: docs/Resonance_Compensation.md:block 51 (paragraph) +msgid "" +"Assuming that you have sliced the ringing model with suggested parameters, " +"complete the following steps for each of the axes X and Y:" +msgstr "" + +#: docs/Resonance_Compensation.md:block 52 (ordered list) +msgid "" +"Make sure Pressure Advance is disabled: `SET_PRESSURE_ADVANCE ADVANCE=0`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 52 (ordered list) +msgid "Execute: `SET_INPUT_SHAPER SHAPER_TYPE=ZV`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 52 (ordered list) +msgid "" +"From the existing ringing test model with your chosen input shaper select " +"the acceleration that shows ringing sufficiently well, and set it with: " +"`SET_VELOCITY_LIMIT ACCEL=...`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 52 (ordered list) +msgid "" +"Execute the command: `TUNING_TOWER COMMAND=SET_INPUT_SHAPER " +"PARAMETER=SHAPER_FREQ_X START=start FACTOR=factor BAND=5` using `start` and " +"`factor` values calculated at step (5)." +msgstr "" + +#: docs/Resonance_Compensation.md:block 57 (paragraph) +msgid "" +"If you use Pressure Advance, it may need to be re-tuned. Follow the " +"[instructions](Pressure_Advance.md#tuning-pressure-advance) to find the new " +"value, if it differs from the previous one. Make sure to restart Klipper " +"before tuning Pressure Advance." +msgstr "" + +#: docs/Resonance_Compensation.md:block 60 (paragraph) +msgid "" +"For tuning, add empty `[input_shaper]` section to your `printer.cfg`. Then, " +"assuming that you have sliced the ringing model with suggested parameters, " +"print the test model 3 times as follows. First time, prior to printing, run" +msgstr "" + +#: docs/Resonance_Compensation.md:block 61 (ordered list) +msgid "`SET_VELOCITY_LIMIT ACCEL_TO_DECEL=7000`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 61 (ordered list) +msgid "`SET_PRESSURE_ADVANCE ADVANCE=0`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 61 (ordered list) +msgid "" +"`SET_INPUT_SHAPER SHAPER_TYPE=2HUMP_EI SHAPER_FREQ_X=60 SHAPER_FREQ_Y=60`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 61 (ordered list) +msgid "" +"`TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1500 " +"STEP_DELTA=500 STEP_HEIGHT=5`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 63 (ordered list) +msgid "" +"`SET_INPUT_SHAPER SHAPER_TYPE=2HUMP_EI SHAPER_FREQ_X=50 SHAPER_FREQ_Y=50`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 65 (ordered list) +msgid "" +"`SET_INPUT_SHAPER SHAPER_TYPE=2HUMP_EI SHAPER_FREQ_X=40 SHAPER_FREQ_Y=40`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 72 (ordered list) +msgid "`SET_INPUT_SHAPER SHAPER_TYPE=EI SHAPER_FREQ_X=... SHAPER_FREQ_Y=...`" +msgstr "" + +#: docs/Resonance_Compensation.md:block 85 (paragraph) +msgid "" +"Yes. In this case, one should measure the resonances twice for each " +"carriage. For example, if the second (dual) carriage is installed on X axis," +" it is possible to set different input shapers for X axis for the primary " +"and dual carriages. However, the input shaper for Y axis should be the same " +"for both carriages (as ultimately this axis is driven by one or more stepper" +" motors each commanded to perform exactly the same steps). One possibility " +"to configure the input shaper for such setups is to keep `[input_shaper]` " +"section empty and additionally define a `[delayed_gcode]` section in the " +"`printer.cfg` as follows:" +msgstr "" + +#: docs/Resonance_Compensation.md:block 86 (code) +msgid "" +"[input_shaper]\n" +"# Intentionally empty\n" +"\n" +"[delayed_gcode init_shaper]\n" +"initial_duration: 0.1\n" +"gcode:\n" +" SET_DUAL_CARRIAGE CARRIAGE=1\n" +" SET_INPUT_SHAPER SHAPER_TYPE_X= SHAPER_FREQ_X= SHAPER_TYPE_Y= SHAPER_FREQ_Y=\n" +" SET_DUAL_CARRIAGE CARRIAGE=0\n" +" SET_INPUT_SHAPER SHAPER_TYPE_X= SHAPER_FREQ_X= SHAPER_TYPE_Y= SHAPER_FREQ_Y=\n" +msgstr "" + +#: docs/Resonance_Compensation.md:block 87 (paragraph) +msgid "" +"Note that `SHAPER_TYPE_Y` and `SHAPER_FREQ_Y` should be the same in both " +"commands. It is also possible to put a similar snippet into the start g-code" +" in the slicer, however then the shaper will not be enabled until any print " +"is started." +msgstr "" + +#: docs/Resonance_Compensation.md:block 88 (paragraph) +msgid "" +"Note that the input shaper only needs to be configured once. Subsequent " +"changes of the carriages or their modes via `SET_DUAL_CARRIAGE` command will" +" preserve the configured input shaper parameters." +msgstr "" + +#~ msgid "" +#~ "There is no dedicated support for dual carriages with input shapers, but it " +#~ "does not mean this setup will not work. One should run the tuning twice for " +#~ "each of the carriages, and calculate the ringing frequencies for X and Y " +#~ "axes for each of the carriages independently. Then put the values for " +#~ "carriage 0 into [input_shaper] section, and change the values on the fly " +#~ "when changing carriages, e.g. as a part of some macro:" +#~ msgstr "" + +#~ msgid "And similarly when switching back to carriage 0." +#~ msgstr "" + +#~ msgid "" +#~ "SET_DUAL_CARRIAGE CARRIAGE=1\n" +#~ "SET_INPUT_SHAPER SHAPER_FREQ_X=... SHAPER_FREQ_Y=...\n" +#~ msgstr "" + +#~ msgid "" +#~ "Basic tuning requires measuring the ringing frequencies of the printer and " +#~ "adding a few parameters to `printer.cfg` file." +#~ msgstr "" + +#~ msgid "" +#~ "Increase `max_accel` and `max_accel_to_decel` parameters in your " +#~ "`printer.cfg` to 7000. Note that this is only needed for tuning, and more " +#~ "proper value will be selected in the corresponding [section](#selecting-" +#~ "max_accel)." +#~ msgstr "" + +#~ msgid "" +#~ "If `square_corner_velocity` parameter was changed, revert it back to 5.0. It" +#~ " is not advised to increase it when using the input shaper because it can " +#~ "cause more smoothing in parts - it is better to use higher acceleration " +#~ "value instead." +#~ msgstr "" + +#~ msgid "Restart the firmware: `RESTART`." +#~ msgstr "" + +#~ msgid "Disable Pressure Advance: `SET_PRESSURE_ADVANCE ADVANCE=0`." +#~ msgstr "" + +#~ msgid "" +#~ "Execute the command `TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL" +#~ " START=1250 FACTOR=100 BAND=5`. Basically, we try to make ringing more " +#~ "pronounced by setting different large values for acceleration. This command " +#~ "will increase the acceleration every 5 mm starting from 1500 mm/sec^2: 1500 " +#~ "mm/sec^2, 2000 mm/sec^2, 2500 mm/sec^2 and so forth up until 7000 mm/sec^2 " +#~ "at the last band." +#~ msgstr "" + +#~ msgid "Do (9) - (11) for Y mark as well." +#~ msgstr "" + +#~ msgid "" +#~ "Print the ringing test model as follows (assuming you already have " +#~ "shaper_freq_x/y set and max_accel/max_accel_to_decel increased to 7000 in " +#~ "printer.cfg file):" +#~ msgstr "" + +#~ msgid "Execute `SET_INPUT_SHAPER SHAPER_TYPE=MZV`." +#~ msgstr "" + +#~ msgid "" +#~ "Execute the command `TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL" +#~ " START=1250 FACTOR=100 BAND=5`." +#~ msgstr "" + +#~ msgid "" +#~ "Now try EI input shaper. To try it, repeat steps (1)-(5) from above, but " +#~ "executing at step 3 the following command instead: `SET_INPUT_SHAPER " +#~ "SHAPER_TYPE=EI`." +#~ msgstr "" + +#~ msgid "" +#~ "You should have a printed test for the shaper you chose from the previous " +#~ "step (if you don't, print the test model sliced with the [suggested " +#~ "parameters](#tuning) with the pressure advance disabled " +#~ "`SET_PRESSURE_ADVANCE ADVANCE=0` and with the tuning tower enabled as " +#~ "`TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1250 " +#~ "FACTOR=100 BAND=5`). Note that at very high accelerations, depending on the " +#~ "resonance frequency and the input shaper you chose (e.g. EI shaper creates " +#~ "more smoothing than MZV), input shaping may cause too much smoothing and " +#~ "rounding of the parts. So, max_accel should be chosen such as to prevent " +#~ "that. Another parameter that can impact smoothing is " +#~ "`square_corner_velocity`, so it is not advisable to increase it above the " +#~ "default 5 mm/sec to prevent increased smoothing." +#~ msgstr "" + +#~ msgid "" +#~ "Assuming that you have sliced the ringing model with suggested parameters " +#~ "and increased `max_accel` and `max_accel_to_decel` parameters in the " +#~ "`printer.cfg` to 7000 already, complete the following steps for each of the " +#~ "axes X and Y:" +#~ msgstr "" + +#~ msgid "" +#~ "Make sure Pressure Advance is disabled: `SET_PRESSURE_ADVANCE ADVANCE=0`." +#~ msgstr "" + +#~ msgid "Execute `SET_INPUT_SHAPER SHAPER_TYPE=ZV`." +#~ msgstr "" + +#~ msgid "" +#~ "From the existing ringing test model with your chosen input shaper select " +#~ "the acceleration that shows ringing sufficiently well, and set it with: " +#~ "`SET_VELOCITY_LIMIT ACCEL=...`." +#~ msgstr "" + +#~ msgid "" +#~ "Execute the command `TUNING_TOWER COMMAND=SET_INPUT_SHAPER " +#~ "PARAMETER=SHAPER_FREQ_X START=start FACTOR=factor BAND=5` using `start` and " +#~ "`factor` values calculated at step (4)." +#~ msgstr "" + +#~ msgid "" +#~ "Do not forget to revert the changes to `max_accel` and `max_accel_to_decel` " +#~ "parameters in the `printer.cfg` after finishing this section." +#~ msgstr "" + +#~ msgid "" +#~ "If you use Pressure Advance, it may need to be re-tuned. Follow the " +#~ "[instructions](Pressure_Advance.md#tuning-pressure-advance) to find the new " +#~ "value, if it differs from the previous one. Make sure to restore the " +#~ "original values of `max_accel` and `max_accel_to_decel` parameters in the " +#~ "`printer.cfg` and restart Klipper before tuning Pressure Advance." +#~ msgstr "" + +#~ msgid "" +#~ "For tuning, add empty `[input_shaper]` section to your `printer.cfg`. Then, " +#~ "assuming that you have sliced the ringing model with suggested parameters " +#~ "and increased `max_accel` and `max_accel_to_decel` parameters in the " +#~ "`printer.cfg` to 7000 already, print the test model 3 times as follows. " +#~ "First time, prior to printing, run" +#~ msgstr "" + +#~ msgid "`SET_PRESSURE_ADVANCE ADVANCE=0`." +#~ msgstr "" + +#~ msgid "" +#~ "`SET_INPUT_SHAPER SHAPER_TYPE=2HUMP_EI SHAPER_FREQ_X=60 SHAPER_FREQ_Y=60`." +#~ msgstr "" + +#~ msgid "" +#~ "`TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1250 " +#~ "FACTOR=100 BAND=5`." +#~ msgstr "" + +#~ msgid "" +#~ "`SET_INPUT_SHAPER SHAPER_TYPE=2HUMP_EI SHAPER_FREQ_X=50 SHAPER_FREQ_Y=50`." +#~ msgstr "" + +#~ msgid "" +#~ "`SET_INPUT_SHAPER SHAPER_TYPE=2HUMP_EI SHAPER_FREQ_X=40 SHAPER_FREQ_Y=40`." +#~ msgstr "" + +#~ msgid "`SET_INPUT_SHAPER SHAPER_TYPE=EI SHAPER_FREQ_X=... SHAPER_FREQ_Y=...`." +#~ msgstr "" + +#~ msgid "" +#~ "Choose the minimum out of the two acceleration values (from ringing and " +#~ "smoothing), and put it as max_accel into printer.cfg (you can delete " +#~ "max_accel_to_decel or revert it to the old value)." +#~ msgstr "" + +#~ msgid "" +#~ "Choose the minimum out of the two acceleration values (from ringing and " +#~ "smoothing), and put it as max_accel into printer.cfg (you can delete " +#~ "max_accel_or_decel or revert it to the old value)." +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Rotation_Distance.po b/docs/locales/lt/LC_MESSAGES/Rotation_Distance.po new file mode 100644 index 0000000000..15a4433a64 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Rotation_Distance.po @@ -0,0 +1,278 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"Stepper motor drivers on Klipper require a `rotation_distance` parameter in " +"each [stepper config section](Config_Reference.md#stepper). The " +"`rotation_distance` is the amount of distance that the axis moves with one " +"full revolution of the stepper motor. This document describes how one can " +"configure this value." +msgstr "" + +msgid "Obtaining rotation_distance from steps_per_mm (or step_distance)" +msgstr "" + +msgid "" +"The designers of your 3d printer originally calculated `steps_per_mm` from a" +" rotation distance. If you know the steps_per_mm then it is possible to use " +"this general formula to obtain that original rotation distance:" +msgstr "" + +msgid "" +"Or, if you have an older Klipper configuration and know the `step_distance` " +"parameter you can use this formula:" +msgstr "" + +msgid "" +"The `` setting is determined from the type of " +"stepper motor. Most stepper motors are \"1.8 degree steppers\" and therefore" +" have 200 full steps per rotation (360 divided by 1.8 is 200). Some stepper " +"motors are \"0.9 degree steppers\" and thus have 400 full steps per " +"rotation. Other stepper motors are rare. If unsure, do not set " +"full_steps_per_rotation in the config file and use 200 in the formula above." +msgstr "" + +msgid "" +"The `` setting is determined by the stepper motor driver. Most " +"drivers use 16 microsteps. If unsure, set `microsteps: 16` in the config and" +" use 16 in the formula above." +msgstr "" + +msgid "Calibrating rotation_distance on extruders" +msgstr "" + +msgid "" +"On an extruder, the `rotation_distance` is the amount of distance the " +"filament travels for one full rotation of the stepper motor. The best way to" +" get an accurate value for this setting is to use a \"measure and trim\" " +"procedure." +msgstr "" + +msgid "" +"First start with an initial guess for the rotation distance. This may be " +"obtained from [steps_per_mm](#obtaining-rotation_distance-from-steps_per_mm-" +"or-step_distance) or by [inspecting the hardware](#extruder)." +msgstr "" + +msgid "Then use the following procedure to \"measure and trim\":" +msgstr "" + +msgid "" +"Make sure the extruder has filament in it, the hotend is heated to an " +"appropriate temperature, and the printer is ready to extrude." +msgstr "" + +msgid "" +"Use a marker to place a mark on the filament around 70mm from the intake of " +"the extruder body. Then use a digital calipers to measure the actual " +"distance of that mark as precisely as one can. Note this as " +"``." +msgstr "" + +msgid "" +"Use the digital calipers to measure the new distance between the extruder " +"body and the mark on the filament. Note this as " +"``. Then calculate: `actual_extrude_distance = " +" - `" +msgstr "" + +msgid "" +"Calculate rotation_distance as: `rotation_distance = " +" * / " +"` Round the new rotation_distance to three " +"decimal places." +msgstr "" + +msgid "" +"If the actual_extrude_distance differs from requested_extrude_distance by " +"more than about 2mm then it is a good idea to perform the steps above a " +"second time." +msgstr "" + +msgid "" +"Note: Do *not* use a \"measure and trim\" type of method to calibrate x, y, " +"or z type axes. The \"measure and trim\" method is not accurate enough for " +"those axes and will likely lead to a worse configuration. Instead, if " +"needed, those axes can be determined by [measuring the belts, pulleys, and " +"lead screw hardware](#obtaining-rotation_distance-by-inspecting-the-" +"hardware)." +msgstr "" + +msgid "Obtaining rotation_distance by inspecting the hardware" +msgstr "" + +msgid "" +"It's possible to calculate rotation_distance with knowledge of the stepper " +"motors and printer kinematics. This may be useful if the steps_per_mm is not" +" known or if designing a new printer." +msgstr "" + +msgid "Belt driven axes" +msgstr "" + +msgid "" +"It is easy to calculate rotation_distance for a linear axis that uses a belt" +" and pulley." +msgstr "" + +msgid "" +"First determine the type of belt. Most printers use a 2mm belt pitch (that " +"is, each tooth on the belt is 2mm apart). Then count the number of teeth on " +"the stepper motor pulley. The rotation_distance is then calculated as:" +msgstr "" + +msgid "" +"For example, if a printer has a 2mm belt and uses a pulley with 20 teeth, " +"then the rotation distance is 40." +msgstr "" + +msgid "Axes with a lead screw" +msgstr "" + +msgid "" +"It is easy to calculate the rotation_distance for common lead screws using " +"the following formula:" +msgstr "" + +msgid "" +"For example, the common \"T8 leadscrew\" has a rotation distance of 8 (it " +"has a pitch of 2mm and has 4 separate threads)." +msgstr "" + +msgid "" +"Older printers with \"threaded rods\" have only one \"thread\" on the lead " +"screw and thus the rotation distance is the pitch of the screw. (The screw " +"pitch is the distance between each groove on the screw.) So, for example, an" +" M6 metric rod has a rotation distance of 1 and an M8 rod has a rotation " +"distance of 1.25." +msgstr "" + +msgid "Extruder" +msgstr "" + +msgid "" +"It's possible to obtain an initial rotation distance for extruders by " +"measuring the diameter of the \"hobbed bolt\" that pushes the filament and " +"using the following formula: `rotation_distance = * 3.14`" +msgstr "" + +msgid "" +"If the extruder uses gears then it will also be necessary to [determine and " +"set the gear_ratio](#using-a-gear_ratio) for the extruder." +msgstr "" + +msgid "" +"The actual rotation distance on an extruder will vary from printer to " +"printer, because the grip of the \"hobbed bolt\" that engages the filament " +"can vary. It can even vary between filament spools. After obtaining an " +"initial rotation_distance, use the [measure and trim " +"procedure](#calibrating-rotation_distance-on-extruders) to obtain a more " +"accurate setting." +msgstr "" + +msgid "Using a gear_ratio" +msgstr "" + +msgid "" +"Setting a `gear_ratio` can make it easier to configure the " +"`rotation_distance` on steppers that have a gear box (or similar) attached " +"to it. Most steppers do not have a gear box - if unsure then do not set " +"`gear_ratio` in the config." +msgstr "" + +msgid "" +"When `gear_ratio` is set, the `rotation_distance` represents the distance " +"the axis moves with one full rotation of the final gear on the gear box. If," +" for example, one is using a gearbox with a \"5:1\" ratio, then one could " +"calculate the rotation_distance with [knowledge of the hardware](#obtaining-" +"rotation_distance-by-inspecting-the-hardware) and then add `gear_ratio: 5:1`" +" to the config." +msgstr "" + +msgid "" +"For gearing implemented with belts and pulleys, it is possible to determine " +"the gear_ratio by counting the teeth on the pulleys. For example, if a " +"stepper with a 16 toothed pulley drives the next pulley with 80 teeth then " +"one would use `gear_ratio: 80:16`. Indeed, one could open a common off the " +"shelf \"gear box\" and count the teeth in it to confirm its gear ratio." +msgstr "" + +msgid "" +"Note that sometimes a gearbox will have a slightly different gear ratio than" +" what it is advertised as. The common BMG extruder motor gears are an " +"example of this - they are advertised as \"3:1\" but actually use \"50:17\" " +"gearing. (Using teeth numbers without a common denominator may improve " +"overall gear wear as the teeth don't always mesh the same way with each " +"revolution.) The common \"5.18:1 planetary gearbox\", is more accurately " +"configured with `gear_ratio: 57:11`." +msgstr "" + +msgid "" +"If several gears are used on an axis then it is possible to provide a comma " +"separated list to gear_ratio. For example, a \"5:1\" gear box driving a 16 " +"toothed to 80 toothed pulley could use `gear_ratio: 5:1, 80:16`." +msgstr "" + +msgid "" +"In most cases, gear_ratio should be defined with whole numbers as common " +"gears and pulleys have a whole number of teeth on them. However, in cases " +"where a belt drives a pulley using friction instead of teeth, it may make " +"sense to use a floating point number in the gear ratio (eg, `gear_ratio: " +"107.237:16`)." +msgstr "" + +msgid "" +"rotation_distance = * / " +"\n" +msgstr "" + +msgid "" +"rotation_distance = * * " +"\n" +msgstr "" + +msgid "rotation_distance = * \n" +msgstr "" + +msgid "rotation_distance = * \n" +msgstr "" + +#: docs/Rotation_Distance.md:block 1 (header) +msgid "Rotation distance" +msgstr "" + +#: docs/Rotation_Distance.md:block 15 (ordered list) +msgid "" +"Extrude 50mm of filament with the following command sequence: `G91` followed" +" by `G1 E50 F60`. Note 50mm as ``. Wait for the " +"extruder to finish the move (it will take about 50 seconds). It is important" +" to use the slow extrusion rate for this test as a faster rate can cause " +"high pressure in the extruder which will skew the results. (Do not use the " +"\"extrude button\" on graphical front-ends for this test as they extrude at " +"a fast rate.)" +msgstr "" + +#: docs/Rotation_Distance.md:block 10 (paragraph) +msgid "" +"Almost all printers should have a whole number for `rotation_distance` on X," +" Y, and Z type axes. If the above formula results in a rotation_distance " +"that is within .01 of a whole number then round the final value to that " +"whole_number." +msgstr "" + +#~ msgid "" +#~ "Almost all printers should have a whole number for `rotation_distance` on x," +#~ " y, and z type axes. If the above formula results in a rotation_distance " +#~ "that is within .01 of a whole number then round the final value to that " +#~ "whole_number." +#~ msgstr "" + +#~ msgid "" +#~ "Extrude 50mm of filament with the following command sequence: `G91` followed" +#~ " by `G1 E50 F60`. Note 50mm as ``. Wait for the " +#~ "extruder to finish the move (it will take about 50 seconds)." +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/SDCard_Updates.po b/docs/locales/lt/LC_MESSAGES/SDCard_Updates.po new file mode 100644 index 0000000000..6b6289d203 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/SDCard_Updates.po @@ -0,0 +1,538 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"Many of today's popular controller boards ship with a bootloader capable of " +"updating firmware via SD Card. While this is convenient in many " +"circumstances, these bootloaders typically provide no other way to update " +"firmware. This can be a nuisance if your board is mounted in a location that" +" is difficult to access or if you need to update firmware often. After " +"Klipper has been initially flashed to a controller it is possible to " +"transfer new firmware to the SD Card and initiate the flashing procedure via" +" ssh." +msgstr "" + +msgid "Typical Upgrade Procedure" +msgstr "" + +msgid "" +"The procedure for updating MCU firmware using the SD Card is similar to that" +" of other methods. Instead of using `make flash` it is necessary to run a " +"helper script, `flash-sdcard.sh`. Updating a BigTreeTech SKR 1.3 might look " +"like the following:" +msgstr "" + +msgid "" +"It is up to the user to determine the device location and board name. If a " +"user needs to flash multiple boards, `flash-sdcard.sh` (or `make flash` if " +"appropriate) should be run for each board prior to restarting the Klipper " +"service." +msgstr "" + +msgid "Supported boards can be listed with the following command:" +msgstr "" + +msgid "" +"If you do not see your board listed it may be necessary to add a new board " +"definition as [described below](#board-definitions)." +msgstr "" + +msgid "Advanced Usage" +msgstr "" + +msgid "" +"The above commands assume that your MCU connects at the default baud rate of" +" 250000 and the firmware is located at `~/klipper/out/klipper.bin`. The " +"`flash-sdcard.sh` script provides options for changing these defaults. All " +"options can be viewed by the help screen:" +msgstr "" + +msgid "" +"If your board is flashed with firmware that connects at a custom baud rate " +"it is possible to upgrade by specifying the `-b` option:" +msgstr "" + +msgid "" +"If you wish to flash a build of Klipper located somewhere other than the " +"default location it can be done by specifying the `-f` option:" +msgstr "" + +msgid "" +"Note that when upgrading a MKS Robin E3 it is not necessary to manually run " +"`update_mks_robin.py` and supply the resulting binary to `flash-sdcard.sh`. " +"This procedure is automated during the upload process." +msgstr "" + +msgid "Caveats" +msgstr "" + +msgid "" +"As mentioned in the introduction, this method only works for upgrading " +"firmware. The initial flashing procedure must be done manually per the " +"instructions that apply to your controller board." +msgstr "" + +msgid "" +"While it is possible to flash a build that changes the Serial Baud or " +"connection interface (ie: from USB to UART), verification will always fail " +"as the script will be unable to reconnect to the MCU to verify the current " +"version." +msgstr "" + +msgid "Board Definitions" +msgstr "" + +msgid "" +"Most common boards should be available, however it is possible to add a new " +"board definition if necessary. Board definitions are located in " +"`~/klipper/scripts/spi_flash/board_defs.py`. The definitions are stored in " +"dictionary, for example:" +msgstr "" + +msgid "The following fields may be specified:" +msgstr "" + +msgid "" +"`firmware_path`: The path on the SD Card where firmware should be " +"transferred. The default is `firmware.bin`." +msgstr "" + +msgid "" +"`spi_pins`: This should be 3 comma separated pins that are connected to the " +"SD Card in the format of `miso,mosi,sclk`." +msgstr "" + +msgid "" +"Prior to creating a new board definition one should check to see if an " +"existing board definition meets the criteria necessary for the new board. If" +" this is the case, a `BOARD_ALIAS` may be specified. For example, the " +"following alias may be added to specify `my-new-board` as an alias for " +"`generic-lpc1768`:" +msgstr "" + +msgid "" +"If you need a new board definition and you are uncomfortable with the " +"procedure outlined above it is recommended that you request one in the " +"[Klipper Community Discord](Contact.md#discord)." +msgstr "" + +msgid "" +"sudo service klipper stop\n" +"cd ~/klipper\n" +"git pull\n" +"make clean\n" +"make menuconfig\n" +"make\n" +"./scripts/flash-sdcard.sh /dev/ttyACM0 btt-skr-v1.3\n" +"sudo service klipper start\n" +msgstr "" + +msgid "./scripts/flash-sdcard.sh -l\n" +msgstr "" + +msgid "./scripts/flash-sdcard.sh -b 115200 /dev/ttyAMA0 btt-skr-v1.3\n" +msgstr "" + +msgid "" +"./scripts/flash-sdcard.sh -f ~/downloads/klipper.bin /dev/ttyAMA0 btt-" +"skr-v1.3\n" +msgstr "" + +msgid "" +"BOARD_DEFS = {\n" +" 'generic-lpc1768': {\n" +" 'mcu': \"lpc1768\",\n" +" 'spi_bus': \"ssp1\",\n" +" \"cs_pin\": \"P0.6\"\n" +" },\n" +" ...\n" +"}\n" +msgstr "" + +msgid "" +"BOARD_ALIASES = {\n" +" ...,\n" +" 'my-new-board': BOARD_DEFS['generic-lpc1768'],\n" +"}\n" +msgstr "" + +#: docs/SDCard_Updates.md:block 1 (header) +msgid "SDCard updates" +msgstr "" + +#: docs/SDCard_Updates.md:block 12 (code) +msgid "" +"./scripts/flash-sdcard.sh -h\n" +"SD Card upload utility for Klipper\n" +"\n" +"usage: flash_sdcard.sh [-h] [-l] [-c] [-b ] [-f ]\n" +" \n" +"\n" +"positional arguments:\n" +" device serial port\n" +" board type\n" +"\n" +"optional arguments:\n" +" -h show this message\n" +" -l list available boards\n" +" -c run flash check/verify only (skip upload)\n" +" -b serial baud rate (default is 250000)\n" +" -f path to klipper.bin\n" +msgstr "" + +#: docs/SDCard_Updates.md:block 18 (paragraph) +msgid "" +"The `-c` option is used to perform a check or verify-only operation to test " +"if the board is running the specified firmware correctly. This option is " +"primarily intended for cases where a manual power-cycle is necessary to " +"complete the flashing procedure, such as with bootloaders that use SDIO mode" +" instead of SPI to access their SD Cards. (See Caveats below) But, it can " +"also be used anytime to verify if the code flashed into the board matches " +"the version in your build folder on any supported board." +msgstr "" + +#: docs/SDCard_Updates.md:block 20 (unordered list) +msgid "" +"Only boards that use SPI for SD Card communication are supported. Boards " +"that use SDIO, such as the Flymaker Flyboard and MKS Robin Nano V1/V2, will " +"not work in SDIO mode. However, it's usually possible to flash such boards " +"using Software SPI mode instead. But if the board's bootloader only uses " +"SDIO mode to access the SD Card, a power-cycle of the board and SD Card will" +" be necessary so that the mode can switch from SPI back to SDIO to complete " +"reflashing. Such boards should be defined with `skip_verify` enabled to skip" +" the verify step immediately after flashing. Then after the manual power-" +"cycle, you can rerun the exact same `./scripts/flash-sdcard.sh` command, but" +" add the `-c` option to complete the check/verify operation. See [Flashing " +"Boards that use SDIO](#flashing-boards-that-use-sdio) for examples." +msgstr "" + +#: docs/SDCard_Updates.md:block 25 (unordered list) +msgid "" +"`current_firmware_path`: The path on the SD Card where the renamed firmware " +"file is located after a successful flash. The default is `firmware.cur`." +msgstr "" + +#: docs/SDCard_Updates.md:block 25 (unordered list) +msgid "" +"`skip_verify`: This defines a boolean value which tells the scripts to skip " +"the firmware verification step during the flashing process. The default is " +"`False`. It can be set to `True` for boards that require a manual power-" +"cycle to complete flashing. To verify the firmware afterward, run the script" +" again with the `-c` option to perform the verification step. [See caveats " +"with SDIO cards](#caveats)" +msgstr "" + +#: docs/SDCard_Updates.md:block 26 (paragraph) +msgid "" +"If software SPI is required, the `spi_bus` field should be set to `swspi` " +"and the following additional field should be specified:" +msgstr "" + +#: docs/SDCard_Updates.md:block 28 (paragraph) +msgid "" +"It should be exceedingly rare that Software SPI is necessary, typically only" +" boards with design errors or boards that normally only support SDIO mode " +"for their SD Card will require it. The `btt-skr-pro` board definition " +"provides an example of the former, and the `btt-octopus-f446-v1` board " +"definition provides an example of the latter." +msgstr "" + +#: docs/SDCard_Updates.md:block 32 (header) +msgid "Flashing Boards that use SDIO" +msgstr "" + +#: docs/SDCard_Updates.md:block 33 (paragraph) +msgid "" +"[As mentioned in the Caveats](#caveats), boards whose bootloader uses SDIO " +"mode to access their SD Card require a power-cycle of the board, and " +"specifically the SD Card itself, in order to switch from the SPI Mode used " +"while writing the file to the SD Card back to SDIO mode for the bootloader " +"to flash it into the board. These board definitions will use the " +"`skip_verify` flag, which tells the flashing tool to stop after writing the " +"firmware to the SD Card so that the board can be manually power-cycled and " +"the verification step deferred until that's complete." +msgstr "" + +#: docs/SDCard_Updates.md:block 34 (paragraph) +msgid "" +"There are two scenarios -- one with the RPi Host running on a separate power" +" supply and the other when the RPi Host is running on the same power supply " +"as the main board being flashed. The difference is whether or not it's " +"necessary to also shutdown the RPi and then `ssh` again after the flashing " +"is complete in order to do the verification step, or if the verification can" +" be done immediately. Here's examples of the two scenarios:" +msgstr "" + +#: docs/SDCard_Updates.md:block 35 (header) +msgid "SDIO Programming with RPi on Separate Power Supply" +msgstr "" + +#: docs/SDCard_Updates.md:block 36 (paragraph) +msgid "" +"A typical session with the RPi on a Separate Power Supply looks like the " +"following. You will, of course, need to use your proper device path and " +"board name:" +msgstr "" + +#: docs/SDCard_Updates.md:block 37 (code) +msgid "" +"sudo service klipper stop\n" +"cd ~/klipper\n" +"git pull\n" +"make clean\n" +"make menuconfig\n" +"make\n" +"./scripts/flash-sdcard.sh /dev/ttyACM0 btt-octopus-f446-v1\n" +"[[[manually power-cycle the printer board here when instructed]]]\n" +"./scripts/flash-sdcard.sh -c /dev/ttyACM0 btt-octopus-f446-v1\n" +"sudo service klipper start\n" +msgstr "" + +#: docs/SDCard_Updates.md:block 38 (header) +msgid "SDIO Programming with RPi on the Same Power Supply" +msgstr "" + +#: docs/SDCard_Updates.md:block 39 (paragraph) +msgid "" +"A typical session with the RPi on the Same Power Supply looks like the " +"following. You will, of course, need to use your proper device path and " +"board name:" +msgstr "" + +#: docs/SDCard_Updates.md:block 40 (code) +msgid "" +"sudo service klipper stop\n" +"cd ~/klipper\n" +"git pull\n" +"make clean\n" +"make menuconfig\n" +"make\n" +"./scripts/flash-sdcard.sh /dev/ttyACM0 btt-octopus-f446-v1\n" +"sudo shutdown -h now\n" +"[[[wait for the RPi to shutdown, then power-cycle and ssh again to the RPi when it restarts]]]\n" +"sudo service klipper stop\n" +"cd ~/klipper\n" +"./scripts/flash-sdcard.sh -c /dev/ttyACM0 btt-octopus-f446-v1\n" +"sudo service klipper start\n" +msgstr "" + +#: docs/SDCard_Updates.md:block 41 (paragraph) +msgid "" +"In this case, since the RPi Host is being restarted, which will restart the " +"`klipper` service, it's necessary to stop `klipper` again before doing the " +"verification step and restart it after verification is complete." +msgstr "" + +#: docs/SDCard_Updates.md:block 42 (header) +msgid "SDIO to SPI Pin Mapping" +msgstr "" + +#: docs/SDCard_Updates.md:block 43 (paragraph) +msgid "" +"If your board's schematic uses SDIO for its SD Card, you can map the pins as" +" described in the chart below to determine the compatible Software SPI pins " +"to assign in the `board_defs.py` file:" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "SD Card Pin" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "Micro SD Card Pin" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "SDIO Pin Name" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "SPI Pin Name" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "9" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "1" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "DATA2" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "None (PU)*" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "2" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "CD/DATA3" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "CS" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "3" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "CMD" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "MOSI" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "4" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "+3.3V (VDD)" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "5" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "CLK" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "SCLK" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "6" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "GND (VSS)" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "7" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "DATA0" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "MISO" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "8" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "DATA1" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "N/A" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "Card Detect (CD)" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "10" +msgstr "" + +#: docs/SDCard_Updates.md:block 44 (table) +msgid "GND" +msgstr "" + +#: docs/SDCard_Updates.md:block 45 (paragraph) +msgid "\\* None (PU) indicates an unused pin with a pull-up resistor" +msgstr "" + +#: docs/SDCard_Updates.md:block 25 (unordered list) +msgid "" +"`mcu`: The mcu type. This can be retrieved after configuring the build via " +"`make menuconfig` by running `cat .config | grep CONFIG_MCU`. This field is " +"required." +msgstr "" + +#: docs/SDCard_Updates.md:block 25 (unordered list) +msgid "" +"`spi_bus`: The SPI bus connected to the SD Card. This should be retrieved " +"from the board's schematic. This field is required." +msgstr "" + +#: docs/SDCard_Updates.md:block 25 (unordered list) +msgid "" +"`cs_pin`: The Chip Select Pin connected to the SD Card. This should be " +"retrieved from the board schematic. This field is required." +msgstr "" + +#~ msgid "" +#~ "`mcu`: The mcu type. This can be retrevied after configuring the build via " +#~ "`make menuconfig` by running `cat .config | grep CONFIG_MCU`. This field is " +#~ "required." +#~ msgstr "" + +#~ msgid "" +#~ "`spi_bus`: The SPI bus connected to the SD Card. This should be retreived " +#~ "from the board's schematic. This field is required." +#~ msgstr "" + +#~ msgid "" +#~ "`cs_pin`: The Chip Select Pin connected to the SD Card. This should be " +#~ "retreived from the board schematic. This field is required." +#~ msgstr "" + +#~ msgid "" +#~ "Only boards that use SPI for SD Card communication are supported. Boards " +#~ "that use SDIO, such as the Flymaker Flyboard and MKS Robin Nano V1/V2, will " +#~ "not work." +#~ msgstr "" + +#~ msgid "" +#~ "`current_firmware_path` The path on the SD Card where the renamed firmware " +#~ "file is located after a successful flash. The default is `firmware.cur`." +#~ msgstr "" + +#~ msgid "" +#~ "If software SPI is required the `spi_bus` field should be set to `swspi` and" +#~ " the following additional field should be specified:" +#~ msgstr "" + +#~ msgid "" +#~ "It should be exceedingly rare that Software SPI is necessary, typically only" +#~ " boards with design errors will require it. The `btt-skr-pro` board " +#~ "definition provides an example." +#~ msgstr "" + +#~ msgid "" +#~ "./scripts/flash-sdcard.sh -h\n" +#~ "SD Card upload utility for Klipper\n" +#~ "\n" +#~ "usage: flash_sdcard.sh [-h] [-l] [-b ] [-f ]\n" +#~ " \n" +#~ "\n" +#~ "positional arguments:\n" +#~ " device serial port\n" +#~ " board type\n" +#~ "\n" +#~ "optional arguments:\n" +#~ " -h show this message\n" +#~ " -l list available boards\n" +#~ " -b serial baud rate (default is 250000)\n" +#~ " -f path to klipper.bin\n" +#~ msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Skew_Correction.po b/docs/locales/lt/LC_MESSAGES/Skew_Correction.po new file mode 100644 index 0000000000..341d805dfb --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Skew_Correction.po @@ -0,0 +1,169 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: docs/Skew_Correction.md:block 1 (header) +msgid "Skew correction" +msgstr "" + +#: docs/Skew_Correction.md:block 2 (paragraph) +msgid "" +"Software based skew correction can help resolve dimensional inaccuracies " +"resulting from a printer assembly that is not perfectly square. Note that if" +" your printer is significantly skewed it is strongly recommended to first " +"use mechanical means to get your printer as square as possible prior to " +"applying software based correction." +msgstr "" + +#: docs/Skew_Correction.md:block 3 (header) +msgid "Print a Calibration Object" +msgstr "" + +#: docs/Skew_Correction.md:block 4 (paragraph) +msgid "" +"The first step in correcting skew is to print a [calibration " +"object](https://www.thingiverse.com/thing:2563185/files) along the plane you" +" want to correct. There is also a [calibration " +"object](https://www.thingiverse.com/thing:2972743) that includes all planes " +"in one model. You want the object oriented so that corner A is toward the " +"origin of the plane." +msgstr "" + +#: docs/Skew_Correction.md:block 5 (paragraph) +msgid "" +"Make sure that no skew correction is applied during this print. You may do " +"this by either removing the `[skew_correction]` module from printer.cfg or " +"by issuing a `SET_SKEW CLEAR=1` gcode." +msgstr "" + +#: docs/Skew_Correction.md:block 6 (header) +msgid "Take your measurements" +msgstr "" + +#: docs/Skew_Correction.md:block 7 (paragraph) +msgid "" +"The `[skew_correcton]` module requires 3 measurements for each plane you " +"want to correct; the length from Corner A to Corner C, the length from " +"Corner B to Corner D, and the length from Corner A to Corner D. When " +"measuring length AD do not include the flats on the corners that some test " +"objects provide." +msgstr "" + +#: docs/Skew_Correction.md:block 8 (paragraph) +msgid "![skew_lengths](img/skew_lengths.png)" +msgstr "" + +#: docs/Skew_Correction.md:block 9 (header) +msgid "Configure your skew" +msgstr "" + +#: docs/Skew_Correction.md:block 10 (paragraph) +msgid "" +"Make sure `[skew_correction]` is in printer.cfg. You may now use the " +"`SET_SKEW` gcode to configure skew_correcton. For example, if your measured " +"lengths along XY are as follows:" +msgstr "" + +#: docs/Skew_Correction.md:block 11 (code) +msgid "" +"Length AC = 140.4\n" +"Length BD = 142.8\n" +"Length AD = 99.8\n" +msgstr "" + +#: docs/Skew_Correction.md:block 12 (paragraph) +msgid "`SET_SKEW` can be used to configure skew correction for the XY plane." +msgstr "" + +#: docs/Skew_Correction.md:block 13 (code) +msgid "SET_SKEW XY=140.4,142.8,99.8\n" +msgstr "" + +#: docs/Skew_Correction.md:block 14 (paragraph) +msgid "You may also add measurements for XZ and YZ to the gcode:" +msgstr "" + +#: docs/Skew_Correction.md:block 15 (code) +msgid "SET_SKEW XY=140.4,142.8,99.8 XZ=141.6,141.4,99.8 YZ=142.4,140.5,99.5\n" +msgstr "" + +#: docs/Skew_Correction.md:block 16 (paragraph) +msgid "" +"The `[skew_correction]` module also supports profile management in a manner " +"similar to `[bed_mesh]`. After setting skew using the `SET_SKEW` gcode, you " +"may use the `SKEW_PROFILE` gcode to save it:" +msgstr "" + +#: docs/Skew_Correction.md:block 17 (code) +msgid "SKEW_PROFILE SAVE=my_skew_profile\n" +msgstr "" + +#: docs/Skew_Correction.md:block 18 (paragraph) +msgid "" +"After this command you will be prompted to issue a `SAVE_CONFIG` gcode to " +"save the profile to persistent storage. If no profile is named " +"`my_skew_profile` then a new profile will be created. If the named profile " +"exists it will be overwritten." +msgstr "" + +#: docs/Skew_Correction.md:block 19 (paragraph) +msgid "Once you have a saved profile, you may load it:" +msgstr "" + +#: docs/Skew_Correction.md:block 20 (code) +msgid "SKEW_PROFILE LOAD=my_skew_profile\n" +msgstr "" + +#: docs/Skew_Correction.md:block 21 (paragraph) +msgid "It is also possible to remove an old or out of date profile:" +msgstr "" + +#: docs/Skew_Correction.md:block 22 (code) +msgid "SKEW_PROFILE REMOVE=my_skew_profile\n" +msgstr "" + +#: docs/Skew_Correction.md:block 23 (paragraph) +msgid "" +"After removing a profile you will be prompted to issue a `SAVE_CONFIG` to " +"make this change persist." +msgstr "" + +#: docs/Skew_Correction.md:block 24 (header) +msgid "Verifying your correction" +msgstr "" + +#: docs/Skew_Correction.md:block 25 (paragraph) +msgid "" +"After skew_correction has been configured you may reprint the calibration " +"part with correction enabled. Use the following gcode to check your skew on " +"each plane. The results should be lower than those reported via " +"`GET_CURRENT_SKEW`." +msgstr "" + +#: docs/Skew_Correction.md:block 26 (code) +msgid "CALC_MEASURED_SKEW AC= BD= AD=\n" +msgstr "" + +#: docs/Skew_Correction.md:block 27 (header) +msgid "Caveats" +msgstr "" + +#: docs/Skew_Correction.md:block 28 (paragraph) +msgid "" +"Due to the nature of skew correction it is recommended to configure skew in " +"your start gcode, after homing and any kind of movement that travels near " +"the edge of the print area such as a purge or nozzle wipe. You may use use " +"the `SET_SKEW` or `SKEW_PROFILE` gcodes to accomplish this. It is also " +"recommended to issue a `SET_SKEW CLEAR=1` in your end gcode." +msgstr "" + +#: docs/Skew_Correction.md:block 29 (paragraph) +msgid "" +"Keep in mind that it is possible for `[skew_correction]` to generate a " +"correction that moves the tool beyond the printer's boundaries on the X " +"and/or Y axes. It is recommended to arrange parts away from the edges when " +"using `[skew_correction]`." +msgstr "" diff --git a/docs/locales/lt/LC_MESSAGES/Status_Reference.po b/docs/locales/lt/LC_MESSAGES/Status_Reference.po new file mode 100644 index 0000000000..2c723b3c81 --- /dev/null +++ b/docs/locales/lt/LC_MESSAGES/Status_Reference.po @@ -0,0 +1,1150 @@ +# Languages add-on , 2024. +msgid "" +msgstr "" +"Language: lt\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +msgid "" +"This document is a reference of printer status information available in " +"Klipper [macros](Command_Templates.md), [display " +"fields](Config_Reference.md#display), and via the [API " +"Server](API_Server.md)." +msgstr "" + +msgid "" +"The fields in this document are subject to change - if using an attribute be" +" sure to review the [Config Changes document](Config_Changes.md) when " +"upgrading the Klipper software." +msgstr "" + +msgid "bed_mesh" +msgstr "" + +msgid "" +"The following information is available in the " +"[bed_mesh](Config_Reference.md#bed_mesh) object:" +msgstr "" + +msgid "" +"`profile_name`, `mesh_min`, `mesh_max`, `probed_matrix`, `mesh_matrix`: " +"Information on the currently active bed_mesh." +msgstr "" + +msgid "configfile" +msgstr "" + +msgid "" +"The following information is available in the `configfile` object (this " +"object is always available):" +msgstr "" + +msgid "" +"`settings.
.