Back
[07:55:08] <jthornton> DEFAULT_SPINDLE_SPEED was added 2 weeks ago and people are trying to use it already... 2.6.3 time?
[08:22:39] <jepler> list of files that include a 'vcvt' instruction from float to unsigned:
http://pastie.org/9526842
[08:23:29] <jepler> .. they probably all should be reviewed for misbehavior on arm (if the converted value can be negative, the behavior is different than on x86)
[08:32:45] <jepler> .. put another way, if the value is negative the behavior is undefined and probably a future version of gcc on x86 will bite us too
[08:35:05] <cradek> it's disappointing when we don't get warnings when building undefined-behavior code
[08:36:30] <jepler> "(uint32_t)doubleval" is only undefined when doubleval is negative
[08:36:48] <jepler> it's too much to ask for the compiler to guess whether doubleval can be negative in practice
[08:37:38] <jepler> "-fsanitize=undefined" can detect that kind of mistake at runtime, but it's not like we get coverage of our realtime drivers from runtests
[08:38:36] <cradek> oh I see, thanks
[09:33:30] <jepler> man the wiki needs to be reamed
[09:36:45] <seb_kuzminsky> jthornton: yeah, i think you're right
[09:36:53] <seb_kuzminsky> i'll try to do it in the next couple of days
[09:37:13] <cradek> I didn't even see/notice that addition
[09:37:18] <jthornton> thanks seb_kuzminsky
[09:37:20] <cradek> added how to what?
[09:38:10] <cradek> I don't see it
[09:38:17] <jepler> cradek: b38e98c axis -add ability to set default spindle speed
[09:38:37] <seb_kuzminsky> cradek: cmorley added [DISPLAY]DEFAULT_SPINDLE_SPEED, which selects what you get when you hit F9 in axis
[09:38:48] <cradek> oh to AXIS
[09:38:59] <cradek> I see
[09:39:50] <seb_kuzminsky> jepler: wikis are like shared workshops, you usually need a dedicated shop foreman to keep it from decaying into entropic noise
[09:42:29] <jepler> seb_kuzminsky: you mentioned wanting to use a u3 to run a 3d printer .. what board(s) would you use for the heaters and analog temperature feedback?
[09:48:44] <seb_kuzminsky> a friend gave me a RAMPS, so i'd start with that
[09:48:44] <jepler> somebody should make something with a mesa-style pinout, using a micro like an AVR for the analog.
[09:50:54] <jepler> oh the ever-lovable arduino footprint (mega variant)?
[10:01:55] <KGB-linuxcnc> 03Norbert Schechner 052.6 24ace7f 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_plasma/plasma.py 10configs/sim/gmoccapy/gmoccapy_plasma/signals.py 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_5_8 - iteration over None object message * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=24ace7f
[10:01:55] <KGB-linuxcnc> 03Norbert Schechner 052.6 607cbe4 06linuxcnc Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=607cbe4
[10:09:43] <jepler> 5 steppers with pololu-style pinouts (2 switches per stepper + one shared enable) + 3 wires to an AVR (reset / serial rx / serial tx) for the heater controls eactly fits on one mesa 50-pin connector
[10:10:43] <jepler> The AVR has ample pins to do the analog temperature sensing and PWM control of some heaters .. including its reset line means you can program it via bootloader once you port avrdude to be able to talk over a serial device that lives on a mesa card
[10:11:03] <jepler> (serial bootloader)
[10:15:32] <jepler> seb_kuzminsky: do you have a 7i90 yet?
[10:22:38] <KGB-linuxcnc> 03Chris Radek 05master 4123238 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4123238
[10:23:33] <seb_kuzminsky> jepler: i do
[10:37:45] <KGB-linuxcnc> 03Norbert Schechner 052.6 ff02b46 06linuxcnc 10src/emc/usr_intf/gmoccapy/dialogs.py 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_5_9 - corrected message system * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ff02b46
[10:53:01] <pcw_home> STM32F303 >>> AVR
[10:53:56] <pcw_home> much better A/D and UART
[10:54:18] <pcw_home> 4 x 5 Ms/sec
[10:55:07] <pcw_home> 72 MHz ARM with floating point ~$3.26 in 100's
[10:57:59] <seb_kuzminsky> wow
[10:59:36] <pcw_home> If I can write a ssremote for the 7I90 in d8 assy, it cant be that hard to do one in C
[11:12:55] <jepler> pcw_home: no doubt there are more capable mcus. I'd probably still pick AVR due to familiarity
[11:18:36] <pcw_home> Yeah each new embedded processor has it learning curve
[11:18:37] <pcw_home> (the 7I90 remote was easy because I know the processor,
[11:18:39] <pcw_home> and I can fix things I dont like, like the funky 80's UARTs on most micros
[11:19:47] <jepler> I do already have a little board with MK20DX256VLH7 which is a Cortex-M4 also
[11:20:14] <jepler> but from freescale, I guess
[11:25:49] <memfrob> are you guys using -mfpu=vfpv4 -mfloat-abi=hard ?
[11:26:24] <memfrob> i heard something about ARM floating point acting differently.
[11:26:36] <jepler> gcc -v says: ... --with-fpu=vfpv3-d16 --with-float=hard ...
[11:26:50] <memfrob> i wonder if -d16 is the problem.
[11:27:48] <memfrob> you know better not to use neon for math :)
[11:28:06] <jepler> I need some context to understand what we're talking about
[11:28:32] <jepler> what problem are you investigating?
[11:30:03] <jepler> memfrob: ?
[11:31:22] <memfrob> negative doubles
[11:31:29] <CaptHindsight> "converting a negative double to an integer gives 0 on arm, in contrast to the result on x86 where you get an "as though signed" conversion"
[11:32:23] <jepler> well it's simply a bug in linuxcnc that we rely on the conversion from negative FP values to unsigned integer types
[11:33:00] <pcw_home> on the stepgen that should be to a signed 32 bit number
[11:33:37] <memfrob> so its not a bug in gcc floating point / ARM VFP unit?
[11:33:40] <jepler> the result of '(unsigned)-1.0' is undefined in C
[11:33:52] <jepler> but we relied on it accidentally, because of how it happened to behave on x86 CPUs
[11:36:13] <jepler> I was grepping for the use of the specific conversion instruction so that I could review each site which cast from floating point to unsigned
[11:37:09] <memfrob> ah according to the gcc docs, when neon is selected, floating point opperations are not done by GCC's auto vectorization because neon hardware does not conform to the IEEE 754 standard
[11:38:41] <memfrob> i thought it did.
[11:46:26] <jepler> anyway, as for the u3 it looks like it architecturally supports vfpv3 without the -d16 (indicating that there are 32 double precision FP registers). I assume ubuntu configured their armhf compiler with -d16 in order to support more hardware with the same binaries.
[11:47:30] <jepler> in particular, fmuld d31, d31, d31 (aka vmul.f64) does not cause a SIGILL
[11:48:15] <jepler> -d16 won't usually have much performance impact
[11:48:46] <jepler> https://wiki.debian.org/ArmHardFloatPort#Minimum_CPU_.26_FPU
[11:58:29] <memfrob> gcc --verbose should report whether -d16 or not
[12:01:35] <memfrob> (it does for me)'
[12:03:53] <jepler> yes, --with-fpu=vfp3-d16
[13:07:44] <KGB-linuxcnc> 03Norbert Schechner 052.6 64b7d9c 06linuxcnc 10(9 files in 3 dirs) gmoccapy_1_2_0 - hal user message system introduced * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=64b7d9c
[13:31:59] <KGB-linuxcnc> 03Norbert Schechner 05master fb9b2ec 06linuxcnc 10(9 files in 3 dirs) gmoccapy_1_2_0 - gmoccapy_1_2_0 - hal user message system introduced * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fb9b2ec
[13:56:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 006af3f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_7i90.c hm2_7i90: remove some dead code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=006af3f
[13:58:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05sivar2 adf5c4c 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_7i43.c experimental! Add support for Sivar 7m43 board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=adf5c4c
[13:58:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05sivar2 c80527b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_7i90.c experimental! add support for Sivar 7m90 board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c80527b
[13:59:21] <jepler> "HUMPS - HAL User Message Passing System"
[13:59:31] <memfrob> heh!
[14:00:59] <skunkworks> what is a sivar 7m43?
[14:01:13] <seb_kuzminsky> i'm not totally sure
[14:01:23] <skunkworks> google failed me..
[14:01:30] <seb_kuzminsky> i think it's a reimplementation of the mesa 7i43, but with some board changes
[14:01:31] <jepler> I overheard that there is someone else who is working on FPGA cards based on the hostmot2 firmware
[14:01:42] <skunkworks> ah
[14:01:45] <seb_kuzminsky> it's isssy, aka jasen, aka sivar
[14:01:46] <skunkworks> I don't like it.
[14:01:51] <seb_kuzminsky> why now?
[14:01:55] <seb_kuzminsky> *not
[14:02:08] <skunkworks> heh - I feel like I need to defend peter ;)
[14:02:18] <seb_kuzminsky> apparently peter's been helping him out ;-)
[14:02:19] <jepler> peter made the card firmwares Free Software
[14:02:36] <cradek> that's awesome
[14:02:39] <seb_kuzminsky> peter sure is generous with his know-how
[14:02:49] <cradek> aren't we all
[14:02:54] <cradek> it makes all our lives better
[14:02:59] <jepler> but it makes me want more than ever a hostmot2 card with an Open Hardware board design.
[14:03:06] <cradek> (he just has more of it than the rest of us)
[14:03:27] <seb_kuzminsky> heh yeah
[14:31:51] <jepler> seb_kuzminsky: 7i90 at least can read board identification first thing. sivar should use a different identifying string in his idrom so that you don't have to take it as a loadrt parameter
[14:31:59] <jepler> seb_kuzminsky: maybe nothing better can be done for 7i43
[14:32:41] <seb_kuzminsky> agreed, the hm2 boards with stored firmwares should be handled better by the driver
[14:33:10] <seb_kuzminsky> i think sivar uses "7M90" as his board identifier, but i dont know for sure
[14:33:19] <seb_kuzminsky> i think no one but issy has this board
[14:35:53] <seb_kuzminsky> this is the sivar we're talking about:
http://www.sivarbg.com/
[14:35:56] <pcw_home> I think Michael G and I will take a stab at IDROMV4 which will have more information
[14:35:58] <pcw_home> and reduce reliance on using the card name as an index into a table of card specific info
[14:36:06] <seb_kuzminsky> they make screen printing machines maybe?
[14:36:27] <seb_kuzminsky> pcw_home: that reminds me i should get the hm2 buildbot working with your latest code push
[14:36:35] <seb_kuzminsky> so it's ready for the next push....
[14:37:11] <pcw_home> I am just doing a big source update (today)
[14:37:30] <seb_kuzminsky> to the git repo?
[14:38:04] <pcw_home> (resolver fixed for Spartan6, twiddler uses latest CPU, DPLL sampling support for stepgen)
[14:38:58] <pcw_home> just the zip sources file :-(
[14:39:16] <seb_kuzminsky> ah ok
[14:39:28] <pcw_home> 7i92 support
[14:40:42] <seb_kuzminsky> the juxtaposition of an ethernet jack (which i think of as a modern way to connect to an fpga) and the parallel port (which i think of as old-fashioned) is humorous to me
[14:41:18] <pcw_home> It is
[14:42:22] <pcw_home> but look at the brand new drives (like Leadshine MX3660) that use parallel port pinout controller connection
[14:43:18] <seb_kuzminsky> what's the difference between 5i24-16 and -25?
[14:43:34] <pcw_home> FPGA size
[14:43:41] <seb_kuzminsky> aha
[14:44:08] <seb_kuzminsky> those look like really good deals
[14:44:11] <pcw_home> the -25 makes no sense for motion though
[14:44:21] <seb_kuzminsky> is that 2.5 Mgates?
[14:44:41] <pcw_home> 25k cells
[14:44:52] <pcw_home> whatever a cell is
[14:46:40] <pcw_home> I find the the -9 Spartan6 parts (like on 5I25) are about like the old Spartan3 400K so multiply the new size by 40 and its ~= "gates"
[14:48:51] <seb_kuzminsky> wow
[14:48:52] <seb_kuzminsky> big
[14:49:37] <pcw_home> Yeah they keep getting bigger, cheaper and faster
[14:51:06] <seb_kuzminsky> it's cool how the $120 5i24-16 blows the $200 5i20 out of the water
[14:51:14] <pcw_home> only problem with new Xilinx stuff is there are no small chips beyond Spartan6 (smallest Artix is 35K cells)
[14:52:07] <pcw_home> well whole PLXTech bridge chip is gone, and 3X bigger FPGA is cheaper
[14:52:43] <ssi> the artix line is much more expensive to, isn't it?
[14:53:02] <pcw_home> Not really, it just starts big
[14:53:18] <ssi> I know the virtex gets pretty ridiculously priced
[14:53:27] <ssi> I have a bunch of big v5s that I recovered that retail like $2500
[14:53:32] <pcw_home> the 35K part is ~$30 in 256 BGA
[14:53:35] <ssi> that's not bad
[14:54:21] <pcw_home> no and its faster than SP6 and has 2X 1 ms/s 12 bit A-Ds
[14:54:44] <ssi> nice
[14:55:02] <pcw_home> And built in PCIE in some
[15:11:31] <CaptHindsight> pcw_home: any idea how much current the spartan6 on the 7i90 draws during startup and config?
[15:17:52] <pcw_home> Configured power depends mainly on how many nodes are toggling and how fast they are toggling
[15:18:23] <pcw_home> for simple configs nor more than 150 mA or so
[15:18:47] <pcw_home> preconfig is much less
[15:45:32] <jepler> someone stop me before I make a *AMPS board of my own
[16:04:27] <ssi> no, stop
[16:57:54] <jepler> toss a bunch of stuff on a board and start selling it. right?
http://emergent.unpythonic.net/files/sandbox/mumps.png
[17:02:25] <PCW> Hey an interesting trick I want to try is a planar transformer embedded in the PCB for isolated MOSFET drive
[17:03:09] <kwallace2> I looked inside minigl.c and it looks like it mostly converts GL in C to Python. Is that right?
[17:03:44] <jepler> kwallace2: yes. back when I starte writing axis, the "pyopengl" package in ubuntu was unsuitable for some reason
[17:04:14] <jepler> kwallace2: today it would probably be more sensible to use "pyopengl" (debian package name python-opengl)
[17:04:30] <PCW> easy to do in 4 layers 1 = primary spiral in, 2= primary spiral out 3= secondary spiral out 4= secondary spiral in
[17:05:25] <kwallace2> jepler, Yay, I actually figured something out.
[17:05:41] <jepler> kwallace2: it was called "mini" because it only wrapped the parts of the opengl api that axis used
[17:06:44] <jepler> or maybe more interesting than switching to python-opengl would be to switch to opengl es via whatever binding; this would apparently allow accelerated opengl on many of the ARM boards
[17:11:03] <kwallace2> I have been chasing my tail the last few days trying to figure OpenGL out. I figured an update might be in order. Then I could learn a modern version, but it seems such a mess that it might be easier to try to deal with what is currently working.
[17:15:24] <kwallace2> OpenGL ES does sound interesting since LinuxCNC doesn't really need the fancy bits of OpenGL proper.
[17:20:31] <seb_kuzminsky> an open source Pluto clone, by Bdale Garbee:
http://www.gag.com/homeshop/cncfpga/
[17:29:00] <ssi> PCW: interesting
[17:29:46] <jepler> > Unfortunately, in June of 2013, our house fell victim to the Black Forest Fire. The prototypes of this board were lost, along with everything else. I do not know if or when I might ever get back to this...
[17:29:50] <jepler> :( :(
[17:30:24] <ssi> PCW: would you get adequate coupling without a ferrous core?
[17:31:09] <PCW> Yeah good enough for simple isolated MOSFET drive
[17:31:34] <ssi> this is just signal level stuff you want to couple, not power?
[17:31:41] <ssi> like to replace an opto?
[17:38:53] <jepler> linuxcnc, axis, hm2-stepper have been running all day on odroid
[17:39:39] <PCW> what was that 60 ms stuff the other day about
[17:39:39] <jepler> PCW: I'm not sure yet
[17:46:35] <jepler> rx-1 and tx-1 indicate the transaction had both tx and rx buffers, which is expected
[17:47:21] <jepler> rx-f and tx-f indicate that after the transfer should have been complete, the driver data structure said it was still busy
[17:48:06] <jepler> the busy flag is expected to be called by the dma tramsfer completion callback
[17:53:00] <jepler> so it smells like something went bad in the kernel dma subsystem, or a dma interrupt was lost, or something similar
[17:54:01] <Tom_itx> long as it doesn't smell like blue smoke
[17:54:55] <jepler> oh on an unrelated subject, duh, here's how to find the start time of a process by pid: ls -ld /proc/PID
[17:54:59] <PCW> At least with blue smoke you can usually find the culprit with a quick look
[17:55:02] <jepler> the directory's timestamp is the process start time
[17:55:36] <jepler> this also works if you're interested in elapsed time: ps -o etime PID
[18:05:56] <PCW> That's nice, didn't know that
[19:04:27] <skunkworks_> jepler: have you had that happen more than once?
[19:17:12] <CaptHindsight> PCW:
http://www.edn.com/design/components-and-packaging/4363548/A-new-calculation-for-designing-multilayer-planar-spiral-inductors
[19:17:55] <CaptHindsight> http://www.scirp.org/journal/PaperDownload.aspx?paperID=29914
[19:19:48] <CaptHindsight> http://www.nuigalway.ie/power_electronics/documents/md_ieee_trans_power_electronics_2003.pdf
[19:23:03] <PCW> The trick (in my case) is that I can modulate the carrier to lower the average power usage since I will be using
[19:23:05] <PCW> this integrated on a FPGA board
[19:23:06] <PCW> (planar transformers are pretty power hungry so burst modulation for low power loads like MOSFET gates makes sense)
[21:20:18] <seb_kuzminsky> cmorley: are you around? i just pushed the "Launch Keyboard" button in gscreen and i understand what you're talking about now
[21:27:16] <seb_kuzminsky> i didn't know that gscreen (and gmoccapy) Popen onboard
[21:27:39] <seb_kuzminsky> that means we should Depend on onboard.deb, which would have alerted us to this problem as soon as we tried to run on wheezy
[21:41:17] <seb_kuzminsky> cmorley: in wheezy, the following packages look like they provide on-screen keyboards (i haven't tried any of them): caribou, florence, kvkbd, literki, matchbox-keyboard, xvkbd
[22:11:33] <memfrob> gles is more supported now than standard gl by linux now. more of the standard is there, plus egl and glamor use it now too
[22:11:49] <memfrob> its almost the new standard with mesa...
[22:17:32] <memfrob> id love to help with the new GL interface :)
[22:17:50] <memfrob> i did a lot of mesa and Xorg development years ago
[22:18:17] <memfrob> love that stuff!
[23:20:40] <seb_kuzminsky> hhhh333kkkk
[23:21:00] <seb_kuzminsky> oh, that's where the kvkbd key-presses went
[23:26:10] <seb_kuzminsky> i think i like matchbox-keyboard best of the ones i tried
