Back
[02:43:02] <KGB-linuxcnc> 03Chris Morley 05new_pncconf 5d423df 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix error with firmware having more then 6 sserial channels * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5d423df
[02:43:02] <KGB-linuxcnc> 03Chris Morley 05new_pncconf 8bd3a89 06linuxcnc 10src/emc/usr_intf/pncconf/pages.py 10src/emc/usr_intf/pncconf/pncconf.py pncconf -add highlight of missing axis data * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8bd3a89
[03:31:13] <linuxcnc-build> build #1817 of 4004.deb-lucid-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/1817 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[03:33:39] <linuxcnc-build> build #1817 of 4003.deb-lucid-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/1817 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[03:35:14] <linuxcnc-build> build #1820 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/1820 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[03:48:09] <linuxcnc-build> build #656 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/656 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[03:56:03] <linuxcnc-build> build #1823 of 4007.deb-precise-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/1823 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[03:56:11] <linuxcnc-build> build #1823 of 4008.deb-precise-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/1823 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[04:57:12] <KGB-linuxcnc> 03Francis Tisserant 05v2.5_branch 3abb8fd 06linuxcnc 10docs/src/config/ini_config_fr.txt French doc update: fix startup code example * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3abb8fd
[09:56:26] <jepler> > Detected 2 layer board of 1.6x0.93 inches (41x24mm). $7.40 for three.
[09:57:01] <jepler> if you don't mind the turn time, the prices for small PCB fabrication can't be beat
[10:01:02] <cradek> wow
[10:04:35] <jepler> plated (enig) pads, soldermask, silkscreen both sides, free worldwide shipping
[10:05:45] <jepler> I've ordered one set of boards from there, a year ago. the quality was quite adequate but the design wasn't quite right, and then I lost interest in that little project
[10:06:42] <cradek> I'm pretty happy making my own little boards, but single-sided is a bit limiting
[10:14:09] <mozmck> where is that?
[10:14:23] <jepler> mozmck: oshpark.com
[10:14:53] <cradek> are you still using eagle?
[10:15:32] <jepler> cradek: yes, I used eagle for this board design
[10:15:45] <jepler> this site takes eagle (6.x) files or gerber files; I used eagle files.
[10:22:40] <seb_kuzminsky> linuxcnc-build: force build --branch=new_pncconf 0000.checkin
[10:22:41] <linuxcnc-build> build forced [ETA 1h16m54s]
[10:22:41] <linuxcnc-build> I'll give a shout when the build finishes
[10:22:42] <mozmck> heard of oshpark but haven't used them yet.
[10:26:53] <seb_kuzminsky> "i changed my hal config and now it doesnt work. any ideas?"
[10:42:29] <mozmck> change it back!
[11:07:06] <cradek> > I get an error if I do addf so I left it out.
[11:08:08] <cradek> doesn't the base thread also have fp now?
[11:19:06] <linuxcnc-build> Hey! build 0000.checkin #2311 is complete: Success [3build successful]
[11:19:06] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2311
[11:25:16] <jepler> cradek: I don't think so
[11:26:04] <cradek> oh it's optional, 02d22d65
[11:27:08] <jepler> yeah I was just getting to that
[11:27:38] <jepler> .. and $20 in parts to populate three boards (like I'll ever populate more than 1 1/2)
[11:27:57] <cradek> what's the board?
[11:28:15] <seb_kuzminsky> spi level shifter i bet
[11:28:20] <jepler> yes, seb_kuzminsky has it
[11:28:49] <seb_kuzminsky> for hooking a hostmot2 anyio board up to a little embedded arm board (odroid u3)?
[11:29:14] <seb_kuzminsky> seems way more awesomer than restricting yourself to the beagle bone black just because it has a pru
[11:29:42] <jepler> https://oshpark.com/shared_projects/OvoWoxU8 (but don't order any, it's untested)
[11:30:07] <seb_kuzminsky> jepler saves the day again :-)
[11:30:13] <seb_kuzminsky> oshpark looks neat
[11:30:19] <jepler> seb_kuzminsky: right, the idea is to write hm2_spi
[11:30:42] <seb_kuzminsky> that's awesome
[11:30:48] <seb_kuzminsky> oh man, 2.7 is gonna kick ass
[11:30:55] <jepler> I tried to get started with that over the weekend, but trying to pass the 1.8V signals over 6" unshielded wire to the level translator introduced suckage
[11:31:51] <jepler> so I hope this board fixes that
[11:32:24] <seb_kuzminsky> haha, here's one for cradek:
https://oshpark.com/shared_projects/NXSJCNKX
[11:33:06] <jepler> blog about it seems to be
http://www.geppettoelectronics.com/2014/08/an-even-better-crazy-clock.html
[11:37:10] <seb_kuzminsky> so your board boosts the u3's 1.8V spi to 3.3 or something? 5?
[11:37:25] <jepler> seb_kuzminsky: the "other" voltage is from SV1 pin 26
[11:37:35] <jepler> 3.3V and 5V would both be acceptable. I think 7i90 puts 5V on that pin
[11:38:00] <seb_kuzminsky> great
[11:38:11] <jepler> SV3 has the high voltage signals with interspersed grounds and can also furnish vcc on pin 9
[11:38:39] <seb_kuzminsky> i wish oshpark would let you attach a bom with purchase links
[11:38:42] <jepler> no doubt I botched the pin assignments despite triple-checking them
[11:38:43] <seb_kuzminsky> because i'm lazy
[11:38:45] <jepler> yeah that would be nice
[11:39:00] <jepler> or any URL
[11:41:00] <jepler> dig my curvy traces
https://644db4de3505c40a0444-327723bce298e3ff5813fb42baeefbaa.ssl.cf1.rackcdn.com/uploads/project/bottom_image/OvoWoxU8/i.png
[11:42:27] <cradek> that's very silly
[11:42:49] <jepler> I heard that electricity moves better without right angles
[11:43:10] <jepler> because of the energy needed to accelerate the electron holes(?) I imagine
[11:52:16] <mozmck> how did you make the curvy traces?
[11:52:35] <jepler> mozmck: in eagle, enter the command "miter .1" and then click on all the sharp corners you can find
[11:52:44] <jepler> then make sure and run erc again,
[11:53:03] <mozmck> I see. I use kicad - don't know if it has something like that.
[11:53:47] <jepler> seems to be on a kicad wishlist, so I guess not
[11:53:52] <mozmck> oh, the idea of right angles is false from what I read.
[11:54:44] <cradek> I don't think he was being serious
[11:55:20] <jepler> http://en.wikipedia.org/wiki/Microstrip#Bends
[11:55:20] <mozmck> ok :)
[11:56:07] <jepler> the bit about the momentum of electron holes is clearly bunkum; I just put in the curves because I think they give a distinctive look
[11:57:30] <mozmck> and the board is not for microwave frequency signals either is it ;)
[11:59:30] <mozmck> http://www.millertechinc.com/pdf_files/mti_tn063_microstrip_right_angle_bends.pdf
[12:00:09] <archivist> use Puff for microwave pcb design
[12:00:10] <mozmck> http://www.edaboard.com/thread41926.html
[12:00:23] <mozmck> puff?
[12:00:50] <jepler> yeah, this thing might see a 25MHz clock but nothing like microwave frequencies.
[12:01:31] <seb_kuzminsky> this will probably be the second jepler board i use and/or copy
[12:01:33] <archivist> was an old DOS package but it knows about microstrip design and is now open source
[12:01:52] <seb_kuzminsky> the first was a little 298 H-bridge servo amp, back in 2006 or 2007
[12:02:58] <mozmck> archivist: found it, but I don't have a clue when it comes to microwave stuff.
[12:03:42] <archivist> I sometimes play with microwaves
[12:03:49] <jepler> seb_kuzminsky: it's not like I have any real design chops
[12:04:09] <jepler> but I'm glad if a board design of mine has been useful to you
[12:09:32] <jepler> seb_kuzminsky: If the board works, I'll consider that I owe you a copy. remind me of my obligation if you hear me celebrating.
[12:11:02] <seb_kuzminsky> wait what?
[12:11:35] <seb_kuzminsky> i dont think you owe me anything, but i'll gladly take a copy...
[12:11:46] <jepler> OK, consider this an offer
[12:33:52] <seb_kuzminsky> #389 is fixed now, right?
https://sourceforge.net/p/emc/bugs/389/
[12:33:55] <seb_kuzminsky> if so i'll close it
[12:34:57] <pcw_home> jepler: if you have not already ordered the cards you might consider adding a series resistor to the clock output
[12:35:36] <pcw_home> (especially if it has to drive a cable)
[12:35:42] <jepler> pcw_home: on which side?
[12:35:50] <jepler> on the HV side?
[12:37:38] <pcw_home> yes
[12:37:51] <jepler> why clk in particular?
[12:37:59] <jepler> and what's a typical value?
[12:38:40] <pcw_home> Because it the most sensitive to undershoot (and so double clocking)
[12:40:37] <pcw_home> it depends on how strong the driver is, but the combination or driver impedance and added resistor
[12:40:38] <pcw_home> should match the characteristic impedance of the cable (130 ohms for .050 gnd,signal,gnd)
[12:41:08] <pcw_home> 1 mm gnd/signal/gnd is ~100 ohms
[12:41:32] <jepler> > The typical output impedance during output transition
[12:41:39] <jepler> .. is 40 ohms at Vcco = 3.3V to 5V
[12:42:00] <pcw_home> so about 82 Ohms
[12:42:19] <jepler> bbl
[12:42:23] <pcw_home> (for standard .050 flat cable)
[13:26:17] <jepler> pcw_home: filed that advice away, thanks
[13:44:29] <CaptHindsight> the colors and the curves remind me of the 70's and PCB layout by hand
[13:46:06] <jepler> oshpark uses purple soldermask, because they can
[13:50:05] <jepler> pcw_home: on the 7i90 with spi configuration, are there pull-ups on the spi lines?
[13:51:07] <jepler> I guess I'm asking about the board, I can see no pullup configured in the ucf file
[13:52:08] <pcw_home> I dont think so, but am not sure
[13:53:01] <jepler> I was just noting that the datasheet for this particular level translator says not to include pullups unless the value is at least 50k
[13:53:42] <pcw_home> thats strange
[13:56:13] <jepler> probably I chose a weird device
[13:56:16] <pcw_home> dont use the "no direction signal needed" translators as they dont have the fast symmetrical drive needed for cable driving
[13:56:17] <pcw_home> (beside you only need 1 direction)
[13:58:31] <jepler> you mean if I'd used a resistive divider or other trick for the MISO signal?
[13:59:39] <pcw_home> No, the bidirectional translators that dont have direction signals depend on pullup resistors = too slow for 25 MHz
[14:01:37] <pcw_home> A resistive divider works for MISO because it can be really low impedance since the FPGA has 24 mA drive capability
[14:02:50] <jepler> for this part at 1.8/5V, rise and fall times of 4.1ns max (faster on the 5v side) and max data rate of 60Mbps are proclaimed
[14:03:53] <jepler> it has high- and low-side one-shot drivers plus a value-holding driver with nominal 4k series resistor (the reason that small-value pull-ups don't behave properly)
[14:03:55] <CaptHindsight> http://www.adafruit.com/products/757 a bit slower than the device you picked but already on a board
[14:03:58] <jepler> txb0104
[14:05:50] <jepler> CaptHindsight: I started with this board
https://www.sparkfun.com/products/11771 but it seems like the 1.8v signals were just not reliable after they went 6" in unshielded, unpaired wires which was my setup
[14:06:12] <jepler> CaptHindsight: hence designing a level-shifter board that attaches directly to the odroid I/Os
[14:08:21] <jepler> (I couldn't even reliably trigger my scope on the 1.8v CS/ signal)
[14:09:43] <jepler> (scope clip at the far end of a 6" wire)
[14:10:06] <CaptHindsight> SPI on the odroid almost seems like an afterthought
[14:10:41] <jepler> yeah, I agree with that assessment. It wasn't even on the first public board revision, and when they added it they didn't even put a GND on the same connector.
[14:14:10] <jepler> pcw_home: anyway, I now know to also pull the resistor pack for the 7i43 ports I repurposed as spi
[14:22:12] <CaptHindsight> https://docs.google.com/file/d/0B4UPrML8Nk9lQzBRNzBuOTBwMjQ/edit?pli=1 their IO shield/cape/serape/cloak board only bring the SPI pins to a flash device, no buffers
[14:23:01] <PCW> I would not bother pulling the resistors since the translator is never tri-stated
[14:23:01] <CaptHindsight> http://www.hardkernel.com/main/products/prdt_info.php?g_code=G138760240354&tab_idx=1
[14:26:09] <PCW> (since its always driving, the keeper circuit is never used)
[14:26:28] <CaptHindsight> their IO board has 1K pullups to 1.8V on all 4 SPI signals
[14:28:44] <CaptHindsight> I don't have the the hardware manual for that Exynos device so I can't tell what type of output driver is on those signals.
[14:35:18] <CaptHindsight> http://forum.odroid.com/viewtopic.php?f=80&t=5702 SPI driver for U3+ (PCB rev 0.5)
[14:36:18] <jepler> CaptHindsight: I have no idea of the provenance of the document that google turns up with the following search: 4
[14:36:24] <jepler> err
https://www.google.com/search?q=allinurl:Exynos_4412_Datasheet_V1.0.pdf
[14:36:56] <CaptHindsight> "We’ve tested the ioboard-spi-misc.ko with a Serial SPI Flash memory SST25WF020A on the new IO Shield and the maximum speed was 40Mhz of SPI clock."
[14:37:52] <jepler> CaptHindsight: (or whether the document answers the question at hand: an equivalent circuit for the SPI pins drivers)
[14:38:51] <CaptHindsight> jepler: sample code for testing the SPI port in that link from their forum ^^
[14:38:56] <jepler> CaptHindsight: thanks
[14:43:41] <CaptHindsight> jepler: thanks, that data sheet is register spec/programming spec, I can't seem to find their hardware and design guide, that would have all the IO specs, pinouts, layout recommendations etc etc
[14:44:14] <CaptHindsight> that might be NDA only and I haven't spotted a leaked version yet
[15:02:30] <jepler> CaptHindsight: well from this document at least we can see that there are configurable pull-up and pull-down, as well as 4 choices of drive strength
[15:21:20] <PCW> 7I90 has no pullups or pulldowns on the SPI pins (EPP D4,D5,D6,D7)
[15:31:21] <jepler> odroid has none external, and internal ones can be disabled
[15:31:48] <jepler> but according to this pdf, power-on value is pull-down enabled; nobody's saying what the drive strength is
[15:32:11] <jepler> surely it's a high value; this is designed to go in portables
[15:52:05] <PCW> built in pullups/pulldowns values tend are pretty wide tolerance (+-50% or more)
[15:55:21] <jepler> I am just wondering whether they're more like 100k or 5k
[15:55:32] <CaptHindsight> 100K
[15:55:39] <jepler> that was my suspicion
[15:56:01] <jepler> 200 I/Os at 100kohm is already 7.2mA, a lot for a portable
[15:56:10] <jepler> err, 3.6mA
[15:56:43] <CaptHindsight> I've seen entire series of chipsets that had internal pullups where the vendor always recommended using redundant externals
[15:57:28] <PCW> you would probably just turn them off if the pins are output or externally driven
[15:57:41] <CaptHindsight> jepler: is there enough info on the registers to poke around and toggle the SPI signals
[15:57:43] <jepler> yes, I could access a register and turn them off
[15:57:55] <jepler> CaptHindsight: yes, and in fact there's a kernel spi driver
[15:58:20] <skunkworks_> rqq
[15:58:24] <jepler> CaptHindsight: with a wire connecting MISO to MOSI I can read back whatever I write
[15:58:26] <skunkworks_> \]
[15:58:57] <jepler> though in the scope I thought I saw some weird things happening with /CS
[15:59:45] <jepler> .. I'm not really confident of a lot of the things I "measured" last weekend
[15:59:53] <CaptHindsight> in the middle of transfers
[16:00:43] <jepler> one thing I saw, when I tried to use the logic analyzer, was CS bouncing at edges of SCK
[16:01:06] <jepler> .. that is when I had the odroid -> 6" wire -> level converter -> 6" wire -> analyzer setup
[16:02:25] <jepler> and why one of the things I'm doing now is designing a board that puts the level converter as close as possible to the odroid, and also provides interspersed GNDs for the 5v signals -- one 5V-level pinout for the analyzer, another to match the 7i90
[16:06:27] <PCW> 7I90 has 5V tolerant but 3.3V signals
[16:11:02] <CaptHindsight> 6" is a bit long at these frequencies, you could try shorter jumpers ~1" before you make your board, but you'll probably want the board anyway for any permanent use
[16:11:24] <jepler> hmm, looks like a 5V supply to TXB0104 is a problem then, in terms of registering the output voltage of the 7i90 as a high
[16:11:57] <jepler> er, hmm
[16:12:18] <jepler> V_IH = VCCI x 0.65 min
[16:13:12] <jepler> in my test, I had the 5V pull-ups on 7i43
[16:13:51] <PCW> pullups should make no real difference
[16:14:17] <jepler> pcw_home: on 7i90, P4 pin 26's "vcc" is 5V or 3.3V?
[16:14:24] <PCW> 5V
[16:15:17] <PCW> but your translator should probably be powered by 3.3V
[16:15:21] <jepler> right
[16:15:51] <PCW> 5V will likely work but margins will be worse
[16:15:53] <jepler> if powered from 5V, then 3.25V is required to register a high input
[16:17:06] <PCW> Yeah the FPGA I/O is set for LVTTL so ~1.6V thresholds
[16:17:28] <jepler> it's FPGA back to level translator that is worrying me this instant
[16:17:32] <CaptHindsight> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/BreakoutBoards/TXB0104_breakout.pdf
[16:17:57] <jepler> CaptHindsight: yes, that's the board I started with
[16:18:33] <CaptHindsight> VCCA to 1.8 and VCCB to 3.3V should do it
[16:18:48] <PCW> if the device is hardwired for a FPGA with high drive, that direction could be done with 2 resistors (say 200/270)
[16:19:20] <PCW> (Thevenin's is close to cable impedance)
[16:21:35] <jepler> My aim is to make a board to interface with 7i90, not a general 5v spi converter
[16:21:44] <jepler> it's sounding more and more like I should go back to the drawing board though
[16:21:44] <PCW> oops that the wrong way NM (would work at 7I90 end, not translator end)
[16:23:15] <PCW> just use the translator with 3.3 VH
[16:23:16] <PCW> any signals that drive a cable to 7I90 should be series terminated (series resistor)
[16:23:18] <PCW> clock most importantly
[16:23:44] <jepler> I don't have 3.3v handy, unless I want to drop in a linear regulator
[16:23:48] <Tom_itx> jepler, oshpark (laen) is pretty good
[16:24:00] <Tom_itx> i've been using #hackvanna also lately
[16:24:33] <Tom_itx> are laen's boards still purple?
[16:24:42] <Tom_itx> kinda his trademark mask color
[16:24:47] <PCW> yeah just add a NCP1117 or some other $.20 LDO regulator
[16:24:50] <jepler> Tom_itx: yeah that's how it looks
[16:25:05] <Tom_itx> he did a few for me when he was getting started
[16:25:18] <Tom_itx> quality was good (US made)
[16:25:29] <jepler> pcw_home: and better to use the resistive divider or the level translator for MISO?
[16:25:31] <Tom_itx> hackvanna is china
[16:26:21] <Tom_itx> Mitch is an aussie that hangs out in #avr that started that service
[16:26:22] <jepler> the problem with Vccb = 5v seems to be on the B-side's input
[16:27:21] <PCW> well other than the power connection there's nothing about the 7I90s SPI interface thats 5V
[16:28:05] <PCW> so local 3.3V regulator seems in order
[16:28:14] <jepler> yeah
[16:28:32] <jepler> I have 5V at the odroid side, I'll use that and ignore pin 26
[16:28:40] <Tom_itx> iirc oshpark was part of twin cities robotics group originally
[16:32:36] <Tom_itx> don't feel bad, this was the 'original' purple:
http://tom-itx.no-ip.biz:81/~webpage/boards/atmega32u4/atmega32U4_3.jpg
[16:33:21] <Tom_itx> back then you never knew what plating you would end up with
[16:39:30] <jepler> that's not as purple as you might wish
[16:39:45] <Tom_itx> ^^ that one was almost brown
[16:45:33] <CaptHindsight> is there a market for exotic soldermask colors? I can make them just about any color
[16:46:31] <Tom_itx> no, he just wanted to be different i think so he could track where his boards ended up
[16:46:59] <seb_kuzminsky> i want a plaid one
[16:47:22] <CaptHindsight> with inkjet we can do just about anything
[16:47:51] <jepler> if instead of soldermask + silkscreen you could offer a full-color process, that'd be neat
[17:03:03] <CaptHindsight> http://imagebin.ca/v/1WcAEuuawOQf we started printing the copper traces a few years ago with inkjet (Linuxcnc is controlling the motion), now we're able to print everything including the epoxy board all from liquids
[17:03:29] <jepler> neat
[17:12:32] <seb_kuzminsky> CaptHindsight: that's cool
[17:14:32] <CaptHindsight> that's our main use for linuxcnc, moving all the lasers, printheads and and trays around
[17:15:45] <jepler> I wish I understood eagle's erc
[17:16:14] <jepler> I added a *117 power supply, and now it complains 'OUTPUT and SUPPLY pins mixed on net 3.3V'
[17:17:40] <CaptHindsight> not sure about eagle but the ERC tools tend to catch devices where the output is connected to power, not understanding that the output is a voltage regulator
[17:17:41] <jepler> maybe it's a flaw in the *117 device I added, its pin type should be PWR rathern than OUTPUT
[17:17:51] <CaptHindsight> yup
[17:20:17] <jepler> yes, and besides that the "name" of the symbol's pin should apparently be the same as the net you connect it to (e.g., 3.3V)
[17:20:24] <jepler> oh well, i'll just approve it in erc
[17:22:00] <CaptHindsight> separate power and ground planes that all connect at one point can also be a headache
[17:22:37] <CaptHindsight> some tools just don't keep up with how high speed mixed signals boards have to be routed
[17:25:58] <jepler> eagle doesn't really try
[17:26:11] <jepler> I don't think there's any way to require a star ground from its autorouter for example
[17:28:34] <seb_kuzminsky> skunkworks_: would you try a new rtai kernel on that machine with the problematic usb? deb
http://highlab.com/~seb/linuxcnc/rtai-debs wheezy main
[17:30:40] <CaptHindsight> I installed Wheezy LXDE from the debian repos and then added the wheezy 2.6 repos. It all seems to work so far. Is there some reason that the howto still recommends using the hybrid ISO?
[17:30:57] <CaptHindsight> Am I missing something I haven't discovered yet?
[17:31:04] <jepler> CaptHindsight: not really
[17:31:19] <jepler> CaptHindsight: if you are an advanced user, there's no reason you should not do that
[17:31:30] <CaptHindsight> ok, so it works, test completed
[17:31:31] <jepler> CaptHindsight: for a new user, particularly a new-to-linux user, it's a lot to ask to do those things
[17:31:53] <jepler> if you're an advanced enough user, you'll just ignore everything from us except our git
[17:32:50] <CaptHindsight> I noticed the precise howto still has you install 12.04 first then add the repos
[17:32:59] <jepler> nobody's made a precise live image
[17:33:37] <jepler> we get what volunteers do, and that's cradek with his wheezy image
[17:33:42] <CaptHindsight> ok, I thought maybe there was some special magic in the wheezy hybrid ISO
[17:34:02] <jepler> well, there was a lot of time spent to make it do certain things
[17:34:17] <jepler> a few of them will not happen if you install wheezy. the update notification is one small item that comes to mind
[17:34:44] <CaptHindsight> so fewer nag screens :)
[17:35:36] <jepler> CaptHindsight: you're thinking like an advanced user again
[17:35:51] <jepler> cradek: hey, didn't you tell me the "source" (scripts) for the iso were in git somewhere?
[17:37:01] <seb_kuzminsky> the infrastructure repo has some old hardy(?) livecd scripts in it
[17:38:21] <jepler> seb_kuzminsky: yeah, I meant the wheezy stuff
[17:38:38] <seb_kuzminsky> i know, i meant to suggest to cradek he put them next to the old ones
[17:38:48] <jepler> ah
[17:46:46] <jepler> From 00000147c748be93-402b74c9-58e4-4874-b36f-85ed85f7fedf-000000@amazonses.com Mon Aug 11 17:55:46 2014
[17:46:49] <jepler> Subject: =?utf-8?B?UmVjZWl2ZWQgeW91ciBlbWFpbCwgQ2FzZSAjIENBUy04NzAw?=
[17:46:51] <jepler> what has the world come to when this is *not* spam
[17:48:39] <seb_kuzminsky> the end of days are here
[17:49:18] <jepler> I notice one UUID just wasn't enough for amazon
[17:49:33] <jepler> they must plan to identify a *lot* of things before they're done
[17:50:00] <CaptHindsight> hmm, I didn't know that a Linuxcnc Mint CD would need approval
http://community.linuxmint.com/tutorial/view/1784
[17:50:36] <jepler> trademarks are funny that way
[17:51:01] <jepler> get a trademark; make it a pain in the ass to *remove* that trademark; ...; profit
[17:51:46] <jepler> (tbh I have no idea how difficult it is to remove the trademarked portions of the branding of a custom mint distro)
[17:52:54] <CaptHindsight> I already have it running here and I was just considering making a LiveCD with it
[17:55:43] <jepler> as far as linuxcnc goes, "linuxcnc" is technically a trademark through the linux foundation, just like "linux mint" is. but when you say that some install media has linuxcnc on it, and that's an accurate factual statement, there's no problem (just like saying distribution media has software from linux mint on it)
[17:56:03] <jepler> as far as I know, nobody's ever claimed any of the (GPL & GFDL) artwork in the linuxcnc source code are trademarks
[17:57:10] <jepler> by the way, I'm pretty sure that cradek's wheezy live image works in the right way: by running debootstrap to create a filesystem
[17:58:15] <jepler> the mint way is the way ubuntu did it a long time ago, where you start with some media, make it editable, run some commands, and turn that back into an iso file. in my viewpoint, that's a less good situation because it's much less clear whether you're satisfying the moral obligation to provide "the scripts used in compilation of the software"
[17:58:22] <jepler> (to borrow a phrase from the GPL)
[17:59:05] <seb_kuzminsky> that's how our lucid live+install CD worked too
[17:59:08] <jepler> (This may not be an actual license requirement, but making it hard for users to build your software is a good way to violate the spirit of any open source license)
[18:00:11] <jepler> http://live.debian.net/
[18:00:23] <CaptHindsight> I'm also not sure of all the differences between Mint Debian and Debian Wheezy and what (if any) Linuxcnc problems there might be in their roadmap
[18:01:20] <jepler> http://live.debian.net/manual/current/html/live-manual/examples.en.html
[18:01:20] <seb_kuzminsky> jepler: ... which links to:
http://cgi.build.live-systems.org/cgi-bin/live-build
[18:01:28] <CaptHindsight> I'd rather stick with what everyone here is working with vs supporting it all alone, except for Gentoo
[18:02:07] <jepler> seb_kuzminsky: holy buckets
[18:03:09] <jepler> seb_kuzminsky: how can they make a live cd for every bot that enters an invalid e-mail address and presses all the buttons?
[18:03:12] <jepler> :-P
[18:03:32] <seb_kuzminsky> maybe there's a captcha later
[18:04:48] <jepler> bbl
[18:06:34] <seb_kuzminsky> seeyas
[18:08:44] <Tom_itx> jepler, in eagle do you use wire or net to draw schematics?
[18:08:55] <Tom_itx> wire doesn't always connect properly...
[18:10:04] <Tom_itx> or if the pins are too close for the DRC it will error
[18:10:08] <Tom_itx> i ignore those
[18:15:18] <skunkworks_> seb_kuzminsky: I can test it tomorrow
[18:15:42] <seb_kuzminsky> thanks! i'll try to test it tonight on the machine i have with the wonky wifi adapter
[18:56:37] <jepler> Tom_itx: in the schematic editor, use "net". in the board editor, route an unconnected net with "route"
[18:57:53] <jepler> Tom_itx: in the schematic editor you might use "wire" to do other things like draw boxes to separate schematic parts
[18:59:03] <jepler> Tom_itx: eagle sure had a learning curve, but now I feel real comfortable with it
[18:59:14] <Tom_itx> why i brought that up was sometimes parts are drawn off grid (metric) in the schematic editor and wire won't connect however net will
[18:59:18] <jepler> I usually hand-route my boards, they tend to be simple ones like the one I linked to earlier on oshpark
[18:59:26] <Tom_itx> i've used it since around ver 2
[18:59:31] <jepler> oh yeah, in the schematic editor you're more or less doomed to use an inch grid
[18:59:42] <jepler> or, you know, 12.7 mm grid or something
[18:59:47] <Tom_itx> yep
[19:00:05] <Tom_itx> do you know how to handle multiple pin GND signals?
[19:00:34] <jepler> on a single device? I think you are supposed to name them GND@1 GND@2 etc in the library, then you have to connect them all in the schematic editor
[19:00:35] <Tom_itx> not sure what was causing your error really
[19:00:40] <Tom_itx> yep..
[19:01:23] <Tom_itx> unless signals got crossed in the schematic
[19:01:29] <Tom_itx> that's where erc looks
[19:01:33] <Tom_itx> drc is board related
[19:02:31] <Tom_itx> i don't mind eagle really... seems everybody curses it
[19:03:19] <Tom_itx> it doesn't do alot of the fancy routing $$$$ do
[19:03:23] <jepler> it's good enough that I never put in the time to learn the open source alternatives
[19:03:44] <jepler> yeah, a hobbyist has to learn how to work with it before she can get anything done -- and the pro needs a more sophisticated product anyway
[19:04:43] <Tom_itx> and i've managed to get 3 or 4 cam jobs for several board houses
[19:04:56] <Tom_itx> seeed seems the pickiest
[19:05:37] <Tom_itx> and i use GC-Preview to make sure the gerbers are good
[19:07:13] <jepler> for this board order, I just sent an eagle .brd file and squinted at the images they produce
[19:08:01] <Tom_itx> seems Laen does 2 or more orders a week now... back then we had to wait for the pannels to fill up
[19:08:31] <jepler> when I was previewing my order, it said that a 2-layer panel would be ordered tomorrow and the day after
[19:08:46] <jepler> .. and then I got an e-mail that the panel order has already gone in
[19:08:50] <jepler> same day I placed the order
[19:09:01] <Tom_itx> he wrote a nifty program to do the pannels to optimize the space
[19:09:13] <Tom_itx> the only thing i don't like are the tabs
[19:09:28] <Tom_itx> hackvanna cuts his to shape.... nice smooth edges
[19:09:53] <Tom_itx> he has sent me several free boards though
[19:10:07] <Tom_itx> laen that is.
[19:12:35] <jepler> that never hurts
[19:13:52] <jepler> I hope the boards I ordered today will still work despite not having most of the tweaks peter and I talked about
[19:14:00] <Tom_itx> i let him use the layout for the avr adapters shown so he sent me a buttload of them in return:
http://tom-itx.ddns01.com:81/~webpage/boards/USBTiny_Mkii/new_kits/USBTinyMkII_adapter_kit_desc.jpg
[19:14:20] <jepler> biggest problem is the supply voltage, but I can just run 3.3v in by the secondary connector from someplace else
[19:14:22] <Tom_itx> you can always hack traces :)
[19:14:43] <Tom_itx> the first rev is never the final
[19:14:53] <Tom_itx> you know that... you write lcnc :)
[19:15:46] <Tom_itx> i think he passed those out at his robotics group
[19:16:40] <jepler> Tom_itx: nice
[19:18:27] <Tom_itx> http://tom-itx.ddns01.com:81/~webpage/boards/USBTiny_Mkii/new_kits/USBTinyMkII_blue_full_kit_desc.jpg
[19:18:33] <Tom_itx> lcnc does the box cutouts
[19:18:49] <jepler> huh, I was unaware avr had three different serial programming protocols (assuming you don't count dfu either)
[19:18:58] <Tom_itx> yep
[19:19:02] <Tom_itx> xmegas use PDI
[19:19:08] <Tom_itx> regular ones use ISP
[19:19:26] <Tom_itx> and the attiny 4 5 9 10 and a couple others use TPI
[19:19:54] <jepler> I guess I've only had ISP ones, and ones with bootloader, and dabbled a little bit with the USBs
[19:20:01] <jepler> better never to make any design so big it needs a mega
[19:20:03] <Tom_itx> xmegas are 3.3v parts
[19:20:10] <jepler> much less an xmega
[19:20:29] <Tom_itx> nice thing about them is the code is pretty portable
[19:20:40] <jepler> that's all thanks to avr-gcc
[19:20:57] <Tom_itx> the regs are all quite similar
[19:21:18] <Tom_itx> newer parts add more and rename them but they're backward compatible
[19:22:52] <Tom_itx> not alot of use for them in this croud though
[19:23:04] <Tom_itx> sensor adapters maybe
[19:23:10] <jepler> yeah that'd be the primary use
[19:23:42] <jepler> there's even a gpl modbus slave out there that builds for avr .. I've always meant to build it and see if it talks to classicladder or whatever in linux
[19:23:45] <jepler> cnc
[19:23:56] <Tom_itx> their xmegas don't make much sense because arm does more for less
[19:25:51] <jepler> other days I wonder if some of the ARMs that are too small to run linux could run an RTOS + hal, reusing parts of linuxcnc like stepgen, encoder, etc
[19:26:18] <jepler> talking to linuxcnc via some interface that is realtime on the PC end is tougher
[19:26:30] <jepler> ethernet, maybe, in master
[19:26:34] <Tom_itx> well they run the silly repraps on mega2560's
[19:27:43] <jepler> but it seems so unlikely that you could beat fpgas at being step generators or encoder counters, and you can't fit enough of linuxcnc to not need a realtime pc at all, so it's a bit silly
[19:31:51] <CaptHindsight> well several of those *duino and reprap devs make $$ on selling their wares, they would have rockstar status (in their circles) and extra income if they just used Linuxcnc
[19:32:07] <CaptHindsight> would/wouldm't
[19:33:56] <jepler> oh given their constraints their decisions are understandable
[19:34:27] <jepler> need to work with Windows and Mac, hobbyist-friendly parts, low price paramount
[19:35:15] <CaptHindsight> that pick-n-place project also went with *duino and reprap style boards since they claim it saves several $$
[19:37:15] <CaptHindsight> http://delta.firepick.org/
[19:37:42] <CaptHindsight> runs a duino for motion and Rpi for machine vision
[19:38:02] <jepler> and as a challenge, fitting a project into a microcontroller can be rewarding
[19:38:35] <jepler> compared to writing everything for machines with 8GB RAM and 10+GHz of aggregate CPU preformance
[19:39:31] <Tom_itx> i think fpgas would be fun but i haven't done that much with them
[19:39:52] <CaptHindsight> back in the 80's we'd fight for extra available bits, then the pendulum swung to how to bog down that 10+GHz PC with bloatware
[19:41:45] <jepler> I've been writing this table-driven assembler in Python. The first time it "worked", its runtime was over 4 seconds to process a ~1500 line file, or way way under 1kloc/s
[19:42:03] <jepler> the parser library I'd picked is very naive compared to what the state of the art was in the 90s
[19:43:43] <jepler> but .. most of them are, because for a lot of tasks "GLR" is fast enough and it's easier for someone to write a working parser without knowing the sorts of things one had to know to use lex/yacc
[19:43:55] <jepler> (and I say this all as a huge python advocate; python's almost always fast enough)
[20:05:49] <jepler> Tom_itx: I agree, you should give FPGAs a try. if you want something standalone, there seem to be some interesting projects for this family of products:
http://papilio.cc/
[20:10:14] <jepler> this isn't intended to be a generic device, but it does have a reprogrammable fpga, 16 inputs, and 16 I/Os:
http://www.seeedstudio.com/depot/Open-Workbench-Logic-Sniffer-p-612.html
[20:19:07] <CaptHindsight> I think that was based on the SUMP project that use the Xilinx or Altera dev boards
[20:19:30] <CaptHindsight> yeah, "Designed for the SUMP logic analyzer client" JAVA
[20:28:16] <jepler> and of course you could always pick up a spare mesa board, and even start with the hostmot2 firmware.
