Back
[11:22:46] <skunkworks> jepler, still running
http://electronicsam.com/images/KandT/testing/7i80j1900.png
[11:23:20] <cradek> how long?
[11:23:35] <skunkworks> I started it monday
[11:23:41] <cradek> cool
[11:24:08] <skunkworks> This is the one that doesn't have as great latency.. (aproching 100us if you let it run for days..)
[11:28:50] <pcw_home> I should build you a config with DPLL so you can read the actual packet latency
[11:30:42] <pcw_home> This is interesting ,too bad its nvidia
[11:30:44] <pcw_home> http://www.nvidia.com/object/jetson-tk1-embedded-dev-kit.html
[11:32:45] <CaptHindsight> all the GPU based supercomputer clusters as Sandia and Los Alamos were considered failures since hardly anyone wanted to rewrite their code
[11:32:55] <CaptHindsight> as/at
[11:33:41] <jepler> "Infragistics Professional"
[11:33:47] <jepler> thanks sf for bringing me new product names to chuckle at
[11:34:13] <jepler> > Build a bridge from your legacy apps to the future.
[11:34:15] <pcw_home> Even without the GPU its a fast CPU
[11:34:43] <CaptHindsight> Odroid announced a RPi clone yesterday using the same Broadcom ARM soc
[11:35:17] <CaptHindsight> yeah, I'll take anything fast, low power-latency-cost
[11:35:58] <CaptHindsight> too bad Nvidia is notoriously bad at sharing docs
[11:36:01] <pcw_home> faster than a lot of current low end X86 and lower power
[11:36:16] <pcw_home> Yeah not open source friendly
[11:36:40] <CaptHindsight> Buy Jetson TK1-Just $192 !
[11:36:48] <pcw_home> but nice hardware (4 PCIE lanes) 4X A15 cores
[11:36:57] <pcw_home> ~6W
[11:37:42] <pcw_home> has SPI 12C LCD and camera I/O and some GPIO
[11:38:44] <CaptHindsight> low power, features, low cost, high performance, open docs, low latency. Has it ever happened?
[11:39:52] <pcw_home> very often an issue with leadng edge products
[11:43:37] <CaptHindsight> sad to see how poor the latency is on the ZYNQ
[11:45:46] <CaptHindsight> no open docs on the samsung Exynos 4412 but looks like ~25uS latency with preempt-rt
[11:48:23] <CaptHindsight> imx6 is ~65uS preempt_rt
[11:54:20] <CaptHindsight> https://www.youtube.com/watch?v=Hzi3dY2WU0k Firesight openCV for pick-n-place
[11:55:19] <CaptHindsight> https://github.com/firepick1/FireSight/wiki
[11:56:39] <CaptHindsight> this can be made as a plug-in to AXIS like camview with the auto zero
[13:20:16] <kwallace2> Hello. I am playing with a PCIe single parallel port card. One issue I have with it is that I can't find any dual port cards and normal motherboards don't have more than two PCIe slots. Is there such a thing as a PCIe slot expansion? It's not a big deal to go to a 6i25, but I have an inquiring mind.
[13:27:01] <pcw_home> http://www.startech.com/Cards-Adapters/Parallel/2-Port-EPPECP-PCI-Express-Parallel-Card~PEX2PECP
[13:28:24] <CaptHindsight> wow $20 but now replaced with a $76
http://www.startech.com/Cards-Adapters/Parallel/2-Port-EPPECP-PCI-Express-Parallel-Card~PEX2PECP2
[13:29:06] <pcw_home> whats that chinese one you found?
[13:30:34] <CaptHindsight> only single port for $10 ...
[13:31:20] <CaptHindsight> http://www.ebay.com/itm/170988778068
[13:31:47] <pcw_home> http://www.newegg.com/Product/Product.aspx?Item=N82E16815287023
[13:31:48] <pcw_home> 2 port $32
[13:36:52] <kwallace2> I guess if I have a motherboard with PCI slots I'll stick with PCI parallel ports for the slow signals.
[13:37:40] <CaptHindsight> PCI are easier to find than PCIe
[13:44:14] <kwallace2> I guess PCI slots are still easy to find. Here is a cheap six ports worth:
http://www.newegg.com/Product/Product.aspx?Item=N82E16813157338
[13:44:43] <kwallace2> I guess I can get back to doing real work.
[13:53:38] <cradek> it even has one built in
[13:58:00] <kwallace2> I fried a motherboard port early on, so I try hard to not use the built in port.
[13:59:39] <kwallace2> Crud, this PCIe card's outputs run at 3 Volts.
[14:05:37] <pcw_home> Most new cards will be 3.3V
[14:05:57] <pcw_home> breakoust that dont use TTL levels are shite
[14:06:24] <pcw_home> 2.4V is a valid TTL high
[14:08:46] <pcw_home> Note that thers no 5V on PCIE bus at all
[15:41:07] <memleak> 1.5 microseconds for the base thread and 8 microseconds on the servo thread with preempt-rt, running for about 45 minutes now. firefox makes it jump in the 100-150 range but while idling its par with RTAI.
[15:41:50] <memleak> (master branch)
[15:48:26] <seb_kuzminsky> jepler: i just pushed glade-3 for wheezy to the wlo repo
[15:48:40] <seb_kuzminsky> i also added ttt & mesaflash for amd64, for precise and wheezy
[15:49:40] <seb_kuzminsky> memleak: that's pretty awesome
[15:49:52] <cradek> sounds like I should add that to the cd? is the package glade-3?
[18:39:01] <jepler> seb_kuzminsky: thank you!
[18:39:11] <jepler> somebody needs to write some documentation about how to effectively edit those files
[18:39:23] <jepler> but .. not me, I am not a user of that
[18:39:42] <jepler> glade-gtk2 is not a build dependency or a runtime dependency of linuxcnc
[18:39:57] <jepler> but the binary package could have a recommends: for this
[18:40:32] <jepler> because it's another package that is likely to be useful to a good chunk of linuxcnc users
[18:41:14] <Tom_itx> oh is this about the glade stuff?
[18:41:22] <Tom_itx> sry, my power has been out..
[18:42:42] <jepler> Tom_itx: yes, to edit the .glade / .ui files in linuxcnc requires a different version of glade than is packaged in debian 7
[18:43:10] <jepler> after I did some research, seb_kuzminsky built a version that does work, porting it from ubuntu 14.04 to debian 7
[18:43:20] <Tom_itx> oh nice
[18:43:57] <Tom_itx> i'm not a glade user either but i did follow jt's tutorials on it
[18:44:42] <jepler> but probably the people who are working on the gtk stuff in linuxcnc should take a look at "modernizing" our stuff so that 2.7 ends up compatible with current gtk when it (2.7) comes out ... apparently gtk 3 is quite different than gtk 2 and they don't care to maintain their backwards incompatibility forever
[18:45:51] <Tom_itx> i gathered that from earlier posts
[18:50:51] <PCW> Ha found an extra packet from hm2_eth (with a scope of all things)
[19:31:42] <PCW> hmm wonder if the wd patch got lost somehow
[19:42:31] <PCW> because the rogue packet is a wd clear command:
[19:42:33] <PCW> 17:14:38.678630 IP 10.10.10.1.53162 > 10.10.10.10.27181: UDP, length 8: 81c2 000e 0000 005a
[21:15:05] <jepler> pcw_home: I saw the same thing, that there are 4 packets per servo cycle.
[21:15:17] <jepler> pcw_home: but I'm not sure whether I ever tcpdump'd a version where there were just 3 or not
[21:15:22] <jepler> i.e., is it my fault that this happened
[21:15:35] <jepler> I'll try to look this weekend, maybe micges can too
[22:06:31] <pcw_home> I dont know if it was ever verified as fixed. Ill talk to Michael tommorow
[22:08:46] <ssi> pcw_home: you see my comments in other channel about hm2's stepgen position?
[22:09:15] <ssi> if I need faster updates for the raster engraving, is there any value to giving hm2 an optional function to update stepper positions on a faster thread?
[22:09:50] <pcw_home> how fast? maybe just a faster servo thread is good enough
[22:10:25] <ssi> I don't know what's required... I'm going based on someone else's work for raster engraving in linuxcnc, and they're using a 27us base thread for the laser updates
[22:10:34] <ssi> er, 27ns I guess?
[22:10:47] <ssi> BASE_PERIOD = 27000
[22:10:53] <pcw_home> nah must be usec
[22:11:11] <ssi> whatever it is... it's much much faster than servo-thread :)
[22:11:33] <pcw_home> 27 usechow fast can your laser turn on and off
[22:11:47] <ssi> I dunno... I guess I need to do the math;
[22:11:54] <ssi> the X will be scanning at 1200ipm
[22:12:07] <ssi> so I guess a 1ms servo period will give me some minimum dpi resolution
[22:12:36] <ssi> 50 dpi?
[22:12:47] <pcw_home> 20 mil dot size
[22:12:54] <ssi> thats pretty coarse
[22:13:21] <pcw_home> at 4 KHz thats 5 mil, probably smaller than your spot
[22:13:41] <ssi> spot is roughly 100 micron
[22:13:53] <ssi> whcih is about 4mil
[22:14:03] <ssi> yeah 4 or 5khz might work
[22:14:36] <pcw_home> the laser/PS may not modulate that fast either
[22:16:48] <ssi> there's a lot of magic going into this raster engraving stuff... it's going to be tough to troubleshoot
[22:17:22] <pcw_home> If you needed to go really fast (say a diode laser that you can modulate into the MHz)
[22:17:23] <pcw_home> I could have a FPGA FIFO that gets clocked out at some rate multiplied version of the stepgen output
[22:17:58] <pcw_home> (with start and stop position count enables)
[22:19:00] <pcw_home> (ive already played with some similar designs for "painting" applications with encoder inputs
[22:19:47] <ssi> I'll start with a 5khz servo thread and see how that goes
