Back
[00:40:48] <tjtr33> i had no luck with patch, so manually patched, cfgd , make , setuid all ok. then ran new linuxcnc w stepper_mm ok
[00:42:51] <tjtr33> when a 2nd terminal had its enc setup, and i ran usrmot -ini stepper_mm.ini, usrmot ran,
[00:42:57] <tjtr33> but, the simple cmd 'coord' gave me "USRMOT: ERROR: command timeout"
[00:44:47] <tjtr33> doh! didnt have linuxcnc co-existant, cmd 'coord' ok now
[00:47:07] <tjtr33> DAYUM it moves! thx!
[00:49:42] <tjtr33> you had suggested using a python scripts as DISPLAY, or linuxcncrsh, instead of usrmot.
[00:50:12] <tjtr33> when you're about, I'd like to hear why. (whats the difference)
[00:50:15] <tjtr33> and what you'd like done with the usrmot code
[00:50:18] <tjtr33> thx again
[00:50:24] <tjtr33> gnite
[01:04:59] <tjtr33> woot! i can program 3d lines, arcs, even helixes this way cool! (and they move the right way AND i can abort at anytime happy happy!)
[01:10:28] <tjtr33> usrmot lines and spirals and aborts
http://imagebin.ca/v/1Zb0WQECTHDF
[01:12:00] <seb_kuzminsky> zq: that's usually done with halui
[01:12:07] <seb_kuzminsky> http://www.linuxcnc.org/docs/2.6/html/man/man1/halui.1.html
[01:12:15] <seb_kuzminsky> look at the 'jog' pins
[02:54:12] <seb_kuzminsky> gin
[02:54:20] <seb_kuzminsky> err
[10:08:12] <tjtr33> jepler, re: usrmot thx for the patch and recent list mail. will look into "python's emcmodule and emcrsh"
[10:10:25] <jepler> tjtr33: I went into more detail about why I am uneasy about usrmot at the bottom of this mailing list message:
http://mid.gmane.org/20140901122011.GC13331%40unpythonic.net
[10:10:50] <jepler> tjtr33: I'm unsure why my patch wouldn't have applied.
[10:11:50] <tjtr33> np, and yes I read that, thx, _but_ its "linuxcnc" module hehe
[10:12:04] <jepler> oops yeah
[10:12:04] <tjtr33> will read up thx
[10:13:00] <jepler> anyway, that post lays out why I would rather see usrmot stay dead and buried. but if there's an active maintainer of usrmot and some automated tests that allow us to have some confidence it keeps working, my other objections are less important.
[10:14:21] <tjtr33> i understand, i can use other means to same end, usrmot is not necc, and it took me a week to suss it out, so i wouldnt vote for me as maintainer.
[10:14:25] <seb_kuzminsky> i can think of two uses for a tool like usrmot
[10:14:40] <tjtr33> tho i will test out linuxcnc pythin to nml now
[10:14:53] <seb_kuzminsky> one is to test motion and the other realtime parts without bringing up task and all the other non-rt parts
[10:15:19] <seb_kuzminsky> the other is if we wanted to move the realtime stuff to a different computer than the gui/interp parts
[10:15:34] <seb_kuzminsky> maybe that's one reason: to test at the realtime/non-realtime interface
[10:16:46] <seb_kuzminsky> heh, the topic in #slic3r (a 3d-printer channel) is "There's no place like G28"
[10:25:49] <skunkworks__> seb_kuzminsky, some controls impliment g28 as a way to physically home the machine
[10:29:56] <seb_kuzminsky> it's a funny twist on the old "there's no place like 127.0.0.1"
[10:31:32] <archivist> I must try and get ##electronics to have there's no place like ohm
[10:32:25] <tjtr33> where is the source for the linuxcnc python module?
[10:32:26] <tjtr33> ( searching for this is hell, using the name "linuxcnc" is very annoying, know any file that wont show up in the search? )
[10:35:32] <seb_kuzminsky> tjtr33: it's src/emc/usr_intf/axis/extensions/emcmodule.cc
[10:35:37] <seb_kuzminsky> how's that for confusing?
[10:36:42] <tjtr33> really, now why didnt i gues that thx seb, i would _never_ have found that
[10:38:44] <seb_kuzminsky> it's quite nice and easy to use, for some inspiration (i won't call them examples), look at tests/toolchanger/m61/test-ui.py
[10:40:36] <tjtr33> I'll look at the xmpls, thx. i hope to find 'n n n' a cmd for a destination to nml, and 'a' cmd to say 'forgetaboutit' <<< thats the beauty to me of usrmot
[10:44:17] <seb_kuzminsky> tjtr33: for going to a destination from python, i'd use mdi and "G0 X Y Z" (the m61 test does a bunch of mdi calls, not sure if any of them are G0 but the same principle applies
[10:44:59] <seb_kuzminsky> for the forgeddaboutit, try the abort() function
[10:45:22] <tjtr33> i need to move the machine into position with linuxcnc, then control position with analog process voltage in EDM ( using nml ) then return to next position with linuxcnc ( rinse repeat )
[10:45:37] <tjtr33> so i think using mdi is out ( im in run mode )
[10:46:04] <tjtr33> let me study a while () you guys ar etoo fast for me :)
[10:46:39] <seb_kuzminsky> moving into the first position and moving to the next position sound like good uses of the python ui module (emcmodule)
[10:47:24] <seb_kuzminsky> for the "control position with analog voltage", do you mean you want to read some process variables from your machine and have those automatically control motion? if so, that sounds like a good thing to use hal for
[10:48:19] <seb_kuzminsky> you could maybe have your python program go to the next place, then throw a switch in hal to change the source of the motion commands from the linuxcnc motion planner to some hal circuitry controlled by your process variables
[10:51:21] <tjtr33> edm motion depends on an analog voltage drop between tool and wkpc. Voltage difference to a setpoint determines direction and velocity along edm path. edm path ( traj) will be figured out in python.
[10:53:17] <tjtr33> simplest motions would occur between start pose and end pose. if the the proces voltage made the tool sit at start pose for long, I'd abort the whoel pgm ( retreated and nowhere to run ). else I'd eventually advance till the final pose was achievd, then would return control to std linuxcnc poath control ( or be all done )
[10:55:52] <tjtr33> in between the process can advance or retract as it needs to , following the vector, but maintaining the correct tool to wkpc 'gap' (maintiaining the voltage difference )
[10:56:09] <tjtr33> thx, lots to read in this module
[11:00:38] <Roguish_> hey, quick question, please. has the hybrid iso been updated to the 2.6.3 ???
[11:02:46] <jepler> Roguish_: no. use the regular update process to get the current package version
[11:03:46] <Roguish_> ok, thanks. i have an associate that want to try it out, because he has some clients that are requiring linuxcnc.
[11:19:09] <jepler> if you're connected on a network you can even do the update while running from the live cd
[11:19:27] <jepler> but only a few minor bugs have been fixed since the last spin of the live cd, so I say go for it
[11:22:02] <Roguish_> yes. that's what i just passed on. my buddy is sorta contrary to open source, but he's being pushed by his clients. heh, heh, heh.
[12:29:08] <skunkworks__> Roguish_, waiting for mach4 is he?
[12:29:56] <archivist> a long wait
[12:33:15] <seb_kuzminsky> not that our 2.6 release was exactly quick...
[12:34:40] <archivist> but like London buses then three come all at once :)
[12:35:38] <seb_kuzminsky> once the .0 is done, the .$((N+1)) ones are all easy
[13:44:17] <skunkworks> why oh why....
http://www.cnczone.com/forums/viper-servo-drives/238848-looking-testers-new-quot-step2linear-quot-step.html
[13:49:57] <skunkworks> $89 * 3 axis > mesa 5i25+7i77 with much more functionallity....
[13:52:26] <jepler> it should be possible to write an FPGA firmware for 7i90+7i77 that acts like a parport and does analog closed loop when driven with stepper signals
[13:52:35] <jepler> you can sell that to all the mach users
[13:53:03] <jepler> and if you choose to use it under the bsd-style license, you don't even have to give away your enhancements even if you start with parts of hostmot2
[13:55:12] <skunkworks> that just seems wrong
[14:01:52] <jepler> neat, with a clever board design you can do .050" pitch pogo pins on two sides of a (.6mm) PCB.
https://www.tindie.com/products/madworm/tiny-avr-isp-pogo-pin-programmig-adapter/
[14:22:32] <jepler> i
[15:10:54] <PCW> People ask us regularly for step/dir --> analog but I have resisted so far
[15:12:11] <jepler> I'm not surprised (on both counts)
[15:13:37] <PCW> Pretty sure I can get about 50 KHz update rate for 4 channels using a
[15:13:39] <PCW> XC6SLX9 with B32 running at 100 MHz and HostMot2 peripherals
[15:13:40] <PCW> Getting good encoder velocity with no floating point will be a bit of a pain
[15:13:42] <PCW> but a simple hardware 64/32 divide at 100 MHz clock is only 330 ns
[15:14:31] <jepler> can you get a reciprocal operation from the DSP blocks?
[15:14:55] <PCW> probably
[15:15:01] <jepler> based on some of the products I know are out there, I'm questioning whether you need a 32-bit precise velocity calculation
[15:15:22] <jepler> telling features like "signals a fault at +-127 count error"
[15:16:19] <PCW> Well we would allow better tuning that the one hopes...
[15:16:29] <PCW> than that
[15:17:04] <PCW> a reciprocal table may be enough
[15:18:35] <PCW> the shidt/subtract divider is not very big either
[15:19:10] <skunkworks> http://032c30a.netsolhost.com/catalog/product_info.php/cPath/36/products_id/56/osCsid/1996e07552d67ed4b57ae5c31c391cb8
[15:19:48] <jepler> I wonder whether linuxcnc customers or m--h customers are higher maintainance for a hardware vendoir
[15:20:02] <jepler> -i
[15:20:54] <skunkworks> len shelton says linuxcnc is way easier to support
[15:21:19] <skunkworks> (although I think he is moving to machine kit for the beagle bone stuff)
[15:21:32] <PCW> I suspect LinuxCNC filters out a lot of customer I wouldn't want
[15:21:40] <PCW> customers
[15:22:06] <skunkworks> heh
[15:22:07] <skunkworks> bbl
[15:35:01] <PCW> Hmm the 7I80 need the Cyclon LED option
[15:42:27] <PCW> well PIN_7I76x2_7I77x2_68 does fit in the -16 chip if you fix the dumb-o in the pinout file (10 is not x"10" )
[15:49:39] <jepler> PCW: it has 16 stepgens when it should have had ten?
[15:49:51] <PCW> yep
[15:50:37] <PCW> trying to squeeze in the DPLL option...
[15:50:52] <jepler> is MuxedQcountTag right at x"10"?
[15:51:04] <jepler> 00..07 on the pins, times two?
[15:51:08] <PCW> yes
[15:53:56] <seb_kuzminsky> looks interesting:
http://linuxgizmos.com/linux-ready-modules-support-range-of-xilinx-fpgas/
[15:56:12] <skunkworks_> PCW, I have the 7i80 -16.. I could test the dpll also.
[16:06:53] <PCW> Ill have some configs with DPLL soon
[16:58:20] <PCW> so space 6 returns garbage?
[16:58:50] <PCW> oops
[17:25:22] <jepler> whee I read hmid over spi
[17:25:28] <jepler> in mesaflash
[17:28:52] <micges-dev> that's great!
[17:58:29] <jepler> PCW: when trying to verify a flash, I get "Error: BootSector is invalid". and indeed it does read something different than it expects ..
http://paste.debian.net/119971/
[17:58:50] <jepler> PCW: but I programmed a firmware and it does boot with a different hmid now so I think that's working
[17:59:28] <Tom_itx> wrong boot offset address?
[17:59:40] <Tom_itx> word vs byte?
[18:00:08] <jepler> I think the boot is at the very start of the eeprom
[18:00:26] <Tom_itx> i know on an avr it gets moved from 0x00
[18:00:45] <Tom_itx> and is specified with fuse bits to the location and size
[18:01:01] <PCW> boot is first 64 bytes of EEPROM
[18:01:06] <jepler> hmm
[18:01:08] <jepler> write says:
[18:01:08] <jepler> Erasing sector 0 for boot block
[18:01:08] <jepler> BootBlock installed
[18:01:26] <Tom_itx> PCW is it usually a jmp to somewhere else?
[18:01:44] <jepler> but on the next run it still calls the boot block incorrect
[18:02:24] <PCW> sounds like it cant read it correctly (or cant write it at all)
[18:02:54] <jepler> I've definitely successfully written and then booted two different bitfiles
[18:04:04] <PCW> well its more important that writes work :-)
[18:04:41] <jepler> without this fixed, verify refuses to verify anything
[18:05:02] <micges-dev> jepler: show me code
[18:05:29] <jepler> micges-dev: I'll push to a branch on gh, give me 5
[18:05:42] <micges-dev> ok
[18:09:47] <jepler> oh I think I know the problem
[18:10:22] <jepler> I had board.flash_start_address 0, so everytime I wrote my fpga config I was overwriting the boot sector and the fallback configuration. oops!
[18:13:16] <jepler> PCW: which bitfile should I program to the fallback area?
[18:13:36] <PCW> any one will work
[18:13:49] <jepler> but you were saying that there's one that's supposed to blink an LED
[18:14:19] <PCW> the distributed fallback config has the blinky light enabled
[18:14:31] <jepler> but none of the bitfiles in 7i90.zip?
[18:15:48] <jepler> OK
[18:15:51] <jepler> I think it works now :)
[18:16:20] <PCW> I guess we never expected anyone to break one
[18:19:15] <jepler> A verify takes 90 seconds. is that typical, or do I have some optimization to do?
[18:21:52] <micges-dev> much too long
[18:22:08] <jepler> I thought so
[18:22:48] <jepler> writing is just 19s
[18:23:02] <micges-dev> it's about 30 sec even on 6i25 recovery write via bridge gpio
[18:23:13] <micges-dev> or verify
[18:23:35] <jepler> OK, pull request on GH, in case you find that a useful place to discuss proposed changes
[18:23:38] <jepler> time to make dinner here
[18:24:30] <micges-dev> thanks
[18:24:48] <jepler> thank you
[18:38:51] <micges-dev> jepler: yeah verify reads byte at once, need to be optimized for burst read
[19:10:32] <jepler> OK, a fairly simple change brings that down to 20s, about in line with program
[19:13:27] <PCW> I think the 7I80 has the fastest verify
[19:14:04] <jepler> in theory, should I be able to do a block read with a non-incrementing read of the spi data register?
[19:14:31] <PCW> yes except the the register is only 8 bits wide
[19:14:39] <jepler> so I take only 8 bits out of every 32?
[19:15:17] <PCW> well the internal SPI hardware is really stupid just a shift register basically
[19:15:55] <PCW> and it needs polling (well maybe not at reasonable SPI speeds)
[19:16:11] <jepler> yes I see there's wait_for_data_hm2
[19:16:37] <PCW> I guess i could be set faster (I think its 12.5 MHz) probably could be 25 MHz at least
[19:17:14] <jepler> Since I didn't want to add rate selection to mesaflash, I am talking at what I feel is a conservative rate, 8MHz
[19:18:05] <PCW> which means you should never need to wait on SPI
[19:18:49] <jepler> hm the layers don't facilitate me sending a non-incrementing read op
[19:32:39] <mozmck> huh, Xilinx doesn't give you many options or guarantees about webtalk if you use ISE WEBPACK
[19:35:58] <KimK> I missed this when it first appeared, maybe others missed it too? "...Ubuntu MATE [MAH-tay] is on the path to become the latest addition to the family of official Ubuntu flavours..." (AKA, The return of the classic interface!)
http://distrowatch.com/weekly.php?issue=20140825#news Maybe by 16.04 LTS it'll be all settled in.
[19:36:54] <mozmck> Interesting. I like XFCE pretty well, and Cinnamon, but haven't tried MATE
[20:04:48] <jepler> got write to run in ~8s, verify in ~6s, so 3x better
[20:05:40] <jepler> doesn't work if I increase U3 <=> 7i90 SPI speed from 8MHz to 24MHz
[20:06:09] <jepler> layer violations galore
[20:12:42] <jepler> probably it's not worth doing, I'm unlikely to program eeproms over SPI enough times in the rest of my life to make a profit on the 10s I get back on each run
[20:13:46] <PCW> Not something you typically do a lot
[20:15:16] <PCW> I mean I can make a 32 bit SPI interface with FIFO but its a fair amount of hardware that may only be used about 5 times total
[20:18:13] <PCW> the Ethernet one is fast because the processor hides the details so you can just
[20:18:14] <PCW> send a command to read the next 256 doublewords from the flash
[20:20:09] <jepler> yeah from the POV of mesaflash that sounds simply luxurious
[20:20:47] <jepler> I guess I should do what I came to do, which is to see whether my self-built (hostmot2-firmware) 7i90spi firmware works
[20:21:22] <PCW> just now building the fallback configs
[20:24:15] <jepler> well that was anticlimactic. but yay, that's two cards (7i80, 7i90spi) confirmed to work with images built by hostmot2-firmware
[20:26:11] <PCW> freeby.mesanet.com/7i90fallbacks.zip
[20:26:33] <PCW> in case you dont want to futz around building them
[20:27:12] <jepler> so I just did this:
[20:27:12] <jepler> ./mesaflash --device 7I90 --addr /dev/spidev1.0 --spi --verbose --write 7i90_spi_fallback.bit --fallback
[20:27:43] <jepler> in theory if I now do a --write (no --fallback) and interrupt it (ctrl-c) it'll boot to the fallback, which will have SPI, and I'll be able to tell from a blinking LED?
[20:28:13] <PCW> yes
[20:28:40] <PCW> you can also just write the fallback in the normal place to check blinkyness
[20:28:50] <jepler> init blinks
[20:29:06] <jepler> hmid reads as justio
[20:29:17] <jepler> or whatever you call it
[20:29:39] <PCW> and the latest SPI configs have ICAP so it should be possible to start a reconfig at any address
[20:30:39] <jepler> the odroid's fan control really needs more hysteresis
[20:30:54] <jepler> it tends to come on for just a few seconds at a time
[20:31:04] <jepler> .. but sometimes multiple times a minute
[20:31:05] <PCW> no speed control?
[20:31:31] <jepler> it has speed control, a PWM register with 128 (?) levels; the fan actually starts rotating at fan duty 48
[20:32:05] <jepler> It's partially my fault, as I tweaked the starting temperature and duty to be lower; the default is nothing until the fan comes on loud
[20:33:19] <jepler> though the cycles might be even faster if the fan comes on harder
[20:34:14] <PCW> yeah so even with proportional control it maybe hard to make it stable
[20:35:12] <jepler> I don't even know if start-stop cycles are harmful for computer fans
[20:35:46] <PCW> Dont know either
[20:37:29] <PCW> Its amazing you got the muddled mess that is hm2 firmware to compile on the buildbot
[20:37:31] <jepler> I can tune it to stay on all the time
[20:38:27] <jepler> PCW: I write software build systems for fun, apparently.
[20:38:43] <PCW> funny idea of fun
[20:38:57] <PCW> bbiab
[20:39:02] <jepler> see ya
[20:40:49] <jepler> anyway, don't sell yourself short on the structure of hm2. figuring out the damned build flags is not a great deal of fun, but your parts mix and match well (but it's no surprise, that's important to what hm2 *is*)
[20:41:39] <jepler> but yes, I take some pride in only having to use the recovery eeprom once in my adventure this past week