#linuxcnc-devel | Logs for 2015-12-29

Back
[01:08:29] <KGB-linuxcnc> 03chris morley 05panelui b9aebd8 06linuxcnc 10src/emc/usr_intf/pyui/widgets.py panelui -supress debug text for widget initialization * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b9aebd8
[01:08:30] <KGB-linuxcnc> 03chris morley 05panelui ab9b98e 06linuxcnc 03configs/sim/axis/panelui-demo/README panelui: add README to sample config * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ab9b98e
[01:08:30] <KGB-linuxcnc> 03chris morley 05panelui 84ec196 06linuxcnc 10configs/sim/axis/panelui-demo/custom_postgui.hal panelui: cleanup postgui.hal file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=84ec196
[01:08:31] <KGB-linuxcnc> 03chris morley 05panelui 18a4a09 06linuxcnc 10src/emc/usr_intf/pyui/panelui_spec.ini panelui: update validation INI file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=18a4a09
[01:08:35] <KGB-linuxcnc> 03chris morley 05panelui 396ec11 06linuxcnc 10src/emc/usr_intf/pyui/master.py panelui: search different paths for INI file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=396ec11
[01:08:39] <KGB-linuxcnc> 03chris morley 05panelui 8199b6c 06linuxcnc 10configs/sim/axis/panelui-demo/custom_postgui.hal 10configs/sim/axis/panelui-demo/panel.glade 10configs/sim/axis/panelui-demo/panelui_handler.py panelui: add a custom command button * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8199b6c
[07:27:01] <jepler> yet another joomla update, nothing critical this time
[07:32:53] <jepler> nice https://www.youtube.com/watch?v=aSwDVi8W2XM&feature=youtu.be
[07:34:16] <jepler> seems to shell out to rs274 to interpret gcode
[07:38:07] <archivist> just need to join that and vismach
[07:58:34] <cncbasher> can we not add that simulation to axis
[08:00:23] <jepler> archivist, cncbasher I am sure you'll let me know when it's done
[08:00:42] <jepler> that specific code is gpl3 so there are license problems incorporating it directly in linuxcnc
[08:01:07] <archivist> I imagine the simulations speed is not quite what we want
[08:52:56] <cncbasher> it would be nice if it's solveable
[08:53:33] <cncbasher> anders may allow to change the licence to what we need , if he's asked
[08:55:48] <archivist> he is lurking in here :)
[08:57:05] <archivist> I see the need for boost as a hurdle as it seems to break projects on a regular basis when they change stuff
[08:57:59] <cncbasher> yea it needs to be binned
[08:59:21] <archivist> one thing this project needs is stability
[09:02:19] <cncbasher> yea i'm sick of chasing things that were once fixed , only for them to reappear
[09:03:08] <cncbasher> and as you say use code thats a bit more stable
[10:17:33] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/uvw-blending-dev b6aca16 06linuxcnc 10src/emc/tp/tp.c tp: compute current velocity directly from TP displacement. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b6aca16
[10:17:33] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/uvw-blending-dev 61a08c7 06linuxcnc 10src/emc/tp/tp.c tp: suppress some unneeded debug information * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=61a08c7
[10:21:28] <linuxcnc-build> build #71 of 1505.rip-jessie-rtai-i386 is complete: Failure [4failed install-missing-build-dependencies compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1505.rip-jessie-rtai-i386/builds/71 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[10:25:47] <seb_kuzminsky> rob: that needs a rebase to a newer version of master (or 2.7, if that's what you're targetting)
[10:57:53] <linuxcnc-build> build #3822 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3822 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[11:54:19] <andypugh> https://forum.linuxcnc.org/forum/24-hal-components/29816-pokeys#64207
[11:54:42] <andypugh> Seems like a HAL component that could potentially be absorbed into the project.
[11:55:37] <andypugh> (It would need caveats in the manpage that it is _not_ realtime IO
[11:56:40] <seb_kuzminsky> andypugh: neat
[11:56:46] <jepler> it depends on an LGPL3 library. besides needing to package it, can we link LGPL3 with GPL2-only code which what ends up happening when you run it?
[11:57:34] <jepler> this table from 2007 suggests otherwise http://www.dwheeler.com/essays/floss-license-slide.html
[11:58:24] <andypugh> Ah, that does seem to be something of a fly in the ointment
[11:58:32] <jepler> I sucks and I hate it :-/
[12:01:54] <andypugh> Where do you get the LGPL3 thing from? https://bitbucket.org/mbosnak/pokeyslib/ just says “LGPL”
[12:02:36] <andypugh> Not that that necessarily helps...
[12:02:45] <jepler> https://bitbucket.org/mbosnak/pokeyslib/src/2cc09d5c051a15a109877c0cc21d7da558ab37b5/License.txt?at=master&fileviewer=file-view-default
[12:02:48] <jepler> GNU LESSER GENERAL PUBLIC LICENSE
[12:02:49] <jepler> Version 3, 29 June 2007
[12:03:47] <andypugh> Ah, OK. I only got as far as the intro screen. license.txt is explicilty V3
[12:05:35] <jepler> it's absolutely fine to distribute in source form, and to build it and run it
[12:05:42] <jepler> but the binary is not distributable AIUI
[12:07:00] <andypugh> So, there is no proble with chap on the forum posting a .comp that depends on it, but we can never distribute his compiled comp?
[12:08:45] <jepler> It is impossible to distribute a binary that meets the GPL version 2 only license requirement of liblinuxcnchal AND the LGPL version 3 license of pokeyslib
[12:09:30] <jepler> other activities, like distribution of the source, modification and use are not affected
[12:10:36] <andypugh> I have forgotten where we got to on the desitrability and practicality of relicensing the GPLV2-only bits of LinuxCNC
[12:11:08] <jepler> nobody has done the work of getting consent to relicense from anybody
[12:11:25] <jepler> or at least, positive results have never been reported
[12:11:42] <jepler> matt shaver had offered to pursue it after the meeting a few years ago in Wichita but I never heard any results one way or another
[12:11:59] <jepler> .. I've gone on public record about my own contrbutions to LinuxCNC being OK to license under GPLv2+
[12:12:43] <jepler> assuming that getting permission will not come to fruition, the other possibility is to identify parts that have to be replaced, but it's hard in a project like ours to say we have made a clean-room implementation
[12:13:39] <cradek> iirc, matt started doing the work, one person said no, it was pointless to continue
[12:16:02] <jepler> you mean, he got "no" from one person he asked?
[12:17:12] <andypugh> I think I can guess who
[12:17:39] <jepler> is this a case of matt preferred not to say who it was?
[12:18:11] <jepler> this all makes me very sad when I have to think about it.
[12:20:47] <pcw_home> modest proposal for a raster output hal comp:
[12:20:49] <pcw_home> basically a stepgen modified for clocking out FIFO data
[12:20:50] <pcw_home> so position locked, but scaled by its independent rate generator DDS
[12:20:52] <pcw_home> with data gating (stream start stop) done with a step position comparator
[12:20:53] <pcw_home> This model should work for both software (comp) and hardware (FPGA)
[12:20:55] <pcw_home> and can be linked to a single axis or a hypot distance for position painting
[12:20:56] <pcw_home> curved paths
[12:22:13] <jepler> pcw_home: I would love to dig into this soon.
[12:22:50] <andypugh> I started to write that pair of comps. A userspace one that loaded jpeg into shared memory and a realtime one that generated a position raster and intensity oiutput.
[12:23:31] <jepler> the sampler/streamer API in master branch helps with the buffering / shared memory aspect of it
[12:23:57] <andypugh> But then I got interested in whether I could write a finite-jerk raster scanner with no actual lookahead, and then realised that as I don’t have a laser it was not something I coule ever test.
[12:24:26] <andypugh> The WIP is somewhere on the forum.
[12:24:43] <jepler> afk for lunch
[12:28:36] <cncbasher> if you need it testing Andy , i have laser here
[12:31:35] <andypugh> I have basically abandoned it. I have lots of things higher up my list. I doubt I will ever dig down to it.
[12:32:58] <cncbasher> yes your like me , the list gets longer the more work you do
[12:34:27] <pcw_home> Whats funny is I actually implemented something like this for a customer a long time ago (all in a FPGA)
[12:34:28] <pcw_home> (XY velocity modulated output for laser heat treating)
[12:34:58] <andypugh> Strangely I get a lot more done when I am not on IRC…
[12:35:30] <cncbasher> arh , thats the problem, i see it now !
[12:35:32] <andypugh> Time to log off and try to remind myself what I was doing
[12:36:14] <cncbasher> pcw_home:maybe time to revive it
[12:41:27] <pcw_home> Most can be done in HAL and I think its best to do with a comp first
[12:41:29] <pcw_home> as that's an easier environment to develop/test in and the result is
[12:41:30] <pcw_home> usable for parallel port systems and a good model for hardware.
[12:41:32] <pcw_home> For raster output on servo thread only systems (like our Ethernet cards) hardware
[12:41:33] <pcw_home> help is needed for the rate clock, FIFO, and gating
[13:08:40] <cncbasher> yea i was thinking as an option somehow on a card for laser use
[13:21:52] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes10 0f35bda 06linuxcnc New branch with 224 commits pushed, 10519 files changed, 0325782(+), 0418856(-) since master/404093e
[13:22:21] <KGB-linuxcnc> 05dgarr/ja10v4 17ad78f 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17ad78f
[13:27:47] <seb_kuzminsky> wooo!
[13:32:43] <cradek> sweet
[14:12:35] <skunkworks> How much extra data would you have to send every servo cycle?
[14:12:46] <skunkworks> to do rasterizing in the fpga?
[14:13:08] <skunkworks> I suppose that is like 'how long is a stick' - depends on the resolution and speed.
[14:32:25] <PCW> Yeah unless you are doing film exposure the data rate is not very high
[14:39:58] <PCW> even 8x 32 bit words would get you to 256 KHz for binary data out /1Khz servo thread
[14:39:59] <PCW> or 32 KHz for 8 bit PWM so its not a lot
[14:44:04] <PCW> 32 KHz is ~1 mill resolution at 1800 IPM so probably enough
[14:47:36] <jepler> I haven't found much information about the appropriate frequency to modulate a laser. Lots of chinese modules with no real documentation in english.
[14:47:39] <jepler> http://jtechphotonics.com/wp-content/uploads/2014/10/5KHz-Input-Signal-2.jpg
[14:48:38] <PCW> Diode lasers should be capable of modulation rates to the MHz region, CO2 are much slower
[14:49:14] <jepler> this is a blue solid state laser, green is input and purple is current feedback
[14:49:19] <PCW> (diode lasers with appropriate drivers)
[14:49:26] <jepler> looks like rise/fall times are a good 10uS with this driver
[14:49:35] <jepler> and of course lots of laser drivers have no real english documentation
[14:50:40] <PCW> yeah, pretty decent
[14:52:57] <PCW> If you used PWM, the PWM rate could probably be only be 10 KHz or so with that driver
[14:55:05] <PCW> Some drivers seem to use analog (you can get pretty decent analog out of the FPGA with 8 bit PWM
[14:55:07] <PCW> since that allows a PWM rate of about 800 KHz, which is easily filtered even at 30 KHz or so update rate)
[14:55:30] <jepler> I agree. You might be able to push a bit further by implementing some sort of compensation function between pixel values and pwm values (in addition to the gamma conversion you'll need to do)
[14:56:22] <PCW> Yeah I expect very funny non-linearities with laser marking
[14:57:09] <jepler> yup that's what I found with my tiny blue laser. https://emergent.unpythonic.net/01444658636#https://media.unpythonic.net/emergent-files/01444658636/IMG_20151008_205502-medium.jpg
[14:58:01] <jepler> the bottom right sample shows that trying to vary velocity doesn't give a useful gradient .. then ignore the tall black rectangle .. the next one shows that varying PWM (not sure what carrier frequency I used though) didn't either
[14:58:18] <jepler> in this case, the solid-state blue laser is driven by a darlington transistor
[14:58:36] <jepler> just open loop current/power and cross your fingers it doesn't eat itself
[14:59:33] <PCW> There must to be some positive feedback from greater absorbance in charred areas
[14:59:43] <jepler> I think you're right
[15:00:24] <jepler> this is basswood. I had different results with thin cardboard when varying feed rates (third image on that page)
[15:00:32] <PCW> is the best gradient from a dithered image source?
[15:01:05] <jepler> yes, on that material 1BPP dithering gave the most usable image
[15:01:55] <jepler> I should try cardboard again
[15:02:11] <PCW> yeah not a good continuous tone media :-)
[15:21:34] <jepler> here's another 2.5A laser driver for solid state lasers with a good datasheet. Its signal bandwidth is 1.1kHz http://www.thorlabs.com/NewGroupPage9.cfm?ObjectGroup_ID=1366
[15:21:58] <jepler> (LD3000R)
[17:05:10] <CaptHindsight> jepler: what wavelength blue? ~460nm?
[17:08:49] <CaptHindsight> or Blu ~405nm
[17:20:17] <jepler> CaptHindsight: no idea honestly
[17:20:27] <jepler> whatever they sent from china for the lowest price possible
[17:21:14] <CaptHindsight> does it look blue or more violet?
[17:21:28] <jepler> I would call it very clearly blue and not violet
[23:19:05] <skunkworks> isn't it odd that the plot is moving?
[23:19:07] <skunkworks> https://www.youtube.com/watch?v=1JzuyvvDWzc