#linuxcnc-devel Logs

Jun 29 2017

07:21 AM KGB-linuxcnc: 03Jeff Epler 052.7 515c0a6 06linuxcnc Merge remote-tracking branch 'origin/jepler/2.7/stretch' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=515c0a6
07:27 AM jepler: OK, I hope to build new isos TONIGHT, since that should be the last thing making a frankendistro
07:52 AM jepler: freenode has updated their policies document https://freenode.net/policies
07:52 AM jepler: on a skim it seems fine
11:26 AM jepler: seb_kuzminsky: once there's a 2.7.10 release on wlo, will it be in "2.7-uspace" or "2.7-rtpreempt"?
11:32 AM seb_kuzminsky: on wlo it's called uspace, on the buildbot it's called -sim and -rtpreempt
11:32 AM seb_kuzminsky: it's pretty lame
11:35 AM jepler: so confuse
11:35 AM jepler: this is partly my fault, I know
11:35 AM jepler: but thanks for confirming what it will be
11:37 AM seb_kuzminsky: the buildbot is from back in the "--enable-simulator" days, it predates uspace realtime, and when i hacked it to support rtpreempt i was too lazy to refactor it all properly
11:38 AM jepler: cradek: yes I found where you had compiled zsync on wlo
11:40 AM jepler: woo it's going to speed the transfer by ~90%
11:40 AM cradek: oh yay!
11:40 AM jepler: Read linuxcnc-stretch-uspace-i386-r1.iso. Target 89.1% complete.
11:40 AM cradek: of course I forgot about it and didn't even look
11:43 AM jepler: used 994484224 local, fetched 123239594
11:48 AM jepler: used 1049993216 local, fetched 105522759
11:49 AM jepler: yay, -r2 isos up (both arches)
11:49 AM cradek: zsync is so awesome
11:49 AM cradek: so are you for making images
11:49 AM cradek: thank you
11:49 AM jepler: http://www.linuxcnc.org/testing-stretch-rtpreempt/
11:50 AM seb_kuzminsky: jepler: no .zsync files for the r2 isos?
11:50 AM jepler: seb_kuzminsky: argh jas
11:51 AM jepler: weird, I assumed zsync would keep the .zsync file around
11:51 AM seb_kuzminsky: i wonder what the support implications will be for us of switching from rtai to rt-preempt
11:51 AM seb_kuzminsky: i guess most users won't notice or care
11:51 AM jepler: seb_kuzminsky: zsync files should be up
11:52 AM jepler: I think software stepgen users will notice and care
11:52 AM jepler: pcw says hardware compatibility with older intel chipsets is poor with the 4.9 rt-preempt kernel
11:53 AM jepler: for instance, tom_itx's j1900 (?) was reported to have bad latency
11:53 AM jepler: with this image
11:53 AM seb_kuzminsky: rt-preempt will bring new problems (replacing the old problems we had with rtai) that we'll have to learn how to recognize and debug/work around
11:54 AM seb_kuzminsky: i guess we should keep the old rtai images in "supported" state for a while, after making available the stretch/rt-preempt images
11:54 AM seb_kuzminsky: and warn people to test latency, and to consider going to the older rtai image if the newer image has bad latency
12:23 PM pcw_mesa: My general impressions is that Preempt-RT has poor latency on slower platforms
12:23 PM pcw_mesa: but can rival RTAI on faster ones (also kernels >4.1 often have lousy latency on older hardware)
12:26 PM pcw_mesa: I have not experimented with isolcpus or other tweaks much, I had poor results on my initial tests with
12:26 PM pcw_mesa: isolcpus /Preempt-RT years ago but I should probably retry now
12:28 PM jepler: isolcpus is obeyed
12:28 PM seb_kuzminsky: this sounds like the beginnings of collective wisdom on rt-preempt :-)
12:28 PM jepler: I don't know if it benefits
12:29 PM seb_kuzminsky: i bet it's at least a little helpful to not run unrelated stuff on processors that share l1/l2 with the processor(s) running our realtime thread(s)
12:29 PM seb_kuzminsky: but i haven't measured...
12:29 PM pcw_mesa: Not sure either, might be worth trying on slower CPUs (I get something like 70 usec latency on a D525 for example)
12:30 PM pcw_mesa: i usually also set idle=poll
12:31 PM jepler: yeah if I were searching for the lowest latency I'd probably isolcpus= the one where LinuxCNC would actually be running, and offline the other in the HT pair if HT is enabled
12:31 PM jepler: I found out when playing with the HT-off bug from tom_idx's other(?) motherboard that you can now dynamically online/offline CPUs which is cool!
12:32 PM pcw_mesa: what determines which CPU runs LinuxCNC?
12:33 PM jepler: the intended algorithm is "the highest numbered CPU that is enabled" but as it turns out you can get non-sequential CPU numbers that's not actually what is implemented
12:34 PM jepler: e.g., on Tom's system with HT off he gets two CPUs numbered 0 and 2, and we try to run on CPU #1 (assuming they're numbered 0 and 1)
12:35 PM jepler: which I have a fix for: https://github.com/LinuxCNC/linuxcnc/pull/296
12:36 PM jepler: seb_kuzminsky: .. which I'd appreciate your review on, because I'd like to toss it in 2.7 as well
12:36 PM jepler: afk for lunch
02:52 PM hazzy: When loading large Gcode files (in the tens of MB) it can take a while to generate the preview, especially on a slow computer. I am trying to add a "Preview generation" progress bar to my interface to give some indication of the actual progress.
02:52 PM hazzy: I found that the current line number being processed is passed to the "next_line" function in GLCanon in glcanon.py.
02:52 PM hazzy: As a proof of concept I am able to print the progress percentage by dividing self.lineno in "next_line" by the total number of lines in the file
02:52 PM hazzy: My problem is I don't know how to precede to make it so I can access the line number else wear. Do you all have any advice for how best to implement this?
02:52 PM hazzy: Also, I can't determine who calls the "next_line" function, I guess it might be best to add any necessary code there instead of in GLcanon?
02:52 PM hazzy: I guess ultimately I envision either adding a gsignal to hal_gremlin.py (hal_gremlin imports CGlanon so maybe that would make since), or maybe adding something to the python interface to report the loading progress so that it would be available to the various user interfaces.
02:55 PM cradek: I don't see how you can have a real progress bar, since you don't know how many lines make up the program until you are totally done interpreting it
02:55 PM cradek: maybe an indication for "I'm busy for an unknown amount of time" is the best you can do
02:59 PM hazzy: When I load the file in my interface I first open the file and read the number of lines, so I have that data, all i need to know is the current line the preview is processing to get the percentage
02:59 PM hazzy: I currently have a spinner that is displayed while the preview is generating, but I was hoping for something a little more informative
03:05 PM hazzy: just looked at my code again, actually I get the program length by calling "buf.get_line_count()" on the sourceview buffer, so there is no extra file reading.
03:06 PM skunkworks: forgot about idle=poll.. going to have to try that again
03:06 PM skunkworks: bbl
03:07 PM hazzy: I just confirmed that so indeed I have the total line count before the preview starts being generated to that should be fine
03:08 PM hazzy: just need the current line data
03:11 PM hazzy: So self.state is passed to next_line as st, and self.lineno = self.state.sequence_number
03:12 PM hazzy: Were does self.state come from? Maybe I can get the line number directly from self.state.sequence_number
03:12 PM cradek: how will you handle a program that makes use of subroutines?
03:12 PM cradek: or loops?
03:12 PM jepler: cradek: it's true this method is a problem with subroutines, but it's essentially what axis does
03:13 PM cradek: oh I didn't know/remember that axis has a progress bar
03:13 PM hazzy: Well programs with subroutines are likely to small enough so they will not take a long time to load
03:14 PM hazzy: The troublesome programs are just a bunch of line small segments
03:14 PM hazzy: Out put from CAM
03:15 PM cradek: yeah I see
03:16 PM hazzy: I essentially want to copy axis's progress bar, it does not need to be real accurate, just some indication
03:16 PM cradek: gotcha
03:36 PM seb_kuzminsky: that's quite an initialized there, jepler
03:37 PM seb_kuzminsky: https://github.com/LinuxCNC/linuxcnc/pull/296/files#diff-1e0916462e2abd03736e702b73ce6c11R818
03:37 PM seb_kuzminsky: *initializer
03:41 PM KGB-linuxcnc: 03Sebastian Kuzminsky 052.7 b0e5f68 06linuxcnc Merge remote-tracking branch 'jepler/issue294-2.7' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b0e5f68
03:43 PM seb_kuzminsky: jepler: can you look at the merge of 2.7 into master? it collides bigly in debian/configure
03:46 PM linuxcnc-build: build #4999 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/4999 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
03:47 PM linuxcnc-build: build #4999 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/4999 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
03:47 PM seb_kuzminsky: ohs noes
03:48 PM seb_kuzminsky: i guess lucid's g++ 4.4 is too old for jepler's initialized shenanigans
03:51 PM jepler: seb_kuzminsky: yeah debian/configure is way different
03:51 PM jepler: I'll also look into that build failures
03:51 PM jepler: -s
03:52 PM jepler: I forgot how bad the C++11 support is in old compilers
03:53 PM seb_kuzminsky: ok, thanks
03:53 PM seb_kuzminsky: i was just trying to spin up my old lucid vm but i'm happy to give it to you
03:54 PM seb_kuzminsky: i should finish the part of the github integration i was working on where it downloads PR branches and does rip-and-test on platforms that dont need sudo...
04:08 PM KGB-linuxcnc: 03Jeff Epler 052.7 731620a 06linuxcnc 10src/rtapi/uspace_rtapi_app.cc uspace: fix compiler error on lucid * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=731620a
04:09 PM seb_kuzminsky: nice
04:11 PM jepler: I didn't imagine making so many changes to debian/configure in 2.7 after refactoring it in master :-/
04:12 PM KGB-linuxcnc: 03Jeff Epler 05master 11e8eec 06linuxcnc 10(5 files in 4 dirs) Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=11e8eec
04:24 PM skunkworks: interesting..
04:34 PM linuxcnc-build: build #5016 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5016 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
05:58 PM jepler: thta was to go with the #4999 failures right?
08:34 PM jepler: skunkworks: bed thermistor failed.
08:35 PM skunkworks: the actual thermistor? or is there a broken wire?
08:35 PM skunkworks: (mine the wire broke twice before the re-wire)
08:40 PM jepler: skunksleep: the wire I assume
08:40 PM jepler: I haven't looked since I'd already written off the heated bed