-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
- <item>
- <title>Is the desktop recommending your program for opening its files?</title>
- <link>https://people.skolelinux.org/pere/blog/Is_the_desktop_recommending_your_program_for_opening_its_files_.html</link>
- <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/Is_the_desktop_recommending_your_program_for_opening_its_files_.html</guid>
- <pubDate>Sun, 29 Jan 2023 11:00:00 +0100</pubDate>
- <description><p>Linux desktop systems
-<a href="https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html">have
-standardized</a> how programs present themselves to the desktop
-system. If a package include a .desktop file in
-/usr/share/applications/, Gnome, KDE, LXDE, Xfce and the other desktop
-environments will pick up the file and use its content to generate the
-menu of available programs in the system. A lesser known fact is that
-a package can also explain to the desktop system how to recognize the
-files created by the program in question, and use it to open these
-files on request, for example via a GUI file browser.</p>
-
-<p>A while back I ran into a package that did not tell the desktop
-system how to recognize its files and was not used to open its files
-in the file browser and fixed it. In the process I wrote a simple
-debian/tests/ script to ensure the setup keep working. It might be
-useful for other packages too, to ensure any future version of the
-package keep handling its own files.</p>
-
-<p>For this to work the file format need a useful MIME type that can
-be used to identify the format. If the file format do not yet have a
-MIME type, it should define one and preferably also
-<a href="https://www.iana.org/assignments/media-types/media-types.xhtml">register
-it with IANA</a> to ensure the MIME type string is reserved.</p>
-
-<p>The script uses the <tt>xdg-mime</tt> program from xdg-utils to
-query the database of standardized package information and ensure it
-return sensible values. It also need the location of an example file
-for xdg-mime to guess the format of.</p>
-
-<pre>
-#!/bin/sh
-#
-# Author: Petter Reinholdtsen
-# License: GPL v2 or later at your choice.
-#
-# Validate the MIME setup, making sure motor types have
-# application/vnd.openmotor+yaml associated with them and is connected
-# to the openmotor desktop file.
-
-retval=0
-
-mimetype="application/vnd.openmotor+yaml"
-testfile="test/data/real/o3100/motor.ric"
-mydesktopfile="openmotor.desktop"
-
-filemime="$(xdg-mime query filetype "$testfile")"
-
-if [ "$mimetype" != "$filemime" ] ; then
- retval=1
- echo "error: xdg-mime claim motor file MIME type is $filemine, not $mimetype"
-else
- echo "success: xdg-mime report correct mime type $mimetype for motor file"
-fi
-
-desktop=$(xdg-mime query default "$mimetype")
-
-if [ "$mydesktopfile" != "$desktop" ]; then
- retval=1
- echo "error: xdg-mime claim motor file should be handled by $desktop, not $mydesktopfile"
-else
- echo "success: xdg-mime agree motor file should be handled by $mydesktopfile"
-fi
-
-exit $retval
-</pre>
-
-<p>It is a simple way to ensure your users are not very surprised when
-they try to open one of your file formats in their file browser.</p>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
- <item>
- <title>Opensnitch, the application level interactive firewall, heading into the Debian archive</title>
- <link>https://people.skolelinux.org/pere/blog/Opensnitch__the_application_level_interactive_firewall__heading_into_the_Debian_archive.html</link>
- <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/Opensnitch__the_application_level_interactive_firewall__heading_into_the_Debian_archive.html</guid>
- <pubDate>Sun, 22 Jan 2023 23:55:00 +0100</pubDate>
- <description><p>While reading a
-<a href="https://sneak.berlin/20230115/macos-scans-your-local-files-now/">blog
-post claiming MacOS X recently started scanning local files and
-reporting information about them to Apple</a>, even on a machine where
-all such callback features had been disabled, I came across a
-description of the Little Snitch application for MacOS X. It seemed
-like a very nice tool to have in the tool box, and I decided to see if
-something similar was available for Linux.</p>
-
-<p>It did not take long to find
-<a href="https://github.com/evilsocket/opensnitch">the OpenSnitch
-package</a>, which has been in development since 2017, and now is in
-version 1.5.0. It has had a
-<a href="https://bugs.debian.org/909567">request for Debian
-packaging</a> since 2018, but no-one completed the job so far. Just
-for fun, I decided to see if I could help, and I was very happy to
-discover that
-<a href="https://github.com/evilsocket/opensnitch/issues/304">upstream
-want a Debian package too</a>.</p>
-
-<p>After struggling a bit with getting the program to run, figuring
-out building Go programs (and a little failed detour to look at eBPF
-builds too - help needed), I am very happy to report that I am
-sponsoring upstream to maintain the package in Debian, and it has
-since this morning been waiting in NEW for the ftpmasters to have a
-look. Perhaps it can get into the archive in time for the Bookworm
-release?</p>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
- <item>
- <title>LinuxCNC MQTT publisher component</title>
- <link>https://people.skolelinux.org/pere/blog/LinuxCNC_MQTT_publisher_component.html</link>
- <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/LinuxCNC_MQTT_publisher_component.html</guid>
- <pubDate>Sun, 8 Jan 2023 19:30:00 +0100</pubDate>
- <description><p>I watched <a href="https://yewtu.be/watch?v=jmKUV3aNLjk">a 2015
-video from Andreas Schiffler</a> the other day, where he set up
-<a href="https://linuxcnc.org/">LinuxCNC</a> to send status
-information to the MQTT broker IBM Bluemix. As I also use MQTT for
-graphing, it occured to me that a generic MQTT LinuxCNC component
-would be useful and I set out to implement it. Today I got the first
-draft limping along and submitted as
-<a href="https://github.com/LinuxCNC/linuxcnc/pull/2253">a patch to the
-LinuxCNC project</a>.</p>
-
-<p>The simple part was setting up the MQTT publishing code in Python.
-I already have set up other parts submitting data to my Mosquito MQTT
-broker, so I could reuse that code. Writing a LinuxCNC component in
-Python as new to me, but using existing examples in the code
-repository and the extensive documentation, this was fairly straight
-forward. The hardest part was creating a automated test for the
-component to ensure it was working. Testing it in a simulated
-LinuxCNC machine proved very useful, as I discovered features I needed
-that I had not thought of yet, and adjusted the code quite a bit to
-make it easier to test without a operational MQTT broker
-available.</p>
-
-<p>The draft is ready and working, but I am unsure which LinuxCNC HAL
-pins I should collect and publish by default (in other words, the
-default set of information pieces published), and how to get the
-machine name from the LinuxCNC INI file. The latter is a minor
-detail, but I expect it would be useful in a setup with several
-machines available. I am hoping for feedback from the experienced
-LinuxCNC developers and users, to make the component even better
-before it can go into the mainland LinuxCNC code base.</p>
-
-<p>Since I started on the MQTT component, I came across
-<a href="https://yewtu.be/watch?v=Bqa2grG0XtA">another video from Kent
-VanderVelden</a> where he combine LinuxCNC with a set of screen glasses
-controlled by a Raspberry Pi, and it occured to me that it would
-be useful for such use cases if LinuxCNC also provided a REST API for
-querying its status. I hope to start on such component once the MQTT
-component is working well.</p>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
- <item>
- <title>ONVIF IP camera management tool finally in Debian</title>
- <link>https://people.skolelinux.org/pere/blog/ONVIF_IP_camera_management_tool_finally_in_Debian.html</link>
- <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/ONVIF_IP_camera_management_tool_finally_in_Debian.html</guid>
- <pubDate>Sat, 24 Dec 2022 08:00:00 +0100</pubDate>
- <description><p>Merry Christmas to you all. Here is a small gift to all those with
-IP cameras following the <a href="https://www.onvif.org/">ONVIF
-specification</a>. There is finally a nice command line and GUI tool
-in Debian to manage ONVIF IP cameras. After working with upstream for
-a few months and sponsoring the upload, I am very happy to report that
-the <a href="https://tracker.debian.org/libonvif">libonvif package</a>
-entered Debian Sid last night.</p>
-
-<p>The package provide a C library to communicate with such cameras, a
-command line tool to locate and update settings of (like password) the
-cameras and a GUI tool to configure and control the units as well as
-preview the video from the camera. Libonvif is available on Both
-Linux and Windows and the GUI tool uses the Qt library. The main
-competitors are non-free software, while libonvif is GNU GPL licensed.
-I am very glad Debian users in the future can control their cameras
-using a free software system provided by Debian. But the ONVIF world
-is full of slightly broken firmware, where the cameras pretend to
-follow the ONVIF specification but fail to set some configuration
-values or refuse to provide video to more than one recipient at the
-time, and the onvif project is quite young and might take a while
-before it completely work with your camera. Upstream seem eager to
-improve the library, so handling any broken camera might be just <a
-href="https://github.com/sr99622/libonvif/">a bug report away</a>.</p>
-
-<p>The package just cleared NEW, and need a new source only upload
-before it can enter testing. This will happen in the next few
-days.</p>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
- <item>
- <title>Managing and using ONVIF IP cameras with Linux</title>
- <link>https://people.skolelinux.org/pere/blog/Managing_and_using_ONVIF_IP_cameras_with_Linux.html</link>
- <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/Managing_and_using_ONVIF_IP_cameras_with_Linux.html</guid>
- <pubDate>Wed, 19 Oct 2022 12:30:00 +0200</pubDate>
- <description><p>Recently I have been looking at how to control and collect data
-from a handful IP cameras using Linux. I both wanted to change their
-settings and to make their imagery available via a free software
-service under my control. Here is a summary of the tools I found.</p>
-
-<p>First I had to identify the cameras and their protocols. As far as
-I could tell, they were using some SOAP looking protocol and their
-internal web server seem to only work with Microsoft Internet Explorer
-with some proprietary binary plugin, which in these days of course is
-a security disaster and also made it impossible for me to use the
-camera web interface. Luckily I discovered that the SOAP looking
-protocol is actually following <a href="https://www.onvif.org/">the
-ONVIF specification</a>, which seem to be supported by a lot of IP
-cameras these days.</p>
-
-<p>Once the protocol was identified, I was able to find what appear to
-be the most popular way to configure ONVIF cameras, the free software
-Windows tool named
-<a href="https://sourceforge.net/projects/onvifdm/">ONVIF Device
-Manager</a>. Lacking any other options at the time, I tried
-unsuccessfully to get it running using Wine, but was missing a dotnet
-40 library and I found no way around it to run it on Linux.</p>
-
-<p>The next tool I found to configure the cameras were a non-free Linux Qt
-client <a href="https://www.lingodigit.com/onvif_nvcdemo.html">ONVIF
-Device Tool</a>. I did not like its terms of use, so did not spend
-much time on it.</p>
-
-<p>To collect the video and make it available in a web interface, I
-found the Zoneminder tool in Debian. A recent version was able to
-automatically detect and configure ONVIF devices, so I could use it to
-set up motion detection in and collection of the camera output. I had
-initial problems getting the ONVIF autodetection to work, as both
-Firefox and Chromium <a href="https://bugs.debian.org/1001188">refused
-the inter-tab communication</a> being used by the Zoneminder web
-pages, but managed to get konqueror to work. Apparently the "Enhanced
-Tracking Protection" in Firefox cause the problem. I ended up
-upgrading to the Bookworm edition of Zoneminder in the process to try
-to fix the issue, and believe the problem might be solved now.</p>
-
-<p>In the process I came across the nice Linux GUI tool
-<a href="https://gitlab.com/caspermeijn/onvifviewer/">ONVIF Viewer</a>
-allowing me to preview the camera output and validate the login
-passwords required. Sadly its author has grown tired of maintaining
-the software, so it might not see any future updates. Which is sad,
-as the viewer is sightly unstable and the picture tend to lock up.
-Note, this lockup might be due to limitations in the cameras and not
-the viewer implementation. I suspect the camera is only able to
-provide pictures to one client at the time, and the Zoneminder feed
-might interfere with the GUI viewer. I have
-<a href="https://bugs.debian.org/1000820">asked for the tool to be
-included in Debian</a>.</p>
-
-<p>Finally, I found what appear to be very nice Linux free software
-replacement for the Windows tool, named
-<a href="https://github.com/sr99622/libonvif/">libonvif</a>. It
-provide a C library to talk to ONVIF devices as well as a command line
-and GUI tool using the library. Using the GUI tool I was able to change
-the admin passwords and update other settings of the cameras. I have
-<a href="https://bugs.debian.org/1021980">asked for the package to be
-included in Debian</a>.</p>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-
-<p><strong>Update 2022-10-20</strong>: Since my initial publication of
-this text, I got several suggestions for more free software Linux
-tools. There is <a href="https://github.com/quatanium/python-onvif">a
-ONVIF python library</a> (already
-<a href="https://bugs.debian.org/824240">requested into Debian</a>) and
-<a href="https://github.com/FalkTannhaeuser/python-onvif-zeep">a python 3
-fork</a> using a different SOAP dependency. There is also
-<a href="https://www.home-assistant.io/integrations/onvif/">support for
-ONVIF in Home Assistant</a>, and there is an alternative to Zoneminder
-called <a href="https://www.shinobi.video/">Shinobi</a>. The latter
-two are not included in Debian either. I have not tested any of these
-so far.</p>
-</description>
- </item>
-
- <item>
- <title>Time to translate the Bullseye edition of the Debian Administrator's Handbook</title>
- <link>https://people.skolelinux.org/pere/blog/Time_to_translate_the_Bullseye_edition_of_the_Debian_Administrator_s_Handbook.html</link>
- <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/Time_to_translate_the_Bullseye_edition_of_the_Debian_Administrator_s_Handbook.html</guid>
- <pubDate>Mon, 12 Sep 2022 15:45:00 +0200</pubDate>
- <description><p align="center"><img align="center" src="http://people.skolelinux.org/pere/blog/images/2020-10-20-debian-handbook-nb-testprint.jpeg" width="60%"/></p>
-
-<p>(The picture is of the previous edition.)</p>
-
-<p>Almost two years after the previous Norwegian Bokmål translation of
-the "<a href="https://debian-handbook.info/">The Debian Administrator's
-Handbook</a>" was published, a new edition is finally being prepared. The
-english text is updated, and it is time to start working on the
-translations. Around 37 percent of the strings have been updated, one
-way or another, and the translations starting from a complete Debian Buster
-edition now need to bring their translation up from 63% to 100%. The
-complete book is licensed using a Creative Commons license, and has
-been published in several languages over the years. The translations
-are done by volunteers to bring Linux in their native tongue. The
-last time I checked, it complete text was available in English,
-Norwegian Bokmål, German, Indonesian, Brazil Portuguese and Spanish.
-In addition, work has been started for Arabic (Morocco), Catalan,
-Chinese (Simplified), Chinese (Traditional), Croatian, Czech, Danish,
-Dutch, French, Greek, Italian, Japanese, Korean, Persian, Polish,
-Romanian, Russian, Swedish, Turkish and Vietnamese.</p>
-
-<p>The translation is conducted on
-<a href="https://hosted.weblate.org/projects/debian-handbook/">the
-hosted weblate project page</a>. Prospective translators are
-recommeded to subscribe to
-<a href="http://lists.alioth.debian.org/mailman/listinfo/debian-handbook-translators">the
-translators mailing list</a> and should also check out
-<a href="https://debian-handbook.info/contribute/">the instructions for
-contributors</a>.</p>
-
-<p>I am one of the Norwegian Bokmål translators of this book, and we
-have just started. Your contribution is most welcome.</p>
-
-<p>As usual, if you use Bitcoin and want to show your support of my
-activities, please send Bitcoin donations to my address
-<b><a href="bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b</a></b>.</p>
-</description>
- </item>
-
- <item>
- <title>Automatic LinuxCNC servo PID tuning?</title>
- <link>https://people.skolelinux.org/pere/blog/Automatic_LinuxCNC_servo_PID_tuning_.html</link>
- <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/Automatic_LinuxCNC_servo_PID_tuning_.html</guid>
- <pubDate>Sat, 16 Jul 2022 22:30:00 +0200</pubDate>
- <description><p>While working on a CNC with servo motors controlled by the
-<a href="https://en.wikipedia.org/wiki/LinuxCNC">LinuxCNC</a>
-<a href="https://en.wikipedia.org/wiki/PID_controller">PID
-controller</a>, I recently had to learn how to tune the collection of values
-that control such mathematical machinery that a PID controller is. It
-proved to be a lot harder than I hoped, and I still have not succeeded
-in getting the Z PID controller to successfully defy gravity, nor X
-and Y to move accurately and reliably. But while climbing up this
-rather steep learning curve, I discovered that some motor control
-systems are able to tune their PID controllers. I got the impression
-from the documentation that LinuxCNC were not. This proved to be not
-true.</p>
-
-<p>The LinuxCNC
-<a href="http://linuxcnc.org/docs/html/man/man9/pid.9.html">pid
-component</a> is the recommended PID controller to use. It uses eight
-constants <tt>Pgain</tt>, <tt>Igain</tt>, <tt>Dgain</tt>,
-<tt>bias</tt>, <tt>FF0</tt>, <tt>FF1</tt>, <tt>FF2</tt> and
-<tt>FF3</tt> to calculate the output value based on current and wanted
-state, and all of these need to have a sensible value for the
-controller to behave properly. Note, there are even more values
-involved, theser are just the most important ones. In my case I need
-the X, Y and Z axes to follow the requested path with little error.
-This has proved quite a challenge for someone who have never tuned a
-PID controller before, but there is at least some help to be found.
-
-<p>I discovered that included in LinuxCNC was this old PID component
-at_pid claiming to have auto tuning capabilities. Sadly it had been
-neglected since 2011, and could not be used as a plug in replacement
-for the default pid component. One would have to rewriting the
-LinuxCNC HAL setup to test at_pid. This was rather sad, when I wanted
-to quickly test auto tuning to see if it did a better job than me at
-figuring out good P, I and D values to use.</p>
-
-<p>I decided to have a look if the situation could be improved. This
-involved trying to understand the code and history of the pid and
-at_pid components. Apparently they had a common ancestor, as code
-structure, comments and variable names were quite close to each other.
-Sadly this was not reflected in the git history, making it hard to
-figure out what really happened. My guess is that the author of
-<a href="https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/at_pid.c">at_pid.c</a>
-took a version of
-<a href="https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/pid.c">pid.c</a>,
-rewrote it to follow the structure he wished pid.c to have, then added
-support for auto tuning and finally got it included into the LinuxCNC
-repository. The restructuring and lack of early history made it
-harder to figure out which part of the code were relevant to the auto
-tuning, and which part of the code needed to be updated to work the
-same way as the current pid.c implementation. I started by trying to
-isolate relevant changes in pid.c, and applying them to at_pid.c. My
-aim was to make sure the at_pid component could replace the pid
-component with a simple change in the HAL setup loadrt line, without
-having to "rewire" the rest of the HAL configuration. After a few
-hours following this approach, I had learned quite a lot about the
-code structure of both components, while concluding I was heading down
-the wrong rabbit hole, and should get back to the surface and find a
-different path.</p>
-
-<p>For the second attempt, I decided to throw away all the PID control
-related part of the original at_pid.c, and instead isolate and lift
-the auto tuning part of the code and inject it into a copy of pid.c.
-This ensured compatibility with the current pid component, while
-adding auto tuning as a run time option. To make it easier to identify
-the relevant parts in the future, I wrapped all the auto tuning code
-with '#ifdef AUTO_TUNER'. The end result behave just like the current
-pid component by default, as that part of the code is identical. The
-<a href="https://github.com/LinuxCNC/linuxcnc/pull/1820">end result
-entered the LinuxCNC master branch</a> a few days ago.</p>
-
-<p>To enable auto tuning, one need to set a few HAL pins in the PID
-component. The most important ones are <tt>tune-effort</tt>,
-<tt>tune-mode</tt> and <tt>tune-start</tt>. But lets take a step
-back, and see what the auto tuning code will do. I do not know the
-mathematical foundation of the at_pid algorithm, but from observation
-I can tell that the algorithm will, when enabled, produce a square
-wave pattern centered around the <tt>bias</tt> value on the output pin
-of the PID controller. This can be seen using the HAL Scope provided
-by LinuxCNC. In my case, this is translated into voltage (+-10V) sent
-to the motor controller, which in turn is translated into motor speed.
-So at_pid will ask the motor to move the axis back and forth. The
-number of cycles in the pattern is controlled by the
-<tt>tune-cycles</tt> pin, and the extremes of the wave pattern is
-controlled by the <tt>tune-effort</tt> pin. Of course, trying to
-change the direction of a physical object instantly (as in going
-directly from a positive voltage to the equivalent negative voltage)
-do not change velocity instantly, and it take some time for the object
-to slow down and move in the opposite direction. This result in a
-more smooth movement wave form, as the axis in question were vibrating
-back and forth. When the axis reached the target speed in the
-opposing direction, the auto tuner change direction again. After
-several of these changes, the average time delay between the 'peaks'
-and 'valleys' of this movement graph is then used to calculate
-proposed values for Pgain, Igain and Dgain, and insert them into the
-HAL model to use by the pid controller. The auto tuned settings are
-not great, but htye work a lot better than the values I had been able
-to cook up on my own, at least for the horizontal X and Y axis. But I
-had to use very small <tt>tune-effort<tt> values, as my motor
-controllers error out if the voltage change too quickly. I've been
-less lucky with the Z axis, which is moving a heavy object up and
-down, and seem to confuse the algorithm. The Z axis movement became a
-lot better when I introduced a <tt>bias</tt> value to counter the
-gravitational drag, but I will have to work a lot more on the Z axis
-PID values.</p>
-
-<p>Armed with this knowledge, it is time to look at how to do the
-tuning. Lets say the HAL configuration in question load the PID
-component for X, Y and Z like this:</p>
-
-<blockquote><pre>
-loadrt pid names=pid.x,pid.y,pid.z
-</pre></blockquote>
-
-<p>Armed with the new and improved at_pid component, the new line will
-look like this:</p>
-
-<blockquote><pre>
-loadrt at_pid names=pid.x,pid.y,pid.z
-</pre></blockquote>
-
-<p>The rest of the HAL setup can stay the same. This work because the
-components are referenced by name. If the component had used count=3
-instead, all use of pid.# had to be changed to at_pid.#.</p>
-
-<p>To start tuning the X axis, move the axis to the middle of its
-range, to make sure it do not hit anything when it start moving back
-and forth. Next, set the <tt>tune-effort</tt> to a low number in the
-output range. I used 0.1 as my initial value. Next, assign 1 to the
-<tt>tune-mode</tt> value. Note, this will disable the pid controlling
-part and feed 0 to the output pin, which in my case initially caused a
-lot of drift. In my case it proved to be a good idea with X and Y to
-tune the motor driver to make sure 0 voltage stopped the motor
-rotation. On the other hand, for the Z axis this proved to be a bad
-idea, so it will depend on your setup. It might help to set the
-<tt>bias</tt> value to a output value that reduce or eliminate the
-axis drift. Finally, after setting <tt>tune-mode</tt>, set
-<tt>tune-start</tt> to 1 to activate the auto tuning. If all go well,
-your axis will vibrate for a few seconds and when it is done, new
-values for Pgain, Igain and Dgain will be active. To test them,
-change <tt>tune-mode</tt> back to 0. Note that this might cause the
-machine to suddenly jerk as it bring the axis back to its commanded
-position, which it might have drifted away from during tuning. To
-summarize with some halcmd lines:</p>
-
-<blockquote><pre>
-setp pid.x.tune-effort 0.1
-setp pid.x.tune-mode 1
-setp pid.x.tune-start 1
-# wait for the tuning to complete
-setp pid.x.tune-mode 0
-</pre></blockquote>
-
-<p>After doing this task quite a few times while trying to figure out
-how to properly tune the PID controllers on the machine in, I decided
-to figure out if this process could be automated, and wrote a script
-to do the entire tuning process from power on. The end result will
-ensure the machine is powered on and ready to run, home all axis if it
-is not already done, check that the extra tuning pins are available,
-move the axis to its mid point, run the auto tuning and re-enable the
-pid controller when it is done. It can be run several times. Check
-out the
-<a href="https://github.com/SebKuzminsky/MazakVQC1540/blob/bon-dev/scripts/run-auto-pid-tuner">run-auto-pid-tuner</a>
-script on github if you want to learn how it is done.</p>
-
-<p>My hope is that this little adventure can inspire someone who know
-more about motor PID controller tuning can implement even better
-algorithms for automatic PID tuning in LinuxCNC, making life easier
-for both me and all the others that want to use LinuxCNC but lack the
-in depth knowledge needed to tune PID controllers well.</p>
-
projects / homepage.git / blobdiff