Back
[03:01:18] <cmorley> mozmck: that's great, I am glad you are winning the good fight :) night
[07:10:56] <KGB-linuxcnc> 03John Thornton 052.7_Docs 20fd28b 06linuxcnc 10(5 files in 2 dirs) add collapsing/expanding to html index lists * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=20fd28b
[07:11:04] <jthornton> and now we wait for buildbot to do it's magic
[07:15:00] <linuxcnc-build> build #1302 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1302 blamelist: John Thornton <bjt128@gmail.com>
[07:15:07] <linuxcnc-build> build #1493 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1493 blamelist: John Thornton <bjt128@gmail.com>
[07:15:19] <linuxcnc-build> build #1302 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1302 blamelist: John Thornton <bjt128@gmail.com>
[07:15:58] <linuxcnc-build> build #813 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/813 blamelist: John Thornton <bjt128@gmail.com>
[07:16:02] <linuxcnc-build> build #965 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/965 blamelist: John Thornton <bjt128@gmail.com>
[07:17:06] <linuxcnc-build> build #1332 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1332 blamelist: John Thornton <bjt128@gmail.com>
[07:18:01] <linuxcnc-build> build #3144 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/3144 blamelist: John Thornton <bjt128@gmail.com>
[07:18:09] <linuxcnc-build> build #3146 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3146 blamelist: John Thornton <bjt128@gmail.com>
[07:18:22] <linuxcnc-build> build #3145 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3145 blamelist: John Thornton <bjt128@gmail.com>
[07:18:33] <linuxcnc-build> build #3145 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3145 blamelist: John Thornton <bjt128@gmail.com>
[07:18:49] <linuxcnc-build> build #3145 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3145 blamelist: John Thornton <bjt128@gmail.com>
[07:22:08] <linuxcnc-build> build #2348 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2348 blamelist: John Thornton <bjt128@gmail.com>
[07:31:47] <linuxcnc-build> build #3155 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3155 blamelist: John Thornton <bjt128@gmail.com>
[07:34:27] <jthornton> I wonder what I broke
[07:39:58] <jthornton> I think I know what I broke
[08:46:40] <cradek> make: Failed to remake makefile `Makefile'.
[08:46:41] <cradek> hmm
[08:47:11] <cradek> if you build from clean do you not get the error?
[08:47:38] <cradek> jthornton:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?FailedToRemakeMakefile
[09:06:11] <jthornton> copy and paste error on my part, just building again local before pushing
[09:14:19] <jthornton> crumb, I set my local branch back one commit and fixed the problem and now it won't let me push. Should I delete the 2.7_Docs branch with git push origin :2.7_Docs or is there another way to fix my situation
[09:19:20] <mozmck> --force
[09:19:43] <jthornton> ok, let me test that
[09:20:54] <jthornton> john@cave:~/emc-dev/src$ git push --force --dry-run
[09:20:54] <jthornton> To ssh://jthornton@git.linuxcnc.org/git/emc2.git
[09:20:54] <jthornton> + d861045...fde52dc 2.7 -> 2.7 (forced update)
[09:20:54] <jthornton> + 20fd28b...7158ed2 2.7_Docs -> 2.7_Docs (forced update)
[09:20:54] <jthornton> + 4ef4cb5...e743793 master -> master (forced update)
[09:21:01] <jthornton> not quite what I expeced
[09:21:22] <mozmck> hmm, don't know about that!
[09:21:50] <mozmck> Do you have changes in 2.7 and master as well?
[09:21:54] <jthornton> I assume it should only do the branch I'm currently on
[09:21:59] <jthornton> no
[09:23:04] <mozmck> I think you can specifiy the branch to push as well, but I'm not a git wizard yet
[09:24:15] <jepler> jthornton: you just did a bad thing
[09:24:31] <jthornton> yes, I know
[09:24:43] <jepler> but if you did it with --dry-run then you didn't *actually* do the bad thing
[09:25:01] <mozmck> :)
[09:25:08] <jthornton> oh that yes --dry-run for sure if I don't know what will happen
[09:25:36] <mozmck> jepler: why would it try to update 2.7 and master?
[09:25:59] <jepler> jthornton: what is your git version (git --version)
[09:26:21] <jthornton> git version 1.7.10.4
[09:27:06] <jepler> jthornton: what, if anything, does this print? git config push.default
[09:27:29] <jthornton> nothing
[09:28:45] <jepler> in git 1.7.10, the default of push is "matching - push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default."
[09:29:02] <jthornton> john@cave:~/emc-dev/src$ git push origin +2.7_Docs --force --dry-run
[09:29:02] <jthornton> To ssh://jthornton@git.linuxcnc.org/git/emc2.git
[09:29:02] <jthornton> + 20fd28b...7158ed2 2.7_Docs -> 2.7_Docs (forced update)
[09:29:17] <jepler> so because you had a local branch called 2.7 and origin has a branch named 2.7, "git push" will push that branch
[09:30:03] <jepler> I prefer the behavior I get by: git config --global push.default tracking
[09:30:14] <jepler> errr "upstream"
[09:30:19] <jepler> git config --global push.default upstream
[09:30:24] <jepler> "upstream - push the current branch to its upstream branch."
[09:30:33] <jepler> (tracking is a 'deprecated synonym for upstream')
[09:31:19] <jthornton> john@cave:~/emc-dev/src$ git config --global push.default upstream
[09:31:19] <jthornton> john@cave:~/emc-dev/src$ git push --force --dry-run
[09:31:20] <jthornton> fatal: The current branch 2.7_Docs has no upstream branch.
[09:31:20] <jthornton> To push the current branch and set the remote as upstream, use
[09:31:20] <jthornton> git push --set-upstream origin 2.7_Docs
[09:31:45] <jepler> yes, in this mode you have to set the upstream of a new branch one time
[09:32:17] <jthornton> so use git push --set-upstream origin 2.7_Docs?
[09:32:37] <jepler> --dry-run it first of course
[09:32:47] <jthornton> nodding
[09:33:08] <jepler> but that will still give you the non-fast-forward error.
[09:33:09] <jthornton> john@cave:~/emc-dev/src$ git push --set-upstream origin 2.7_Docs --dry-run
[09:33:09] <jthornton> To ssh://jthornton@git.linuxcnc.org/git/emc2.git
[09:33:09] <jthornton> ! [rejected] 2.7_Docs -> 2.7_Docs (non-fast-forward)
[09:33:09] <jthornton> error: failed to push some refs to 'ssh://jthornton@git.linuxcnc.org/git/emc2.git'
[09:33:09] <jthornton> hint: Updates were rejected because the tip of your current branch is behind
[09:33:10] <jthornton> hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
[09:33:11] <jthornton> hint: before pushing again.
[09:33:13] <jthornton> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
[09:33:23] <jepler> I assume you deliberately rewrote or amended a commit on that branch?
[09:33:45] <jthornton> yes, I though I reverted it back by one commit to fix my copy and paste error
[09:34:17] <jepler> you can add --force to the rest of the flags
[09:35:46] <jthornton> john@cave:~/emc-dev/src$ git push --set-upstream origin 2.7_Docs --force --dry-run
[09:35:47] <jthornton> To ssh://jthornton@git.linuxcnc.org/git/emc2.git
[09:35:47] <jthornton> + 20fd28b...7158ed2 2.7_Docs -> 2.7_Docs (forced update)
[09:35:47] <jthornton> Would set upstream of '2.7_Docs' to '2.7_Docs' of 'origin'
[09:36:06] <jthornton> is this correct?
[09:37:28] <jepler> if 20fd28b...7158ed2 is intended, then yes
[09:37:45] <jepler> and next time, you won't need to "--set-upstream origin"
[09:40:45] <jthornton> 7158ed2 is the last commit, the one I fixed but I don't see 20fd28b anywhere
[09:41:51] <jepler> 20fd28b no longer is in the history of your branch 2.7_Docs
[09:42:20] <jthornton> so that is the one I reverted locally
[09:43:50] <jthornton> ok, I see 20fd28b on git.linuxcnc.org and yes that is the one to remove
[09:44:15] <jepler> summary of commits being added: git log --oneline 20fd28b..7158ed2
[09:44:26] <jepler> summary of commits being removed: 7158ed2..20fd28b
[10:04:25] <mozmck> I'm trying to convert a HAL file to HALTCL. When I run using the HAL file, I get a message like this: hm2_eth: WARNING: Unable to restrict other access to the hm2-eth device.
[10:04:56] <mozmck> But with the HALTCL file it gives me this: {hm2_eth board_ip="10.10.10.10"}: dlopen: /usr/lib/linuxcnc/modules/{hm2_eth board_ip="10.10.10.10"}.so: cannot open shared object file: No such file or directory
[10:12:56] <cradek> {...} is the way you quote a string in tcl, very much like single quote in bash
[10:13:45] <cradek> clearly something about the quoting is wrong
[10:13:49] <mozmck> Here is the loadrt line: loadrt $::HOSTMOT2(DRIVER) config=$::HOSTMOT2(CONFIG)
[10:14:32] <cradek> that doesn't seem like the guilty line
[10:18:49] <jepler> and I assume the value of $::HOSTMOT2(DRIVER) is hm2_eth board_ip="10.10.10.10"
[10:18:59] <jepler> so Tcl invokes loadrt with two arguments
[10:19:19] <mozmck> Here is a simplified haltcl file that exhibits the same behaviour:
http://pastebin.com/vbRMCYrs
[10:19:38] <jepler> the first argument is supposed to be the name of the component to be loaded, but it is not -- it is actually the name of the component to be loaded and a parameter to pass it
[10:19:43] <mozmck> DRIVER=hm2_eth board_ip="10.10.10.10"
[10:23:05] <mozmck> I see. So I moved the board_ip argument to the config string, and now it gives a different error, but looks like it did try to load hm2_eth this time.
[10:23:46] <jepler> % set command echo
[10:23:47] <jepler> echo
[10:23:47] <jepler> % set argument hi
[10:23:47] <jepler> hi
[10:23:47] <jepler> % exec $command $argument
[10:23:49] <jepler> hi
[10:23:56] <jepler> exec works a bit like loadrt, enough to illustrate the point I'm trying to make
[10:24:04] <jepler> so that works ^^^
[10:24:12] <jepler> % set command {echo hi}
[10:24:12] <jepler> echo hi
[10:24:19] <jepler> % exec $command
[10:24:19] <jepler> couldn't execute "echo hi": no such file or directory
[10:24:28] <mozmck> Ok, that makes sense.
[10:24:29] <jepler> ^^^ this doesn't, because the first argument to 'exec' is expected to be the command itself
[10:24:38] <mozmck> yes
[10:24:42] <jepler> % exec {*}$command
[10:24:42] <jepler> hi
[10:25:06] <jepler> The special notation {*}$foo expands the list $foo into its constituent parts and makes each part a separate argument in the command
[10:25:27] <jepler> % set argument hitoo
[10:25:28] <jepler> hitoo
[10:25:28] <jepler> % exec {*}$command $argument
[10:25:28] <jepler> hi hitoo
[10:25:44] <jepler> other arguments can follow
[10:25:56] <mozmck> Interesting - thanks!
[10:26:11] <jepler> bbl
[10:26:12] <mozmck> tcl is a bit strange starting out
[10:26:24] <jepler> it is a bit strange 20 years later
[10:26:30] <mozmck> :)
[10:26:44] <jepler> it doesn't help that with respect to loadrt and loadusr there are additional layers each of which may also do argument parsing
[10:27:17] <mozmck> do either of those return a value that can be checked in tcl?
[11:02:39] <jthornton> <jepler> summary of commits being removed: 7158ed2..20fd28b
[11:02:53] <jthornton> are you saying that 20fd28b will be removed? I'm confused now...
[11:03:28] <jthornton> I mean 7158ed2
[11:04:47] <jthornton> I don't understand what this is saying 7158ed2..20fd28b and 20fd28b..7158ed2
[11:28:45] <jepler> jthornton: those are things you can type to git log
[11:29:27] <jepler> X..Y refers of the range of commits that are in the history of Y, but not in the history of X
[11:29:35] <jepler> usually that's a lot like saying "commits from X to Y"
[11:30:07] <jepler> so for instance, this is a summary of commits from release 2.6.7 to release 2.6.8: git log --oneline v2.6.7..v2.6.8
[11:30:36] <jepler> in this case I was suggesting how to use git log to show the commits that would be removed from history when you do this push --force
[11:46:05] <skunkworks_> pcw_home, could a firmware for the 5i25 be made with encoder counters from pins 1 -> 8?
[11:56:45] <skunkworks_> heh
[11:56:47] <skunkworks_> pcw_home, could a firmware for the 5i25 be made with encoder counters from pins 1 -> 8?
[11:57:17] <Tom_itx> don't see why not
[11:57:38] <Tom_itx> unless there's a limit on instances
[11:59:09] <Tom_itx> how many encoders do you need?
[11:59:35] <Tom_itx> there are 3 pins per encoder i think... A B & I
[12:07:31] <pcw_home> Sure (encoders could only have 'A' if you just need a counter or just A,B if you dont need index)
[12:09:39] <cradek> skunkworks_: do you mean 2-9?
[12:12:12] <mozmck> yuck, my dc7800 seemed to work great with the testing, but now running real hardware I'm getting realtime errors and watchdog biting
[12:12:31] <Tom_itx> pcw_home is there a limit on instances?
[12:20:00] <pcw_home> for most modules the limit is 64 instances
[12:23:12] <pcw_home> watchdog biting sounds like communications were lost or something global went bad (power?)
[12:39:12] <skunkworks_> cradek, that would be fine too... I usually start counting at strobe though (1)
[12:39:38] <skunkworks_> for a normal printer port.
[12:39:51] <mozmck> pcw_home: hmm, power glitch? I don't think so but I can check that some more.
[12:40:23] <mozmck> I have a usb->rs485 hub that I'm talking to every 20ms - I wonder if that could be causing problems?
[12:41:26] <skunkworks_> I would need a and b
[12:45:35] <pcw_home> yeah almost any pinout is possible
[12:47:21] <pcw_home> I'm using a USB mouse on my DC7800 and that doesn't seem to cause any issues
[12:47:34] <mozmck> Hmm, me too.
[12:48:01] <mozmck> I set up and ran with Axis first without my usb hub traffic, and did not have any realtime delays
[12:49:05] <pcw_home> probably have to bisect the problem
[12:49:12] <mozmck> One difference is that this usb traffic results in a bunch of hal pins getting updated and read, and the the gui responds to them.
[12:49:16] <mozmck> bisect?
[12:49:35] <pcw_home> binary serach
[12:49:40] <pcw_home> search
[12:49:41] <mozmck> isn't that a git thing?
[12:49:52] <pcw_home> its a debug thing
[12:50:00] <mozmck> you mean cut out stuff until it quits faulting?
[12:50:54] <pcw_home> well, yes but that doesn't sound so fancy-dan
[12:51:21] <mozmck> haha! I know how to do that, but don't always know the fancy-dan words for things :)
[12:51:37] <mozmck> guess I'm not completely buzz-word compliant
[12:52:42] <mozmck> Looks like I need to figure out a way to reset the has_bit pin after a watchdog bites when I bring linuxcnc out of estop
[12:56:19] <pcw_home> I would not expect the watchdog to bite unless things have gone very bad
[12:59:17] <mozmck> watchdog.timeout_ns is set to 25000000
[12:59:31] <KGB-linuxcnc> 03John Thornton 052.7_Docs 7158ed2 06linuxcnc 10(5 files in 2 dirs) add collapsing/expanding lists to html docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7158ed2
[13:05:31] <skunkworks_> pcw_home, when you have some time. I want to be able to plug a parallel port into the 5i25 for some logging.
[13:05:46] <skunkworks_> no rush
[13:07:09] <pcw_home> sure so a,b starting at 2 probably as cradek suggested to log step/dir?
[13:07:44] <pcw_home> 2 A0
[13:07:46] <pcw_home> 3 B0
[13:07:47] <pcw_home> 4 A1
[13:07:49] <pcw_home> 5 B1 etc
[13:08:15] <skunkworks_> yes
[13:08:17] <skunkworks_> exactly
[13:08:50] <pcw_home> I'll do that when I get a chance
[13:09:03] <skunkworks_> Thank you
[13:45:23] <cradek> do you mean step/dir or quadrature?
[13:45:58] <cradek> if it's step/dir I think pcw has to match the pinout?
[13:55:06] <jepler> not sure I'm looking at the right vhdl file, but yes I think so
[13:55:34] <skunkworks_> well - I can configure the sending machine to whatever the pinout is.. (step/dir or maybe quadature..)
[13:56:03] <cradek> oh ok
[13:56:18] <cradek> ... we don't know what your sending machine is
[13:56:43] <jepler> fwiw looks like countermode = 1 is up/down mode, with B as direction and A as step (qcountersfp.vhd)
[14:02:00] <skunkworks_> It could be linuxcnc..
[14:02:28] <skunkworks_> most things I would be testing - the printer port pinout is configureable.
[14:03:07] <skunkworks_> right - I have used the mesa encoder counter to count step/dir signals.
[14:03:19] <skunkworks_> works quite well :)
[14:21:30] <Tom_itx> so this is just for a test?
[14:28:01] <skunkworks_> yes
[14:28:35] <skunkworks_> so I can do stuff like
https://www.youtube.com/watch?v=HfU4uyGgLZw
[14:28:54] <skunkworks_> I was using the 7i80 but that is going to be used for a converstion.
[14:31:18] <mozmck> I found I can cause a realtime delay in axis if I run my utility which talks to my usb hub at the same time.
[14:32:18] <Tom_itx> skunkworks what pin file do you have loaded currently?
[14:32:29] <mozmck> In the BIOS I can set the IRQ number for each PCI device, but it looks like there are only 3 available and the usb and ethernet ports use 2 of them, and sata uses the other.
[14:33:55] <skunkworks_> Tom_itx, I don't know in the 5i25..
[14:33:59] <mozmck> If USB and ethernet are using the same IRQ, couldn't that cause delays?
[14:38:51] <Tom_itx> skunkworks you just need A & B inputs?
[14:39:10] <skunkworks_> On a side note - revisiting the rolling average componant I made. Is there a way to 'smooth out' zero crossing tranissions?
[14:40:25] <skunkworks_> I was calculating accelleration by boxcar averaging over 60us or so..
[14:41:01] <skunkworks_> wait - more like 60ms..
[14:42:01] <skunkworks_> the rolling average looked a lot better Vel -> rolling average -> ddt.
[14:42:23] <skunkworks_> but when the velocity crossed zero you got quite a bump. Let me find a picture.
[14:47:43] <JT-Shop> buildbot seems somewhat happy
[14:49:15] <mozmck> Another thing I'm seeing which seems odd: after a watchdog bite, when I reset estop and set the watchdog has_bit pin to false, if I try to jog I get this error: Cannot unhome while moving, joint 1
[14:49:32] <mozmck> I can only move again by re-starting linuxcnc
[14:53:12] <skunkworks_> pcw_home, could a firmware for the 5i25 be made with encoder counters from pins 1 -> 8?
[14:53:16] <skunkworks_> heh
[14:53:19] <Tom_itx> skunkworks is 4 encocers enough?
[14:53:29] <skunkworks_> I mean
http://imagebin.ca/v/22PTVKng92NW
[14:53:33] <Tom_itx> AB AB AB AB
[14:53:33] <skunkworks_> yes
[14:53:35] <skunkworks_> yes
[14:53:42] <Tom_itx> starting at 1?
[14:53:43] <skunkworks_> starting at pin 2?
[14:53:53] <skunkworks_> 2 is more standard...
[14:53:56] <Tom_itx> what io is pin 2... i don't have a 5i25
[14:54:06] <skunkworks_> oh. I don't know..
[14:56:01] <skunkworks_> the manual says 2 is io2, 3 is io4, 4 is io6 and so on.
[14:56:29] <skunkworks_> if that is what works
[14:57:35] <Tom_itx> hmm
[14:57:51] <Tom_itx> one sec..
[14:59:38] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/cnc/configs/sherline/bitfiles/PIN_7I76_skunktest.vhd
[14:59:46] <Tom_itx> see if that's close to what you want
[15:00:03] <skunkworks_> Cool - thanks. I will try it tomorrow.
[15:00:12] <Tom_itx> i haven't compiled it yet...
[15:00:49] <Tom_itx> you may need a GPIO between each if the pinout is what you say
[15:01:13] <Tom_itx> if you want them pin aligned
[15:01:52] <Tom_itx> i'm not quite done with that btw... just posted for you to view the layout
[15:03:14] <skunkworks_> righyt - if I understand it - there would have to be a gpio in the odd io
[15:03:41] <Tom_itx> lemme fix it real quick
[15:03:48] <Tom_itx> then i'll compile it
[15:04:00] <Tom_itx> starting with IO2?
[15:04:30] <mozmck> I still can't get my tcl to work. I tried this: loadrt $::HOSTMOT2(DRIVER) board_ip=$::HOSTMOT2(IPADDR) config=$::HOSTMOT2(CONFIG)
[15:05:04] <mozmck> in my ini file: IPADDR="10.10.10.10"
[15:05:34] <mozmck> and I get an error while executing: "hal loadrt hm2_eth board_ip={\"10.10.10.10\"} {config={"num_encoders=0 num_pwmgens=0 num_stepgens=6"}}"
[15:05:54] <cradek> wow look at all those curlies and quotes
[15:06:05] <cradek> try removing the quotes in the inifile
[15:06:34] <mozmck> I know if I do that for the config string it barfs.
[15:06:42] <mozmck> let me try on the ipaddr string
[15:07:03] <cradek> unfortunately I bet you're going to have to understand the problem :-/
[15:07:16] <cradek> and it might take a tcl wizard
[15:07:35] <mozmck> yes, which I'm not even hardly a newbie yet :-(
[15:07:44] <mozmck> hal loadrt hm2_eth board_ip=10.10.10.10 {config={"num_encoders=0 num_pwmgens=0 num_stepgens=6"}}
[15:08:02] <mozmck> after removing the quotes in the inifile
[15:08:12] <mozmck> from IPADDR
[15:08:15] <cradek> jepler's information about {*}$ was both enlightening and offputting
[15:08:22] <mozmck> I'll play with it more.
[15:08:36] <cradek> ok so now that part sure looks right
[15:09:31] <cradek> you were getting tcl-style {} quoting to preserve the quotes, but I don't know why the doublequotes got backslashified
[15:09:57] <Tom_itx> skunkworks, have a look at that one... that puts the qcount on IO2 4 6 8 10 12 14 16
[15:09:59] <cradek> seems like maybe if you add the {*} thing it'll undo one level of tcl-style quoting
[15:10:09] <mozmck> hmm, I'll try that.
[15:10:09] <cradek> <- not a wizard
[15:10:40] <cradek> oh wait, it's hal loadrt, as in hal is a tcl command? maybe you need the tcl-style quoting
[15:11:17] <cradek> I think you're getting tcl-quoted twice and you want it to be once
[15:11:37] <cradek> you're getting one when reading the ini file, and another when constructing the "hal" tcl command
[15:11:50] <mozmck> I don't know. I'm trying to convert a hal file to haltcl, so hopefully I can catch some errors and give a meaningful message.
[15:13:22] <mozmck> I'll play with it some more. tanks.
[15:13:27] <mozmck> thanks even!
[15:13:36] <cradek> tanks!!
[15:13:45] * cradek backs slowly away from texas
[15:14:11] <mozmck> haha! just don't try to come shoot something up here ;)
[15:22:01] <Tom_itx> skunkworks, i'll post the bitfile up there when it's done compiling
[15:38:03] <Tom_itx> skunkworks,
http://tom-itx.no-ip.biz:81/~webpage/cnc/skunkworks/
[16:01:03] * JT-Shop thinks jepler is going to beat me over the head with git commands until I quit using git gui :)
[16:15:02] <Tom_itx> ok i think i got it right...
[16:15:45] <Tom_itx> should put the encoders on pins 2 3 4 5 6 7 8 9
[16:37:58] <skunkworks> Tom_itx: thank you - will test it tomorrow
[17:56:03] <kwallace> I just discovered an almost local maker space in my neck of the woods,
http://myinnovationlab.org/ . I
[17:57:18] <kwallace> I'm thinking it would be nice to have a cheap demo mill to do a presentation. Does anyone favorite base machine to build a mill?
[17:57:59] <kwallace> opps ...have a favorite..
[18:00:23] <JT-Shop> kwallace, did you see the link to the code the other day?
[18:04:40] <kwallace> JT-Shop, yes I did, thank you. It turns out ConfigParser doesn't like leading spaces which my app config files have.
[18:05:17] <JT-Shop> well that sucks
[18:05:47] <kwallace> Cheap but worth it?
http://www.ebay.com/itm/140625033164
[18:07:20] <JT-Shop> I guess that depends on what you expect...
[18:07:50] <kwallace> JT-Shop, I think it might be better if I have a large string that has the base config file contents in my python script, then modify it and write a new file each time.
[18:08:27] <kwallace> Rather than read an existing file, parse and rewrite.
[18:09:00] <JT-Shop> what are you doing?
[18:10:22] <kwallace> The parsing is for adding dxf2gcode to my conversational screen. A lot of the parameters need to be passed in two config files.
[18:10:56] <kwallace> The mill is for showing off LinuxCNC to the maker space people.
[18:11:22] <kwallace> My smallest CNC is 3,000 lbs.
[18:13:20] <JT-Shop> doesn't dxf2gcode just need the file?
[18:17:42] <kwallace> I'm not fully up to speed with dxf2gcode, but I think it goes like - open qcad and draw paths on different layers, the layer title has the tool information, open dxf2gcode and set the path direction and cutter comp and create g-code, the header and footers are controlled by the config files.
[18:18:45] <JT-Shop> ah a bit complicated then
[18:19:03] <kwallace> What I need is a simple one tool with information coming from my app screen with my own header and footer, so it gets complicated.
[18:19:49] <kwallace> I also need to decide how much effort to put into it.
[18:22:27] <kwallace> Currently, the dxf2gcode GUI pops up from my screen then returns when I close dxf2gcode, then I use Post to File. It would be better to embed dxf2gcode in my screen.
[18:23:09] <kwallace> With enough effort I think it could be done.
[18:23:16] <JT-Shop> I guess the only reason you need dxf2gcode is the profiles?
[18:24:41] <kwallace> So far we only do circular and rectangular profiles and bosses.
[18:26:49] <kwallace> I have used dxf2gcode in the past to do more complex shapes, but now I have to do it in a way that an average joe can manage without a degree in science.
[18:43:10] <JT-Shop> if your just doing simple shapes then you don't need dxf2gcode it just adds complexity to the job
[18:52:32] <kwallace> Here is an example I have been playing with:
http://wallacecompany.com/dxf2gcode/
[19:22:34] <skunkworks> I have used dxf2gcode a little bit.. seems powerful
[19:24:03] <kwallace> It has gotten better and the docs are not bad... because they don't seem to exist.
[21:03:54] <mozmck> JT-Shop: did you see my suggestion/question about a table of contents on the left of all the pages?
[21:45:39] <cradek> kwallace: nylocks as thrust bearings is an interesting choice
[21:45:53] <cradek> kwallace: I guess you could adjust the play ... sort of