Petter Reinholdtsen - Entries from December 2022

ONVIF IP camera management tool finally in Debian

Sat, 24 Dec 2022 08:00:00 +0100

Merry Christmas to you all. Here is a small gift to all those with +IP cameras following the ONVIF +specification. 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 libonvif package +entered Debian Sid last night.

+ +

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 bug report away.

+ +

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.

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

LinuxCNC MQTT publisher component

Sun, 8 Jan 2023 19:30:00 +0100

I watched a 2015 +video from Andreas Schiffler the other day, where he set up +LinuxCNC 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 patch to the +LinuxCNC project.

+ +

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.

+ +

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.

+ +

Since I started on the MQTT component, I came across +another video from Kent +VanderVelden 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.

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

LinuxCNC MQTT publisher component

Sun, 8 Jan 2023 19:30:00 +0100

+ +

As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Automatic LinuxCNC servo PID tuning?

Sat, 16 Jul 2022 22:30:00 +0200

While working on a CNC with servo motors controlled by the +LinuxCNC +PID +controller, 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.

+ +

The LinuxCNC +pid +component is the recommended PID controller to use. It uses eight +constants Pgain, Igain, Dgain, +bias, FF0, FF1, FF2 and +FF3 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. + +

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.

+ +

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 +at_pid.c +took a version of +pid.c, +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.

+ +

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 +end result +entered the LinuxCNC master branch a few days ago.

+ +

To enable auto tuning, one need to set a few HAL pins in the PID +component. The most important ones are tune-effort, +tune-mode and tune-start. 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 bias 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 +tune-cycles pin, and the extremes of the wave pattern is +controlled by the tune-effort 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 tune-effort 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 bias value to counter the +gravitational drag, but I will have to work a lot more on the Z axis +PID values.

+ +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: + ++loadrt pid names=pid.x,pid.y,pid.z + + +Armed with the new and improved at_pid component, the new line will +look like this: + ++loadrt at_pid names=pid.x,pid.y,pid.z + + +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.#. + +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 tune-effort to a low number in the +output range. I used 0.1 as my initial value. Next, assign 1 to the +tune-mode 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 +bias value to a output value that reduce or eliminate the +axis drift. Finally, after setting tune-mode, set +tune-start 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 tune-mode 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: + ++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 + + +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 +run-auto-pid-tuner +script on github if you want to learn how it is done. + +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. + +As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. +

LinuxCNC translators life just got a bit easier Fri, 3 Jun 2022 21:10:00 +0200 Back in oktober last year, when I started looking at the +LinuxCNC system, I +proposed to change the documentation build system make life easier for +translators. The original system consisted of independently written +documentation files for each language, with no automated way to track +changes done in other translations and no help for the translators to +know how much was left to translated. By using +the po4a system to generate POT and PO +files from the English documentation, this can be improved. A small +team of LinuxCNC contributors got together and today our labour +finally payed off. Since a few hours ago, it is now possible to +translate the +LinuxCNC documentation on Weblate, alongside the program itself. + +The effort to migrate the documentation to use po4a has been both +slow and frustrating. I am very happy we finally made it. + +As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. + Run your industrial metal working machine using Debian? Wed, 2 Mar 2022 18:40:00 +0100 After many months of hard work by the good people involved in +LinuxCNC, the +system was accepted Sunday +into Debian. +Once it was available from Debian, I was surprised to discover from +its +popularity-contest numbers that people have been reporting its use +since 2012. Its project site might +be a good place to check out, but sadly is not working when visiting +via Tor. + +But what is LinuxCNC, you are probably wondering? Perhaps a +Wikipedia quote is in place? + + +"LinuxCNC is a software system for numerical control of +machines such as milling machines, lathes, plasma cutters, routers, +cutting machines, robots and hexapods. It can control up to 9 axes or +joints of a CNC machine using G-code (RS-274NGC) as input. It has +several GUIs suited to specific kinds of usage (touch screen, +interactive development)." + + +It can even control 3D printers. And even though the Wikipedia +page indicate that it can only work with hard real time kernel +features, it can also work with the user space soft real time features +provided by the Debian kernel. +The source code is +available from Github. The last few months I've been involved in the +translation setup for the program and documentation. Translators are +most welcome to +join the +effort using Weblate. + +As usual, if you use Bitcoin and want to show your support of my +activities, please send Bitcoin donations to my address +15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. +