Back
[08:36:08] <quitte_> Hi. I used those instructions:
http://www.linuxcnc.org/index.php/english/forum/9-installing-linuxcnc/27080-install-linuxcnc-on-preempt-rt to checkout a copy that I want to build for preempt_rt. but there seems to be no such configuration option. what should I use instead?
[08:38:40] <mhaberler> quitte_: I recommend you read up on this document:
http://static.mah.priv.at/public/html/common/UnifiedBuild.html#_issue_tracker
[08:40:25] <mhaberler> this the branch I worked on, and which is stable but packaged:
https://github.com/mhaberler/linuxcnc - this packaging effort is underway in this branch but is work in progress:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/unified-build-candidate-3
[08:40:44] <mhaberler> probably better to use the latter by now
[08:42:29] <quitte_> thanks. I guess I messed up when typing the git checkout. it created a new branch for me.
[08:43:45] <mhaberler> no, the checkout command is wrong in the forum
[08:43:48] <mhaberler> try this:
[08:44:01] <mhaberler> git checkout -b unified-build-candidate-3 origin/unified-build-candidate-3
[08:44:14] <mhaberler> the one in the forum will give you master :-/
[08:44:53] <quitte_> thanks. another day that I don't have to read into the git manpages ;)
[08:53:30] <mhaberler> sorry meant to say 'stable but building packages dont work in this branch'
[08:55:10] <quitte_> this whole thing already took 2 more days than expected. packaging doesn't scare me any more
[08:56:46] <mhaberler> what was the problem? the right starting point?
[08:58:13] <quitte_> I noticed I ruined my pxe boot setup which contained the linuxcnc installation. and in the process of restoring that I got annoyed with ubuntu so now I'm building a pxe bootable debian live system to replace what worked fine
[08:58:46] <quitte_> it's what I call holidays, I guess
[08:59:08] <mhaberler> welcome to the ubuntu defectors club ;)
[08:59:48] <mhaberler> I dont see any point in using it, debian ist just fine as a LinuxCNC bootrom with lots less hassle
[09:01:18] <quitte_> the preempt-rt kernel lacks aufs support. but still,yes, debian feels like less hassle
[09:03:46] <mhaberler> are you doing embedded?
[09:04:41] <quitte_> I guess. studying something ece-ish
[09:06:00] <quitte_> i hope to get my hands on some arm with multiple cores and an mmu and then approach it with a bare-metal compiler to see what that's all about
[09:11:28] <mhaberler> ece .. whats that?
[09:12:13] <quitte_> electronics and computer engineering
[09:12:17] <mhaberler> rt-preempt support on ARM might be disappointing
[09:12:26] <quitte_> Elektronik und technische Informatik
[09:12:29] <CaptHindsight> 80uS on arm
[09:12:46] <mhaberler> the best results we have is with Xenomai
[09:13:11] <CaptHindsight> RTAI should drop it further
[09:14:17] <quitte_> I don't care much about linux on arm at the moment. I wanted to learn about how computers work and thus I like using things no more complicated than freertos and jtag
[09:14:29] <mhaberler> Besides all this latency discussion, I would really be interested in a good answer to: what difference in quality does it make to have say 10uS vs 100uS latency - I never got a sensible answer to that question
[09:14:39] <memleak> i dont think any of the RTAI devs are working on ARM
[09:14:53] <mhaberler> thats my observation too
[09:16:25] <CaptHindsight> ...yet
[09:16:34] <memleak> lower latency -> more precision at faster speeds if i understand it correctly, i personally am not a machinist
[09:16:54] <memleak> i think it would be sort of fun to be the first of the group to port RTAI to ARM :)
[09:17:40] <archivist> I agree that lower latency -> more precision at faster speeds
[09:18:49] <CaptHindsight> 80uS = 12.5khz, that fast enough for lots of stepper machines
[09:18:54] <mhaberler> I'd be interested in a quantitative answer - there are lots of qualitative arguments, but none I actually saw backed up with actual figures
[09:20:14] <CaptHindsight> and you don't even notice missed steps on a glue gun printer
[09:20:17] <mhaberler> I dont understand your 80uS thing leading to 12.kHz - I assume 80uS is the jitter hence the window of nondeterminism
[09:20:38] <CaptHindsight> yeah roughly
[09:21:18] <mhaberler> right, but 80uS latency means: if you have a 80uS interval thread, chance is you have no cycles left do to any work
[09:21:58] <mhaberler> (at some thread invocations)
[09:22:02] <CaptHindsight> so you'll run a bit slower, it's just back of the napkin figures
[09:22:07] <mhaberler> ah ok
[09:22:10] <pcw_home> for a quantitative answer you need to feed the exact noise signal from a particular system in to the control loop (or model thereof)
[09:22:36] <archivist> but given an amount of jitter you have to leave a margin else the stepper will lose steps/stop
[09:23:17] <mhaberler> pcw_home: are you aware anybody came up with something based on a real machine, like max path deviation?
[09:23:23] <quitte_> wouldn't it be easier to use a really slow system or maybe something like an additional virtualization layer? my guess would be an audible increase in noise as the first sign.
[09:23:27] <pcw_home> some systems have "peaky" jitter, others have baseline wander
[09:24:07] <archivist> I have a tool that may be able to measure but it needs some repair
[09:25:12] <mhaberler> that'd be really interesting
[09:25:39] <mhaberler> it would help to add some meat to the latency belief systems ;)
[09:25:45] <archivist> I need a shottky diode for the psu 60v 70A ish
[09:25:47] <pcw_home> mhaberler: No but it should be fairly easy to try
[09:26:28] <pcw_home> I would make a random delay hal comp
[09:26:57] <mhaberler> ah and a slow path so the delay comp actually makes a difference?
[09:27:23] <archivist> I would want to externally measure from the encoder to the control signal
[09:27:52] <mhaberler> you mean the error term?
[09:28:15] <CaptHindsight> I could put some steppers on a plotter/inkjet and actually print the results of missed steps
[09:29:05] <quitte_> why would a non-servo system loose steps instead of the steps being late?
[09:29:24] <mhaberler> missed steps is a disjoint problem really
[09:29:24] <archivist> inertia in the motor
[09:29:50] <mhaberler> too much load on joint
[09:30:59] <cradek> for soft stepping I think the thing to measure would be the tendency to stall motors
[09:31:06] <mhaberler> pcw_home: any idea what a good noise distribution model would be?
[09:32:27] <pcw_home> Thats a sticky issue because different systems generate different noise statistics
[09:33:31] <mhaberler> research homework: measure machine noise with spectrum analyzer and deterine reasonable approximation ;)
[09:33:44] <pcw_home> yeah
[09:34:05] <mhaberler> gut feeling: this has been done before
[09:36:08] <pcw_home> I'm sure (I just got a taste of this with tuning the hardware stepgen to be tolerant of jitter)
[09:36:12] <archivist> must have been as HP made the dynamic system analysers for the job
[09:37:21] <quitte_> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5396239&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5396239
[09:37:39] <pcw_home> the PID maxerror term is quite helpful to slew limit bogus corrections caused by sampling jitter
[09:37:57] <mhaberler> quitte: any idea how to get a copy?
[09:40:18] <mhaberler> ok, assume we do this in a posix servo-thread only setup, and insert random delay in the servo function chain past halsampler, but before motion.controller - I'd think the next sample should show the distorted value
[09:40:36] <mhaberler> thinking of an easy way to get a handle on it with just a sim setup
[09:40:43] <mhaberler> and halsample
[09:41:02] <mhaberler> so it can be actually plotted
[09:41:13] <archivist> but you are measuring a jitter with a system that has jitter
[09:41:31] <pcw_home> yeah that and a machine model (a low pass filter to start)
[09:41:32] <mhaberler> the way to do this is scale down by a huge factor
[09:41:39] <archivist> it is why I think you need to externally measure
[09:42:00] <mhaberler> so the actual jitter dont count relative to the injected delay
[09:42:13] <CaptHindsight> an actual stepper powered plotter would print actual results :)
[09:42:43] <CaptHindsight> but maybe you just want simulation
[09:43:27] <cradek> what are you trying to measure? how jitter affects path following?
[09:43:53] <mhaberler> determine a quantitative answer to that, yes
[09:44:56] <cradek> gut feel: probably not much. bigger effects would be in the velocity realm: finish problems, machine resonance problems, steppers stalling
[09:45:51] <archivist> as pcw says it is motherboard specific so I dont think you can have a general quantative answer
[09:46:00] <mhaberler> how big.. that's what I'm curious about.
[09:46:52] <mhaberler> for instance there is likel about zero point squeezing out 10uS if the thing is driving a slow glue gun - but I'd rather have a numeric handle upon this
[09:47:12] <archivist> I think the hobbing setup would be a good test bench
[09:47:15] <mhaberler> I think jitter can be perfectly modeled
[09:47:21] <mhaberler> or at least good enough
[09:47:32] <cradek> yes I suspect any effect on path following is in the who-cares realm
[09:47:42] <cradek> stalling your glue gun's steppers is the concern
[09:47:57] <mhaberler> dewey's backplot curve - starting point for distribution
[09:48:07] <cradek> and that depends hugely on hardware issues
[09:48:28] <mhaberler> is _that_ the basis of the latency argument: loosing steps in soft stepping?
[09:48:57] <cradek> I don't know what argument you mean -- but not losing steps. stalling.
[09:49:07] <cradek> steppers work badly enough when they have nice even steps
[09:49:33] <cradek> bet it gets worse pretty fast
[09:49:52] <mhaberler> I'm interested primarily in the servo loop effects because afaic the soft stepping issue is taken care of
[09:50:06] <cradek> taken care of?
[09:50:15] <archivist> one lost step can mean a stall and wrecked work
[09:50:26] <mhaberler> by cheap hardware, like mesa or bb pru
[09:50:28] <cradek> archivist: a late step
[09:50:35] <pcw_home> the position error cause by jitter is
[09:50:37] <pcw_home> 1. proportional to velocity
[09:50:38] <pcw_home> 2. largely determined by jitters effect on feedback
[09:50:49] <archivist> so to keep the torque level right the signal has to be on time
[09:50:51] <cradek> mhaberler: sure in an ideal world, but most of our users are using soft stepping.
[09:50:59] <cradek> [citation needed], I know
[09:51:16] <quitte_> <- anecdata, right here
[09:51:26] <mhaberler> that's an interesting conjecture
[09:52:03] <pcw_home> #2 can be ameliorated by tuning
[09:53:50] <pcw_home> (at leasts that my experience in reducing apparent stepgen FEs in the face of 100 usec jitter from Preemt/RT/Ethernet)
[09:56:43] <cradek> mhaberler: I just polled in #linuxcnc, we'll see (although that's surely not a representative sample)
[09:57:40] <mhaberler> you need to add in about 1000 MachineKit SD card downloads, which are defacto hw stepping
[09:59:11] <cradek> yeah, and 15 years of other downloads (but downloads != users)
[10:00:26] <CaptHindsight> the trend seems to be steppers with EPP on lower cost smaller machines, and nearly all the large machine conversions use servos
[10:01:28] <cradek> that's also what my gut says
[10:01:53] <cradek> not getting much response in #linuxcnc but 3/4 so far say they use software stepping
[10:02:10] <mhaberler> sorry, gotta leave - cu
[10:02:15] <CaptHindsight> either EPP or a mesa fpga
[10:02:39] <CaptHindsight> I rarely even see discussion on servos
[10:02:55] <quitte_> does that mean that I should set my parport to as close to epp only in the bios?
[10:04:38] <pcw_home> if you are using software stepping it does not matter
[10:04:40] <pcw_home> (unless you need the control outputs to be push pull)
[10:05:57] <CaptHindsight> the number of IO (shield/cape/poncho) sold for the BBB is probably a better indication of the number of actual users
[10:14:52] <mozmck> cradek: "but most of our users are using soft stepping." <- I'm not most of linuxCNC users, but we plan to hopefully start using and supporting it soon, and *all* of our stuff is step/dir
[10:15:33] <mozmck> I do use it for my personal router table (4' x 4') and it is software stepping.
[10:17:12] <cradek> mozmck: interesting, thanks
[10:17:33] <archivist> I suppose jitter driving a step/dri servo is a percentage
[10:17:55] <cradek> mozmck: I'm pretty sure I'm right, but mhaberler, the one interested in the answer to this question, has left
[10:17:56] <mozmck> I use Mach at work because I have to :(
[10:19:04] <pcw_home> archivist is also phase jitter
[10:19:12] <pcw_home> its also
[10:19:22] <mozmck> Jitter makes a large difference in how the steppers run. If a machine has too much jitter, you can hear the steppers run roughly, and stall if it's bad enough etc
[10:19:32] <cradek> yes exactly
[10:19:42] <cradek> I think that's the primary harmful effect of jitter
[10:20:10] <mozmck> we have people quite often have to change their computer to get one that will run the machine smoothly
[10:20:11] <seb_kuzm1nsky> jitter shows up as large unexpected (uncontrolled) decelerations in all steppers
[10:20:19] <CaptHindsight> he is able to answer questions from before he logged into the channel so I wouldn't be concerned about him missing out :)
[10:20:21] <cradek> but it is not what mhaberler is proposing trying to measure, which is why I tried to advise
[10:21:58] <mozmck> We try to run at 45 kHz because there is simply not enough speed at 25 khz for a 4' x 8' plasma table, so I disagree that 12.5 khz is enough :)
[10:22:09] <cradek> effect on path following is something you could measure and get a number. effect on stepper motor stalls is something related to the physics of the motors and machine, and is much harder to know
[10:22:24] <mozmck> the drives are 10 micro-stepping (gecko drives)
[10:24:49] <mozmck> It's easy once you've set up steppers on a bunch of machines and watched them scream and chatter and growl and stall on ones with lots of jitter :)
[10:25:08] <pcw_home> I thing part of the problem in not directly host caused jitter
[10:25:09] <cradek> a high-microstep drive will tolerate crappy pulse trains much better, because single pulses don't move the motor much, so late single pulses will not cause much motor acceleration
[10:25:10] <pcw_home> but the DDS beats because of the low base thread rate
[10:25:37] <cradek> I bet that's true too
[10:25:38] <mozmck> 45 khz?
[10:25:50] <pcw_home> (subharmonics)
[10:26:08] <pcw_home> you can hear them
[10:26:22] <mozmck> well, when we use the Mach tool to check the jitter it is high on the machines with the problems.
[10:26:45] <mozmck> We can switch the system to another computer with the exact same settings and it is cured.
[10:27:13] <cradek> some of the microcontroller stepgens switch into a mode that sends clumps of steps
[10:27:29] <cradek> which might work sort-of-ok for microstepping drives
[10:27:42] <cradek> (but ick)
[10:27:45] <mozmck> Wouldn't subharmonics sound rhythmic?
[10:28:14] <pcw_home> we have customers that have seen ~40% faster rapids with hardware stepping
[10:28:15] <pcw_home> not because of the higher possible rate but I think because of no beats
[10:28:36] <pcw_home> (that can excite resonances)
[10:29:07] <cradek> I'm not surprised
[10:29:27] <cradek> (I thought ed nisley studied the clumping stepgen, but I'm not finding it)
[10:29:49] <mozmck> pcw_home: I'm sure you are right there, and hardware stepping is nice, but the extra cost for what we do is mostly not justified so far.
[10:30:08] <cradek> I need to get my 5i25 going... :-/
[10:30:54] <mozmck> We buy whole computers with the parport for less than a hardware step solution costs without the computer!
[10:31:43] <CaptHindsight> lets say jitter is ~80uS, and adding some headroom ~10% you're at 90uS so 11khz
[10:32:41] <CaptHindsight> whats the ratio most use for distance per step? 10um, 25um 50um?
[10:33:14] <mozmck> um? it's all inches here!
[10:33:20] <pcw_home> I think stepconf doubles the jitter to set the basethread
[10:34:00] <CaptHindsight> oh sorry 0.0005", 0.001", 0.002"
[10:35:17] <mozmck> I think X and Y on stuff our customers build typically runs around 2000 steps-per-inch
[10:35:23] <pcw_home> Im sure you could make a PC compatible hardware stepgen for < $10 (say using the Lattice ICE40 FPGAs or a LPC4300)
[10:35:54] <seb_kuzminsky> pcw_home: how would you interface it?
[10:35:55] <mozmck> rapids should be 600 ipm or so which is 20000 step rate.
[10:35:57] <CaptHindsight> lets pick 0.001" and 5khz stepping so 300"/min max
[10:36:14] <pcw_home> EPP for Cheap
[10:36:23] <mozmck> 300 is cutting speed for these machines on thin material
[10:36:30] <seb_kuzminsky> sort of a "7i43 lite"
[10:36:33] <pcw_home> Ethernet on the LPC
[10:37:33] <mozmck> pcw_home: I think we could, and it would be an interesting project, but I don't have the time.
[10:38:39] <mozmck> CaptHindsight: 2000 steps per inch is on the low side too - the Z is normally 10000
[10:39:25] <mozmck> router tables don't have to move as fast but they are typically geared down so they have more steps-per-inch
[10:40:21] <CaptHindsight> so losing a step or two won't even be noticed
[10:40:46] <CaptHindsight> it's well under the play in the machine
[10:40:52] <archivist> once you lose one you stall, so you do notice
[10:40:54] <mozmck> It's noticed in roughness, and even stalling. So they have to slow everything down.
[10:41:47] <CaptHindsight> depends on how often it's losing steps
[10:41:56] <CaptHindsight> makes sense
[10:42:20] <mozmck> true, and they may lose 1 every once in a while and not notice the "bump"
[10:43:17] <mozmck> but if they lose many they definitely notice, and they can lose position as well.
[10:43:24] <mozmck> and they call us...
[10:44:07] <archivist> when I get a one in the while loss its in the middle of a gear and the rest of the gear is wrong, I notice those too
[10:45:01] <CaptHindsight> well preemptRT is ~40uS on x86
[10:45:44] <mozmck> Getting there, and I might play with it, but would never use it for production yet.
[10:46:09] <CaptHindsight> using it with servos here
[10:46:51] <mozmck> Servos and external hardware would be different...
[10:49:44] <CaptHindsight> I'm actually finishing up a small stepper powered printer today
[10:49:58] <memleak> i remember someone was talking about base thread being broken (which it is for me) in latency-test is that fixed yet in latest master with PREEMPT_RT?
[10:50:33] <CaptHindsight> we'll see how it works
[10:51:28] <CaptHindsight> 4k steps per inch
[10:51:59] <mozmck> How fast will it run? That should be interesting.
[10:53:00] <CaptHindsight> I'll plot the actual results
[10:54:13] <CaptHindsight> if I use a 0.003" nozzle about 0.005" will be the res of the plot
[10:55:17] <CaptHindsight> if I use a small laser we could plot down to 0.001"
[10:57:16] <CaptHindsight> but this is all non-contact
[10:59:10] <skunkworks> with the ethernet interface current jitter - you start to see the following error be 'noisier' from my experience
[10:59:51] <skunkworks> more noisy on machines with more jitter - be it nic or reatlime
[11:00:54] <skunkworks> but it is still > a few tenths with the setup I have been playing with
[11:01:02] <skunkworks> < I mean
[11:01:35] <pcw_home> that is mostly "apparent" following error (position sample time jitter)
[11:02:33] <pcw_home> it will be interesting to try the DPLL with the stepgen
[11:09:32] <skunkworks> How is that coming along?
[11:11:11] <pcw_home> I think Michal will add it when he gets a chance
[11:11:28] <skunkworks> neat
[11:12:43] <pcw_home> for the stepgen I need to add the 'latch position on timerN' option
[11:17:35] <pcw_home> (to the firmware)
[12:01:56] <brianmorel99> CaptHindsight, are the latency numbers you are getting from your own customer kernels, or some that are published somewhere?
[12:10:26] <CaptHindsight> brianmorel99: the 8uS RTAI numbers are from following
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_On_Ubuntu_Precise
[12:11:08] <CaptHindsight> the preempt_RT kernels are from memleak, we posted his configs here a few times
[12:13:59] <CaptHindsight> pastebin.com/zgRt1p2E
[12:14:29] <CaptHindsight> 3.10.28 rt25 kernel config
[12:14:50] <memleak> thats the one
[12:17:41] <brianmorel99> thanks!
[12:19:30] <memleak> that kernel config may not work for other machines as it is tuned to specific hardware
[12:20:44] <CaptHindsight> brianmorel99: all AMD MB's
[12:21:40] <brianmorel99> I had a Intel with some crappy built in video, but I have an old AMD board I can swap out and try.
[12:22:02] <brianmorel99> memleak, I'll just be using it as a reference, thanks though.
[12:22:18] <memleak> all NEW AMD MBs
[12:23:04] <memleak> without systemd init*
[12:23:28] <brianmorel99> I shouldn't say old. IT's a Phenom board. I rebuild my dev machine with a Core-i7
[12:34:38] <CaptHindsight> I have it working on a 6-core phenom-II with 780 chipset