Back
[00:09:55] <linuxcnc-build> build #473 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/473 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:10:42] <linuxcnc-build> build #1903 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/1903 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:11:23] <linuxcnc-build> build #473 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/473 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:12:24] <linuxcnc-build> build #1909 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/1909 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:14:04] <linuxcnc-build> build #1909 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/1909 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:15:11] <linuxcnc-build> build #176 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/176 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:16:39] <linuxcnc-build> build #742 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/742 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:19:06] <seb_kuzminsky> hey, yeah
[00:19:36] <seb_kuzminsky> that's the buildbot complaining because jepler/proposed-2.6 is based on the v2.6.2 tag, not the 2.6 branch
[00:19:56] <seb_kuzminsky> and 2.6.2 had the udev rules file for the xhc-hb04 jog pendant in the wrong place
[00:20:25] <seb_kuzminsky> so, yay, it complained about a problem, for once, instead of accidentally peeing on itself
[00:32:22] <linuxcnc-build> build #1903 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/1903 blamelist: Jeff Epler <jepler@unpythonic.net>
[00:32:45] <linuxcnc-build> build #1906 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/1906 blamelist: Jeff Epler <jepler@unpythonic.net>
[02:41:10] <seb_kuzminsky> hrm, i can't set the channel topic any more
[02:41:16] <seb_kuzminsky> "#linuxcnc-devel You're not a channel operator"
[02:56:24] <archivist> op yourself then
[03:06:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master ce43af0 06linuxcnc 10configs/by_interface/mesa/hm2-stepper/hm2-stepper.hal 10src/hal/drivers/mesa-hostmot2/hm2_7i90.c Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ce43af0
[03:12:17] seb_kuzminsky changed topic of
#linuxcnc-devel to:
http://linuxcnc.org | Latest release: 2.6.3
[03:13:24] <seb_kuzminsky> good night folks
[08:36:59] <jepler> pcw_home: thanks!
[08:58:35] <cradek> seb_kuzminsky: yay! thanks!
[09:37:17] <meji3> hi folks
[09:37:25] <meji3> does anyone know if the BIOSTAR A68N-5000 AMD A4-5000
[09:37:29] <meji3> is recommended
[09:37:31] <meji3> or has issues
[09:37:39] <meji3> thanks for you help
[09:43:31] <CaptHindsight> meji3: no problems with the A4-5000, I have nothing positive to say about Biostar, their BIOS and EFI tends to have issues with Linux
[09:46:08] <meji3> i guess i could try it out then
[09:46:34] <meji3> building a new cnc and having bought a few things i had to resell/return
[09:46:40] <meji3> i'm trying to be a bit more careful
[09:46:58] <meji3> what would be an equivalent board that might lead to less issues
[09:47:17] <meji3> i guess i should say first cnc
[09:47:19] <meji3> not new
[09:47:26] <meji3> thanks again
[09:54:10] <CaptHindsight> meji3: haven't had any BIOS/EFI issues with asrock, asus, msi or gigabyte and Linux yet
[09:55:00] <meji3> me neither my builds tend to be with gigabyte for desktops and supermicro for my esxi boxes, none of them seem to have anything with this apu though...maybe i'll wait a while
[09:55:03] <meji3> thanks a bunch
[09:55:05] <meji3> enjoy!
[09:55:07] <pcw_home> Someone on th the Newwegg Q/A section says it works with Ubuntu14.04
[09:55:22] <pcw_home> so may be hope
[09:57:32] <meji3> it's 70 bucks so i'll probably try it out and see, i've been around *nix for a while so i can probably tweak my way around as long as i don't have to write a driver, which if there's a gun to my head i can
[10:13:17] <jepler> pcw_home: I looked in your batch files and didn't find the answer to this: which workaround do you use for this problem?
[10:13:20] <jepler> WARNING:PhysDesignRules:2410 - This design is using one or more 9K Block RAMs
[10:13:23] <jepler> (RAMB8BWER). 9K Block RAM initialization data, both user defined and
[10:13:25] <jepler> default, may be incorrect and should not be used. For more information,
[10:13:28] <jepler> please reference Xilinx Answer Record 39999.
[10:13:39] <jepler> this is with ise 13.4 generating a bitfile for 7i90 spi
[10:13:57] <jepler> I didn't see that you enabled any of the workarounds given at
http://www.xilinx.com/support/answers/39999.html
[10:14:13] <jepler> except that page says 13.4 should automatically be generating an appropriate bitfile
[10:14:36] <jepler> (bitgen -g INIT_9K:yes)
[10:15:00] <seb_kuzminsky> cradek: welcome :-)
[10:17:16] <pcw_home> That error message is bogus
[10:21:39] <jepler> $ touch WAT
[10:21:40] <jepler> $ echo [a-z]*
[10:21:40] <jepler> WAT
[10:21:55] <jepler> thanks, locales :-/
[10:23:26] <pcw_home> I have never had an issue with ROM/RAM initilization (and I use 13.1 all the time)
[10:23:27] <pcw_home> I think the warning is for actual 9K RAMs (with parity) but I dont use them
[10:24:00] <jepler> OK
[10:24:16] <jepler> this morning I've got 7i90 epp, 7i90 spi, and 7i80 bitfiles, but none of them tested yet.
[10:26:14] <pcw_home> 7I80 bitfiles should be easy enough to test
[10:26:35] <jepler> yes, that's going to be the easiest
[10:26:48] <jepler> I've also refactored how configurations are specified
[10:26:55] <pcw_home> just done bust both flash images
[10:27:02] <jepler> instead of a growing number of lookup tables, each one will be a class
[10:27:05] <jepler> class i80db(TopEth, DBx4, Spartan6_25_256):
[10:27:06] <jepler> path = "7i80db"
[10:27:06] <jepler> name = "i80db_x25" # (ucf filename)
[10:27:06] <jepler> card = "7i80db"
[10:27:06] <jepler> humanname = "Mesa 7i80 DB"
[10:28:04] <jepler> there will still be a big table to specify all the combinations of pinfiles
[10:28:49] <pcw_home> eventually I want to get rid of the moduleid section
[10:29:09] <pcw_home> (create it from the pinout)
[10:29:40] <pcw_home> and perhaps split the pinouts into per connector groups
[10:33:24] <pcw_home> but thats a long ways off, need to get IDROMV4 working first
[10:35:11] <jepler> always more to do
[10:35:51] <pcw_home> I should have started off with V4
[10:38:12] <jepler> when you run out of things to do, you should stick in a ring oscillator trng module into hostmot2
[10:39:25] <jepler> I misplaced the code for the one I wrote years ago
[10:40:18] <pcw_home> multiple ring oscillators for random number generation?
[10:41:18] <jepler> At its base, Intel's original HWRNG involved a free-running ring oscillator that was sampled by a synchronous process that whitened it
[10:41:49] <pcw_home> must have to use the "keep" attribute or similar so they don't get optimized away
[10:42:58] <jepler> yes something like that
[10:43:22] <pcw_home> Ive heard a good way to fry a FPGA is make each LUT a ring oscillator
[10:43:41] <jepler> I think my 5i20's FPGA felt warm when I did this
[10:44:13] <jepler> > The Intel 82802 Firmware Hub (FWH) chip included a hardware RNG[9] using two free running oscillators, one fast and one slow. A thermal noise source (non-commonmode noise from two diodes) is used to modulate the frequency of the slow oscillator, which then triggers a measurement of the fast oscillator. That output is then debiased using a von Neumann type decorrelation step (see below). The output rate of this device is some
[10:44:22] <jepler> this is the scheme I was thinking of, I see I oversimplified it
[10:45:12] <jepler> others have done FPGA random numbers; they went to the trouble of characterizing the rate variation of FPGA ring oscillators in order to bolster their argument that there was sufficient entropy there due to thermal variation
[10:46:05] <pcw_home> I would worry about phase locking
[10:48:28] <jepler> http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/High%20Speed%20True%20Random%20Number%20Generators%20in%20Xilinx%20FPGAs.pdf
[10:48:40] <pcw_home> Didn't the California lottery use video of a lava lamp at one time?
[10:50:27] <jepler> I dunno about the lottery, but a lava lamp random number generator was a thing at one time.
http://en.wikipedia.org/wiki/Lavarand
[10:50:47] <jepler> > It is covered under U.S. Patent 5,732,138, titled "Method for seeding a pseudo-random number generator with a cryptographic hash of a digitization of a chaotic system."
[10:55:02] <pcw_home> The xilinx paper looks interesting and the FPGA implementation is quite small
[10:56:58] <jepler> "FPGA Vendor Agnostic True Random Number Generator (pdf)."
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.5319&rep=rep1&type=pdf
[10:57:06] <pcw_home> The 7I80 has a pseudo-random number generator, maybe I could replace it with hardware :-)
[10:58:38] <jepler> what was the intended purpose of the PRNG in the 7i80? tcp initial sequence numbers need them I suppose
[10:58:52] <jepler> er does that apply to udp?
[10:59:45] * jepler goes in search of breakfast
[11:00:00] <pcw_home> bootp uses them
[11:12:19] <pcw_home> oops 7I76e names are still broken :-(
[11:13:51] <micges-dev> how so...
[11:14:36] <pcw_home> Never mind, they are OK
[11:15:21] <pcw_home> I forgot the port.channel part of the name
[11:35:21] <jepler> hm, anyone used master branch, rtai realtime, with a parport device since uspace was merged?
[11:35:35] <jepler> user reports that in master branch, hal_parport won't insert for him
[11:36:18] <jepler> I'll give it a test later today, since if anybody ruined it it was me
[11:39:10] <MrHindsight> jepler: was that merge in the hybrid wheezy ISO or after?
[11:44:51] <jepler> MrHindsight: this is something in master branch only, so not on any iso
[12:19:05] <MrHindsight> http://www.ecklersoft.com/ers.html "rt-stepper software is used to drive the dongle over the USB bus" "based on the EMC2 software from www.linuxcnc.org"
[12:20:31] <jepler> at first glance source is offered, so yay
[12:22:25] <MrHindsight> https://code.google.com/p/rtstepperemc/
[12:25:16] <jepler> given how much of linuxcnc he had to delete to achieve his aims, it's not surprising if he hasn't felt any part of it was particularly "upstreamable"
[12:28:08] <MrHindsight> his motctl.c is his motion controller
[12:28:22] <MrHindsight> and he has his version of trivkins
[12:30:21] <MrHindsight> "TkMini generates the step pulses, but step timing is maintained by dongle thus eliminating the need for a real time kernel."
[12:33:45] <MrHindsight> his dongle is a Microchip PIC182455
[12:39:06] <pcw_home> Is that from pre-hal EMC?
[12:40:13] <MrHindsight> jeplers name is in some of the source files
[12:41:58] <MrHindsight> I don't see any HAL in there
[12:45:59] <jepler> "EMC2" was what we called it after we added HAL
[12:46:49] <jepler> > HAL has been removed. All configuration options are done via a *.ini file. The rcslib library dependency has been removed.
[12:49:07] <micges-dev> jepler: what is shortest way to add man pages to mf ?
[12:49:46] <micges-dev> can it be one file in main src dir or there is other way?
[12:50:47] <jepler> micges-dev: yes, just copy e.g., mesaflash.1 to /usr/share/man/man1/mesaflash.1 to install it
[12:51:02] <jepler> micges-dev: and test your markup with: man ./mesaflash.1 (the ./ is important)
[12:51:42] <micges-dev> cool thanks
[13:30:33] <micges-dev> pcw_home: --reload along with --write works in mf
[13:32:04] <pcw_home> Great!
[13:32:06] <pcw_home> reload is really nice, I was wearing my fingers out pulling the 7I76E power connector :-)
[13:33:00] <micges-dev> heh me too
[13:33:26] <micges-dev> also great time saver with 5i25 testing
[13:34:18] <pcw_home> yeah (5i24 6i24 6i25 also)
[13:35:28] <pcw_home> 7i90 has ICAP added to the source but I have not rebuilt the bitfiles yet
[13:38:13] <micges-dev> so I can add ICAP cookie checking to all supported boards?
[13:38:25] <pcw_home> yes
[13:43:57] <pcw_home> well except hm2_eth and hm2_serial
[13:44:46] <micges-dev> yeah
[13:47:50] <pcw_home> and hm2_serial doent have the hm2_eth assy code merged yet
[13:49:31] <micges-dev> what assy code?
[13:50:35] <pcw_home> hm2_serial uses basically the same ROM code as 7I80
[13:51:09] <pcw_home> (with a pktuart instead of a Ethernet MAC)
[13:51:21] <micges-dev> ah
[13:51:54] <pcw_home> this is sufficient to test the DPLL stepgen sampling:
[13:51:55] <pcw_home> setp hm2_[HOSTMOT2](BOARD).0.raw.write_address 0x2A00
[13:51:57] <pcw_home> setp hm2_[HOSTMOT2](BOARD).0.raw.write_data 0x00009000
[13:51:58] <pcw_home> setp hm2_[HOSTMOT2](BOARD).0.raw.write_strobe true
[13:52:00] <pcw_home> setp hm2_[HOSTMOT2](BOARD).0.dpll.01.timer-us -50
[13:52:53] <micges-dev> oh thanks
[13:53:58] <micges-dev> 7i92 support added to mf, test when you can
[13:56:34] <jepler> boo, wrote a size-25 bitfile to my size-16 7i80. recovered from that now.
[13:58:29] <micges-dev> pcw_home: do you think mf can again check bitfile header part name against current board part ?
[13:58:55] <micges-dev> it was enabled but many part names were wrong
[14:00:10] <micges-dev> brb
[14:23:18] <jepler> pcw_home: it looks like the manual says to use reset_on_error:enable but that the actual flag is probably reset_on_err
[14:23:47] <jepler> and the value is :Yes, not :enable
[15:02:10] <skunkworks_> logger[psha]:
[15:02:11] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-09-06.html
[15:02:59] <skunkworks_> since when did feed hold stop working for rapids?
[15:03:11] <skunkworks_> (slight suprise...)
[15:03:33] <skunkworks_> I know it is 'feed' hold but I am almost positive it worked for rapids also
[15:03:51] <skunkworks_> (2.6.0)
[15:04:06] <skunkworks_> I could just not be remembering right
[15:06:34] <micges-dev> jepler: mf won't be able to write incorrect bitfile to flash anymore
[15:06:44] <pcw_home> I think all the bitgen options are the same for SP6 cards
[15:07:04] <pcw_home> bbl again
[15:08:33] <micges-dev> skunkworks_: I *think* it could be side effect of spliting feed override and rapid override as feed hold is just setting feedoverride to 0.0
[15:08:55] <micges-dev> and now FO doesn't affect rapids at all
[15:09:05] <skunkworks_> micges-dev: that was my thought
[15:09:11] <skunkworks_> the question is - what is right?
[15:10:02] <micges-dev> I vote for feedhold stop rapid also despite the pin name
[15:11:00] <skunkworks_> that might work - then you could hook them together if you want
[15:13:18] <micges-dev> I was thinking about old behavior but your idea is better
[15:14:01] <skunkworks_> heh - we communicate like we are married...
[15:14:01] <micges-dev> same was for FO and RO, if you want old behavior just net them together
[15:14:10] <skunkworks_> right
[15:15:38] <micges-dev> skunkworks_: oh so it seems that marriage communcation problems are the same around the globe ;)
[15:17:05] <skunkworks_> I would assume...
[15:17:07] <skunkworks_> :)
[15:19:31] <jepler> micges-dev: I haven't pulled mesaflash lately, this seems like a good reason to do so
[15:21:20] <skunkworks_> http://electronicsam.com/images/KandT/slots.jpg
[15:28:48] -verne.freenode.net:#linuxcnc-devel- [freenode-info] why register and identify? your IRC nick is how people know you.
http://freenode.net/faq.shtml#nicksetup
[15:54:08] <jepler> yay, second try worked on 7i80
[15:54:52] <skunkworks_> jepler: what are you doing? automating the compiling of firmware?
[15:55:25] <jepler> skunkworks_: yes. we've had that for a long time (hostmot2-firmware) but it hasn't been updated in years
[15:55:38] <skunkworks_> neat!
[15:55:50] <jepler> skunkworks_: last month(?) peter put some new source in, and I've been working on making the build process work again
[15:56:58] <jepler> the goal of hostmot2-firmware is for linuxcnc.org to be capable of building all the bitfiles we want to ship in .deb packages (and, obviously, on iso images and so forth)
[15:57:14] <jepler> and not only that, but to supply the infrastructure for anyone to build their own firmwares
[15:58:02] <jepler> .. on Linux, after they've obtained the (proprietary but no-cost) software from xilinx
[16:55:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master cc2c670 06hostmot2-firmware 10.gitignore ignore python bytecode files * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=cc2c670
[16:55:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master b995924 06hostmot2-firmware 10(7 files in 2 dirs) factor chip data to its own file, improve the format * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=b995924
[16:55:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 9b26c8e 06hostmot2-firmware 10build.py Report total time * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=9b26c8e
[16:55:23] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master b149ceb 06hostmot2-firmware 10build.py reduce noise in ise output * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=b149ceb
[16:55:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 4cb70a2 06hostmot2-firmware 10Makefile 10build.py List additional files needed for 7i80 * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=4cb70a2
[16:55:31] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master fd1a0b9 06hostmot2-firmware 10debian/gencontrol debian: drop conflicts with very old package names * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=fd1a0b9
[16:55:35] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master cd5c937 06hostmot2-firmware 10cards.py Define 7i80, 7i90 cards * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=cd5c937
[16:55:39] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 714f16b 06hostmot2-firmware 10build.py delete work.ncd to avoid confusing map * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=714f16b
[16:55:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 68456a9 06hostmot2-firmware 10build.py enable one firmware for each new card for testing * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=68456a9
[17:00:45] <jepler> hmm that last commit was not what I intended
[17:00:55] <jepler> hm2-buildmaster: stop build build wrong code
[17:00:55] <hm2-buildmaster> build 25 interrupted
[17:01:25] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master f6eff12 06hostmot2-firmware 10firmwares.txt enable one firmware for each new card for testing * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=f6eff12
[17:07:10] <pcw_home> Steogen sample time noise during 20 ips move with DPLL reduced to ~4u inch P-P ~=200 ns P-P
[17:07:17] <pcw_home> stepgen
[17:09:48] <jepler> ERROR:Place:375 - The design does not fit in device.
[17:10:07] <jepler> trying to build a fw/7i80db16/7I76x2_7I77x2.BIT
[17:10:09] <pcw_home> shoehorn time
[17:10:11] <jepler> which I thought had built here before I pushed it
[17:10:22] <jepler> pcw_home: is this a combo you build or did I pick a questionable one?
[17:10:50] <pcw_home> I may have shoehorned it in
[17:12:23] <hm2-buildmaster> build #26 of build is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/hm2-buildbot/builders/build/builds/26 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[17:12:49] <jepler> your make7i80db25.bat has it, but not make7i80db16.bat
[17:13:20] <pcw_home> so it really doesn't fit
[17:13:54] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 220b389 06hostmot2-firmware 10firmwares.txt enable one firmware for each new card for testing * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=220b389
[17:14:16] <jepler> yeah, I was mistaken that I had built it
[17:14:24] <jepler> hm2-buildmaster: try again
[17:17:30] <pcw_home> it might fit if the Synthesize strategy was changed to area instead of speed but not worth fussing with
[17:18:32] <jepler> first linuxcnc should try getting to parity with the firmware you ship
[17:19:32] <jepler> then hopefully I can use my assembler to start building those d8* ROMs
[17:19:39] <jepler> and then my software building fetish will be satisfied
[17:20:43] <pcw_home> will your assembler work on the D16?
[17:21:45] <jepler> hopefully
[17:21:53] <jepler> I think we discussed that it has a 24-bit instruction word
[17:22:01] <jepler> that's not a problem
[17:22:17] <pcw_home> Yeah (the B32 has a 24 bit instruction also)
[17:23:01] <jepler> but obviously at this point there's only one table for it so surprises may lurk
[17:23:12] <jepler> not to mention needing variant tables for all these versions of the d8 you've done over the years
[17:23:46] <pcw_home> Not needed (I moved everything but USB to the latest)
[17:23:52] <jepler> are there relative jumps? the lack of those in d8 means I haven't thought about them yet.
[17:24:07] <jepler> cool, I know you had talked about doing that
[17:24:12] <pcw_home> no relative jumps
[17:24:41] <pcw_home> i even have example code for the twiddler (untested)
[17:24:44] <jepler> I don't think they represent a problem, instructions know what address they're assembling to, and the address of the arguments
[17:25:18] <pcw_home> never had the goal of PIC
[17:25:35] <jepler> I should do 6502 or something else that I can read and write by hand
[17:26:09] <pcw_home> I can just about read and write D8 code (in hex)
[17:26:52] <pcw_home> I pretty much had the TMS9900 inst set memorized at one time
[17:27:11] <jepler> I probably had about 1/4 of the d8 opcodes memorized while I was staring at differences between hex files
[17:27:30] <jepler> "that's a load from memory and it's different by one byte .. wtf"
[17:27:47] <pcw_home> pretty simple (PDP8 is fancier)
[17:29:45] <jepler> I know I'm showing my youth, but 6502, x86, and MIPS are the three oldest assembly languages I've dipped my toes in (and mips only for school, of course)
[17:30:49] <pcw_home> I toggled a sieve or Eratosthenes program into a PDP8S :-(
[17:32:01] <pcw_home> (it showed the primes on the console lights)
[17:32:07] <jepler> I entered tons of hex listings as a kid, but by then they had fancy check digit calculators so you knew when you were wrong and got to correct your mistakes
[17:33:16] <jepler> hm, any div instruction on pdp8s?
[17:33:38] <pcw_home> only if you had the hardware option
[17:36:19] <micges-dev> jeez guys, I couldn't switch on a computer in 2001...
[17:36:48] <pcw_home> :-)
[17:39:17] <pcw_home> looks like you can set the P term quite high in the stepgen control loop once you get rid of the sampling noise
[17:42:12] <pcw_home> Using 1000 now and getting <50 uinch deviations during
[17:42:13] <pcw_home> accel/decel (20 IPS 400 IPS*S) less than 4 uinch during 20 ips cruise
[17:43:22] <pcw_home> unfortunately getting this performance does require tuning FF2 to minimized errors during accel/deccel
[17:45:23] <micges-dev> very good numbers
[17:47:20] <pcw_home> considering the noise was about +-2 mills before :-)
[17:48:33] <jepler> how many steps/inch? or is this error scale independent of step size?
[17:48:55] <pcw_home> i dont think so
[17:49:55] <pcw_home> scale is set to 10000 steps/inch
[17:50:23] <jepler> so 100 uinch = 1 step, or your error is a half step worst case?
[17:50:32] <pcw_home> yes
[17:50:33] <jepler> you can stop tuning now
[17:50:41] <jepler> :)
[17:52:07] <pcw_home> I need to add some P and remove some I from my DPLL if has mild overshoot (~1 second period)
[17:52:28] <pcw_home> makes me seasick watching it
[17:52:57] <jepler> at some point you'll need to add a 1pps input from a gps so that we can know our velocities are accurate
[17:53:39] <pcw_home> well there already is a DPLL input pin :-)
[17:55:03] <jepler> I've been trying to figure out if there's a "right" timebase to use in uspace
[17:55:33] <jepler> right now it relates everything to CLOCK_MONOTONIC, but it "is affected by the incremental adjustments performed by adjtime(3) and NTP"
[17:56:14] <jepler> there's CLOCK_MONOTONIC_RAW which is not, but you can't clock_nanosleep until a CLOCK_MONOTONIC_RAW deadline
[17:56:14] <pcw_home> that could be painful
[17:58:02] <jepler> I think the advice may be to not run ntp on a machine where you run linuxcnc
[17:58:36] <jepler> adjtimex can directly add or subtract time offsets in microseconds, though I think that once synchronized ntp mostly just adjusts the frequency offset in units of ppm
[18:03:12] <pcw_home> Wonder if there's a convenient way to shut off NTP or NTP adjustments when linuxcnc is running
[18:19:28] <jepler> don't install the package 'adjtimex'. It *sounds* like a program for reading the kernel adjtimex parameters, but it appears to try (at installation time without confirmation) to discipline linux's timekeeping to follow the RTC but either my RTC is crazy bad or adjtimex (the program) is crazy bad
[18:19:42] <jepler> it made my clock go about 1% slow
[18:47:34] <pcw_home> RTCs are often fairly bad but not that bad
[18:54:15] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 9f1bd71 06linuxcnc 10docs/man/man9/hostmot2.9 docs: fix a copy/paste error in the hostmot2.9 manpage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9f1bd71
