By popular demand, a quick hack that modifies the pyVCP meter widget to have two independent needles. It's used inside the <meter> tag by specifying <halpin2>"my2ndpin"</halpin2> and hooking up something to that pin. If <halpin2> is not used meter works as before, showing only one needle.
There's an XML file for this test-panel, a short HAL-file that hooks up the pins, and a shell script to run it all here: pyvcp_dual-needle-test
The modifications to linuxcnc source required are in lib/python/pyvcp_widgets.py: 0002-dual-needle-meter-use-with-halpin2-meter2-halpin2.patch
NOTE: This is a quick hack to make it work - don't take my code/patch too seriously...
I tried a number of things that are supposed to improve real-time performance, as described in this forum post.
But not much changed. This series of jitter-histograms shows little or no changes:
The things I tried are roughly
- measure first latency histogram 0.png
- uninstall the package irqbalance using synaptic. reboot.
- measure 1.png
- in /etc/default/grub modify GRUB_CMDLINE_LINUX_DEFAULT="isolcpus=1 acpi_irq_nobalance noirqbalance" (Aside: why are the files in /etc/grub.d/ made so incredibly hard to read? Someone should re-write them in Python!). Run sudo update-grub. reboot.
- measure 2.png
- Add irq-affinity.conf to /etc/init/
- Add set-irq-affinity and watchirqs to /usr/local/sbin. reboot
- measure 3.png
- Try to tweak BIOS settings. Turn off power-saving features, etc.
- measure 4.png
The output of watchirqs looks like this:
The scripts mentioned above: irqstuff
Update: this version of the component may compile on 10.04LTS without errors/warnings: frequency2temperature.comp (thanks to jepler!)
There's been some interest in my 2-wire temperature PID control from 2010. It uses one parallel port pin for a PWM-heater, and another connected to a 555-timer for temperature measurement. I didn't document the circuits very well, but they should be simple to reproduce for someone with an electronics background.
Here's the HAL setup once again:
The idea is to count the 555 output-frequency with an encoder, compare this to a set-point value from the user, and use a pid component to drive a pwm-generator that drives the heater.
Now it might be nicer to set the temperature in degrees C instead of a frequency. I've hacked together a new component called frequency2temperature that can be inserted after the encoder. This obviously required the thermistor B-parameters as well as the 555-astable circuit component values as input (these are hard-coded constants in frequency2temperature.comp) . Like this:
I didn't have the actual circuits and extruder at hand when coding this. So instead I made a simulated extruder (sim_extruder) component and generated simulated 555-output. Like this:
This also requires a conversion in the reverse direction called temperature2frequency. A stepgen is then used to generate a pulse-train (simulating the 555-output).
- The INI and HAL files for the simulated extruder, based on the default axis_mm config: simextruder
- frequency2temperature component: frequency2temperature.comp (install with: "comp --install frequency2temperature.comp")
- temperature2frequency component: temperature2frequency.comp (only for simulated setup, not required if you have actual hardware)
- sim_extruder component: sim_extruder.comp (only for simulated setup, not required if you have actual hardware)
"heartyGFX" has made some progress on this. He has a proper circuit diagram for the PWM-heater and 555-astable. His circuits look much nicer than mine!
The diagrams above were drawn with Inkscape in SVG format: temp_pid_control_svg_diagrams
Why bother with these real-time kernels and APIs at all? Isn't timing on a modern PC good enough? Look at this:
This histogram shows latency-numbers from the same 1ms thread test run compiled without (red) and with (green) real-time enabled. All the green real-time data clusters around zero +/- 20us. Without real-time enabled the event we are expecting to happen every 1 ms might happen almost 1 ms too early, or up to 3 ms late. With real-time the timing is mostly consistent to better than 1% (10 us) with a worst-case jitter of 2% (20 us).