Back
[07:14:57] <jepler> skunkworks: just once
[07:15:23] <skunkworks> jepler, is that good or bad...
[07:28:58] <jepler> skunkworks: it depends whether my strategy is to try to ignore it, or to try and fix it
[07:29:06] <jepler> if the strategy is ignore, then it's excellent news
[07:33:53] <alex_joni> hi guys
[07:40:12] <jepler> hi alex_joni
[07:46:58] <skunkworks> alex_joni, How are things?
[08:20:44] <skunkworks> jepler, I forget about the 'has to work 100%' as in the windows world - if something crashes once a week - it is an awesome application!
[08:23:52] <alex_joni> skunkworks: busy ;)
[08:23:54] <alex_joni> jepler: hi
[08:30:40] <jepler> skunkworks: you should make sure alex_joni heard your news
[08:30:51] <jepler> alex_joni: I've been busy too, in good ways.
[08:30:56] <jepler> afk, in search of breakfast
[08:32:31] <skunkworks> oh yah! alex_joni - we are expecting our 2nd
[09:36:04] <jepler> pcw_home: perhaps you already thought of this, but the next idrom format could explicitly give the location and size of TRAM
[09:44:43] <cradek> about bug 391, I'd expect a watchdog bite to turn "off" (float?) all outputs, which should cause whatever estop chain you have to fire. I've always thought of this watchdog as a hardware-level thing.
[09:46:55] <jepler> cradek: the hm2 watchdog does float all outputs
[09:47:07] <jepler> cradek: but nothing in the sample config makes linuxcnc actually estop
[09:47:39] <jepler> on a servo system you'd at least get a following error, but you don't even get that since stepgens continue counting in this condition
[09:48:13] <jepler> so I think the bug is calling for the watchdog has-bit pin to be wired into the software estop chain
[09:51:15] <cradek> on a stepper system the machine would stop moving, right? because there is no output?
[09:51:36] <jepler> right, the motors stop but the GUI keeps going, showing that nothing is wrong
[09:51:44] <cradek> ok, I see
[09:51:54] <jepler> stepgen feedback positions keep updating, etc
[09:51:55] <cradek> I agree it would be better if the gui noticed
[09:52:35] <cradek> but on any real machine (with a real estop chain) it would notice soon enough, by sensing the hardware estop
[09:53:33] <cradek> hm2-stepper.hal:net estop-loop iocontrol.0.user-enable-out => iocontrol.0.emc-enable-in
[09:54:51] <jepler> so can we do better than that in the sample config, without making it worse for the sane user who actually adds a proper physical estop chain?
[09:55:29] <jepler> can we use an estop_latch component with the watchdog has-bit output pointing to the estop fault input?
[09:55:57] <cradek> I've never been sure how estop_latch works
[09:56:17] <cradek> I don't think you'll make it harder for sane users - they'll just not use the thing you set up
[09:56:23] <cradek> heh "sane"
[10:20:26] <seb_kuzminsky> we currently use iocontrol.0.emc-enable-in to signal "external estop condition" to the controller, as in the loopback that cradek grepped above
[10:21:10] <seb_kuzminsky> how about if .emc-enable-in gets the AND of user-enable-out and watchdog.has-bit (and whatever else we want to be True for the machine to run)?
[10:21:10] <jepler> cradek: This documents my understanding of estop-latch:
http://pastie.org/9529618
[10:21:44] <jepler> seb_kuzminsky: a remaining problem is: how does watchdog.has-bit get cleared?
[10:21:58] <seb_kuzminsky> currently by hand, unforch
[10:22:32] <seb_kuzminsky> it's an exceptional situation, and it probably requires user intervention to unhork (for example, re-connecting an epp or spi cable)
[10:24:32] <seb_kuzminsky> jepler: your new estop_latch manpage is better
[10:24:53] <seb_kuzminsky> for some reason, the "use" down near the bottom rendered in green
[10:25:21] <jepler> seb_kuzminsky: funky syntax highlighting I guess.
[10:25:24] <seb_kuzminsky> also, it might be even clearer if you capitalized True and False throughout
[10:25:43] <seb_kuzminsky> also, if you replaced manpages with something that can display state machines graphically
[10:25:56] * seb_kuzminsky </snark>
[11:02:29] <seb_kuzminsky> hi micges
[11:02:35] <micges> hi
[11:05:12] <micges> seb_kuzminsky: what's up
[11:05:13] <micges> ?
[11:07:57] <seb_kuzminsky> just sent you a github PR that makes mesaflash build on lucid
[11:08:21] <micges> ok
[11:18:30] <micges> seb_kuzminsky: I hope to release mf 3.1 in about few weeks with idrom v4 support and spi support from jepler
[11:18:47] <jepler> either I'll work on SPI mesaflash this weekend or I won't.
[11:19:08] <jepler> if I don't get around to it, please don't hold a MF release for it. This only affects about one person in the universe, and that's me
[11:19:51] <micges> ok
[11:20:53] <micges> jepler: do you have still old 5i20 with pci setup eeprom problems?
[11:22:53] <jepler> micges: I resolved the eeprom problem on my 5i20
[11:22:56] <jepler> using some dos program
[11:23:19] <micges> mf 3.1 will do the same
[11:23:24] <jepler> oh that's cool
[11:24:04] <micges> just want you to test mf if you already know other way to fix it
[11:24:39] <micges> if that;s not a problem
[12:14:44] <pcw_home> jepler: the hardware translation RAM should be brought in if present in the
[12:14:46] <pcw_home> module ID section but current its hardwired to some configs (EPP configs)
[12:14:47] <pcw_home> since its was never used I think Ive forgotten to add it in newer pinout files
[12:14:49] <pcw_home> even though the hardware is present
[12:24:57] <zq> hm
[12:26:18] <zq> 'comp_id' is the ID of the component that will 'own' the variable. Normally it
[12:26:21] <zq> should be the ID of the caller, but in some cases, a user mode component may be
[12:26:24] <zq> doing setup for a realtime component...
[12:26:53] <zq> so i came across that for the hal_pin_<type>_newf functions
[12:27:45] <zq> is there an actual case of one component allocating pins for another component?
[12:29:10] <zq> a cursory grep for hal_pin_*_newf shows that it's always called to allocate a pin for the same component
[12:42:07] <jepler> zq: yeah I doubt there is
[12:50:16] <zq> jepler: then why would a pointer (to a hal pin) itself need to reside in hal's shm?
[12:50:22] <zq> shared memory, that is
[12:50:57] <jepler> zq: I don't know that offhand. Almost always, a pin is in a structure with a parameter; the parameter would have to be in hal's shm.
[12:51:32] <jepler> oh of course: because "net" has to modify the pointer
[12:52:34] <zq> right, i missed that
[13:12:30] <micges> pcw_home: I didn't have machine time to test stepgen + dpll but I will on monday ,also there will be scurve test on same machine on monday
[13:14:12] <pcw_home> I would expect to be a noticeable improvement only on Ethernet or maybe all Preemt-RT systems
[13:17:04] <micges> this is 5i25+7i76 so I could use 7i76e and get some rt-preempt kernel
[13:18:15] <pcw_home> yes
[13:19:09] <pcw_home> I have been testing it with the 7I76E
[14:50:50] <seb_kuzminsky> thanks micges-dev
[14:51:17] <micges-dev> thanks too
[14:52:01] <jepler> micges: what are you referring to when you said "scurve test"?
[14:56:01] <micges-dev> jepler: I've extracted important part from araisrobo branch and applied it to master (before new tp merge)
[14:57:01] <micges-dev> it's mostly working, still got few acc spikes at scope to fix
[14:57:39] <micges-dev> but even so results on real machine are great
[14:57:44] <jepler> micges-dev: interesting. not that I'm likely to look at it anytime soon, is it in a published git branch?
[14:59:02] <micges-dev> I think most of changes are here:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/araisrobo-scurve2
[15:04:52] <jepler> ah OK
[15:04:57] <jepler> thanks!
[15:06:18] <jepler> For embedded systems, the FreeRTOS project that Andy mentioned on the mailing list looks interesting. Unfortunately, most of their documentation is paywalled.
[15:06:36] <cradek> uh
[15:08:54] <jepler> cradek: did you look at my revised estop-latch documentation?
http://pastie.org/9529618 (ignore syntax highlighting)
[15:10:07] <cradek> wow, that's shockingly clear
[15:10:36] <jepler> it also is about 3 times as long as the implementation :-P
[15:10:52] <cradek> that is not a count against it
[15:11:52] <jepler> I'll test that I can set up a hm2-stepper software estop based on the docs I wrote
[15:12:13] <jepler> and if so I'll push at least the doc fixes to 2.6 if seb_kuzminsky doesn't mind
[15:12:20] <jepler> but he seemed to like the doc fixes too
[15:12:22] <cradek> cool, thanks
[15:12:36] <mozmck> Sometimes the decisions going into one line of code merit a page of explanation :)
[15:12:40] <jepler> I should tell him one caveat, though: the bit about the default value on the input pins is a change
[15:13:31] <jepler> before, ok-in defaulted to false when not connected
[15:13:53] <jepler> I also fixed fault-out to default to true; otherwise, it could have been false for a short time before the estop-latch function was executed once
[15:48:06] <seb_kuzminsky> jepler: here's an open hardware pluto clone, not sure if this is relevant to your interests
[15:48:09] <seb_kuzminsky> git clone git://git.gag.com/hw/cncfpga; gschem cncfpga.sch
[15:49:51] <cradek> cool!
[15:50:05] <cradek> it looks hand-solderable
[15:50:10] <cradek> http://www.gag.com/homeshop/cncfpga/
[15:53:57] <seb_kuzminsky> cradek: it's by bdale garbee, of old-timey debian fame
[16:11:01] <jepler> I wish I could buy everybody a reliable host to irc from
[16:11:47] <jepler> then the channel would just fill up with people who forgot they ever set it up
[16:13:29] <cradek> in perfect har-mon-y
[16:30:31] <seb_kuzminsky> cradek, jepler: i cloned bdale's cncfpga repo and pushed it to github, and added issues for the things he said were wrong with the current board
[16:30:39] <seb_kuzminsky> https://github.com/SebKuzminsky/cncfpga
[16:30:53] <seb_kuzminsky> let me know if you want push access to that repo
[16:31:22] <seb_kuzminsky> the .sch file opened fine with gschem, and the .pcb file opened with pcb-gtk
[16:32:13] <seb_kuzminsky> Bdale offered to "handle the logistics of having them made in small lots". he runs a business making and selling open-source hardware for high-power amateur rocketry
[16:34:16] <jepler> axis nearing two days of runtime on odroid with a hm2-spi configuration
[16:35:34] <jepler> read/write tmaxes are higher than in my standalone testing but no realtime delay messages
[16:36:08] <seb_kuzminsky> sweet
[16:39:20] <jepler> tmaxes after 1 day 19 hours:
http://paste.debian.net/119551/
[16:39:40] <jepler> obviously if those all hit at once I wouldn't be making my 1ms deadline
[16:56:25] <PCW> Dont those tmaxes indicate that the servo thread is being interrupted?
[16:56:26] <PCW> It seems to me that the servo thread should disable any lower priority interrupts
[16:58:49] <PCW> (ideally only interrupts from LinuxCNC interface hardware should be allowed when the thread is running)
[17:02:38] <jepler> no interrupts (of the kind listed in /proc/interrupts) are delivered to CPU3 except GIC MCT (timer interrupt) and rescheduling interrupt.
[17:02:50] <PCW> i dont know if this opens up the possibility of deadlocks in the kernel but for example you can
[17:02:51] <PCW> see interference from video access even on RTAI systems in comps like PID that have no hardware access
[17:04:19] <jepler> though I don't know why so many rescheduling interrupts are delivered; looks like 2/ms. possibly something overlooked in spi is causing one reschedule per call.
[17:05:25] <jepler> interrupts are of course being delivered on the other CPUs, and code is running on them, so it interferes with things like memory bandwidth, shared caches, etc.
[17:05:46] <PCW> I suspect they should be blocked as well
[17:06:59] <jepler> hm something's not right
[17:07:09] <jepler> rtapi_app is not pinned to the last CPU core according to taskset
[17:07:33] <jepler> in fact it's not running with realtime priority
[17:09:10] <jepler> that's unexpected
[17:10:35] <jepler> oh I was looking at the affinity of the main task
[17:10:38] <jepler> not the realtime threads
[17:19:56] <seb_kuzminsky> jepler: can we close #389 now?
https://sourceforge.net/p/emc/bugs/389/
[17:20:10] <seb_kuzminsky> 615e8348 claims to fix it
[17:20:15] <seb_kuzminsky> (in 2.6)
[17:20:31] <jepler> seb_kuzminsky: I think dewey tested and committed his own version of the patch
[17:21:28] <seb_kuzminsky> i think so too
[17:21:32] <seb_kuzminsky> i'll close it then
[17:22:02] <jepler> thanks!
[17:22:42] <jepler> seb_kuzminsky: did you see my disclosure above about slightly changing the estop_latch component (default values for unconnected pins)?
[17:28:13] <micges-dev> seb_kuzminsky: mesa 7i92 support can go to 2.6?
[17:29:15] <micges-dev> seb_kuzminsky: err sorry I messed up names, nm
[17:34:50] <jepler> seb_kuzminsky: so more concretely, here's the patch which I assume will apply to 2.6:
http://emergent.unpythonic.net/files/sandbox/0001-estop-latch-improve-documentation-set-default-pin-va.patch
[17:35:05] <jepler> seb_kuzminsky: and also for 2.6,
http://paste.debian.net/119557/
[17:38:28] <jepler> or to avoid the bad coloring
http://paste.debian.net/plain/119557
[17:38:39] <PCW> micges-dev: uspace is master only so no Ethernet for 2.6
[17:39:07] <PCW> at least I think that's the situation
[17:39:29] <jepler> yes, no ethernet in 2.6.
[17:39:37] <micges-dev> yeah
[17:40:57] <micges-dev> PCW: double dot bug is on sserial hal pins?
[17:46:22] <PCW> yes
[17:46:41] <PCW> I think 7I76e only
[17:47:14] <PCW> something to do with the 5 character name
[17:48:27] <micges-dev> yep found it
[17:59:06] <PCW> ohh and theres a "registred" somewhere
[18:00:22] <KGB-linuxcnc> 03Michael Geszkiewicz 05master 422c844 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: support for up to 8 chars device names in sserial * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=422c844
[18:00:51] <micges-dev> I see it too
[18:01:21] <jepler> micges-dev: char name[21];
[18:01:31] <jepler> your patch doesn't change this, unless I overlooked something
[18:01:42] <jepler> micges-dev: also, a C++ tip
[18:02:06] <jepler> you can rtapi_snprintf(chan->name, sizeof(chan->name), ...) so that you don't have to change it in two places
[18:02:50] <micges-dev> right...
[18:02:57] <micges-dev> thanks
[18:03:06] <jepler> the count given to snprintf includes the size for the string-terminating NUL
[18:04:58] <jepler> (before you had an array of 21 but a snprintf argument of 20, so not sure if this was a misconception)
[18:06:23] <micges-dev> it's not my code but I think it was for safety
[18:34:10] <KGB-linuxcnc> 03Michael Geszkiewicz 05master 9d3c1d7 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c 10src/hal/drivers/mesa-hostmot2/sserial.h hostmot2: properly support for up to 8 chars device names in sserial * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d3c1d7
[18:41:37] <seb_kuzminsky> jepler:
http://paste.debian.net/plain/119557 looks good
[18:42:28] <KGB-linuxcnc> 03Michael Geszkiewicz 05master 0cdcb9b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: remove duplicated info about successfull hostmot2 registration * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0cdcb9b
[18:42:36] <seb_kuzminsky> i guess hm2-servo would benefit less from a similar fix, since the encoder feedback will ferror and estop the machine that way
[18:49:24] <seb_kuzminsky> jepler: oh, 119557 is against master, no wonder it doesn't apply to 2.6
[18:49:30] * seb_kuzminsky fixes the patch
[18:49:46] <PCW> one difference is that a wd bite would put you in estop even if not moving
[18:50:33] <micges-dev> PCW: do you have blinking led on io part on new 7i76s ?
[18:50:49] <PCW> No, no free pins
[18:51:23] <micges-dev> ah
[18:51:24] <PCW> :-(
[18:51:49] <PCW> when we move to STM :-)
[19:00:49] <KGB-linuxcnc> 03Michael Geszkiewicz 05master bda8153 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: add support for mesa 7i92 ethernet board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bda8153
[19:02:21] <PCW> Thanks!
[19:09:02] <PCW> 5i25 configs updated to latest with ICAP cookie
[19:10:20] <PCW> updating 5I24 now (takes hours and hours)
[19:12:30] <PCW> Monday Ill fix the Ethernet configs to have DPLL on anything with a stepgen
[19:12:52] <PCW> and 7I90 SPI
[19:14:20] <jepler> hours? why?!
[19:14:30] <jepler> oh are you talking the fpga firmware building?
[19:14:49] <PCW> Yes 50 or so bitfiles
[19:14:59] <PCW> I need a faster machine
[19:15:55] <jepler> at $DAY_JOB we all got 12-thread i7 machines. great for software development. probably great for fpga development.
[19:16:59] <PCW> Yeah I I should get a lower end I7 at least
[19:17:27] <micges-dev> what do you have now?
[19:17:34] <jepler> what's the state of multicore use in the xilinx tools? for hostmot2-firmware, I enabled use of build-level parallelism instead of thinking about that.
[19:20:10] <PCW> looks like there a -mt option for Spartan6 at least
[19:20:32] <seb_kuzminsky> jepler: the estop_latch .hal patch you sent me doesnt work with the estop_latch component in 2.6, as the .ok-in pin is not set True
[19:21:07] <jepler> seb_kuzminsky: ah it's cumulative with the not-quite-all-doc patch
[19:23:12] <seb_kuzminsky> is there a branch somewhere i can pull into 2.6?
[19:24:01] <jepler> seb_kuzminsky: no because I suck
[19:24:09] <jepler> seb_kuzminsky: I'll whip one up; sorry to be wasting your time
[19:25:44] <CaptHindsight> do you guys want to start testing 3.14 RTAI?
[19:25:59] <jepler> seb_kuzminsky: I guess it didn't even apply to 2.6, did it
[19:26:14] <seb_kuzminsky> CaptHindsight: i'd love to, but i dont have the bandwidth at the moment :-(
[19:26:26] <CaptHindsight> no rush
[19:26:28] <seb_kuzminsky> jepler: because of the pet_watchdog going away
[19:26:31] <seb_kuzminsky> CaptHindsight: heh
[19:27:35] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-2.6 2be9299 06linuxcnc 10src/hal/components/estop_latch.comp estop-latch: improve documentation; set default pin values * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2be9299
[19:27:36] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-2.6 4bc862e 06linuxcnc 10configs/by_interface/mesa/hm2-stepper/hm2-stepper.hal hm2-stepper: estop when hm2 watchdog bites * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4bc862e
[19:27:46] <CaptHindsight> Arc_Eye on the forums was going to build from scratch and test
[19:35:29] <jepler> seb_kuzminsky: I think I'm getting somewhere with hostomt2-firmware
[19:35:44] <jepler> seb_kuzminsky: the old version used top-level modules like 9054.vhd.in
[19:35:50] <jepler> seb_kuzminsky: those files didn't get updated
[19:36:09] <jepler> seb_kuzminsky: I'm rearranging it so that we can use the toplevel files like Top9054HostMot2.vhd that peter provides
[19:36:33] <jepler> I've gotten to the par step on the first target
[19:36:53] <jepler> so I think I'm on track
[19:37:33] <jepler> fw/3x20-1/SV24.BIT
[19:37:38] <jepler> bitfile achieve!
[19:38:07] <jepler> seb_kuzminsky: do you want crazy monkey push to hostomt2-firmware.git?
[19:39:38] <PCW> I'm trying to fix all top level files so they have the @Card@ and @Pin@ options selected
[19:40:12] <jepler> PCW: yes, at least Top9054HostMot2.vhd had that
[19:40:32] <jepler> PCW: does having @Card@ work for you in xilinx without our build stuff?
[19:41:08] <PCW> Yes I use it (with a gnarly batch file)
[19:41:41] <jepler> OK
[19:41:44] <PCW> and sed!
[19:42:25] * jepler unleashes 4 parallel builds
[19:42:34] <jepler> wish I had ise on my work machine, I'd ssh and do it htere
[19:44:42] <jepler> damned fall allergy season
[19:47:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 882a26a 06hostmot2-firmware 10build.py 10pin.py 10pinxml.py be case-insensitive in @-replacement * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=882a26a
[19:47:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 31388fb 06hostmot2-firmware 049030.vhd.in 049054.vhd.in 10build.py 04epp.vhd.in build: Use peter's toplevel vhd files * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=31388fb
[19:47:26] <hm2-buildmaster> build #22 of build is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/hm2-buildbot/builders/build/builds/22 blamelist: Jeff Epler <jepler@unpythonic.net>
[19:47:29] <jepler> seb_kuzminsky: there, have a proposed branch instead
[19:48:01] <jepler> hm that was a quick failure
[19:49:01] <PCW> I did fix all car/pin names to Card/Pin
[19:50:02] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 024311b 06hostmot2-firmware 10(5 files) build: Use peter's toplevel vhd files * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=024311b
[19:50:36] <jepler> ooh seb's machine builds with -j8
[19:52:04] <jepler> WARNING:Security:42 - Your software subscription period has lapsed. Your current
[19:52:07] <jepler> version of Xilinx tools will continue to function, but you no longer qualify for
[19:52:10] <jepler> Xilinx software updates or new releases.
[19:52:44] <PCW> yeah yeah
[19:53:30] <PCW> There are no new ISE releases (its all Vivado now)
[19:53:56] <jepler> yay, bitfiles are generating on buildbot as well
[19:56:17] <seb_kuzminsky> jepler: that VM has vCPUs
[19:56:40] <seb_kuzminsky> err
[19:56:43] <seb_kuzminsky> 8 of them
[19:57:13] <jepler> ERROR:HDLParsers:3374 - "/usr/src/hostmot2-firmware/PIN_TPEN6_6_72.vhd" Line 108. Actual for index 128 is missing in array aggregate.
[19:59:27] <jepler> maybe just some emptypin declarations missing
[20:00:00] <hm2-buildmaster> build #23 of build is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/hm2-buildbot/builders/build/builds/23 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>
[20:01:29] <jepler> since I can build not-from-clean I'll continue working on things before doing another push. but I think I have that error corrected.
[20:02:36] <PCW> I dont think that pinout file is anything but a test file (it does not work with any of our daughtercards for example)
[20:02:46] <jepler> PCW: oh really?
[20:03:13] <jepler> we build it for i23, i68, i20, i65 for some reason
[20:03:55] <PCW> probably best just dropped
[20:05:44] <PCW> maybe used when I tested the TPPWM gen the first time
[20:07:06] <seb_kuzminsky> jepler: your new proposed-2.6 branch works as advertised for me
[20:07:07] <seb_kuzminsky> thanks
[20:07:18] <jepler> I don't suppose the others => syntax can be used in ModuleID or PinDesc
[20:07:29] <PCW> the Spartan 6 builds require some funny options so may want to look at my batch file of xilinx cmd_log
[20:07:42] <PCW> maybe
[20:07:57] <seb_kuzminsky> jepler: except that it's based off the v2.6.2 tag instead of the 2.6 branch, shrug
[20:08:32] <jepler> seb_kuzminsky: do you want it rebased rather than merged?
[20:08:40] <seb_kuzminsky> i rebased it locally
[20:08:43] <jepler> ok
[20:08:45] <seb_kuzminsky> i see no need for a merge commit
[20:09:28] <seb_kuzminsky> aight, imma ingest that and extrude 2.6.3
[20:09:36] <jepler> thanks!
[20:09:41] <seb_kuzminsky> thank *you*
[20:10:20] <jepler> PCW: no new card support in hostmot2-firmware yet, that's an obvious next step though
[20:10:40] <jepler> quite a few new cards and their firmwares to add, too
[20:10:58] <PCW> yes lots of SP6 cards
[20:11:08] <jepler> looks like 3x20 was the latest card added, not that I know the chronology offhand
[20:11:32] <jepler> to me, this matters more for the cards with only volatile firmware
[20:11:37] <KGB-linuxcnc> 03Jeff Epler 052.6 9f7f497 06linuxcnc 10src/hal/components/estop_latch.comp estop-latch: improve documentation; set default pin values * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9f7f497
[20:11:37] <KGB-linuxcnc> 03Jeff Epler 052.6 1861599 06linuxcnc 10configs/by_interface/mesa/hm2-stepper/hm2-stepper.hal hm2-stepper: estop when hm2 watchdog bites * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1861599
[20:11:58] <jepler> because then we *have* to ship the firmwares with linuxcnc or people can't use the hardware
[20:13:23] <PCW> Yeah
[20:15:37] <jepler> 7i90 is spartan6?
[20:15:44] <PCW> Yes
[20:16:08] <jepler> .. and uses TopEPPSHostMot2.vhd or TopGCSPIHostMot2.vhd ?
[20:16:35] <PCW> Yes or TopSerialHostMot2.vhd
[20:16:51] <PCW> or TopSSRemote.vhd
[20:17:07] <Tom_itx> what's that one?
[20:17:14] <jepler> since I have HW for testing probably I should do that spartan6 one first
[20:17:27] <jepler> Tom_itx: 72 I/O, epp, spi, or two flavors of serial
[20:17:40] <PCW> a 72 I/O smart serial remote card
[20:17:51] <Tom_itx> using the last vhd file
[20:17:59] <PCW> yes
[20:19:15] <PCW> the first three are standard HM2 configs, the ssremote config is a like a 7i69 with 72 I/O
[20:19:38] <Tom_itx> i figured the first 3 were
[20:20:16] <PCW> (the RJ45 is a RS-422 interface compatible with sserial)
[20:20:19] <seb_kuzminsky> gods our wiki search sucks
[20:20:35] <seb_kuzminsky> searching for "release checklist" doesn't find the ReleaseChecklist page
[20:21:01] <PCW> bbl dinner
[20:23:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 19b6855 06linuxcnc 10VERSION 10debian/changelog v2.6.3 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=19b6855
[20:23:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 791d633 06linuxcnc 03v2.6.3 LinuxCNC v2.6.3 (tagged commit: 19b6855) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=791d633
[20:25:22] <seb_kuzminsky> crap, i typoed the changelog
[20:26:04] <seb_kuzminsky> oh well, maybe no one will notice
[20:29:16] <jepler> seb_kuzminsky: here ya go
http://makeameme.org/meme/signed-the-release
[20:29:24] <seb_kuzminsky> uh oh
[20:29:26] <jepler> that poor woman
[20:29:37] <seb_kuzminsky> heh yeah
[20:29:40] <seb_kuzminsky> sucks to be her
[20:32:12] <jepler> During Prohibition in the United States (1919–1933), when alcoholic beverages were illegal, cocktails were still consumed illegally in establishments known as speakeasies. [citation needed]
[20:32:34] <jepler> OK, every card that builds with xilinx 13 is built
[20:32:53] <seb_kuzminsky> am i doing it right?
http://makeameme.org/meme/the-first-rule-5yupkf
[20:32:55] <jepler> .. and which built before peter's last code push
[20:33:37] <cradek> haha
[20:41:47] <Tom_itx> everyone's a winner tonight
[21:12:23] <jepler> tequila + triple sec + lemon juice = time to stop programming for the evening
[21:15:07] <seb_kuzminsky> Redemption High Rye for me
[21:16:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master ce374f8 06hostmot2-firmware 10PIN_TPEN6_6_72.vhd 10build.py tpen6_6_72: fill out pin structure with empty pins to the idromv3 size * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=ce374f8
[21:16:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master e94730e 06hostmot2-firmware 10TopEPPHostMot2.vhd 10TopSerial16HostMot2.vhd Top*: fix card/pin selection * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=e94730e
[21:16:45] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master e511bb7 06hostmot2-firmware 10build.py build: look for local settings.sh symlinks as README promises * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=e511bb7
[21:16:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master eacca95 06hostmot2-firmware 10README README: remove out-of-date note about 'par -r' * 14http://git.linuxcnc.org/?p=hostmot2-firmware.git;a=commitdiff;h=eacca95
[21:25:33] <jepler> pcw_home: I'm not sure where I'd find your batch file for the spartan6 options. I have a 7i90.zip but didn't find any cmd_log or relevant .bat files
[21:27:27] <jepler> maybe these non-default options in seveni90.xise are worth looking at though
[21:27:30] <jepler> http://paste.debian.net/119567/
[21:34:02] <skunkworks> camp fire and wine (and smores) for me.
[21:35:14] <seb_kuzminsky> and wifi, apparently
[21:36:55] <skunkworks> it is over... (we have a wee one..)
[21:37:08] <skunkworks> bath and in bed.
[21:37:28] <skunkworks> but yes - the camp fire is within wifi..
[21:40:59] <seb_kuzminsky> that sounds nice
[21:41:07] <seb_kuzminsky> wish i could have a campfire in my back yard
[21:42:27] <jepler> program finished with exit code 0
[21:42:27] <jepler> elapsedTime=1085.201736
[21:43:53] <jepler> wow it built .. and in under 20 minutes
[21:46:04] <jepler> pcw_home: I found two vhd files didn't have the right use @foo@ lines:
http://git.linuxcnc.org/gitweb?p=hostmot2-firmware.git;a=commitdiff;h=e94730e1d4bafd05a3a2af6ca0b87deb08da63f5
[22:47:13] <pcw_home> I will fix (that latest source will need 3 .vhd files added to the source list for the DPLL sampled stepgen option)
[22:47:14] <pcw_home> plus some pinout files that make use of the option (add DPLL)
[22:54:27] <pcw_home> freeby.mesanet.com/scripts.zip
[22:54:58] <pcw_home> has some build scripts for the 7I90 and others