Back
[06:42:29] <jepler> src/po/git-merge-po is the file that's supposed to somehow help with merging po files. it has some instructions at the top.
[06:43:59] <jepler> I realized after going to bed that there might be messages on the monitor, if it was hooked up and turned on
[06:44:03] <jepler> so I looked, and there are.
[06:44:34] <jepler> "an error occurred while mounting /boot"
[06:44:47] <jepler> "press S to skip mounting or M for manual recovery"
[06:45:37] <jepler> and, two lines later, maybe the real error: systemd-udevd: could not open moddep file '/lib/modules/.../modules.dep.bin'
[06:48:20] <jepler> it seems that my kernel doesn't agree with itself about whether it's "3.8.13.26-rt-rt31" or "3.8.13-rt-rt31"
[06:49:59] <jepler> well, way too much to hope the kernel would boot the first time
[07:35:01] <jepler> Linux odroid 3.8.13.26-rt31 #5 SMP PREEMPT RT Tue Aug 5 06:38:40 CDT 2014 armv7l armv7l armv7l GNU/Linux
[07:35:51] <skunkworks> ooh
[07:36:19] <skunkworks> what was happening las night?
[07:36:43] <jepler> however, latency's terrible
[07:36:53] <jepler> skunkworks: a series of things were wrong, which I could troubleshoot better once I could see the console
[07:37:02] <skunkworks> ah
[07:37:40] <jepler> oh after I "sudo make setuid", latency's much better
[07:38:52] <jepler> http://emergent.unpythonic.net/files/sandbox/latency-odroid.png
[07:39:09] <jepler> by no means am I "taxing" it, but it's running X and playing mp3s
[07:39:21] <skunkworks> very neat!
[07:39:31] <skunkworks> now spi? :)
[07:39:31] <jepler> note: the bins are 10x bigger than the usual latency-histogram
[07:40:47] <jepler> maybe
[07:41:13] <skunkworks> that latency seems quit good for rt preempt
[07:41:49] <jepler> now time to go to $DAY_JOB
[07:42:16] <jepler> graph stays OK while stressing filesystem..
[07:42:36] <jepler> and while pingflooding
[07:43:35] <jepler> and while running glmark2-es2
[07:44:25] <jepler> latency image updated with 359 seconds runtime
[07:44:34] <jepler> anyway, really leaving this time
[08:05:45] <jepler> darnit, the serial console cable is *not* at my office either
[08:27:25] <jepler> ooh crw------- 1 root root 153, 0 Aug 5 08:00 /dev/spidev1.0
[09:13:12] <cradek> rick is using remap now for his lathes, instead of a patch. that's great.
[09:13:31] <cradek> I don't get the 10000 thing, but whatevs
[09:21:08] <seb_kuzminsky> rick could easily write a custom tooltable-ui to put T>10,000 on a different tab
[09:21:56] <cradek> he only wants one offset per tool, like normal, but for some reason it should be 10000+toolno?
[09:22:18] * seb_kuzminsky shrugs
[09:22:21] <cradek> yep
[09:22:23] <seb_kuzminsky> 2.6.1 is on wlo
[09:22:26] <cradek> but, yay remap
[09:22:28] <cradek> cool!
[09:22:29] <seb_kuzminsky> yeah
[09:22:36] <seb_kuzminsky> see ya!
[09:23:37] <cradek> Get:1
http://linuxcnc.org/ wheezy/2.6 linuxcnc-dev i386 1:2.6.1 [589 kB]
[09:23:38] <cradek> whee
[09:23:57] <cradek> did you send out an announcement?
[09:25:07] <cradek> yep
[09:27:07] <jepler> $ ./a.out
[09:27:07] <jepler> > 55aa f00f
[09:27:07] <jepler> < ffff ffff
[09:27:30] <jepler> cool, writing a basic SPI userspace program is easy
[09:27:44] <jepler> with no device, it always reads "1"s due to a pull-up -- I'm assuming :-)
[09:27:49] <cradek> neat
[09:27:54] <cradek> your kernel works now?
[09:28:03] <jepler> yes.
http://emergent.unpythonic.net/files/sandbox/latency-odroid.png
[09:30:12] <cradek> neat
[09:30:36] <jepler> hm, it says 1_core but that's not right
[09:33:08] <jepler> apparently arm /proc/cpuinfo is different enough that latency_test doesn't quite grok it
[09:34:49] <KGB-linuxcnc> 03Dewey Garrett 052.6 f0c9384 06linuxcnc 10configs/apps/latency/README 03configs/apps/latency/latency-histogram-1.demo latency-histogram-1: single thread app * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f0c9384
[10:02:31] <jepler> CaptHindsight: I worked out my booting problems.
http://emergent.unpythonic.net/files/sandbox/latency-odroid.png
[10:06:15] <CaptHindsight> nice
[10:11:34] <jepler> yeah I'm amazed to be honest
[10:11:50] <cradek> [I uploaded a new debian image based on 2.6.1, so stepconf works out of the box]
[10:12:10] <jepler> cradek: yay, thanks
[10:14:14] <CaptHindsight> jepler: best ARM so far, have you tried playing a Flash video in Firefox yet? Staring Firefox and playing a youtube has had the most dramatic effect on delay
[10:15:40] <jepler> CaptHindsight: no. why would I install flash?
[10:16:04] <CaptHindsight> even starting firefox
[10:17:03] <jepler> CaptHindsight: it's not a system without problems. I wrote about some of them here:
http://emergent.unpythonic.net/odroid-u3
[10:20:08] <CaptHindsight> so it's just like the other ARM distro projects, everyone races to be first and say they have a working distro but half of it is broken
[10:20:13] <jepler> yup
[10:21:56] <jepler> but especially if I can make my 7i43 run in spi mode it is looking like a nice headless/embedded system to develop linuxcnc on
[10:40:30] <jepler> 4096 bytes over SPI at 25MHz should take about .0013s. strace shows about .0016 from ioctl to ioctl, so that's pretty good (not running with RT privs)
[10:40:49] <jepler> .0015 in ioctl
[10:47:27] <CaptHindsight> http://www.andahammer.com/t1-nanopc/
[10:49:50] <jepler> > Ludicrously long list of features goes here! (Here is the beginning).
[10:50:44] <jepler> > Source Code in GitHub repositories - to be made public soon.
[10:53:20] <jepler> ah, maybe this tree I have is based on ubuntu's 3.8.y.z extended stable.
https://lkml.org/lkml/2014/7/1/694
[10:53:43] <jepler> I didn't try adding that one as an upstream before now
[10:57:45] <CaptHindsight> SPI on the 4412 prime is 50 MHz max
[10:58:27] <jepler> yup
[10:59:20] <jepler> a level translator is required, and the one I picked is good to ~30MHz according to the datasheet, so I figured I'd start trying at 25MHz
[10:59:57] <CaptHindsight> no SATA :(
[11:00:05] <jepler> no, and the ethernet is USB
[11:00:09] <jepler> and not gb
[11:00:28] <jepler> but the emmc is removable and fast
[11:00:50] <CaptHindsight> and mini PCIe on some boards looks like it is just power and USB
[11:00:57] <jepler> the headers are inconveient (for home prototyping) 2mm pitch, hidden on the bottom, and blocked by the standard case
[11:01:32] <CaptHindsight> there is a Tiny 4412 COM board that's available in China
[11:01:41] <CaptHindsight> ~$60
[11:02:29] <CaptHindsight> http://www.arm9.net/Super4412/super4412-01.jpg
[11:02:50] <jepler> ugh, no mounting provision?
[11:03:27] <CaptHindsight> friction fit 2mm headers
[11:05:10] <CaptHindsight> I'm finding more but I have to translate
[11:05:25] <jepler> that's OK
[11:05:35] <jepler> I don't need to be board shopping now, I have one that's perfectly adequate
[11:07:51] <CaptHindsight> they have them with smt low profile board to board connectors
[11:08:28] <CaptHindsight> and you could have a large hard drive on USB
[11:23:49] <CaptHindsight> http://img03.taobaocdn.com/imgextra/i3/298010950/TB2hZfoXVXXXXbVXXXXXXXXXXXX_!!298010950.jpg
[11:25:42] <ssi> jepler: which odroid are you working with?
[11:25:54] <jepler> ssi: U3
[11:26:06] <ssi> cool
[11:26:19] <seb_kuzminsky> the u3 is the bees' knees
[11:26:33] <jepler> it's not perfect
[11:26:44] <CaptHindsight> also as a giant SO leaded module
http://img02.taobaocdn.com/imgextra/i2/153580992/TB223b_XVXXXXaUXpXXXXXXXXXX-153580992.jpg
[11:27:00] <jepler> CaptHindsight: that last one's just crazy
[11:27:27] <CaptHindsight> yup
[12:02:41] <jepler> after a couple hours, I have some latencies out at about 65us
[12:02:48] <jepler> still not particularly stressing the machine
[12:07:39] <memleak> try firefox + youtube ;)
[12:07:48] <CaptHindsight> keeping the cores at 100% on ARM tends to keep the latency the lowest
[12:08:23] <pcw_home> idle hands are the devil's workshop
[12:08:26] <CaptHindsight> 100% busy and at the highest core speed
[12:08:48] <memleak> (all late night with jimmy fallon youtube clips work with HTML5 / no flash)
[12:11:34] <KGB-linuxcnc> 03Jeff Epler 05master 3beb85d 06linuxcnc 10scripts/latency-histogram latency-histogram: Use getconf for ncpus * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3beb85d
[12:15:06] <jepler> hum, why would cpuinfo_max_freq and scaling_max_freq be different?
[12:15:16] <jepler> cpuinfo_cur_freq:1704000
[12:15:16] <jepler> cpuinfo_max_freq:2000000
[12:15:18] <jepler> scaling_max_freq:1704000
[12:16:01] <jepler> anyway, it looks like my rt kernel configuration selected "performance" as the only scaling governor, so the CPUs are stuck at top speed
[12:16:40] <memleak> scaling comes from kernel cpuinfo comes from.. firmware?
[12:16:48] <memleak> u-boot possibly?
[12:18:49] <CaptHindsight> Answers: (A) Confused developer. (B) Poor Docs. (C) Unknown. (D) Both A and B. (E) Just works
[12:19:27] <jepler> the odroid-u3 is specced as 1.7GHz
[12:20:02] <CaptHindsight> maybe it overclocks to 2GHz
[12:21:15] <CaptHindsight> http://forum.odroid.com/viewtopic.php?f=15&t=764&p=3338
[12:23:43] <jepler> yeah, seems to
[12:24:34] <jepler> .. but now it's crashed
[12:24:46] <jepler> I hope it's not catching on fire, I'm at work and it's at home :-/
[12:26:38] <ssi> hah
[12:34:19] <CaptHindsight> cubie2 (A20) latency was ~80uS running both cores
[14:05:25] <jepler> CaptHindsight: so your experience is that running 100% loaded CPUs helps above and beyond ensuring governor is performance? Were you using a tree that did /dev/cpu_dma_latency hardening?
[14:06:00] <jepler> (linuxcnc master branch will do the latter, but it doesn't touch performance governor)
[14:51:34] <CaptHindsight> jepler: some ARM devices have very aggressive power management and even with the core supposedly set at some frequency would still sleep / throttle down the core speed
[14:52:11] <CaptHindsight> why it would still do that remains a mystery, it could be broken governor settings or something else
[14:54:03] <CaptHindsight> it's difficult to track down when using poor docs, no access to the engineers that would have his register specs in his notebook or uncommented supposedly working source
[14:56:56] <jepler> indeed
[14:58:06] <jepler> sometimes I see the attraction of writing your whole motion control stack for an 8-bit microcontroller: you can still cycle count over there
[14:58:45] <jepler> but 98% of the time I think the reprap people are nuts to try to do that much on something only a few times more powerful than my first home computer
[14:59:30] <CaptHindsight> my guess is that even misconfigured governor and power management keeping the cores close to 100% keeps them from throttling down to save power and mucking up the latency as a result
[15:03:24] <mozmck> jepler: sounds better though if you say they are many times more powerful than the computers used to put man on the moon:
http://www.computerweekly.com/feature/Apollo-11-The-computers-that-put-man-on-the-moon
[15:16:14] <CaptHindsight> I mostly use servos and perform image processing so the 8b micros are out for me
[15:55:38] <ssi> it might be feasible to do a softcore in an fpga and offload our entire motion stack to a mesa card :)
[15:56:38] <CaptHindsight> but aren't FPGA boards expensive and confusing?
[15:59:13] <ssi> yes, exactly :)
[15:59:47] <jepler> ssi: peter already puts a fine softcore in many of his firmwares. It's called "dumbass8" and I'm sure it would be a super fun project to port gcc to it
[16:00:52] <jepler> actually .. in all seriousness .. someone heroic needs to write a linux assembler for it (he uses a windows table-driven assembler for it), so that the hostmot2-firmware project can build that part of the software instead of using pre-built hex files
[16:01:00] <ssi> I'm sure there are cycle-accurate arm softcores that already have toolchains for them which would make quite nice motion microcontrollers
[16:01:40] <ssi> arm7tdmi is a nice architecture to work with
[16:07:38] <jepler> wow this board (odroid-xu3) appears to have 12 little surface mount inductors by what I assume is the voltage regulator / PMIC .. all connected by fat traces, too
[16:07:47] <jepler> http://dn.odroid.com/homebackup/201407071202252748.jpg
[16:09:01] <ssi> yeah, looks like a multi-output multi-phase PMIC or something similar
[16:09:13] <PCW> It would be nice to have a linux assembler for D8, if just for the twiddler module (generic smart I/O peripheral, so possibly user generated code)
[16:10:10] <jepler> > MAX77802 is a PMIC that contains 10 high efficiency Buck regulators, 32 Low-dropout (LDO) regulators [...]
[16:10:13] <jepler> (no public datasheet)
[16:10:41] <PCW> 32 LDOs !!!
[16:11:21] <jepler> not sure if it's the same one, the board that's on has 14 inductors
http://dn.odroid.com/homebackup/201307292018402641.jpg
[16:11:45] <PCW> must be a cell phone/tablet thing that can power down each output selectively
[16:11:46] <jepler> I suppose you might as well have an LDO for every subsystem you might want to turn on or off
[16:12:01] <jepler> might that design also reduce transients on the other outputs when switching on/off?
[16:12:24] <PCW> yeah staged startup
[16:14:01] <PCW> (the Ethernet code uses a 16 bit variant of D8 and the resolver code uses a 32 bit variant)
[16:14:11] <ssi> D16, D32? :)
[16:14:27] <PCW> ba32
[16:15:31] <jepler> bad-?
[16:15:44] <PCW> big
[16:15:54] <PCW> (too many cells)
[16:21:23] <PCW> Most of the peripheral processors (sserial, resolver, twiddler) allow downloading the processor's
[16:21:25] <PCW> ROM from the host so you can try new code without re-compiling the FPGA
[16:22:41] <jepler> you'd think there would be a good table-driven assembler for linux
[16:23:22] <PCW> the one we use will run on linux but its shareware
[16:23:32] <jepler> it does?
[16:23:39] <PCW> yes
[16:24:02] <jepler> I should look into this again
[16:24:17] <jepler> it seems like two years ago you sent me a link to a windows program that I tried but failed to get to run in wine
[16:25:18] <jepler> can you give me the information again? I'd love to give this another try.
[16:25:46] <PCW> theres a native linuxcnc version (I think some code needs to be run through a macro processor not sure which particular on it is)
[16:27:24] <PCW> http://home.comcast.net/~tasm/
[16:29:38] <jepler> OK, so I'd need an eRegistration which gets me access to the source code, and that builds on Linux?
[16:31:23] <PCW> yeah we just bought it of course
[16:31:55] <jepler> small change
[16:32:24] <Tom_itx> what are the 'attic' configs in the startup screen?
[16:32:48] <jepler> it's a higher barrier to someone who wants to build hostmot2-firmware than "download some free (but proprietary) software"
[16:33:25] <jepler> Tom_itx: did you read the text which is shown when you click on the "attic" entry itself in the configuration selector?
[16:33:41] <cradek> holy smokes, is this the same tasm I was using 20 years ago?
[16:33:53] <jepler> cradek: if so, it's just $10 to upgrade!
[16:34:08] <PCW> No its not Borland tasm
[16:34:20] <cradek> no mine wasn't borland, it was some shareware thing
[16:36:02] <cradek> Speech Technology Incorporated 837 Front Street South, Issaquah, WA 98027 August, 1990 Version 2.8
[16:36:14] <cradek> yep, same address, different name
[16:36:23] <cradek> but it was 24 years, not 20
[16:36:28] <PCW> I was able to write a single stepper/disassembler in a few hours because the instruction set is so simple
[16:36:29] <PCW> wonder if there a good open source simple assembler skeleton available
[16:36:31] <Tom_itx> jepler, thanks. i just opened the tab and never clicked on the item
[16:37:20] <cradek> (yes I knew right where it was)
[16:37:37] <PCW> hmm
http://www.penguin.cz/~niki/tdasm/
[16:38:28] <jepler> PCW: yeah, I can't tell if it does anything useful
[16:38:47] <jepler> it's certainly unlikely to read your tasm sources unmodified
[16:39:35] <PCW> yeah there's a fair overhead just to figure out how close it might be
[16:41:03] <jepler> it must not be a very long program to blink an LED, in terms of # of distinct instructions and encodings
[16:41:27] <jepler> a first step .. then you'd need to make sure it supports all the different encodings; I don't know how many encodings you have.
[16:41:30] <jepler> surely not many
[16:42:28] <PCW> fastblink
[16:42:30] <PCW> ldab ff
[16:42:31] <PCW> stab led
[16:42:33] <PCW> ldab 00
[16:42:35] <PCW> stab led
[16:42:36] <PCW> jmp fastblink
[16:43:33] <jepler> that software's not remotely close to building on modern g++
[16:45:17] <PCW> not terribly surprising
[16:46:50] <PCW> there's only one currently used encoding for each processor (with the exception of hm2_usb which I really dont want to muck about with)
[16:52:03] <jepler> well .. I repeatedly hit tdasm until it compiled
[16:53:59] <jepler> also, "stab led" is funny
[16:54:33] <jepler> led stands for a memory or I/O location?
[16:56:10] <PCW> yes
[16:56:33] <PCW> maybe ledloc would be better
[16:56:34] <jepler> is "b" a byte suffix?
[16:56:40] <PCW> yes
[16:57:10] <jepler> how do you tell the difference between lda which reads memory and lda which reads a constant?
[16:57:26] <jepler> or maybe you just make memory location 00 have value 00 and memory location ff have ff
[16:57:51] <PCW> sorry
[16:57:53] <PCW> ldib 00
[16:57:55] <PCW> stab ledloc
[16:57:56] <PCW> ...
[16:58:16] <PCW> or
[16:58:18] <PCW> ldab zeroloc
[16:58:19] <PCW> stab ledloc
[17:02:59] <jepler> so for ldi, opcode is "opr" (hex "0") and opcode2 is "ldi" (hex "1")? If the immediate value is ff, then is that the two bytes 01 ff ?
[17:04:32] <PCW> yes (well all d8 instructions are 16 bits)
[17:04:43] <jepler> but if I'm viewing it as a stream of bytes
[17:04:51] <PCW> sure
[17:05:46] <jepler> and stab is 0xbXYZ where XYZ is ledloc?
[17:05:57] <PCW> yep
[17:06:36] <PCW> not terribly complicated :-)
[17:07:01] <jepler> hmm did this guy get around to implementing labels?
[17:07:33] <PCW> pretty painful without lables
[17:07:48] <PCW> or labels even
[17:12:47] <jepler> Error 7: syntax error
[17:15:01] <PCW> seems like there would be a better starting point that had all the assembler basics
[17:15:14] <jepler> it's not gnu as, I can tell you that
[17:15:45] <PCW> Yeah
[17:15:55] <jepler> I don't think it's this software either
[17:16:44] <jepler> well, I decided to spend $25 on a copy of TASM and intend to see whether I can integrate it into the hostmot build
[17:17:11] <jepler> building the embedded program ROMs in our build process is still better than not building them
[17:17:57] <seb_kuzminsky> nasm? yasm?
[17:18:10] <PCW> there ares still some missing bits (our makeinc and makerom utils)
[17:19:10] <jepler> turning an object file into a vhdl array seems like a much more tractable problem
[17:19:21] <jepler> not sure if that's what those tools you name are concerned with
[17:21:29] <PCW> yes ROM text i trivial, makeinc just makes our include files generic
[17:22:09] <PCW> (so the same source can make C, Pascal, Assy constants)
[17:22:45] <PCW> for assy only what it does is trivial
[17:25:10] <jepler> ah
[17:26:24] <PCW> makerom also checks for some processor code sequence violations
[17:27:21] <PCW> (the assembled should do this but not smart enough to)
[17:27:30] <PCW> assembler
[17:28:32] <jepler> that would be a bit more work
[17:29:27] <jepler> I finally got tdasm to assemble something
[17:30:24] <jepler> $ cat d8.tst | tr '\n' ';'; echo
[17:30:24] <jepler> ldib 00; stab abc; ldib ff; stab abc; jmp 000;
[17:30:24] <jepler> $ ./tdasm/tdasm tables/d8.tbl d8.tst
[17:30:24] <jepler> $ od -tx2 d8.tst.out
[17:30:24] <jepler> 0000000 0100 babc 01ff babc 1000
[17:31:08] <jepler> PCW or seb: which version of webpack do I need these days?
[17:31:27] <jepler> the card I particularly care about targeting is my 7i43-400
[17:32:18] <PCW> 9.2 for 5I20,4I65 >13.0 for everything else (I haven't moved to avocado yet)
[17:33:36] <jepler> yeah, absolutely no sign that labels even started to be implemented in tdasm
[17:34:17] <PCW> so you get to guess jmp target addresses? thats nice
[17:34:54] <jepler> PCW: seems like
[17:35:19] <PCW> not sure thats a whole lot better than hex
[17:35:27] <jepler> not at all
[17:35:37] <seb_kuzminsky> jepler: in hostmot2-firmware.git, build.py has a dict named card2ise that has the card to ... uh, ise mapping
[17:35:59] <seb_kuzminsky> the buildbot currently uses 10.1 and 13.3
[17:36:11] <seb_kuzminsky> 13.3 for 7i43
[17:36:27] <jepler> seb_kuzminsky: ok
[17:37:25] <seb_kuzminsky> those versions were the latest, at the time i set up that machine, which was years ago
[17:37:36] <seb_kuzminsky> drwxr-xr-x 3 root root 4.0K 2011-12-22 18:42 13.3/
[17:37:43] <jepler> PCW: is 10.1 OK for 5i20,4i65?
[17:38:20] <PCW> If it ever worked its OK (I still use 9.2)
[17:38:47] <PCW> (and 13.1 for everything else)
[17:38:48] <jepler> there are sure people who use 5i20s
[17:38:51] <jepler> cradek is one
[17:39:06] <jepler> heck, I'm one
[17:39:26] <jepler> it was the first board I tested with uspace, and had a panic about the identity eeprom that had lost its programming
[17:40:34] <PCW> Yeah many 5I20's out there (thousands and many for linuxcnc)
[17:40:47] <seb_kuzminsky> that's awesome
[17:41:32] <PCW> people still buy them
[17:47:04] <seb_kuzminsky> i used one until i ran out of io and switched to a 5i22
[17:54:09] <PCW> You can use a 7i90 for more I/O now
[17:58:02] <seb_kuzminsky> 7i90 and 5i20 both have 72, no? did i miss something?
[18:03:50] <PCW> 7I90 can be a sserial remote
[18:05:23] <seb_kuzminsky> i'm running a custom firmware you made for me that doesn't have sserial
[18:05:51] <seb_kuzminsky> yet another reason to get the new hm2 firmwares building right...
[18:17:08] <Tom_itx> i think i loaded the last one they published which was 14.7
[18:17:18] <Tom_itx> for the newer boards
[18:17:54] <kwallace> Just in case anyone is interested:
http://frankieflood.blogspot.com/search?updated-max=2014-08-03T13:15:00-05:00
[18:25:25] <seb_kuzminsky> kwallace: neat
[18:50:06] <kwallace> seb_kuzminsky: It's a little strange that the guys comment's were so favorable. I have a long list of things I know are not so good that I would like to fix, but I suspect they are things that only I would notice.
[18:54:40] <PCW> Lathe stuff?
[18:57:03] <kwallace> The lathe function seems pretty solid, but things like the corners on various buttons are different size or text is different size.
[18:58:37] <ssi> kwallace: you have one of their lathes?
[18:58:45] <PCW> Ahh the GUI. still looks like they spent a lot of time on it
[18:59:11] <ssi> is it linuxcnc with a proprietary UI?
[18:59:21] <ssi> the backplot looks like axis
[19:00:03] <kwallace> No lathe, but I have the smaller 770 mill on loan.
[19:00:36] <kwallace> I've been a small cog on the UI for over a year now.
[19:00:48] <ssi> ahh I see
[19:01:12] <ssi> as an employee, or a volunteer, or what?
[19:01:22] <kwallace> Yes, the backplot is Gremlin with some of our tweaks.
[19:01:43] <ssi> hm you may or may not have some insight into one of my issues
[19:01:43] <kwallace> I'm on contract.
[19:02:12] <ssi> i have two gantry machines that are running joints_axes with two joints for the Y axis
[19:02:18] <ssi> and both of them have a backplot problem
[19:02:28] <ssi> they seem to scale projected and actual toolpaths at 2x height
[19:02:34] <ssi> like it's summing both joints' motion or something
[19:02:46] <ssi> I have no clue where to start looking in the code to find the problem
[19:05:19] <ssi> here's an example:
[19:05:19] <ssi> http://www.prototechnical.com/~imcmahon/backplot_problem.png
[19:05:26] <ssi> that's an array of 3/4" circles
[19:05:33] <kwallace> I've gotten into Gremlin far enough to try an fix particular issues. It and OpenGL are not easy to deal with.
[19:05:43] <ssi> and they all fit within the machine envelope, which is correctly represented by the dotted red rectangle
[19:05:52] <ssi> and the pink lines correctly estimate the overall job travel
[19:05:57] <ssi> it's bizarre
[19:06:05] <ssi> I imagine the probelm probably isn't within gremlin
[19:06:10] <ssi> it's probably whatever's feeding it
[19:08:02] <kwallace> I'll take a look at Gremlin with respect to your problem and let you know what I come up with. I usually surprise myself when I make any headway with OpenGL.
[19:08:54] <skunkworks_> kwallace: I got to see your wizards in madison - very nice work
[19:09:28] <ssi> are the conversational pieces using ngcgui?
[19:09:32] <ssi> or something more ccustom
[19:09:52] <skunkworks_> jepler: did you smoke it?
[19:12:41] <jepler> skunkworks_: haven't gone home yet
[19:14:59] <kwallace> ssi: it's more custom. It's more like GladeVCP, with using Glade and Python, but without the GladeVCP bridge. GladeVCP does a bit of work in the background to glue Glade, Python and LinuxCNC together. The people I work with have figured the glue part out in order to get the look and feel they want.
[19:17:09] <ssi> it looks like they have roughing and finishing cycles
[19:17:16] <ssi> that's one thing I want very very badly in linuxcnc
[19:18:53] <jepler> PCW: it's not table-driven, but I have the start of a d8 assembler in Python.
http://emergent.unpythonic.net/files/sandbox/ada8.py some things that it does:
http://pastebin.com/Acg7qkii
[19:19:34] <jepler> I think I don't know how indirection / offsetting works
[19:20:05] <PCW> wow thats impressive (and it has labels!)
[19:21:33] <PCW> Yeah
[19:21:35] <PCW> addtocb @y,17
[19:22:12] <jepler> how's that encoded? I see add is major opcode C ..
[19:22:49] <PCW> did you look at tasmd8s.tab
[19:23:02] <jepler> no, I'm trying to read d8o8.vhd!
[19:23:32] <PCW> thats the hard way!
[19:23:47] <kwallace> ssi: the roughing and finishing is a product of generating a g-code file and not done with canned g-code commands which would might be considered part of LinuxCNC.
[19:24:43] <jepler> PCW: where would I get this file tasmd8s.tab ?
[19:24:48] <PCW> d8o8sqws is the latest (d808 is obsolete)
[19:26:20] <PCW> its buried in the hostmot2 source distribution, let me dig it out
[19:26:21] <PCW>
[19:27:11] <PCW> freeby.mesanet.com:TASMD8SS.TAB
[19:27:28] <jepler> ta
[19:30:18] <ssi> kwallace: makes sense
[19:30:26] <ssi> I should probably just sit down and write something similar
[19:30:40] <ssi> kwallace: what does it take as input? a gcode path, the way G70-type cycles do?
[19:30:59] <jepler> hm, I didn't lay a very good foundation for syntax like @y,17
[19:45:30] <kwallace> ssi: We do use the G76 canned cycle for threading but generally I consider how I would want to do a basic type of machining operation, work out what parameters are needed, create entry boxes in Glade to enter these parameters, then write a Python script or .ngc file that couples the parameters to basic g-code commands and puts them in order.
[19:45:44] <kwallace> oops, dinner time.
[20:00:56] <kwallace> ssi: There are some Gremlin notes here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Gremlin
[21:03:58] <jepler> skunkworks_: the odroid was fine after a reboot
[21:11:52] <ssi> kwallace: thanks, I'll poke around
[21:17:15] <skunkworks_> jepler: nice! so - it just couldn't handle the higher clock?
[21:18:40] <cradek> ssi: I suspect that's a consequence of the DISPLAY[GEOMETRY] setting
[21:18:50] <cradek> err I mean [DISPLAY]GEOMETRY
[21:19:37] <cradek> ugh, which is not documented in
http://linuxcnc.org/docs/html/gui/axis.html
[21:19:41] <cradek> weird
[21:19:43] <cradek> I was sure it was
[21:19:53] <skunkworks_> so was I...
[21:20:30] <cradek> oh it's in
http://linuxcnc.org/docs/html/config/ini_config.html
[21:21:19] <cradek> > Geometry has no effect without a rotary axis.
[21:21:27] <cradek> it doesn't seem like that would be true
[21:21:56] <cradek> axis_foam has GEOMETRY = XY;UV which is not a thing that's documented
[21:27:13] <jepler> skunkworks_: I guess -- it's sold as a 1.7GHz device, so no wonder if running it at 2.0GHz doesn't work right
[21:28:10] <skunkworks_> heh - I had the same problem with the nook color.. you could overclock it to 1ghz - but mine seemed to run the best at the 800mhz spec
[21:29:24] <jepler> I dunno that you can really call it a "problem"
[21:29:40] <skunkworks_> right
[21:32:18] <ssi> cradek: any idea how that works with machines with multiple joints in an axis?
[21:32:35] <ssi> I'm guessing I'll need either XY or XYY
[21:32:38] <jepler> [DISPLAY]GEOMETRY takes no account of joints, it is based purely on axes
[21:32:42] <ssi> ok
[21:32:47] <ssi> I'll give it a shot
[21:33:09] <jepler> If GEOMETRY=XYY is accepted, it might show twice the Y displacement
[21:33:29] <ssi> if it defaults to the kins geometry string, that might explain my problem
[21:34:24] <jepler> a quick glance at the source suggests axis is only looking at [DISPLAY]GEOMETRY
[21:34:55] <cradek> gantry.ini:GEOMETRY = XYYZ
[21:34:55] <ssi> laser machine is shut down right now, but teh plasma machine has GEOMETRY = XYYZ
[21:35:01] <ssi> so yeah that's probably the issue
[21:35:02] <cradek> it's in our sample config
[21:35:23] <cradek> jepler: does it do something with ; ?
[21:35:40] <ssi> I'm pretty sure that fixed it :)
[21:35:42] <jepler> cradek: yes
[21:36:53] <jepler> cradek: though I don't immediately find where
[21:38:09] <ssi> that might be the last of my little bugs with the gantry machines!
[21:38:21] <jepler> oh I have been looking at 2.5
[21:38:52] <ssi> if i were a motivated, helpful individual, I would write up some sort of document explaining my findings on running dual-homing gantry machines with ja
[21:41:47] <jepler> # apt-get remove cups
[21:41:48] <jepler> ...
[21:41:51] <jepler> The following extra packages will be installed:
[21:41:51] <jepler> hplip-data libhpmud0 libsane-hpaio
[21:41:52] <jepler> whaaaa
[21:42:18] <jepler> 3 upgraded, 0 newly installed, 9 to remove and 161 not upgraded.
[21:42:34] <ssi> D:
[21:42:38] <jepler> I don't think apt is quite telling me the truth here
[22:17:36] <jepler> emc/rs274ngc/interp_convert.cc:2642:19: warning: size argument in 'strncat' call
[22:17:40] <jepler> appears to be size of the source [-Wstrncat-size]
[22:17:41] <jepler> clang always has such interesting warnings
[22:17:43] <jepler> strncat(cmd,buf,sizeof(buf));
[22:17:46] <jepler> ^~~~~~~~~~~
[22:18:06] <jepler> emc/task/taskclass.hh:45:9: warning: private field 'fms' is not used
[22:18:07] <jepler> [-Wunused-private-field]
[22:18:07] <jepler> int fms[CANON_POCKETS_MAX];
[22:18:07] <jepler> ^
[22:26:19] <jepler> clang 3.5 is about the same speed as gcc 4.6 on this arm
[22:26:33] <jepler> from time to time I read about how clang is faster than gcc, but I've never personally experienced it
[22:27:25] <jepler> hal/utils/halrmt.c:2838:13: warning: expression which evaluates to zero treated as a null pointer constant of type 'char *' [-Wnon-literal-null-conversion]
[22:27:28] <jepler> args[i] = '\0';
[22:27:30] <jepler> ^~~~
[22:28:27] <cradek> ooh that's an interesting one
[22:28:34] <KGB-linuxcnc> 03Chris Radek 052.6 b03d2f5 06linuxcnc 10configs/sim/axis/gantry.ini This made the backplot scale wonkily * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b03d2f5
[22:28:57] <cradek> iirc, coverity says halrmt is bad in lots of ways
[22:29:09] <jepler> clang scan-build has a litany of complaints too
[22:29:22] <jepler> (as opposed to 'regular' clang)
[22:40:50] <mozmck> I've read a couple of articles indicating that the latest gcc is sometimes faster and generates faster code than clang.
[22:42:20] <jepler> I have found that gcc 4.6 is faster than 4.7, both on linuxcnc and $DAY_JOB
[22:42:28] <jepler> in neither case have I found clang faster than gcc 4.6.
[22:42:35] <mozmck> interesting
[22:42:44] <jepler> execution speed is not as important to me
[22:42:58] <jepler> bedtime here
