Back
[00:01:53] <tjtr33> i get be28ea49b99854ea130dc8eed208a5f8 binary.hybrid.iso if it seems bad burn i'll report back
[01:09:12] <KGB-linuxcnc> 03Chris Morley 05v2.5_branch 348ace4 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix error with firmware with more then 5 sserial channels * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=348ace4
[08:34:10] <skunkworks> cradek, win32diskimager also works in windows 7..
[08:38:45] <cradek> awesomeness
[09:19:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/rtos-uspace-apis 0fc7ad3 06linuxcnc 10src/Makefile 10src/hal/drivers/mesa-hostmot2/setsserial.c setsserial: port to uspace and enable (untested) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0fc7ad3
[09:24:08] <jepler> linuxcnc-build: ^^ let me know how that works out, OK?
[09:24:48] <jepler> when I get back from this trip, if no more review items or outright objections turn up in my e-mail, I intend to push this to master branch. this would be sunday/monday.
[09:24:59] <skunkworks> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Hybrid_Iso
[09:25:03] <jepler> assuming me and buildbot can come to an agreement
[09:25:04] <skunkworks> cradek, ^
[09:26:15] <cradek> yay! thanks!
[09:33:23] <cradek> I'm adding linux instructions
[09:34:40] <skunkworks> cradek, I was hoping... ;)
[09:45:24] <cradek> ok, I did my best
[09:46:10] <skunkworks> yay!
[09:56:06] <cradek> if I put commented-out sources in linuxcnc.list, they show up as unchecked/unselected in synaptic. this is nice, because I can put the buildbot alternatives right there.
[09:57:05] <cradek> I'm also installing "nopaste" by default, which is an automatic pastebinner. so you can do things like "dmesg | nopaste" and it gives you a URL in return.
[09:57:23] <cradek> I wonder what other things I can do to make things easy on the (haha) support department
[09:57:43] <skunkworks> some editor other than mousepad? ;)
[09:57:52] <skunkworks> or whatever it is called...
[09:57:56] <cradek> hmm
[09:58:01] <cradek> is the editor bad, or just the name?
[09:58:20] <skunkworks> just the name probably.. I have used it off and on with no issues)
[11:05:15] <skunkworks> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Hybrid_Iso
[11:05:20] <skunkworks> oops
[11:05:36] <skunkworks> what I meant to say...
http://electronicsam.com/images/KandT/testing/loading.png
[11:10:51] <cradek> cool. I bet that's ok for a servo-thread-only system
[11:13:09] <skunkworks> sure - it is running -rt
[11:14:12] <pcw_home> what CPU
[11:21:12] <skunkworks> http://www.newegg.com/Product/Product.aspx?Item=N82E16813128698
[11:22:58] <pcw_home> what kernel?
[11:31:03] <skunkworks> http://electronicsam.com/images/KandT/testing/IMG_20140717_110054_019.jpg
[11:31:32] <skunkworks> I just pulled the wheezy -rt kernel from the synaptic package manager.
[11:33:19] <pcw_home> Ill check but I think I'm closer to 50 usec or so on the J1800
[11:37:10] <skunkworks> I had the latency-test running for days - it was around 50us.. but when I started running youtube - it jumped..
[11:37:17] <pcw_home> (home built generic preemt-rt kernel)
[11:37:35] <pcw_home> yeah this is with youtube
[11:38:00] <pcw_home> video seems to be the main source of badness
[11:38:06] <skunkworks> yes
[11:38:54] <pcw_home> plot readtime or dpll-delay-us and move the mouse around
[11:39:05] <pcw_home> (even on RTAI)
[11:40:42] <skunkworks> still totally useable.
[11:41:35] <pcw_home> Yes (and a lot of the side effects of latency noise can be worked around)
[11:42:11] <pcw_home> on the stepgen you lower the bandwidth of the correction loop
[11:43:42] <pcw_home> for a servo I may have to add the DPLL sampled position to the quadrature encoder
[11:43:44] <pcw_home> (pretty sure the velocity estimation is unaffected by sampling jitter)
[11:44:00] <jepler> somewhere along the line I posted a patch which wakes up a certain amount early and busy-waits for the real deadline
[11:44:20] <jepler> it seemed to help the fast thread a certain amount, but harmed the slow thread (probably because it couldn't interrupt the busy-waiting fast thread)
[11:44:37] <jepler> for a single-thread system, this would probably be good
[11:44:41] <pcw_home> thats a possibility also
[11:44:50] <skunkworks> I could try it.
[11:45:46] <pcw_home> the SSI,Fanuc and BISS encoder interfaces are already triggered by the DPLL (since they need a early start)
[11:45:48] <jepler> hmm, I don't immediately find the patch.
[11:46:59] <jepler> if it turns up, I'll repost it
[11:47:03] <jepler> and retest with only a 1ms thread
[11:47:18] <jepler> does anyone know if either of those latency-graphing programs can be started in a single-thread mode?
[11:47:23] <jepler> seems like they always run with two threads
[11:48:42] <pcw_home> is there a man page
[11:50:29] <skunkworks> jepler, this?
http://emergent.unpythonic.net/files/sandbox/0001-uspace-bad-idea-busy-waiting.patch
[11:52:57] <jepler> yes, probably
[11:53:13] <jepler> there's some kind of problem on my end that stopped me finding it in my list of attachments
[12:05:08] <jepler> aha, I have too many backups of my website, and I was looking at files in the wrong backup
[12:05:23] <skunkworks> ehe
[12:05:24] <skunkworks> heh
[12:25:30] <pcw_home> jepler: latency-histogram --nobase
[12:25:46] <pcw_home> (--help shows options)
[12:26:11] <jepler> thanks
[15:14:58] <SkapiN> hi
[15:16:34] <SkapiN> seb_kuzminsky: i tried your deb package on kubuntu 12.04.4{PAE} (i7) , works perfect. 0 trouble (
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_On_Ubuntu_Precise)
[15:21:06] <skunkworks> jepler, no real improvement there.. - creeped up to 80us..
[15:21:16] <skunkworks> (just base thread)
[15:26:42] <skunkworks> * (just servo thread)
[15:27:26] <SkapiN> I have a hard question about LinuxCNC step generation. Perhapse someone can help me to find out some trouble. My latency is 20,000. My driver allow 10,000 as step and time. So i setup like that. I setup my computer with stepconf to use 45,000 latency jitter.
[15:28:55] <SkapiN> i setup maxspeed just bellow calculated Freq. by linxucnc. But when i check the step generation with an external osci. i got some µdelay periodicaly (each 7-9 cycle, depending the current speed)
[15:30:10] <SkapiN> like that :
http://fboudinet.frenchdev.com/files/bad_timing . But when i change the max speed, (more than allowed speed for example) i get perfect step generation. It's kinda random, with max speed, latency and current speed value as parameters
[15:30:45] <SkapiN> (with 25,000 and same max speed i get perfect cycle, but with less max speed i got some delay).
[15:32:01] <SkapiN> It's not Latency issue In my opinion, because latency test tell me 20.000 with full loaded computer. LinuxCNC is okay with25K (no missing thread, motor okay etc...)
[15:33:36] <SkapiN> any idea why linuxCNC do that ? I guess it's due to Math (round(), 32bit etc...) but it's kinda annoying with heavy CNC to have some weird µdelay sometime (but Freq is okay). Perhpase i miss something about step generation etc...
[15:33:51] <cradek> SkapiN: if you're trying to generate steps slightly less than the theoretical maximum, you will get that behavior because the output can only change or not change at each period
[15:36:13] <SkapiN> cradek: explain a bit more, please.
[15:36:21] <SkapiN> but thanks a lot :)
[15:37:11] <SkapiN> soem confusion in my head. I mean it's bad for CNC to have this behavior. I will move a bit more/less thatn calculated
[15:37:18] <cradek> if you want 90% of your maximum possible step rate, the only way to get it is to pulse for 9 periods and then not pulse for 1 period
[15:37:56] <cradek> I don't think that follows from what you have said. Either your thinking is unclear or you have not explained what you mean well enough for me to understand
[15:38:47] <SkapiN> okay
[15:40:42] <SkapiN> cradek: for what i know, speed is calculated on high/low ratio/time., if step go up/down faster, my motor move faster. It's not based on "9 periods and then not pulse for 1 period" . I mean ALL high should stay longer for example
[15:40:55] <SkapiN> not 1 for 10 or 1 for 5 etc...
[15:41:26] <SkapiN> I think I dont have some "data" perhpase you can help me a lot to understand :)
[15:41:58] <cradek> if you are using software pulse generation, the base period is the only time the output can change. it is a periodic event whose timing is fixed.
[15:42:12] <SkapiN> I.E i have the Freq i shoudl have for the given speed. but the "cycle" is not regular/linear
[15:42:19] <cradek> every period, the only possible decision is to change or not change the output
[15:42:43] <SkapiN> yes
[15:42:45] <SkapiN> got it
[15:42:46] <cradek> if this is inadequate, you cannot use software stepgen -- buy a mesa card and you will have wonderful smooth pulses at any speed
[15:42:58] <SkapiN> so it can be because i need 9 and 0.5 hup pulse for example
[15:43:59] <SkapiN> my issue is that the geenrated step is not "linear" so it'es not base_period issue. sicne he can "change" the pin faster but he should not (too soon)
[15:44:18] <cradek> in practice, software stepgen works OK, because drives that need very fast pulses are microstepping with them anyway, and individual microsteps have little effect on the position
[15:44:29] <SkapiN> or it's a "normal" behavior, for exmaple generate some 9.4586 HIGH front in X sec
[15:44:48] <cradek> are you having an actual observed problem with positioning, or are you just imagining that it must be there because of what you see on test equipment?
[15:44:49] <SkapiN> cradek: yes i know, i'm in 128/
[15:45:30] <SkapiN> cradek: just good equipment. i knwo perhapse it's nothing, but the behavior is not "attended"
[15:45:31] <cradek> can you turn your microstep setting down? 128 is very silly and does you no good.
[15:45:52] <cradek> like set it to 8 instead
[15:45:52] <SkapiN> yes i can but it's not driver issue
[15:46:02] <SkapiN> i check the pulse right on DB25 output
[15:46:17] <SkapiN> so we can avoid driver trouble.
[15:46:31] <cradek> but a slower rate will be much smoother because there are many base periods per pulse
[15:46:59] <SkapiN> cradek: i want a specifi rate, regardless the microsteeping
[15:47:04] <SkapiN> microstepin is after
[15:47:13] <cradek> I think you are inventing an imaginary problem?
[15:47:23] <SkapiN> i mean we need more step for same move. but step are the same
[15:48:15] <SkapiN> cradek: no. delay on stepping can be bad with high speed and heavy tools. Inerty etc...
[15:48:47] <SkapiN> but perhapse linuxcnc handle this and "smooth" the delay i dotn know
[15:49:00] <SkapiN> (sometime faster sometime slower)
[15:49:04] <cradek> if you need 1.5 out of 20 base periods to generate a pulse, you will get very low dither. if you need 19.5/20 you will get very high dither
[15:49:23] <SkapiN> yes
[15:49:36] <cradek> so you can reduce the dither by reducing your microstep setting
[15:50:23] <SkapiN> na, you are just changin the Freq.
[15:50:45] <cradek> brb
[15:51:17] <SkapiN> okay, thank you anyway cradek :)
[15:51:21] <SkapiN> really nice of you
[16:23:45] <jepler> you might imagine some other design in which the driver calculates the amount of time to sleep, and then sleeps that long; but that becomes complicated when you have 3 or more stepgens, and it also harms activity like counting encoder pulses, where your main interest is in polling frequently enough that you don't miss any pulses.
[16:25:23] <jepler> even the mesa hardware works on the principle of DDS to generate step pulses, but its basic time unit is on the order of 20ns instead of 20us
[18:10:59] <PCW> skunkworks: I get 54 Usec on my J1800 (running about 4 hours now with youtube flash etc)
[18:12:31] <PCW> skunkworks: I get 54 Usec on my J1800 running about 4 hours now with youtube flash etc (in case that was lost in the netsplit)
[22:01:47] <skunkworks_> I can compare it to the j1800...
[22:05:47] <CaptHindsight> which kernel is this you're testing?
[22:06:34] <CaptHindsight> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Hybrid_Iso the new one in here?
[22:06:58] <skunkworks_> this is user space reatlime using the -rt kernel from debian
[22:07:01] <skunkworks_> realtime
[22:07:42] <skunkworks_> I think this is the j1800 with the debian -rt kernel.
[22:07:43] <CaptHindsight> ah great, I still have to get around to testing linux-image-3.4-9-rtai-686-pae
[22:07:44] <skunkworks_> http://electronicsam.com/images/KandT/testing/posix.png
[22:08:38] <CaptHindsight> it's funny when I'm free everyone else is away, when everyone gets busy with new development I'm away
[22:10:55] <CaptHindsight> I have to still try Wheezy, if I can get multitouch and the onscreen keyboard working that would be great
[22:11:15] <CaptHindsight> it works best so far with Trusty
[22:24:23] <skunkworks_> heh
