Back
[06:59:03] <jthornton> zlog
[08:05:29] <jepler> http://www.pcworld.com/article/3164876/linux/arch-linux-pulls-the-plug-on-32-bit.html [reports also that fedora, ubuntu, and opensuse also are likely to stop with 32-bit x86 soon]
[08:06:13] <jepler> of and of course tails was also recently in the news for dropping 32-bit
https://tails.boum.org/news/Tails_3.0_will_require_a_64-bit_processor/index.en.html
[08:07:30] <archivist> kind of dumb as not all applications need 84 bit
[08:07:37] <archivist> 64
[08:24:43] <jepler> I assume that it's also a matter of where to allocate finite developer and build/CI compute time
[08:24:47] <jepler> .. and testing time
[08:50:44] <archivist> I am thinking of all the embedded linux stuff like routers etc where 64 bit would be overkill
[13:43:31] <seb_kuzminsky> http://chezphil.org/rwanda/index.html
[13:43:50] <seb_kuzminsky> notes on the gigabyte MP30-AR1
[13:43:54] <seb_kuzminsky> tldr: It reflects badly on the ARM ecosystem that this is the best that we have.
[13:50:41] <jepler> or else > This board's greatest strength is that it actually exists
[13:54:04] <cradek> > I've resorted to building a timer circuit that activates the power button shortly after mains power is applied
[13:54:35] <jepler> my experience has been that adding a pull-up resistor on the ATX power connector will also achieve this
[13:55:27] <jepler> PS_ON# to GND, I think
[13:55:50] <jepler> but that assumes the computer boots when the supply rails come up, which may not be true on this machine(?)
[13:55:55] <cradek> > it is extraordinarily slow. It takes 3 minutes to show a Gigabyte logo
[13:57:49] <cradek> > The two gigabit ethernet ports don't work if connected to a 10/100 Mbit/s switch
[13:58:58] <cradek> > I don't think I've received an offer of source code for the Linux and busybox in the BMC.
[13:59:53] <skunkworks> why such a big push for arm servers?
[14:00:32] <cradek> I think seb was hoping to find something for the buildbot that actually works reliably
[14:00:40] <cradek> to build our arm packages
[14:00:57] <skunkworks> I understand that.. but why are people wanting arm servers?
[14:01:37] <cradek> this reviewer says: > You need to be an "ARM geek" to choose it.
[14:01:38] <jepler> as usual the assumption is server class = reliable
[14:02:07] <skunkworks> hmm - I think I will stick to my intel/amd based systems for now.
[14:04:19] <jepler> yeah I wouldn't advocate otherwise
[14:05:52] <jepler> my interest is basically that we've discovered a few interesting bugs when trying to run on ARM; they're real bugs with real fixes, but they just happen to not show up on x86 systems as readily
[14:06:28] <jepler> software is better when it's more portable, and having an ARM server in the buildbot farm helps make sure it stays portable
[14:07:59] <jepler> but there are way too many missing pieces and rough edges that prevent me recommending it for end users to control real iron, and we're short on people who are motivated to work on that (tinkerer was the last one to make a major contribution, a SPI driver for pi2/3 (which is in our git))
[14:08:23] <jepler> (he also worked on an OS image for pi2/3 but it built on kernel debs that didn't appear to have corresponding source offered, which shut down my interest real fast)
[14:08:32] <skunkworks> machinekit just pushed some major changes to fix some of these problems (as I understand it)
[14:10:35] <jepler> ARM is pretty much their emphasis afaik (I sure don't follow their efforts lately)
[14:10:46] <skunkworks> right
[14:26:54] <pcw_mesa> They have Machinekit/Hostmot2 running on both Xilinx and Altera FPGA/ARM combo chips
[14:32:57] <pcw_mesa> Bought one of these to see how well it does
[14:32:59] <pcw_mesa> https://www.newegg.com/Product/Product.aspx?Item=N82E16813157726
[14:33:01] <pcw_mesa> I expect it will work as well as a J1800
[14:33:02] <pcw_mesa> Even has a serial port
[14:34:18] <jepler> hear about the C2000-family Atom processors that have a chip-eating flaw?
http://www.anandtech.com/show/11110/semi-critical-intel-atom-c2000-flaw-discovered
[14:34:29] <jepler> Problem: The SoC LPC_CLKOUT0 and/or LPC_CLKOUT1 signals (Low Pin Count bus clock outputs) may stop functioning.
[14:34:32] <jepler> Implication: If the LPC clock(s) stop functioning the system will no longer be able to boot.
[14:36:13] <JT-Shop> what does sv12 mean on a bit file like 7i90_epp_sv12.bit?
[14:37:49] <pcw_mesa> SV12 is a 12 axis servo config (3 x 7I33 or 7I40 for example)
[14:38:50] <JT-Shop> so one 7i33 on each p1, p2 and p3?
[14:39:24] <skunkworks> doesn't machinekit also have some sort of interrupt control working also? Where the mesa card does the realtime clock?
[14:39:28] <pcw_mesa> Yes (or 7I40x2, 7I29x2)
[14:40:12] <pcw_mesa> Yes they have both SOC and PCI card interrupts working
[14:40:15] <JT-Shop> thanks
[14:40:31] <JT-Shop> so sv=servo?
[14:40:55] <pcw_mesa> yes (normally means PWM+encoder)
[14:41:50] <skunkworks> pcw_mesa, did you see that PDM at 10khz made this 0-10v out of this cheap bob work pretty linear. (+- .01v or so
[14:42:11] <pcw_mesa> They are using the DPLL for IRQ, (DPLL can be used as just a free running timer))
[14:42:45] <skunkworks> what happens if the computer misses the irq? or wouldn't that ever happen?
[14:42:56] <pcw_mesa> I woulld normally expect PWM to be more linear
[14:43:12] <skunkworks> weird
[14:43:15] <JT-Shop> trying to make a firmware reference page
http://www.mesaus.com/info/7i92-firmware.html
[14:43:46] <skunkworks> maybe I didn't pick the right pwm frequency.
[14:44:09] <pcw_mesa> Should never happen ( probably less likely to happen than Linuxcnc's more convoluted IRQ--thread dispatch)
[14:44:49] <skunkworks> This makes it so I can run a lower frequency for the bob (10khz pdm) while still running the drives at 20khz pwm
[14:45:16] <pcw_mesa> Yeah thats a HostMot2 limitation
[14:45:52] <pcw_mesa> so using both PWM/PDM is a decent workaround
[14:46:01] <skunkworks> yes - jepler thought of it :)
[14:47:19] <pcw_mesa> The IRQ thing is nice but has issues with multiple cards (though thats pretty uncommon)
[14:49:49] <pcw_mesa> still futzing with stored read transfer lists for Ethernet (so a broadcast read request could trigger all Ethernet remotes to respond with read data and sync DPLLs simultaneously)
[16:04:14] <stustev> I am looking in the convert_straight to put my 5 axis cutter comp routine. I don't need to use the comp1 section at all but I need to have the gcode values for the current point (where the tool is now) and the next two points. How would I access this information?
[16:06:48] <cradek> get_current and get_programmed are the two representations of the current point (programmed is nominal, current is compensated) and the arguments to the function are the next programmed point
[16:07:43] <cradek> you can't see the future, so if you need more/future points you need to enqueue them and wait until you have the points you need before you calculate and issue your move
[16:08:12] <cradek> this is what the interp queue does, since it is needed for when the tool is in a concave corner
[16:09:10] <cradek> you can play with and understand how that works if you use comp in mdi
[16:09:35] <cradek> compensate inside of a square and you'll see how the moves are remembered and then compensated motion is issued when it becomes possible
[16:10:41] <stustev> heh - the future looks a little obsure atm. I will look at the inter queue and play in mdi - thanks
[16:12:25] <cradek> the queue is in interp_queue.cc
[16:12:37] <stustev> I was hoping the gcode positions were in an array and I could just read 0, +1 and +2
[16:12:39] <stustev> thanks
[16:12:56] <cradek> the enqueue_STRAIGHT_TRAVERSE type functions are mirrors of the canon calls that add to the queue instead of issuing motion
[16:13:54] <cradek> heh nope, then it would require brain reading for mdi to work
[16:14:29] <cradek> so you have to read ahead and then use 0, -1, -2 instead
[16:14:49] <cradek> pretty much the same idea, actually
[16:15:32] <stustev> except inverse and you know how well I see inverse :)
[16:15:33] <cradek> the non-comp part of the interpreter works with -1, 0 (-1 is the machine's current position, 0 is the line of gcode with the new command)
[16:16:29] <cradek> comp sorta has two types of -1 (machine's programmed nominal position from gcode, and the comped position that was previously calculated, where we actually are now)
[16:17:50] <cradek> with -1p (programmed) and -1n (nominal) and comp side (left/right) you can actually determine the direction vector, and the comp algorithm uses this
[16:18:47] <cradek> theta = atan2(cy - opy, cx - opx);
[16:19:16] <cradek> oops I meant nominal/programmed and actual
[16:19:39] <cradek> in this line c is current/actual, op is programmed
[16:19:58] <cradek> so theta is the direction of the previous move
[16:21:09] <stustev> You said the functions are mirrors - are the mirrors or copies?
[16:21:20] <stustev> the/they
[16:21:31] <cradek> consider STRAIGHT_FEED and enqueue_STRAIGHT_FEED
[16:21:44] <stustev> I will look
[16:21:47] <cradek> the first makes motion, the second saves the motion in the queue for possible modification and then later issue
[16:22:30] <stustev> I understood the point of loading the queue and then writing at a later time otherwise why queue?
[16:22:37] <cradek> later when the queue flushes the enqueue_STRAIGHT_FEED will turn into a STRAIGHT_FEED that's perhaps been modified
[16:22:46] <cradek> yep
[16:22:59] <cradek> so you can maybe modify the moves and then later issue them
[16:23:15] <stustev> that is what I will have to do
[16:23:27] <cradek> yep sounds like
[16:24:33] <cradek> I say with trepidation that you're probably going to have to understand all the existing structure of cutter comp
[16:25:11] <cradek> I think you might find that the modification you want is intricate/clever but a small change on the existing code
[16:51:55] <stustev> you use big scary word - trepidation! Did you see the movie 'The Lion King'?
[16:57:49] <stustev> I think I have a fair understanding of the existing cutter comp. With your explanation it seems pretty clear. I agree it should not be a huge change and doesn't look near as daunting as when I started. It would be a lot simpler if I could do it without the queue but it is what it is.
[17:00:06] <andypugh> Does anyone have a clue what happend to the [code] tags in the forum? They used to give you about 10 lines and a scroll bar, now it just gives you monspaced and a greay background.
[17:00:28] <jepler> probably shit that broke when I installed updates
[17:00:34] <jepler> does somebody else want my fucking job?
[17:01:37] <andypugh> jepler: Your real job or the voluntary job?
[17:02:16] <jepler> this coerced job of maintaining the forum
[17:02:53] <andypugh> Hey, if we just canned the forum, you wouldn’t have the admin headache and I wouldn’t feel that I have to scan every new message at luncthime. We could have our lives back.
[17:03:01] <jepler> the "protostar" template, protostar/css/template.css, which is rewritten / overwritten on updates by joomla, is the place where the bad CSS lives
[17:03:52] <jepler> as far as I know there's no way to edit the CSS and have it stick when you update, because joomla
[17:04:38] <andypugh> I tried to Google for anyone else with the same problem, but basically could not find any search terms that worked.
[17:05:31] <jepler> (on firefox, anyway, the code blocks are wrapped at whatever the width of the code block is, which somebody clearly preferred over having a horizontal scrollbar)
[17:06:53] <andypugh> That’s not good, but I was more concerned with the vertical scrollbars.
[17:07:48] <andypugh> (I liked to put in [code] tags whenever anyone posted a complete from-boot-to-crash dmesg, for example.
[17:08:14] <jepler> oh you are concerned about the vertical size
[17:08:30] <jepler> you want it to be small and force a scroll bar
[17:09:26] <andypugh> It used to work that way.
[17:09:50] <jepler> I see now that's exactly what you said at first
[17:10:15] <jepler> you can use the [spoiler] tag to make the long [code] tag possible to open/close
[17:10:35] <jepler> it's dumb to have to do so I get that
[17:11:05] <andypugh> Yes, I have started using [spoiler] instead of [code].
[17:13:58] <JT-Shop> I run into that with my web stores so I try and avoid upgrading...
[17:14:34] <JT-Shop> I think one needs the keys to the back end to fix things like that, I've not see a way to do it from the front end
[17:15:50] <jepler> unfortunately all software has bugs, and keeping up to date with security fixes of web-exposed software is critically important.
[17:16:00] <jepler> that's how I see it at any rate
[17:16:38] <JT-Shop> yes, I remember the period when we were spammed to death
[17:21:08] <andypugh> Our latest spammer gave herself away. She used a girl’s name at signup. It’s a little sad that my suspicions were instantly raised.
[17:22:03] <JT-Shop> I missed that one
[17:22:08] <andypugh> Hmm, interesting. I don’t think the [table] tags work any more either. But they were very rarely used.
[17:23:16] <JT-Shop> mostly I used the code tags to "fix" long dmesg and stuff like that
[17:27:00] <jepler> OK, I found a plugin that lets you hard code css directly into the html
[17:27:07] <jepler> and I put some junk in there to change how [code] tags look
[17:27:48] <jepler> it's Plugins: System - Easy Includes
[17:29:10] <JT-Shop> I don't see that plugin
[17:30:01] <jepler> extensions > plugins and search for "easy"
[17:30:26] <JT-Shop> ah I was looking in the forum plugins
[17:30:32] <jepler> click the extension name to edit it, then "general settings" tab, then you can write the "css declaration"s you want
[17:30:51] <jepler> it will apply to each and every page in the system (administrator section excepted, I hope)
[17:31:23] <jepler> If someone wants to edit it who is already an administrator, that's fine by me
[17:31:31] <JT-Shop> I see it now
[17:32:23] <JT-Shop> oh crap solidworks just crashed my windows7 again trying to repair faces on an imported part
[17:32:57] <andypugh> jepler: Wahey! It works a treat. Thanks.
https://forum.linuxcnc.org/12-milling/32294-prototrak-plus-retrofit-with-mesa-7i77-5i25-cards?start=10#87599
[17:33:40] <jepler> glad I can please a few of the people occasionally
[17:34:45] <andypugh> jepler: Perhaps a tactical blunder, you just proved you are the only one who understands this stuff :-)
[17:34:56] <JT-Shop> jepler: your a huge help to LinuxCNC
[17:41:13] <JT-Shop> opening that link and looking at the source I see div class="highlight" and <pre xml:> with pre being monospaced fixed-width so good call using pre
[17:49:01] <skunkworks_> again - thank you Jeff! The forum is a great asset - even though it goes against your very being.. :)
[17:49:40] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #167: @robEllenberg, I took your new branch for a little spin (no pun intended). The warning message looks great.... 02
https://github.com/LinuxCNC/linuxcnc/issues/167#issuecomment-278807369
[18:15:53] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15zultron commented on issue #167: Actually, I think the warning "Reducing spindle speed from XXXX to YYYY for synched motion" Rob added is even better than my proposal to raise a warning when the target spindle speed is never reached, since it's enough information for users with fixed-speed spindle to figure out the reason for the hang, and it's more straightforward. Nice work! 02
https://github.com/LinuxCNC/linuxcnc/iss