[HN Gopher] DIY electronic leadscrew for metalworking lathe [video]
___________________________________________________________________
DIY electronic leadscrew for metalworking lathe [video]
Author : OJFord
Score : 29 points
Date : 2020-03-29 19:00 UTC (4 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| tardo99 wrote:
| Not sure I agree with the bit about Linux + Raspberry Pi not
| being able to handle precision timing down to the microsecond
| level. I'd be interested if anyone has thoughts.
| analog31 wrote:
| I've done a fair amount of timing-critical design, including
| control of stepping motors and encoders for specialized uses.
| My experience has been that "real time" programming on a
| mainstream computer with an operating system is a headache, if
| it's possible at all. It's just a lot easier to do that kind of
| stuff on a mid range microcontroller, where the processor has
| exactly one task and predictable sequencing of operations.
|
| Granted, it was a long time ago, but I remember trying to work
| with a CNC milling machine that generated all of the timing on
| a Windows computer. Everything worked fine unless you touched
| the mouse, which would cause motion to stutter. So, there can
| be a lot of gotchas that have to be accounted for when using a
| "big" computer for "little" things.
| pengaru wrote:
| With proper care it's doable, but that stack is bringing a
| whole lot of baggage you'll need to either strip out or isolate
| your control process from.
|
| Having a bunch of cores is advantageous though. There are a
| variety of options for dedicating one core to the special
| purpose while the rest serve the general-purpose wild west.
|
| But I'd be surprised if you didn't have headaches using some
| python code with cpu affinity on an otherwise unchanged
| raspbian install.
| bacon_waffle wrote:
| Not Raspberry Pi exactly, but the SoC used in Beaglebone has a
| couple "PRU" co-processors which run at 200MHz, share RAM with
| the main CPU, and have access to peripherals including some
| GPIO. It's not too hard to use those for precision timing while
| the main CPU does the typical Linux stuff.
| pritovido wrote:
| He never says that. You probably could do the same with
| multiple 8 bit arduinos as well, I have done something similar
| myself with klipper. But your life while doing that will be
| miserable.
|
| The first thing you have to add for anything serious is a real
| time clock that Raspi DOES NOT HAVE by default.
|
| What he is saying is that Linux is not intended for that,not
| designed for that, because it it not a RTOS, and it is huge.
|
| You can fill the void, but you will be reinventing the wheel.
| Low level hardware design is painful.
|
| Linux is extremely complex, too complex for a person to
| understand. It will take man-years of work to handle all the
| details, that is, it cost hundreds of thousands of dollars just
| in salaries alone.
|
| It is way easier to do what this man has done. And then if you
| want you add an additional raspi with linux as the controlling
| UI.
| clarry wrote:
| Tldw? What do you mean by timing?
|
| Measuring time (down to nanoseconds) is easy. Hard realtime
| scheduling with microsecond precision... just forget about it,
| unless you're building a custom distro & custom kernel and have
| in-depth knowledge about all the drivers that are going to be
| running on the system (you almost definitely do not).
|
| EDIT: I found a relatively recent socket benchmark with worst
| case scheduling latencies ranging from tens to hundreds of
| usec: https://www.codeblueprint.co.uk/2019/12/23/linux-
| preemption-...
| jws wrote:
| You can't really bang bits like you can with carefully cycle
| counted code on something like an Arduino, but you can put
| all your bits into a good sized buffer and use DMA to push
| them out a stable, hardware clocked rate. You still have to
| be able ping pong your buffers fast enough and that isn't
| really guaranteed, but for large enough buffers can be made
| to work, mostly, probably, well... except when...
|
| This technique doesn't work when you need to respond to
| inputs rapidly, but is fine for driving steppers. I see he
| appears to have gone with servos and encoders, so that would
| be a bit of a problem since there are inputs to be read.
| clarry wrote:
| > you can put all your bits into a good sized buffer and
| use DMA to push them out a stable, hardware clocked rate.
|
| Obviously; without buffering, glitch-free audio playback
| would be impossible. I made the assumption that when we're
| talking about timing on Linux, it's not about throwing
| buffers at a hardware clocked device.
|
| Does libgpio or some other interface on Linux give you
| access to clocked DMA out of the box? Do the drivers on RPi
| support it?
|
| All the gpio drivers I've worked with are just directly
| writing state to registers.
| jws wrote:
| Yes, there are DMA driven gpio libraries.
| amelius wrote:
| In Linux you can isolate a cpu from the others, so you can
| get closer to a realtime solution (though you still get
| contention on cache lines, memory bus etc.). I haven't tried
| it though.
|
| https://www.linuxjournal.com/article/6900
| clarry wrote:
| Ouch those graphs indicate worst case interrupt latency in
| the 100ms range... that's one old article!
| bluGill wrote:
| Any cpu with a cache cannot do it because you are not sure if
| the data is in cache and will arrive on time or not. If there
| is something else on the bus (USB, video, network...) you need
| to design the whole system to ensure that the cpu gets the bus
| when it needs it regardless of other uses - most computers are
| not designed this way. A multitasking cpu generally cannot do
| this because you cannot be sure some other process isn't using
| the cpu when you need something.
|
| That isn't to say it can't be done. Audio is very time
| sensitive and Linux does it well with the right kernel options.
| (video is easier, though it uses far more cpu and data on the
| bus, it is less sensitive to delay).
|
| Depending on how bad delay it might or might not work. As rule
| though most real time control is run by low speed 8 bit cpus
| that have exact timing. You have a high power cpu doing the
| calculations and then the microcontroller just runs the result
| of the calculations checking in for new orders as needed.
| monocasa wrote:
| Linux for sure doesn't for the reasons stated here by others.
|
| I would love to see a real RTOS on a RPi though. Something
| based on sel4 would be very nice to see for instance. You won't
| get nanosecond precision due to the cache/system effects like
| people are saying, but microsecond precision should be more
| than doable.
| fermienrico wrote:
| Linux is a GPOS (general purpose operating system) whereas the
| domain of servo controller programming (as shown in the videos)
| is falls under (RTOS). Even if there is no RTOS installed and
| the author is programming on bare metal with interrupt-service-
| routines (ISR), it is essentially a "Real-time Operating
| System" or RTOS. The author could also have used FreeRTOS. The
| primary difference between GPOS such as Linux and RTOS (bare
| metal roundrobin or using something like FreeRTOS, Micrium,
| etc) is that GPOS focus on "throughput" and RTOS specializes in
| "priority". RTOS works by priority-scheduling or roundrobin.
|
| An example would be better. Say there is an external input to
| the system (a sensor that detects roller coaster position), you
| want a deterministic scheduling of the task without any concern
| about the rest of the state of the operating system. Doesn't
| matter what the OS is doing - when the roller coaster's
| position is sensed and there is an interrupt generated to call
| a subroutine (ISR), a RTOS will not block and it will guarantee
| execution. Meanwhile, Linux will schedule the task hoping it
| will get executed but there is no guarantee... I am sure you
| can hack into the kernel space and write a driver but it
| becomes a much more of a laborious task - it is just better to
| use the right OS from the get go.
|
| Hope that makes sense.
|
| A professional motion control system such as [1] comes with 2
| components. RTOS element which is a proprietary controller and
| a GPOS component which is used to communicate, monitor,
| interface with the user (GUI) and do high-level functions.
| Usually this is a piece of software installed on a Windows OS,
| with dedicated PCI cards to communicate to the RTOS modules.
|
| [1] https://www.aerotech.com/product-catalog.aspx
|
| Related reading:
| https://stackoverflow.com/questions/38241352/rtos-example-wh...
|
| https://stackoverflow.com/questions/536506/how-do-real-time-...
|
| Also, checkout LynxOS...this is the top-end of all RTOSs which
| has some POSIX (UNIX) like features. It can also run on
| powerful processors such as Intel and AMD. This is used in
| airplanes (avionics), trains and public works, super critical
| operations:
| https://www.lynx.com/products/lynxos-178-do-178c-certified-p...
| jacquesm wrote:
| It's quite doable but you have to do some low level plumbing to
| make it work, simply disable interrupts, pre-read your data at
| least once to warm up the cache and you're good to go. That's
| how I controlled my plasmacutter.
| defterGoose wrote:
| Yep, he's right about the timing issues. I've taken a deep dive
| into LinuxCNC recently, as I'm using it as the motion controller
| for my custom servo-driven 3dp/Mill, and one of the most
| important decisions one makes up front is what Linux kernel to
| run. The real-time kernels are all but necessary for doing heavy
| number crunching and encoder reading, and that's even on a
| powerful i5-powered desktop machine with custom IO hardware.
|
| As you start to climb into the multiple-thousand dollar arena on
| a project that was planned with just a couple, you really start
| to realize why the manufacturing industry routinely pays
| significant fractions of a $MM for their machines.
___________________________________________________________________
(page generated 2020-03-29 23:00 UTC)