#linuxcnc-devel | Logs for 2014-08-25

Back
[01:39:26] <cmorley> pcw_home. i updated the 5i25 (the program said successful) cycled the power. still says version 33. I got the download from the forum. Is there an old and new version?
[01:40:14] <cmorley> used this instructions: http://linuxcnc.org/hardy/lucid/index.php/italian/forum/27-driver-boards/26618-5i25-with-7i76-not-responding-correctly?start=20
[01:40:54] <cmorley> i'll check tomorrow for suggestions. night
[09:37:10] <cradek> last night (on my 5i25 machine) I was seeing occasional single steps on Z when Z shouldn't have been moving. I think it was moving back and forth.
[09:37:50] <cradek> the error did not accumulate (it was cutting for about an hour)
[09:38:20] <cradek> ... so of course I didn't study the problem
[09:39:05] <pcw_home> I think thats a bug in the driver (which is hidden by higher ustep ratios)
[09:40:27] <cradek> yeah this machine is half-stepping, so every step causes some motion I can see
[09:42:09] <pcw_home> The driver has enough bugs and is so fragile with regard to jitter,
[09:42:11] <pcw_home> that I think its better to just abandon the built in position mode
[09:42:12] <pcw_home> and run velocity mode in a PID loop
[09:42:43] <cradek> is there a certain pid setting that works without fiddling?
[09:42:51] <pcw_home> Yes
[09:43:14] <cradek> so we could just change the hm2-stepper sample config (and pncconf?)
[09:43:27] <cradek> and by we, I might mean you :-)
[09:43:44] <skunkworks> I think the new pncconf uses pid - atleast it is talked about
[09:43:48] <pcw_home> pncconf has already been changed AFAIK
[09:43:49] <cradek> I used the hm2-stepper sample to set mine up
[09:43:58] <cradek> aha! then the hard part is done
[09:47:37] <pcw_home> the dithering in the current code could probably be fixed also, basically a error deadzone where the velocity is set to 0
[09:48:33] <pcw_home> (I think theres some thats supposed to do this already, not sure why it doesnt work)
[09:53:07] <pcw_home> s/some/something/
[10:04:35] <kwallace> I'm doing some planning on how to work on my caliper output. It looks like the calipers output BCD and I'll need to convert the 1.5V signals to something usable -- op amp maybe?. I'll need an analyzer of some type too. Any hints?
[10:06:24] <pcw_home> a comparator (lm393 or some such) is probably the thing but beware positive GND on some calipers
[10:09:37] <kwallace> I've never played with op-amps or comparators, so I suppose I'll need to order extras.
[10:10:29] <pcw_home> they are cheap
[10:13:48] <pcw_home> another possibility is a line receiver (like 26ls32) with one input tied to halfway up (0.75V)
[10:14:24] <kwallace> It looks like the LM393 only sinks. Should I consider a push-pull device?
[10:16:38] <pcw_home> sure but make sure the Batery + is not GNDed or you have an interesting level shifting problem
[10:18:47] <pcw_home> the 26LS32 (or CMOS equiv) has the advantage of negative common mode range with single +5V power
[10:19:42] <kwallace2> Damn, my ISP logs me off just before 8:00 every morning.
[10:28:49] <pcw_home> thats nice of them
[10:31:28] <kwallace2> It sort of is since they do this to change the rate they charge for peak time periods. It seems there should be a better way to do it though.
[10:34:15] <kwallace2> I'm guessing I could use HALscope to get traces, and write a component to capture bits on a signal edge.
[10:36:45] <seb_kuzminsky> good morning friends
[10:37:32] <cradek> hello
[10:38:09] <kwallace2> Another project -- I have a bunch of 300 Watt 27 Volt telecom power supplies I need to find a use for.
[10:38:25] <skunkworks> kwallace2, did you see my comment about smithy doing something similar.. I tried to look through their configs but could not find an example.. (using a digital caliper for measuring something in hal)
[10:38:38] <skunkworks> you might want to ping matt
[10:43:21] <kwallace2> skunkworks, yeah I didn't find anything in the Smithy files. I'm tending to not use the calipers with LinuxCNC because the update rate is so slow. My concern is to figure out how they work and maybe use a tiny AVR and generic LCD display to replace the proprietary display.
[10:43:54] <skunkworks> ah
[10:47:04] <seb_kuzminsky> lol @ cmorley's url
[10:47:40] <seb_kuzminsky> err, i guess i've not been paying enough attention, is there a bug in the hm2 stepgen driver that i should know about?
[10:48:09] <kwallace2> After looking at the lot a little more, it looks like most of the LCD's are intact but the top windows are cracked. I contacted General to see it I could order new windows but they don't supply parts.
[10:49:02] <kwallace2> I'm also looking at making the glass windows from thin sheet stock.
[10:50:24] <pcw_home> seb_kuzminsky: cradek found an issue with step/dir dithering about when stopped
[10:50:42] <seb_kuzminsky> pcw_home: whoops
[10:52:03] <cradek> I would put a picture of what I made on my website, but I'd need to tape close-up lenses to my phone
[10:53:06] <kwallace2> I thought you had a real camera.
[10:53:29] <cradek> not really...
[10:56:20] <seb_kuzminsky> linuxcnc-build: force build --branch=jepler/master-proposed 0000.checkin
[10:56:21] <linuxcnc-build> build forced [ETA 1h00m25s]
[10:56:21] <linuxcnc-build> I'll give a shout when the build finishes
[10:56:23] <linuxcnc-build> build #2366 of 0000.checkin is complete: Failure [4failed fetch branch to local git repo] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2366
[10:57:04] <seb_kuzminsky> did i misspell the branch name?
[10:57:23] <seb_kuzminsky> linuxcnc-build: force build --branch=jepler/proposed-master 0000.checkin
[10:57:24] <linuxcnc-build> build forced [ETA 1h00m25s]
[10:57:24] <linuxcnc-build> I'll give a shout when the build finishes
[10:59:29] <skunkworks> cradek, can you describe it? :)\
[11:07:30] <kwallace2> Has anyone machined glass sheet?
[11:07:41] <seb_kuzminsky> i used the stereo microscope at the hackspace the other night, it's so much better than my $10 radioshack loupe
[11:08:23] <seb_kuzminsky> kwallace2: i have not, but ben krasnow has: http://benkrasnow.blogspot.com/2011/08/cnc-milling-glass-plates-and-mirrors.html
[11:08:32] <cradek> seb_kuzminsky: yeah I have a nice stereo continuously-adjustable power one
[11:08:51] <seb_kuzminsky> cradek: so nice
[11:08:52] <cradek> it would be nice if it had a camera on it
[11:09:01] <seb_kuzminsky> can you strap your phone to the eye piece?
[11:09:11] <cradek> yes I have sort of accomplished that before
[11:09:42] <cradek> it would be too much power. I want to take a photo of something about 1" square
[11:10:01] <seb_kuzminsky> a friend has a hologram picture on their wall of a microscope, and if you look at it from the right angle you can look down the eye piece and see a magnified mosquito
[11:10:07] <seb_kuzminsky> it's pretty mind-blowing
[11:10:20] <seb_kuzminsky> what did you make?
[11:10:37] <cradek> I engraved a pendant (jewelry)
[11:10:53] <seb_kuzminsky> cool!
[11:11:16] <cradek> well I have a bad photo to share
[11:22:20] <cradek> http://timeguy.com/cradek/01408982148
[11:22:58] <skunkworks> cradek, wow - very neat
[11:23:00] <jepler> cradek: want me to come by with my macro lens to make a better photo?
[11:23:05] <jepler> cradek: where'd the artwork come from?
[11:23:07] <jepler> just internet?
[11:23:14] <cradek> yeah, the artwork was for some guy's tattoo
[11:23:36] <skunkworks> cradek, are you running master?
[11:23:56] <cradek> skunkworks: nope, that was 2.6.2
[11:24:00] <skunkworks> ah
[11:24:27] <cradek> jepler: hey that would be great. I'll replace the photo then.
[11:25:00] <cradek> or I could just try a +4d or so lens in front of my phone
[11:25:30] <jepler> what I'd like to do in glass is stippler-type images http://emergent.unpythonic.net/01108611472
[11:26:26] <cradek> I bet you could do that pretty easily with the glass underwater or under light oil
[11:33:07] <jepler> his ideas for securing the glass could be useful
[11:33:14] <cradek> whose?
[11:33:24] <jepler> from the video at http://benkrasnow.blogspot.com/2011/08/cnc-milling-glass-plates-and-mirrors.html
[11:33:48] <seb_kuzminsky> cradek: that looks great
[11:33:49] <cradek> ah I missed that
[11:33:55] <jepler> you'd just need to be able to place the top clamp in two spots
[11:34:04] <jepler> cradek: that's why glass was on my mind at the moment
[11:37:30] <cradek> wow that's a bridgeport. you'd think you'd want a much faster spindle than that 3-4k
[11:38:14] <cradek> oh it's a boss8! that's very ... familiar
[11:39:27] <cradek> a commenter suggests he take the servos off and replace them with steppers to be more "modern"
[11:39:38] <cradek> *sigh*
[11:42:35] <seb_kuzminsky> another commenter suggests he upgrade to linuxcnc ;-)
[11:43:26] <cradek> yeah he should (if he needs contouring or more than 100 feet of ram)
[11:44:04] <jepler> OSH Park - Order #KS9Ag4nN sent to fab.
[11:44:13] <cradek> but keep the amps and encoders and motors that have worked great for 30 years, of course
[11:54:29] <kwallace2> This is the glass part I need: http://wallacecompany.com/tmp/IMG_2165-1a.jpg
[11:54:57] <linuxcnc-build> Hey! build 0000.checkin #2367 is complete: Success [3build successful]
[11:54:57] <linuxcnc-build> Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2367
[12:17:45] <kwallace2> BTW, the latest on my board tester: http://wallacecompany.com/tmp/Screenshot-lbt3_ui.png
[12:31:20] <seb_kuzminsky> hrm, the hostmot2 firmware debs dont get auto-installed when you install linuxcnc
[12:31:37] <seb_kuzminsky> because linuxnc Recommends hostmot2-firmware, but the package is called "hostmot2-firmware-all"
[12:31:41] <seb_kuzminsky> i thought we fixed that?
[12:31:43] <seb_kuzminsky> guess not
[13:25:44] <seb_kuzminsky> pull request sent, did i do it right?
[13:31:16] <jepler> seb_kuzminsky: looks like
[13:32:29] <cradek> 340 files changed, 230406 insertions(+), 7991 deletions(-)
[13:32:34] <cradek> uh ok, I doubt I did that right
[13:32:47] <cradek> I guess I have to guess more carefully what branch yours is based on
[13:33:16] <jepler> so I had to figure out this incantation: git remote add seb-gh https://github.com/sebkuzminsky/linuxcnc-mirror
[13:33:28] <cradek> I did what it said in the email
[13:33:44] <jepler> then while on master branch I
[13:33:45] <jepler> $ git merge seb-gh/seb/master/fix-recommends-hm2
[13:33:51] <jepler> 2 files changed, 2 insertions(+), 3 deletions(-)
[13:33:55] <jepler> this seems plausible
[13:34:08] <cradek> yeah
[13:34:20] <cradek> once I did what the email said while on master, it was fine
[13:37:38] <jepler> it might be better workflow to do the merge with --no-ff, so that the identity of the person who merged the pull request is preserved.
[13:38:48] <jepler> huh, there's no "git merge --signed-off-by"?
[13:44:34] <seb_kuzminsky> whoops, i messed up
[13:44:41] <seb_kuzminsky> that should probably go in 2.6
[13:44:54] <cradek> the non-uspace parts
[13:47:37] <seb_kuzminsky> yeah
[13:48:25] <seb_kuzminsky> heh, the merge of the 2.6 version into master wont work at all
[13:49:04] <jepler> this is a bad test case
[13:56:17] <seb_kuzminsky> ok, there's the ridiculous 1-line PR, with the correct dest branch this time
[13:56:47] <seb_kuzminsky> i'd be happy to do the merge to master afterward if you like
[14:00:36] <seb_kuzminsky> jepler: you know this already, but you could 'git merge --no-commit && git commit -s'
[14:09:30] <jepler> seb_kuzminsky: $ git merge --no-ff --no-commit seb-gh/seb/2.6/fix-recommends-hm2 && git commit -s
[14:09:36] <jepler> want me to push it?
[14:09:39] <jepler> I mean, you must, right?
[14:10:50] <jepler> ugh, the merges created by "git pull" won't be signed off either
[14:10:59] <jepler> lots of people prefer to work by doing a "git pull" every 5 minutes
[14:11:15] <jepler> there'll be some reeducation, but it'll be for the best
[14:12:32] <KGB-linuxcnc> 03Jeff Epler 052.6 d49f698 06linuxcnc Merge remote-tracking branch 'seb-gh/seb/2.6/fix-recommends-hm2' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d49f698
[14:14:43] <KGB-linuxcnc> 03Jeff Epler 05master fd6704b 06linuxcnc 10debian/configure Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fd6704b
[14:16:13] <jepler> yay, as promised the pull request was automatically closed on github
[14:19:02] <cradek> neat
[14:19:12] <seb_kuzminsky> great
[14:20:34] <seb_kuzminsky> github told me my branch had been merged and presented a big button that said "delete merged branch"
[14:20:37] <seb_kuzminsky> so that's nice too
[14:27:35] <cradek> does it have "delete the now-useless clone I made for that one patch"?
[14:36:36] <seb_kuzminsky> that operation is manual
[14:37:01] <seb_kuzminsky> it'd be more useful for me personally if i could make pull requests from non-github repos
[14:37:30] <cradek> well you can send an email
[14:37:45] <jepler> seb_kuzminsky: write yourself a script that (A) pushes to your github repo and (B) uses the github API to create a pull request
[14:38:08] <jepler> but you .. you can just engage willy-nilly mode and merge master into 2.6 by accident and push the result without checking
[14:38:32] <cradek> jepler: that's a trade secret
[14:38:42] <jepler> cradek: oops
[14:40:15] <seb_kuzminsky> then finally we'd have the new tp in 2.6
[14:40:41] <cradek> oh you guys
[14:51:24] <skunkworks> It isn't in 2.6?
[14:51:28] <skunkworks> ;)
[14:54:01] <seb_kuzminsky> no, but for you i made a special branch that has it, only you can check it out, it's called master
[14:55:45] <skunkworks> That is sweet!
[14:55:48] <skunkworks> wait
[14:56:15] <seb_kuzminsky> :-)
[16:51:19] <jepler> PCW: 7i90 in hand. too bad the other parts of my little project are in shambles.
[16:51:55] <PCW> need to pull the female connector on the Odroid?
[16:52:08] <seb_kuzminsky> jepler: did you see this? http://forum.odroid.com/viewtopic.php?f=80&t=5702
[16:52:23] <jepler> seb_kuzminsky: yes
[16:53:23] <jepler> PCW: days before the female connector replacements come, and up to two weeks for the new board with proper mounting provision to be fabbed and shipped.
[16:53:47] <jepler> seb_kuzminsky: unfortunately spi-s3c64xx + spidev have lousy RT performance on my preempt-rt kernel
[16:54:08] <jepler> seb_kuzminsky: a kernel that will go a day without a latency over 40us will get 3ms latencies using /dev/spidev in under a minute
[16:54:19] <seb_kuzminsky> crikey
[16:54:51] <jepler> seb_kuzminsky: I haven't gotten around to finding just where the suck is in the kernel side of things, because it should be so effing simple
[16:55:30] <jepler> even apart from the hostmot2 driver, just trying to talk a little on /dev/spidev from a realtime thread shows the problem. http://emergent.unpythonic.net/files/sandbox/spidev.comp
[16:55:47] <seb_kuzminsky> gotcha
[16:55:47] <jepler> the guts being the basic ioctl for an spi transaction: return ioctl(dev->fd, SPI_IOC_MESSAGE(1), &t);
[16:55:57] <PCW> primary config on 7I90 is SPI secondary is EPP (all fallbacks are EPP)
[16:55:59] <jepler> so .. register level programming from userspace, here I come
[16:56:47] <jepler> making for a much less generic driver than I'd originally envisioned
[16:56:50] <PCW> I wonder if the SPI stuff is ARM boilerplate or if every one is different...
[16:57:23] <jepler> PCW: somewhere in between, I think. spi-s3c64xx seems to work on a range of samsung cpus.
[16:58:27] <jepler> with minor variations like how the spi clock rate is chosen, size of fifos, etc
[16:59:16] <PCW> there will certainly be upstream clock tree differences
[16:59:45] <PCW> (with different SOCs)
[17:00:27] <jepler> in spidev, every ioctl SPI_IOC_MESSAGE calls kmalloc
[17:00:46] <seb_kuzminsky> lol
[17:01:22] <jepler> spidev is the character device driver which exposes a generic linux kernel spi device to userspace
[17:01:54] <jepler> I should figure out enough kernel tracing to find out just where in the kernel the latency comes from
[17:02:46] <jepler> large messages (above 127 bytes, I think) do memory allocation for dma inside of the device-specific spi part, which is another possible source of suck but not the one I think I'm hitting in my simplest test program
[17:04:56] <PCW> hmm the resolver code works better when RET returns to somewhere other than 0
[17:23:12] <jepler> hm, got rid of two per-ioctl memory allocations in spidev but that didn't help latency much
[17:24:27] <jepler> /* Acquire DMA channels */
[17:24:27] <jepler> while (!acquire_dma(sdd))
[17:24:27] <jepler> msleep(10);
[17:26:15] <PCW> I would hope it only uses that code if the driver needs DMA...
[17:26:29] <jepler> I'm not sure
[17:26:46] <jepler> but mostly the latencies I see are under 10ms so either it's not hitting that code path, or the dma's not actually contended
[17:28:22] <PCW> or acquire_dma takes too long
[17:28:33] <jepler> point taken
[17:30:01] <jepler> actually acquire_dma always succeeds unless something here's a dirty evil macro
[17:37:34] <jepler> the decision to acquire dma is made when "preparing" for a transfer. at this time, the transfer's size is unknown, so it can't make a choice bsaed on size of transfer vs hardware fifo size
[17:37:49] <jepler> in my device, the fifo is 32 bits x 64 depth
[17:38:05] <jepler> tempting to rip out dma just to see what happens
[17:39:52] <PCW> 64 deep is enough for any normal "run" of hostmot2 channels
[17:47:12] <jepler> still no good
[17:47:34] <jepler> so all the obvious allocations are gone, including clocks and dma
[17:48:21] <jepler> in the middle layer of spi, the fundamental operation is asynchronous, and the "spi_sync" operation is synthesized from spi_async_locked + wait_for_completion
[17:48:55] <jepler> but it seems like the same's likely to be true of, say, ethernet and that works fine
[17:50:23] <jepler> as someone else pointed out, rpi people also have trouble with latency from the spi driver. http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=19489&start=50 -- I think somebody else linked to this thread
[17:52:06] <PCW> I wonder if Ethernet drivers have had some rt optimizations and the SPI stuff has not even been looked at from a rt perspective
[17:52:17] <jepler> also quite possible
[17:52:31] <PCW> (at least X86 Ethernet I mean)
[19:01:36] <jepler> hum I must not understand something about /dev/mem. I can read some plausible values from it (match power-on values from the datasheet), but write followed by readback doesn't work
[19:01:42] <jepler> probably something to do with cache
[19:41:40] <PCW> hardware registers?
[20:05:21] <jepler> PCW: yes, was starting to see if I can do pure userspace spi
[20:05:50] <jepler> pcw: must be the equivalent of MTRRs to poke, or at least that's one theory
[20:06:59] <jepler> others' examples didn't have anythingg like that, as far as I saw so far (for userspace gpio)
[20:07:14] <PCW> registers may well be "funny" (read only bits etc)
[21:00:12] <jepler> PCW: my datasheet shows the bits I've tried to tickle as R/W
[21:01:05] <jepler> a few registers, like the TX fifo register, are denoted W, so I assume they're making the usual distinction