Back
[10:21:12] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 7d84e80 06linuxcnc 10(20 files in 2 dirs) hm2 sample config: set HOME_SEQUENCE * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7d84e80
[10:21:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master ebedd0a 06linuxcnc Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ebedd0a
[10:21:52] <cradek> seb_kuzminsky: I hear the hm2-stepper configs should be using pid...
[10:22:19] <cradek> you touched 'em last
[10:43:46] <skunkworks_> your it!?
[10:43:51] <skunkworks_> you're
[11:46:00] <seb_kuzminsky> cradek: noted
[11:46:52] <cradek> thanks for doing that
[13:11:46] <kwallace1> Are there pogo pin sets for dual row headers or do I have to drill and set each one?
[13:32:28] <PCW_> I have an example pid stepper config
[13:32:29] <PCW_> the ini files will need to have the PID parameters added
[13:34:23] <cradek> if it doesn't need tuning (I hope it doesn't) we could just hide them in the hal file
[13:35:59] <PCW_> yeah FF1=1 P=100 FF2=.somethingreallysmalthat'snottooimportant
[13:37:49] <PCW_> oh and for Ethernet I set a small maxerror
[13:39:13] <PCW_> so for large latency spikes it switches to fixed slew correction rather than proportional
[13:41:25] <PCW_> ultimately for things with poor jitter I should add the option of DPLL sampling of the encoder and stepgen positions
[13:41:26] <PCW_> (as is already done for SISS, BISS and Fanuc encoders)
[13:42:31] <PCW_> sample say 50 usec before the DPLL read baseline
[13:48:04] <PCW_> kwallace1: I always just drilled out a blank PCBs for the pogo pin support
[13:48:06] <PCW_> (using 2 PCBs one with normal hole for the pogo tail and one (spaced away from the first)
[13:48:08] <PCW_> drilled out for the shaft
[13:48:18] <jepler> PCW_: is the widest freerunning counter on hm2 the 16-bit one that is used for encoder timestamping?
[13:48:57] <PCW_> the DPLL has a 32 bit non freerunning counter
[13:49:30] <PCW_> (that can be freerunning if the feedback gains are set to 0)
[13:49:49] <PCW_> also the stepgen is a 32 bit counter
[13:49:58] <jepler> ah that should have been obvious
[13:50:30] <jepler> I am thinking that since I trust hm2, I should repeatedly read a timestamp from it
[13:51:11] <PCW_> yeah there really should be a default timer
[13:51:16] <jepler> I mean, to confirm these large latencies I see from spidev transactions
[13:51:51] <jepler> I can set stepgen going at 1MHz, then do say 4 spidev transactions each reading the counter
[13:52:04] <jepler> if the counter difference is really big then I know I had a real latency
[13:52:12] <jepler> this is a testing thing, not an everyday thing
[13:52:18] <PCW_> Yep, actually 10 MHz is possible
[13:52:38] <PCW_> eventually I think the DPLL will be standard
[13:53:18] <PCW_> so latency relative to the baseline is always acquired
[13:54:56] <jepler> my latest results are that if I do CPU-bound things (repeatedly summing an array of ints) for a similar amount of time that an SPI transaction takes, I also get the ~300us tmax spikes, so whatever problem I'm left with is not actually specific to spidev
[13:55:35] <jepler> the linux clock source that can be used for high-resolution timestamping and sleeping, "CLOCK_MONOTONIC" is subject to adjustements by NTP and other sources
[13:55:58] <PCW_> maybe just the limits of standard kernel drivers (thats similar to Ethernet)
[13:56:47] <jepler> oh, 300us 1-cycle time spikes are seen with preempt-rt but linuxcnc deals OK with it?
[13:57:18] <PCW_> yeah not a problem (and can be much improved by using the DPLL)
[13:58:29] <PCW_> (for input sampling time generation)
[14:01:40] <PCW_> The only issue I see is that the following error must be widened to accommodate the
[14:01:42] <PCW_> position jitter at high speeds cause by the input sampling time error
[14:01:43] <PCW_> (sampling with the DPLL will fix most of this)
[14:01:45] <jepler> hm, now how big will a transaction be with 3 stepgens enabled
[14:02:12] <jepler> in particular, will it be at or under the 16-word limit in order to avoid doing DMA
[14:02:24] <PCW_> depends on how efficient the driver is...
[14:02:26] <jepler> (I *think* that doing DMA was still introducing bigger latencies than not doing it)
[14:03:03] <PCW_> if it has to poke at the (shared) DMA controller that might be an issue
[14:03:42] <jepler> yes, it looks like it's written so that it acquires the dma controller at each transaction
[14:04:09] <jepler> so a change I'm contemplating making is moving the "claim" of the dma controller to the time the device is registered
[14:04:38] <jepler> I think my datasheet said there are 8 DMA controllers that can work with the SPI module so if that's right, camping on one should be OK in terms of letting the rest of the system work
[14:05:44] <PCW_> Hey the Jetson has a SPI port...
[14:06:07] <jepler> do you have a jetson? someone else was talking about that board as well
[14:06:29] <PCW_> nah was just looking at the schematics
[14:06:32] <jepler> ah
[14:07:57] <PCW_> has a bunch of GPIO and a SPI port on the touch screen interface connector
[14:08:28] <PCW_> looks nice, too bad its from nvidia
[14:11:47] <PCW_> its funny to watch the DPLL track latency (baseline shift) when you move the mouse
[14:11:49] <PCW_> total baseline shift is ~20 uSec (over ~500 ms so only about 40 ns/thread slew)
[14:13:21] <jepler> you mean it's an accumulating error of 40ns per servo period?
[14:13:30] <jepler> I'm sad if there's accumulating timing error
[14:13:49] <jepler> this is with the uspace branch?
[14:14:38] <PCW_> Yes uspace and no, its tracking the average latency
[14:15:06] <jepler> oh, it takes 500ms to track the ~20us change in latency ?
[14:15:29] <PCW_> Yes (about and depending on tuning)
[14:15:47] <jepler> now that I understand what you were saying, that sounds good
[14:16:14] <PCW_> 20 usec _average_ change in latency
[15:06:14] <kwallace1> PCW_, Thanks for your reply. Even with existing holes that's a lot of drilling, but it needs to be done just once. There is a lot of soldering to do too. It would have been nice to have the tester interface board have all the connectors, interface chips and pogo pin layout on one board, but it didn't work out that way. Things could be worse I suppose.
[15:21:20] <PCW_> The old way was to use the drill file, drill plexiglass or blank fr4 and use individual wires with .025" receptacles
[15:22:53] <PCW_> a Excellon drill file should be massageable into a useable gcode file
[15:27:10] <cradek> yeah that looks pretty darn easy
[15:28:31] <cradek> remove some crap, stick a g81 at the top, scale the numbers or insert decimal points
[15:30:01] <cradek> the LZ/TZ thing is silly
[16:05:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 5f9974c 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2: don't enable the watchdog in hm2_read() and hm2_read_gpio() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5f9974c
[16:05:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 3fd02ac 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2: write the watchdog in hm2_write_gpio() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3fd02ac
[16:05:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 613759f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: simplify how "watchdog period is short" warning is printed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=613759f
[16:05:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog b05541d 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: simplify auto-enabling of the watchdog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b05541d
[16:05:53] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 043a0a2 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: move watchdog petting from pet_watchdog() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=043a0a2
[16:05:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 0b48bda 06linuxcnc 10docs/man/man9/hostmot2.9 10docs/src/drivers/hostmot2.txt 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2: remove pet_watchdog from the docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b48bda
[16:06:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 858eb48 06linuxcnc 10configs/by_interface/mesa/hm2-servo/hm2-servo.hal 10configs/by_interface/mesa/hm2-stepper/hm2-stepper.hal 10configs/by_interface/mesa/plasma-5i20/plasma-5i20.hal hm2 configs: dont call pet_watchdog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=858eb48
[16:06:08] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 427fba5 06linuxcnc 10(12 files) smithy configs: dont call pet_watchdog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=427fba5
[16:06:12] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog c68f379 06linuxcnc 10(8 files) smithy configs: dont call hm2 read_gpio/write_gpio * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c68f379
[16:06:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 47b3e95 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf: dont use hm2 pet_watchdog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=47b3e95
[16:12:03] <PCW_> Yeah!
[16:15:08] <jepler> > Your boards have been depanelized and shipped to you via via United States: Free Shipping
[16:17:27] <PCW_> adding ICAP support to the 7I90EPP and SPI configs
[16:18:17] <jepler> that's the thing that allows "rebooting"?
[16:18:32] <PCW_> yes and should eventually make testing new firmware a bit safer
[16:19:02] <PCW_> the 7I90 already allows re-config from host command
[16:19:28] <PCW_> so its not such a big deal as it is on the 7I80 and 5i25/5i24
[16:19:55] <micges> seb_kuzminsky: great!
[16:20:35] <seb_kuzminsky> well, let's see if it works this time :-)
[16:20:52] <seb_kuzminsky> micges: did you get the mesaflash patch i sent you for building on lucid?
[16:21:57] <micges> I got it, but I don't get to mesaflash coding yet, I hope today is the day
[16:22:05] <seb_kuzminsky> ok
[16:22:19] <seb_kuzminsky> PCW_: could you attach your hm2 stepper pid config to #392 on sf?
[16:22:24] <PCW_> the nice thing about ICAP is that eventually you can test a config by loading it in the fallback area and launching it from there
[16:22:26] <PCW_> so even ifs its a bad bifile and you lose card access, a simple power cycle will recover
[16:22:55] <jepler> PCW_: hm, on 7i90 I'm imagining one basic FW which would just support ICAP "rebooting" but over all 3 connection methods..
[16:23:45] <PCW_> we now are using a bigger common EEPROM for all cards so there room for 4 configs in one EEPROM
[16:23:56] <micges> PCW_: hmm so I need to add flag to mf to select if you want reboot to user area or fallback area
[16:24:15] <PCW_> Eventually
[16:24:57] <PCW_> This would make testing bitfiles on 5I25s (or 7I92S) that have only one EEPROM much safer
[16:26:10] <PCW_> actually the 7i90 has 4 connection methods (but 1 is not a HM2 slave)
[16:26:53] <jepler> spi, serial, epp, ?
[16:27:04] <PCW_> ssremote
[16:27:19] <jepler> oh lbp and lbp16 are two distinct things .. ok
[17:09:01] <PCW_> The configs are different, hm2_ser is just a serially accessed hostmot2 confg almost identical to hm2_eth
[17:09:03] <PCW_> ssremote is a serial remote I/O device that works with the sserial driver on the host (currently just provides 72 I/O bits)
[17:58:34] <skunkworks> walnut trees play havoc to gardeningJHFFJVBOHIPYN
[17:58:45] <skunkworks> ,|
[17:58:46] <skunkworks> \
[19:37:22] <jepler> skunkworks: this seems to be an emotional topic for you
[19:39:00] <skunkworks> jepler: a little girl too close to a keyboard...
[19:39:07] <skunkworks> :)
[20:05:56] <cradek> I think on the linuxcnc side (not counting the hardware to read them) absolute encoders would just work. before machine on, command already follows feedback so you can move the machine manually, and isn't it exactly like that?
[20:06:40] <cradek> I think I have an abs encoder in my junk box, but I have no idea how to read it
[21:29:04] <skunkworks> logger[psha]:
[21:29:04] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-08-30.html
[21:29:52] <skunkworks> cradek: I am pretty sure mesa hardware now has support for some abs encoders..
[21:31:13] <cradek> then I wonder why we always wonder whether it works
[21:32:57] <skunkworks> maybe it's just you that wonders? (I don't know how far along things are but I know peter has some working...)
[21:33:00] <skunkworks> ;)
[21:38:36] <NTU> would it make any sense for latency to be any better when flashed into EFI? my motherboard allows booting from EFI files, all i need to do is rebuild my MBR and enable EFI stub support in kernel
[21:39:42] <cradek> skunkworks: you might be right
[21:40:03] <jepler> NTU: what makes you think that anyone can deduce the answer from first principles, descartes style?
[21:43:00] <NTU> you lost me..
[21:43:32] <NTU> i was just thinking, because coreboot can help with latency, why not EFI?
[21:43:35] <jepler> "I think you're gonna have to try it if you really wana know"
[21:43:39] <NTU> ok
[21:52:35] <pcw_home> "<seb_kuzminsky> PCW_: could you attach your hm2 stepper pid config to #392 on sf? "
[21:52:37] <pcw_home> where would that be?
[21:55:05] <skunkworks> pcw_home: you have some absolute encoders working with your hardware?
[21:55:06] <jepler> pcw_home: sourceforge.net I think he means
[21:55:33] <jepler> pcw_home:
http://sourceforge.net/p/emc/bugs/392/
[21:56:46] <jepler> pcw_home: you may or may not be permitted to add an attachment to that bug after logging in to sourceforge. if yo udon't see an 'add attachment' link on that page next to the 'post' button after logging in (or if you don't have an account) then e-mail me or send me a url for the config .zip and I'll add it.
[21:59:00] <jepler> cradek: it sounds like what you're really saying is that you need an absolute encoder to test with linuxcnc
[22:00:16] <skunkworks> he said he has one...
[22:03:10] <pcw_home> I have tried SSI and Fanuc serial and they both work under linuxcnc
[22:03:43] <pcw_home> the BISS firmware is known to work but I dont have a BISS encoder to try with linuxcnc
[22:04:13] <cradek> it just comes up at the right location, and you only have to disable homing?
[22:04:24] <cradek> (that's what I'd expect)
[22:04:56] <jepler> I must have missed the start of the conversation then
[22:07:51] <pcw_home> I would think that also (not sure if emulated index is implemented for them however_
[22:08:57] <pcw_home> http://freeby.mesanet.com/pidstep.zip
[22:09:28] <pcw_home> is a pid run stepgen config
[22:09:57] <jepler> pcw_home: added to the sf bug, thanks
[22:10:10] <pcw_home> (SF had no add file option for me)
[22:19:20] <pcw_home> I will try an absolute encoder linuxcnc setup some time next week (at least 1 axis)
[22:42:42] <skunkworks> http://linuxcnc.org/index.php/english/download
[22:43:56] <skunkworks> 'burning iso' should go here
http://linuxcnc.org/docs/2.6/html/common/Getting_LinuxCNC.html#_burning_the_cd
[22:44:27] <skunkworks> not
http://linuxcnc.org/docs/html/common/Getting_EMC.html#_burning_the_cd
[22:46:35] <skunkworks> atleast That is what I think anyway...
[23:02:13] <cradek> pcw_home: the encoder I have is marked HENGSTLER 0 566 878 Ge No. 3242727-3 5VDC=/0.2A and has a clearly marked DB25 with UIN, GND, and D0..D16
[23:02:34] <cradek> pcw_home: it's yours if it would be useful for linuxcnc testing
[23:02:58] <pcw_home> Ahh a parallel (Garay code) encoder
[23:03:04] <pcw_home> Gray
[23:03:38] <cradek> oh really - that's a lot of IO isn't it
[23:03:48] <pcw_home> I have SSI and several Fanuc encoders I can test with
[23:04:45] <pcw_home> well 17 bits (probably multiturn)
[23:07:20] <pcw_home> SSI encoders are little more that a parallel Gray code encoder and a shift register
[23:09:40] <cradek> so just like this one, but with an extra part to reduce the IO requirements
[23:09:48] <pcw_home> Yep
[23:09:53] <cradek> ok, I'll put it back in the box of doom if you don't need it :-)
[23:10:37] <pcw_home> I already have the cabling for the SSI and Fanuc so they are easier to deal with
[23:12:11] <pcw_home> the SSI one I have is easier to use the the Fanuc since it needs no battery
[23:12:26] <pcw_home> than the
[23:14:18] <pcw_home> (uses a gear driven encoder disc or so for the multiturn part)