Back
[06:24:05] <jthornton> I forgot to hit the sign off button on a commit, is there a way to post sign off the commit?
[06:24:19] <jthornton> remote: 607bfe6 Docs: add info on asciidoc markup
[06:58:43] <jthornton> never mind I figured out how to reset my branch then commit again
[06:59:37] <KGB-linuxcnc> 03John Thornton 052.7 9b09a87 06linuxcnc 10docs/asciidoc-markup.txt Docs: add markup info * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9b09a87
[06:59:37] <KGB-linuxcnc> 03John Thornton 052.7 cba0adc 06linuxcnc 10(13 files in 7 dirs) Docs: delete unused anchors and use same naming convention * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cba0adc
[07:00:57] <skunkworks> so I don't know what I am doing wrong
[07:01:00] <skunkworks> http://pastebin.com/TvmLJi8B
[07:01:17] <skunkworks> seb says it should be 2.7?
[07:02:16] <jthornton> running a RIP?
[07:02:27] <skunkworks> yes
[07:03:07] <jthornton> did you run . ./scripts/rip-environment?
[07:03:10] <skunkworks> yes
[07:03:18] <skunkworks> I did a ./autogen
[07:03:33] <skunkworks> ./configure --with-realtime=uspace
[07:03:39] <skunkworks> then make clean and make
[07:03:46] <skunkworks> sudo make setuid
[07:04:26] <jthornton> dunno if it makes a difference by my notes say to do ./autogen.sh
[07:04:37] <skunkworks> yes - sorry
[07:04:56] <jthornton> got me stumped
[07:09:52] <jthornton> I was trying to test it here but got this error with configure checking for libudev... configure: error: libudev-dev not found
[07:14:19] <skunkworks> apt-get install?
[07:17:19] <jthornton> yes seems to be working, might run out of time
[07:33:20] <jthornton> I started with a fresh terminal and got LINUXCNC - 2.7.0~pre6
[07:33:21] <jepler> hm2_eth is *supposed* to work with 2 cards on 2 nics, but I sure didn't test that combination
[07:33:45] <jthornton> gotta run
[07:34:06] <skunkworks> Good morning
[07:35:03] <skunkworks> Am I running the right build?
[07:35:39] <jepler> like everyone else, I agree it's weird that you get a 2.8 version number
[07:36:26] <jepler> $ git describe origin/jepler/hm2-eth-startup
[07:36:26] <jepler> v2.7.0-pre6-211-g5bc678a
[07:36:56] <skunkworks> well that doesn't make sense
[07:40:20] <skunkworks> I had just greated a new repository and I get a different git describe than that.
[07:40:25] <skunkworks> *created
[07:40:34] <skunkworks> and different than my last one.
[07:40:38] * skunkworks is confused
[07:41:05] <skunkworks> and when you launch it - it says 2.8.0~pre1 still
[07:41:28] <skunkworks> Am I not successfully checking out your branch?
[07:41:47] <skunkworks> I do a git checkout -b jepler/hm2-eth-startup
[07:41:51] <jepler> what does "git describe" (no args) say?
[07:42:44] <skunkworks> http://pastebin.com/aiBburKQ
[07:43:32] <jepler> $ git describe origin/master
[07:43:33] <jepler> v2.7.0-pre6-346-g77eb37d
[07:43:59] <jepler> you created a branch named jepler/hm2-eth-startup but you have it pointing at origin/master
[07:44:30] <jepler> you can go to the correct ref, discarding any local changes, with: git reset --hard origin/jepler/hm2-eth-startup
[07:45:02] <skunkworks> is it because I didn't do origin/jepler.. in checkout?
[07:45:12] <skunkworks> just jepler/
[07:46:00] <jepler> I don't know what command you initiall wrote, but it was the wrong one :-P
[07:46:12] <jepler> $ git checkout jepler/hm2-eth-startup
[07:46:15] <jepler> Branch jepler/hm2-eth-startup set up to track remote branch jepler/hm2-eth-startup from origin.
[07:46:18] <jepler> Switched to a new branch 'jepler/hm2-eth-startup'
[07:46:23] <jepler> this is the command I would use
[07:46:35] <jepler> and the output I'd expect to get the first time in a particular repo
[07:48:26] <skunkworks> was it the -b maybe?
[07:48:40] <skunkworks> Because I thought I got that ouput also.
[07:49:03] <jepler> ah you did post the command you use
[07:49:05] <jepler> +d
[07:49:42] <jepler> yes, git checkout -b ham-sandwich starts a new branch called ham-sandwich at the same ref you were at already -- master, in this case
[07:49:52] <skunkworks> ah
[07:50:32] <skunkworks> if I would have named it - it would have worked I bet. git checkout -b jeplers-ethernet-stuff jepler/hm2-eth-startup
[07:51:00] <jepler> you can give a start point as an additional argument. in that case you'd have had to specify origin/ there.
[07:51:21] <jepler> $ git checkout -b eggs-over-easy origin/jepler/hm2-eth-startup
[07:51:24] <jepler> Branch eggs-over-easy set up to track remote branch jepler/hm2-eth-startup from origin.
[07:51:27] <jepler> Switched to a new branch 'eggs-over-easy'
[07:52:41] <jepler> afk
[07:55:41] <skunkworks> jepler,
http://pastebin.com/5yBrdRxG
[07:55:44] <skunkworks> Yay!!
[08:21:08] <jepler> skunkworks: this is with 2 nics? great, we can check that compatibility question off the list
[08:21:20] <skunkworks> Yes!
[08:22:07] <jepler> while running, in another terminal, do sudo iptables-save and pastebin the output please
[08:22:26] <jepler> alternately, while linuxcnc is running see if you can "ping" the mesa cards
[08:23:25] <jepler> (you shouln't be able to)
[08:23:51] <skunkworks> http://pastebin.com/d55FAXQ9
[08:24:48] <jepler> looks good
[08:25:00] <skunkworks> operation not permitteed
[08:25:07] <skunkworks> for both
[08:25:09] <skunkworks> awesome!
[08:25:11] <jepler> good again
[08:25:27] <jepler> one last test I'd ask you for ..
[08:25:27] <skunkworks> and my wireless internet access still works
[08:25:40] <jepler> restart linuxcnc 10 times and make sure it starts everytime
[08:25:45] <skunkworks> ok
[08:26:09] <jepler> one problem peter and I have seen is it being flaky with detecting the ethernet cards at startup, and that's what the specific branch you're testing is supposed to fix
[08:28:17] <skunkworks> 10X no issues
[08:28:28] <jepler> thank you for testing
[08:29:25] <skunkworks> Thank you for making this so flexable
[08:29:53] <jepler> seb_kuzminsky: I don't remember whether I asked you to review this branch, but since the testing is going so well I think it's time
[08:44:36] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 d4cb237 06linuxcnc 10docs/src/hal/rtcomps.txt docs: don't force image width for step type diagram * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d4cb237
[09:24:15] <jthornton> IIRC that image is so huge if you don't force the size it is not fully viewable in the pdf docs
[09:25:38] <seb_kuzminsky> jthornton: i just tested it, bernie is correct
[09:25:54] <seb_kuzminsky> in the old docs (before this morning) the image gets cut off in the pdf and doesn't fit
[09:26:05] <seb_kuzminsky> in the new docs (after that commit) it's scaled to fit the pdf page
[09:26:30] <seb_kuzminsky> (at least on my wheezy build system, which has asciidoc 8.6.7-1)
[09:27:01] <skunkworks> is the mesa flash in the repository updated?
[09:27:01] <skunkworks> http://pastebin.com/RaeHjJKy
[09:27:18] <seb_kuzminsky> which is what the buildbot builds the official docs with too
[09:27:58] <seb_kuzminsky> jthornton: i haven't found a way to make both our html and pdf backends scale the too-big image to fill the page
[09:28:07] <seb_kuzminsky> the options i've found are:
[09:28:36] <mozmck> skunkworks: which repository?
[09:28:41] <seb_kuzminsky> 1 (what we did before): force a width, if it's too big the pdf cuts off the image and the html gives you scrollbars
[09:29:02] <seb_kuzminsky> 2 (what we do now): don't force a width, pdf scales it down to fit if needed, html gives you scrollbars if it's too big
[09:29:08] <seb_kuzminsky> what i want is:
[09:29:46] <seb_kuzminsky> both pdf and html should leave the image size alone if it fits on the pdf page & the user's browser, and scale it down (just enough, & maintaining ascpect ratio) if it's too big to fit
[09:29:52] <seb_kuzminsky> but i dont know how to tell asciidoc that
[09:30:18] <skunkworks> linuxcnc
[09:30:30] <mozmck> skunkworks: I'm pretty sure the master repository for mesaflash is here:
https://github.com/micges/mesaflash.git and that one works with 7i92
[09:30:44] <seb_kuzminsky> hm, and the docs landing page doesn't know about the new pdf names:
http://linuxcnc.org/docs/2.7/
[09:31:16] <mozmck> skunkworks: I didn't even know mesaflash was in the linuxcnc repository
[09:31:58] <cradek> yeah the idea was that people would automatically get updates to it
[09:32:34] <skunkworks> I just did an apt-get update/upgrade (didn't notice if mesaflash is getting updated..)
[09:32:35] <cradek> except we haven't been good at knowing when to push them out, and people often give the advice of "build from the latest source" instead
[09:32:50] <cradek> and once you do that you never get updates
[09:32:56] <skunkworks> rigbht
[09:32:57] <skunkworks> right
[09:33:23] <skunkworks> Is that error most likely a mesa flash issue or something else?
[09:33:34] <cradek> I don't agree with the advice to get the latest source. mesaflash should have releases when it's stable and bugfixed, just like linuxcnc, and we'll push it to all the users at once.
[09:33:35] <pcw_home> mesaflash
[09:33:41] <seb_kuzminsky> it'd be smop to set up a mesaflash buildbot to keep the deb archive up to date with the source repo
[09:34:07] <skunkworks> pcw_home, do you know if the latest on linuxcnc is fixed?
[09:34:50] <pcw_home> Dont know but the 7I92 chip name error is the last error I know about
[09:34:56] <cradek> mesaflash:
[09:34:56] <cradek> Installed: 3.1.0
[09:34:56] <cradek> Candidate: 3.1.0
[09:35:35] <seb_kuzminsky> hm, the french docs still have the split pdfs
[09:36:01] <skunkworks> that is the same version. Could we get the latest stable on linuxcnc?
[09:36:39] <skunkworks> we would need that for 2.7 for sure.
[09:38:50] <seb_kuzminsky> in the mesaflash git repo there's one commit on the v3.1 branch that's newer than our debs, "Always show full info about bit file while using 'info' command"
[09:38:56] <seb_kuzminsky> are you talking about something in the master branch?
[09:39:47] <seb_kuzminsky> oh yeah, lots of new stuff in master
[09:40:16] <seb_kuzminsky> and the 3.1 branch has never been merged into master, is that intentional?
[09:44:25] <skunkworks> pcw_home, can you force the program?
[09:44:27] <jthornton> seb_kuzminsky, great to know that the images scale properly YEA
[09:44:50] <pcw_home> force it?
[09:45:21] <skunkworks> (using the older mesaflash - can you force it to send the bit file to the 7i92?)
[09:45:34] <skunkworks> using the older mesaflash
[09:46:51] <pcw_home> On a very old version (Years old) you can program any Ethernet card (it doesn't check)
[09:48:01] <mozmck> I think if it complains, you can't force it.
[09:49:03] <seb_kuzminsky> jthornton: maybe wheezy's newer version of asciidoc does something better with the pdf backend than the old one did
[09:49:52] <jthornton> I'm glad it does, I removed the other occurrence of width=800
[09:51:58] <seb_kuzminsky> alright, cool
[09:52:25] <seb_kuzminsky> fixed pixel widths are a pretty bogus workaround in any situation
[09:52:33] <seb_kuzminsky> i'll merge it to master for gene
[09:53:11] <JT-Shop> I'll push it as soon as it is done building
[09:54:01] <skunkworks> how do you run the mesaflash from the utility diretory?
[09:54:29] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 b8d0661 06linuxcnc 10docs/src/Master_Getting_Started_es.txt 04docs/src/getting-started/Updating_LinuxCNC_es.txt 03docs/src/getting-started/updating-linuxcnc-es.txt docs: finish spanish .txt file rename * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8d0661
[09:54:50] <seb_kuzminsky> ugh: == Actualizando de 2.4.x a 2.5.x
[09:56:48] <seb_kuzminsky> rob ellenberg's brain got hacked
[09:57:02] <cradek> well something did
[09:57:20] <seb_kuzminsky> I Kill Kokomo
[09:57:24] <skunkworks> uh oh.
[09:57:24] <mozmck> skunkworks: you can change to a directory in a terminal, then run an executable file with ./ - so for mesaflash it would be something like ./mesaflash
[09:57:39] <skunkworks> hmm - I tried that.
[09:57:52] <mozmck> sounds more like rob is running windows :)
[09:58:02] <pcw_home> skunkworks: if you want a quick fix (that cradek wont like) fetch the source from github and build the latest
[09:58:07] <mozmck> skunkworks: did it not run?
[09:58:37] <cradek> !!!
[09:58:39] <cradek> :-P
[09:59:07] <mozmck> skunkworks: you can even do fakeroot debian/rules binary and it will build a deb package.
[10:02:21] <skunkworks> http://pastebin.com/93AkKQnh
[10:02:37] <pcw_home> https://github.com/micges/mesaflash
[10:03:12] <skunkworks> although if you do ./mesaflash it seems to be an older version (support software for the 7i92)
[10:03:18] <skunkworks> 3.0.0
[10:04:23] <pcw_home> I need to just delete that
[10:04:54] <seb_kuzminsky> skunkworks: the mesaflash master branch still says version 3.0.0, so it might not be wrong
[10:19:26] <linuxcnc-build_> build #3294 of 1306.rip-precise-amd64 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3294 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[10:20:08] <seb_kuzminsky> noooo
[10:20:40] <seb_kuzminsky> it's that dropped-mdi bug again
[10:20:48] <seb_kuzminsky> i should deal with that one of these days
[10:20:51] <skunkworks> http://pastebin.com/N1eEzCYX
[10:21:01] <skunkworks> seems to me I am missing a dependency
[10:21:14] <seb_kuzminsky> skunkworks: looks like
[10:21:24] <seb_kuzminsky> from the top-level directory (the one with debian/ in it)
[10:21:29] <seb_kuzminsky> run "dpkg-checkbuilddeps"
[10:21:33] <seb_kuzminsky> it'll tell you what you're missing
[10:23:29] <skunkworks> that works
[10:23:32] <skunkworks> flashing now
[10:23:36] <skunkworks> it does say 3.2
[10:25:48] <seb_kuzminsky> oh, i see that the version string in the mesaflash program in master is different from the debian package version in debian/control
[10:58:48] <linuxcnc-build_> build #3303 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3303 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:05:35] <seb_kuzminsky> linuxcnc-build_: force build --branch=2.7 2000.docs
[11:05:35] <linuxcnc-build_> build forced [ETA 10m03s]
[11:05:36] <linuxcnc-build_> I'll give a shout when the build finishes
[11:13:55] <linuxcnc-build_> Hey! build 2000.docs #2694 is complete: Success [3build successful]
[11:13:55] <linuxcnc-build_> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/2694
[11:22:18] <skunkworks> so what is the magic config line to get the 7i92 to recognize the 7i77?
[11:23:04] <skunkworks> or should it just recognize it?
[11:23:58] <jepler> "this is set using the sserial_port_N= option in the hm2_pci[sic] modparam" -- man sserial
[11:24:40] <jepler> seems to be explained in further detail in man hostmot2 down at sserial_port_N
[11:28:21] <jepler> PCW: ethernet must add a lot to the BOM cost ? Just pondering the price difference between 7i80 and 7i90..
[11:29:17] <jepler> PCW: trivial typo on store page for 7i80hd-16, stray "0" after the link "download support software"
[11:37:59] <skunkworks> with no config line I would think it would find it..
[11:38:08] <skunkworks> maybe my cable is bad.
[11:40:02] <pcw_home> it should recognize it (the I/O section will not work unless there is field I/O power)
[11:40:41] <pcw_home> main cost difference in 7I90 and 7I92 is number of parts (so assy cost mostly)
[11:41:58] <pcw_home> 7i92 BOM cost is probably about ~$20
[11:43:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 6a5ad14 06linuxcnc 10docs/man/man9/hostmot2.9 10src/emc/rs274ngc/rs274ngc_pre.cc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6a5ad14
[11:44:38] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master fc374e3 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fc374e3
[11:57:36] <jepler> pcw_home: interesting, thanks
[12:22:20] <skunkworks> This is what I get with no config line
http://pastebin.com/Cdb4nQzq
[12:22:49] <skunkworks> I have the field power and 5v on the 7i77
[12:23:40] <pcw_home> 7i77 on DB25?
[12:25:52] <skunkworks> yes
[12:26:04] <skunkworks> maybe my parrallel cable is not good
[12:26:22] <pcw_home> might need sserial_port_0=000xxxxx
[12:27:52] <pcw_home> though I think sserial port 0 defaults to 00000000 (and sserial port 1 defaults to xxxxxxxx)
[12:28:17] <pcw_home> so sserial port 0 should work
[12:28:31] <pcw_home> without any config string
[12:31:50] <skunkworks> that is how I read it..
[12:35:56] <skunkworks> The 5v power is confusing in the direction..
[12:35:56] <skunkworks> When TB1 is used with an external 5V supply (not 5V from the host PC) , W5 must
[12:35:57] <skunkworks> be in the right-hand position to avoid back-powering the host computer via the host
[12:35:57] <skunkworks> interface card. TB1 is a two pin 3.5 MM pluggable terminal block supplied one two pin
[12:35:57] <skunkworks> removable screw terminal plug. TB1 pinout is as follows
[12:36:26] <skunkworks> I am using a 5 v supply - so I should have the jumper to the left?
[12:36:43] <skunkworks> sorry - right?
[12:36:50] <skunkworks> *right hand
[12:37:19] <skunkworks> it is defaluted to the left
[12:38:13] <pcw_home> yes right position if you are using a external 5V supply
[12:38:15] <pcw_home> _AND_ 7I92 must be jumpered to not supply 5V
[12:48:09] <skunkworks> http://pastebin.com/Gm7vu7XW
[12:50:09] <skunkworks> although - shouldn't I be getting more i/o?
[12:53:39] <skunkworks> ah - it doesn't show in the initalization - it does show in the show pin.
[13:19:03] <jthornton> lesson learned never grep before git pull --rebase or you'll chase your tail trying to fix something that Seb has already fixed
[13:19:57] <jthornton> seb_kuzminsky, this page still lists the User, Integrator, and HAL pdf manuals. Is that a hard coded page?
[13:23:01] <skunkworks> cradek, I don't know what he is trying to do..
http://www.linuxcnc.org/index.php/english/forum/40-subroutines-and-ngcgui/29451-rigid-tapping-fail-advice-and-qdiscriminantq-err?start=20
[13:23:33] <skunkworks> he is not directly connecting encoder positon to motion - it is going throug a mult..
[13:25:07] <cradek> haha it jumps by 35 turns
[13:25:12] <cradek> toldya
[13:25:43] <PCW> thats going to be hard to follow
[13:27:47] <cradek> net spindle-reversed <= motion.spindle-reverse => mux2.0.sel
[13:27:54] <cradek> he doesn't have a real encoder
[13:28:15] <cradek> he's made a hal setup to assume the spindle is going in the commanded direction
[13:28:57] <cradek> that ain't gonna work
[13:29:25] <cradek> I wish people would know when they've done something crazy
[13:30:27] <cradek> setp hm2_5i25.0.encoder.00.counter-mode 1
[13:30:34] <cradek> jeez louise
[13:31:00] <skunkworks> does he not have a 2 channel encoder?
[13:31:12] <cradek> no
[13:31:16] <skunkworks> ugh
[13:31:59] <PCW> Not going to rigid tap unless you have a real encoder
[13:32:49] <PCW> (or if linuxcnc supported servo spindles)
[13:33:49] <archivist> the hard part is a polite reply to him
[13:34:01] <cradek> how could you look at that halscope plot and NOT say: oh crap I see what's very clearly wrong
[13:41:52] <mozmck> Lack of knowledge?
[13:43:12] <andypugh> So, who is going to tell him what is wrong?
[13:43:16] <PCW> archivist: Maybe " Unfortunately you cannot code around the requirement for a real encoder (that has A and B channels so can count up and down) "
[13:43:47] <andypugh> I bet you can. You need a ddt on the counts so that it only allows the direction to flip at zero speed
[13:44:09] <andypugh> :-)
[13:44:26] <PCW> Yeah a PLL is possible but very tricky to make work over a wide range of conditions
[13:44:52] <PCW> easier with a high res encoder
[13:45:03] <cradek> it seems hard to figure out when zero speed is hit
[13:45:45] <andypugh> You don’t need to be super-exact, because nothing is moving physically at that point either.
[13:45:59] <PCW> yep if you can throw away a count or so its probably possible
[13:46:16] <andypugh> I am not saying that is it sensible or wise.
[13:46:32] <cradek> that should be our new motto
[13:47:35] <andypugh> Am I also right in guessing that motion.spindle-revs is linked to a spindle speed, not a position?
[13:47:46] <cradek> spindle-revs is position
[13:47:46] <skunkworks> if it dithers at one transition - it isn't going to work very well
[13:47:57] <andypugh> (an understandable mistake)
[13:48:02] <cradek> there is also a spindle velocity input for fpr etc
[13:48:11] <cradek> tapping is a position mode problem
[13:48:15] <andypugh> cradek: I was meaning in his config, looking at the halscope
[13:48:43] <cradek> I think it's position...?
[13:49:36] <andypugh> I haven’t seen the HAL, but I am not seeing how the position would jump like that, but the measured velocity would with a switch in counting direction.
[13:49:49] <cradek> it's his crazy hal
[13:50:04] <cradek> he flips the sign of the feedback when the *commanded* spindle direction changes
[13:50:18] <PCW> the position jumps because he inverts it
[13:50:20] <archivist> ew
[13:50:34] <cradek> he probably did it to make G33 + M4 work
[13:50:51] <cradek> which it would
[13:51:05] <cradek> but that doesn't mean he can tap
[13:51:14] <andypugh> It’s not 100% crazy, just slightly
[13:51:27] <cradek> it's fine for threading
[13:51:58] <andypugh> So he should single-point his threads
[13:52:00] <cradek> (he should flip the encoder gain so it counts backwards instead of negating)
[13:52:09] <cradek> would avoid the jump
[13:52:18] <andypugh> Would still be wrong, though.
[13:52:23] <cradek> sure
[13:52:24] <cradek> won't fix tapping
[13:52:36] <PCW> yep still a tap breaker
[13:54:15] <skunkworks> I found my good m-m parallel cable... (it was hooked between the 5i25 and a printer port..
[14:00:25] <andypugh> skunkworks: Mach testing?
[14:00:30] <skunkworks> yes
[14:00:36] <skunkworks> and grbl
[14:01:11] <skunkworks> I got brian (mach4) to admit that mach4 has the same exact TP as mach3
[14:01:42] <skunkworks> (people where complaining about path following with mach4 - and there is no path following adjustment in mach4 *yet)
[14:13:53] <seb_kuzminsky> jthornton: yeah, the docs-per-branch pages are static html:
http://linuxcnc.org/docs/2.6/
[14:14:09] <seb_kuzminsky> it'd be better if they were generated by the docs build system probably
[14:15:35] <jthornton> I kinda thought they might be static pages
[14:16:18] <seb_kuzminsky> yeah :-/
[14:18:06] <skunkworks> andypugh, mach4
http://electronicsam.com/images/KandT/testing/grbl/mach4poslogpath.png
[14:18:25] <skunkworks> mach3
http://electronicsam.com/images/KandT/testing/grbl/mach3poslogpath.png
[14:33:34] <skunkworks> and I hooked up the 7i73 correctly. wow - lots of pins
[14:34:51] <skunkworks> Should I reply to tome?
[14:43:40] <skunkworks> mesa hardware is awesome!
[15:16:17] <skunkworks> http://pastebin.ca/3080910
[15:20:15] <andypugh> Yikes thats a lot of pins
[15:21:39] <skunkworks> how about
http://pastebin.ca/3080919
[15:23:34] <andypugh> I wonder if HAL can actually service them all fast enough?
[15:24:09] <skunkworks> I think peter and jeff have been running multible cards reading and writing 2 or mre khz
[15:25:33] <skunkworks> (I don't need 'that' much i/o - just testing)
[15:25:39] <skunkworks> bbl
[15:26:40] <andypugh> But maybe not running all the step / encoder / pwm HAL drivers
[16:01:13] <skunksleep> No clue at what point the hal modules would take too long to process compared to the servo time
[16:01:49] <skunksleep> Computer power dependent too
[16:10:08] <jepler> yeah peter has been running, 2 cards at 2kHz, but the second one (maybe both?) are just I/O
[16:10:33] <jepler> I'm running 3 cards at 1.5kHz, 2 just I/O, but for <1 day continuously due to interruptions
[16:10:52] <jepler> in my case it's also hal only, not hal+linuxcnc
[16:11:36] <jepler> but it looks like each additional hm2 ethernet card is only costing ~80us per servo period when using the read-request methods
[16:27:29] <PCW> I have 2 cards running at 3 KHz, a 7i76E running motion and field I/O + a 7I90 sserial remote doing 72 GPIO + a 7I80 just with GPIO
[16:28:19] <seb_kuzminsky> jepler & PCW : sweet!
[16:28:48] <jepler> seb_kuzminsky: do you want to review that latest branch (the one concerned with fixing flaky detection) before I push it?
[16:28:52] <PCW> maximum servo thread time after a week or so is 195 usec sp 4 KHz with 2 Ethernet card may be possible if you can get by the startup delays
[16:39:03] <seb_kuzminsky> jepler/hm2-eth-setup?
[16:40:18] <jepler> seb_kuzminsky: -startup yes
[16:40:48] * seb_kuzminsky looks
[16:41:28] <jepler> my one question mark is whether this one is simply unnecessary: hm2_eth: use a longer timeout during setup
[16:41:44] <jepler> in retrospect I don't think that was the real problem, and the non-looping recv (fixed in the next commit) was
[16:42:11] <andypugh> If you timeout something is wrong. Does it matter how long you wait for fail?
[16:42:13] <jepler> I can pretty quickly run 100 (maybe 1000) startup tests without it
[16:42:59] <jepler> I mean, I propose to do that test
[16:43:04] <jepler> andypugh: there's some initial communication that happens not from a realtime thread
[16:43:31] <jepler> andypugh: that communication sometimes would time out, when using a receive timeout of 10us
[16:44:20] <jepler> I increased that timeout to 1000us but that still wasn't a fix
[16:44:22] <andypugh> Anyway, looking for this duplicate O-word problem. Where to start? I have a feeling that the answer is “man gdb” ?
[16:46:22] <jepler> personally I'd go grepping around the code and see if I can find a place where "line numbers" are used differently depending whether you're in the middle of a remapo
[16:46:25] <jepler> s/o$//
[16:47:39] <jepler> and debugging task / interp via printf is totally viable if that's how you roll
[16:48:14] <jepler> .. if it's the commandline aspect of gdb that makes your teeth itch, there are graphical front-ends, but I can't vouch for how well any of 'em work.
https://sourceware.org/gdb/wiki/GDB%20Front%20Ends
[16:48:40] <andypugh> Just reading :
http://www.drdobbs.com/testing/13-linux-debuggers-for-c-reviewed/240156817
[16:48:42] <jepler> afk
[16:50:16] <andypugh> I was until last year using Eclipse on my mac to edit code then compiling on whatever hardware was handy and not busy. But doing it that way means that you can’t use the Eclipse debugger. (well, GDB gui really)
[16:50:42] <andypugh> So, native Eclipse might be the way to go
[16:55:15] <seb_kuzminsky> jepler: looking at "hm2_eth: reset errno before socket recv", i dont see where you're using errno in such a way that you need to reset it, but i believe you that you are, somewhere
[16:58:04] <seb_kuzminsky> jepler: looks good to me
[16:58:23] <seb_kuzminsky> i dont know all the intricacies, but i dont see anything that looks obviously off in that branch
[16:59:03] <seb_kuzminsky> i agree that the longer timeout for setup and the looping during setup both independently accomplish the goal of waiting for the reply for longer, during the setup
[17:01:44] <seb_kuzminsky> i dont understand why setup-time receive needs to wait longer, but i bet there are reasons
[17:45:07] <seb_kuzminsky> Announcement! This is the official theme song of LinuxCNC 2.7:
https://www.youtube.com/watch?v=9_5_AD9wXuY
[17:47:27] <JT-Shop> I like that song too
[17:51:44] <JT-Shop> this is a favorite
https://www.youtube.com/watch?v=DUDtFdnn9oQ
[18:00:47] <seb_kuzminsky> sounds like something my little kids would sing
[18:11:42] <andypugh> seb_kuzminsky: Suddenly that song makes sense
[18:11:59] <andypugh> (just saw RE’s email)
[18:14:33] <jthornton> I've had that happen to me when I put my stupid phone in my pocket without turning the screen off
[18:38:25] <andypugh> I had a phone (Motorola) where pressing one key repeatedly would turn the phone on and dial the first number in the phonebook.
[18:38:43] <andypugh> (I arranged for the first number to be the phones own number)
[18:39:11] <andypugh> That was the same phone that could send txt messages, but not to numbers from the phone book.
[19:38:38] <jepler> seb_kuzminsky: the setting of errno to 0 looks like it went with some unfinished work
[19:39:13] <jepler> seb_kuzminsky: in the event that a packet is not recv'd (recv returned -1 and set errno) OR that a packet is received but is the wrong size, the code should log an rtapi error message, including strerror(errno)
[19:39:36] <jepler> .. but if the return value is >= 0 but != expected, I want errno to be 0 (success)
[19:39:53] <jepler> not the left over errno of some other syscall
[20:23:29] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-remap-bug 3e9eccd 06linuxcnc 10(10 files) tests: add a test for the remap bug Andy Pugh found * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3e9eccd
[20:24:05] <seb_kuzminsky> jepler: ah yes, the good old "Error: Success"
[20:24:08] <seb_kuzminsky> love that one
[20:24:34] <seb_kuzminsky> the 2.6-remap-bug branch reproduces the "duplicate O-word" bug in runtestable form
[20:24:46] <seb_kuzminsky> i removed as much as i could without making the bug go away
[20:25:53] <seb_kuzminsky> if i remove the M66 in toolchange.ngc, it no longer prints that "duplicate O-word" error
[20:25:59] <seb_kuzminsky> and then the test passes
[20:27:43] <jepler> somebody mumbled that it might "have to do with queue busters", of which I think M66 are one
[20:28:07] <seb_kuzminsky> bbl
[20:45:09] <linuxcnc-build_> build #1456 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1456 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:46:34] <linuxcnc-build_> build #1455 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1455 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:46:41] <linuxcnc-build_> build #3295 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3295 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:47:55] <linuxcnc-build_> build #3296 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3296 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:48:03] <linuxcnc-build_> build #1118 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1118 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:49:26] <linuxcnc-build_> build #3297 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3297 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:50:44] <linuxcnc-build_> build #2499 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2499 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:53:17] <linuxcnc-build_> build #3296 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3296 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[21:04:38] <linuxcnc-build_> build #3299 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3299 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[21:04:38] <linuxcnc-build_> build #3306 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3306 blamelist: Sebastian Kuzminsky <seb@highlab.com>
