Back
[02:45:00] <skunkworks> jon is funny
[11:36:57] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[12:45:15] <CIA-48> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/User_Concepts.lyx: add info on rapids and path following and markup changes to the override section
[12:45:16] <CIA-48> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: add info on rapids and path following and markup changes to the override section
[12:48:17] <CIA-48> EMC: 03bigjohnt 07v2_3_branch * 10emc2/docs/src/common/User_Concepts.lyx: add info on rapids and path following and markup changes to the override section
[12:48:18] <CIA-48> EMC: 03bigjohnt 07v2_3_branch * 10emc2/docs/src/gcode/main.lyx: add info on rapids and path following and markup changes to the override section
[13:08:38] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/rs274ngc_pre.cc: revert to r1.70 to fix test failures
[13:53:41] <skunkworks> jmkasunich: did you see these. (probably too small for anything you would need)
http://www.skycraftsurplus.com/index.asp?PageAction=VIEWPROD&ProdID=1877
[14:22:19] <alex_joni> jepler_: I think the naive cam tolerance is fine
[14:22:28] <alex_joni> both the tolerance and the mode get saved in emccanon
[14:22:36] <alex_joni> and they are correct even on abort's
[14:22:52] <alex_joni> the problem is with motion, that changes to the default mode (blending) on abort
[14:23:17] <alex_joni> the change I suggested to micges simply sends a canon call which triggers the change to the current mode in the motion controller
[14:31:57] <jmkasunich> skunkworks: yeah, I saw those when they were posted a couple weeks ago - I have them bookmarked
[14:32:07] <skunkworks> heh
[14:32:19] <jmkasunich> I haven't decided what I'm going to use to drive Z on my pcb mill yet, those might be a candidate
[14:34:00] <skunkworks> I have the ok to buy some ;) but I have not yet.
[14:34:24] <skunkworks> It is one of those deals that are just too good to pass up.
[14:36:00] <skunkworks> They would work great the pcbmill project - but the thing already has steppers. The issue is that it needs to be geared down. (.0075 movement per half step) So switching to servos might just be fun.
[14:39:33] <skunkworks> it is pretty light - 18"X18" work evelope with .75 shafts.
[14:41:21] <skunkworks> LawrenceG: !
[14:44:47] <LawrenceG> skunkworks, !
[14:45:24] <skunkworks> How is the drive coming?
[14:45:27] <LawrenceG> I am just prying my eyes open.... coffee has not kicked in yet (local time 7:45)
[14:45:49] <skunkworks> heh - working on the second.
[14:46:39] <LawrenceG> drive smarts board is built.... working on software at the moment... need to take my existing stuff and move some I/O around and change the pwm section to match the new power stage
[14:47:31] <LawrenceG> I was trying to get a bootloader running yesterday, but it seems that the one I used on another project doesnt support the chip I am using
[14:48:27] <LawrenceG> to speed things up, I'll just unplug and program.... or maybe jury rig an icsp header on the board
[14:51:40] <LawrenceG> skunkworks,
http://imagebin.ca/view/KEc0JG.html
[14:52:59] <LawrenceG> skunkworks,
http://imagebin.ca/view/le6GAb.html
[14:55:59] <LawrenceG> skunkworks, also looking at DSPIC33FJ128MC802-I/SP chip for a servo project.... it has 2 encoder interfaces, so a dual servo board would be possible
[15:12:33] <skunkworks> neat!
[15:16:16] <mozmck> LawrenceG: what does your driver do? doesn't look like it has any power stuff...
[15:21:34] <LawrenceG> mozmck, that picture is for the brains.... the 10 pin header passes the PWM signals to a 4 fet or 6 fet power board for a brushed or 3 phase brushless motors
[15:23:04] <LawrenceG> mozmck,
http://imagebin.ca/view/mRa-bn_X.html
[15:28:02] <LawrenceG> mozmck, the board takes quadrature input from the PC and basically has the emc servo loop for a single channel on board. The two boards together are pretty much a smart version of the gecko servo amp
[15:30:10] <alex_joni> no need to leave #emc though
[15:30:20] <alex_joni> Goslowjimbo: you can have more than one channel open ;)
[15:30:37] <Goslowjimbo> OH. Didn't know that.
[15:34:46] <Goslowjimbo> I see Seb isn't here right now. Does anyone else want to discuss structure of EMC/HM2/SPI?
[15:38:44] <jmkasunich> seb and PCW are the experts on that
[15:38:53] <jmkasunich> seb is usually around in the evening
[15:39:48] <Goslowjimbo> Thanks, I'll check then.
[15:40:51] <Goslowjimbo> Any certain time? (I'm on Eastern time.)
[15:41:10] <cradek> pretty late usually
[15:41:15] <jmkasunich> he's in colorado, and usually shows up "after dinner", sometimes "after kids are in bed"
[15:42:21] <Goslowjimbo> Mine got to bed around 1:00 to 2:00 in the morning (as near as I can tell). College agers.
[15:42:46] <Goslowjimbo> I assume his are younger.
[15:44:25] <Goslowjimbo> Bye.
[15:46:42] <mozmck> LawrenceG: interesting!
[15:47:20] <mozmck> so the loop is closed in your drive?
[15:47:33] <mozmck> what makes it smart compared to a gecko?
[15:49:42] <LawrenceG> mozmck, yes encoder feeds onboard pic not into the PC. It has a full PID/FF1/FF2 tunable servo loop... tuning and setup is done via the serial port.Items like step multiplier are trivial in software.
[15:51:20] <mozmck> interesting. are going to make these to sell?
[15:51:47] <mozmck> what is the quadrature input from the pc? not step and dir signals?
[15:52:47] <mozmck> sorry for the ignorant questions, but I'm trying to overcome some ignorance :-)
[15:54:11] <LawrenceG> mostly for my own machine, I dont think I can compete with gecko. Quadrature is a much better way to indicate incremental motion than step/dir. It has much better noise immunity and relaxed timing requirements
[15:56:06] <LawrenceG> step/dir is possible with about 2 lines of code changed, but emc supports stepping type 2 which is quadrature... that is what I use in all my controllers
[15:56:39] <mozmck> I see. The more noise immunity the better from my experience. thanks for the info. bbl
[15:56:59] <LawrenceG> no problem ... cheers
[16:35:03] <jepler_> jepler_ is now known as jepler
[19:05:53] <CIA-48> EMC: 03mshaver 07TRUNK * 10emc2/docs/NEWS: doing this mainly to test CVS commit ability
[19:07:09] <mshaver> now I need to read that "bean book" or whatever it's called...
[19:08:32] <cradek> don't spend too much time learning cvs at this late stage in the game.
[19:10:26] <mshaver> I just need to figure out how to: 1. add a directory, 2. add files to my new directory, 3. make these new things part of 2.3.2, which I guess is a branch or tag or something
[19:13:41] <alex_joni> mshaver: also, nowadays (as you can see) we use mainly debian/changelog to take care of news
[19:13:47] <alex_joni> cvs add folder
[19:13:52] <alex_joni> cvs add folder/*
[19:13:59] <alex_joni> cvs commit -m "added folder"
[19:14:12] <alex_joni> that takes care of 1. and 2.
[19:14:24] <alex_joni> if you want 3, you need a v2_3_branch checkout
[19:14:36] <mshaver> thanks alex!
[19:15:03] <alex_joni> cvs -d:ext:
[email protected]/cvs co -rv2_3_branch -d emc2.v2_3_branch emc2
[19:16:14] <alex_joni> it will be a bit easier with git ;)
[19:16:20] <alex_joni> (I hear)
[19:16:52] <mshaver> so, are developers now committing to the 2.3.2 branch, and their changes also show up in TRUNK? Or does jepler merge TRUNK into 2.3.2 before the release?
[19:17:36] <jmkasunich> new features are committed to TRUNK
[19:17:51] <jmkasunich> bugfixes are committed to TRUNK and the branch, usually by the developer
[19:18:43] <mshaver> OK, I guess what I have would be a "new feature" - a new config sample
[19:18:56] <jmkasunich> sort of
[19:19:11] <jmkasunich> the main reason we don't add new features to the released branch is to make sure we don't break anything
[19:19:25] <jmkasunich> a new sample config is pretty safe against that kind of breakage
[19:19:55] <jmkasunich> so if there is a benefit to getting it "out there" sooner than the 2.4 release, you should feel free to add it to the branch too
[19:20:18] <alex_joni> unless it breaks something
[19:20:39] <jmkasunich> you should of course test your config under both TRUNK and 2.3.x
[19:20:45] <alex_joni> usually a config shouldn't be able to break anything, but it happened in the past iirc
[19:20:49] <mshaver> so, at release time does the package maintainer go through TRUNK for new features to add to the release? Or is it up to the developer to decide that they will be in the next release?
[19:21:23] <jmkasunich> yes ;-/
[19:21:28] <cradek> the release manager usually announces an upcoming release to see if anyone wants to do last-minute backports
[19:21:47] <alex_joni> * alex_joni thinks we are talking slightly sideways
[19:21:57] <cradek> but if you want something in an upcoming 2.3 release, you ought to put it on the 2.3 branch. if you're not sure if it belongs there, definitely ask
[19:22:09] <alex_joni> when there's a new majour version coming out (2.3.0, 2.4.0, etc) there is a period of stabilisation on TRUNK
[19:22:17] <alex_joni> then a feature freeze,
[19:22:34] <alex_joni> after that the respective branch is created v2_3_branch for 2.3.x releases
[19:22:47] <mshaver> jeff mentioned 2.3.2 about a week ago, but I think there was more work to be done so he has put it off a little while
[19:23:06] <alex_joni> ok, minor version releases are more up to the release manager
[19:23:17] <alex_joni> they usually contain only bugfixes
[19:23:17] <mshaver> alex_joni: that is very informative!
[19:23:33] <jmkasunich> mshaver: the 2.4.0 "major revision" release is a long way off
[19:23:56] <alex_joni> new features aren't part of a minor release..
[19:24:02] <jmkasunich> I don't even have a guess as to when it will be - might not even happen during 2009
[19:24:05] <alex_joni> config files should be acceptable though
[19:24:26] <jmkasunich> 2.3.2 is the next "minor version", which will be happening soon
[19:24:29] <alex_joni> otoh, I volunteered as a RM for 2.4
[19:24:39] <jmkasunich> the #1 rule for a minor version is "don't break things"
[19:24:50] <jmkasunich> so new features inside EMC2 proper are not allowed
[19:25:01] <alex_joni> the #2 rule is have enough stuff to make the release worthwhile
[19:25:12] <mshaver> yea, I'd really like to start maintaining these configs as part of emc, rather than something that lives on my personal website
[19:25:12] <jmkasunich> but a new sample config won't break any existing configs, so it is allowed in a minor release
[19:25:16] <alex_joni> either a serious bugfix, or enough little fixes
[19:25:43] <alex_joni> as a sidenote I have some config updates for cooltool/ that will be part of 2.3.2
[19:26:11] <mshaver> i have no version control on my website, and it's a problem...
[19:26:33] <jmkasunich> mshaver: short answer - the smithy stuff should probably be in the 2.3.2
[19:26:38] <jmkasunich> commit it ti TRUNK first
[19:26:48] <jmkasunich> then backport it to the 2.3.2 branch
[19:26:50] <mshaver> alex_joni: it was one of your posts about the cooltool configs that pushed me to do this now
[19:26:57] <jmkasunich> there are different ways to do the backport
[19:27:12] <jmkasunich> I just have two completely independent checkouts, one for TRUNK and one of the 2.3.x branch
[19:27:44] <alex_joni> jmkasunich: either way is kinda pita with CVS :)
[19:27:55] <jmkasunich> if you are only adding new files, the easiest way is to simply copy them from your trunk directory tree to your 2.3 directory tree, then do the cvs adds in the 2.3 tree and commit
[19:28:23] <jmkasunich> if you are changing the contents of existing files, then it can be trickier
[19:29:57] <mshaver> I think I'll add them to TRUNK, then test some more in the intervening time. When the call for 2.3.2 goes out, I'll put it in there.
[19:30:28] <jmkasunich> make sure that when you copy them to 2.3.x, they work with that version
[19:30:55] <jmkasunich> I don't know what, if any, new ini file items might have been added in trunk - if you use one of those items in 2.3 it won't work
[19:31:04] <jmkasunich> (probably not an issue, but test it anyway)
[19:34:18] <mshaver> I'll make sure it's not a problem. The only likely problem is incompatibility between 2.3.2 and the latest version of Smithy's eztrol program. I think what I'll do is default the DISPLAY to axis in the files I check in. That will assure there won't be a problem. Eztrol users can just edit the .ini file themselves.
[19:35:17] <jmkasunich> if the eztrol is not part of EMC, then (IMO only), none of our sample configs should invoke it
[19:35:43] <jmkasunich> as you say, the users can edit it themselves
[19:36:10] <jmkasunich> you can go as far as to put in the eztrol line, commented out, with another comment telling them what to do
[19:36:57] <mshaver> that's my thinking as well. Of course, they'll also fail on non-5i20 equipped computers, but that's unavoidable
[19:43:05] <alex_joni> remember to add a proper README file ;)
[19:49:37] <mshaver> alex_joni: it's in there!
[19:51:51] <alex_joni> mshaver: sweet
[20:13:34] <CIA-48> EMC: 03mshaver 07TRUNK * 10emc2/configs/smithy/ (29 files): adding smithy machines to sample configs
[20:14:12] <alex_joni> that's a lot of files
[20:14:18] <mshaver> well, it's all over now...
[20:14:32] <mshaver> it's a lot of machines
[20:16:01] <alex_joni> what's 924proto.bit ?
[20:17:27] <alex_joni> mshaver: a couple minor nags: for 2.3.x+ we don't need emc.nml anymore (emc2 looks and uses the default emc.nml file)
[20:17:39] <mshaver> it's a 5i20 firmware file for 1 specific machine (a lathe). I had hoped to rewire this machine to conform to all the others we have shipped, but it was sold to somebody before it could be revised
[20:17:59] <SWPadnos> that one file should maybe not be in the distro
[20:18:04] <SWPadnos> if there's exactly one user
[20:18:32] <alex_joni> also, there's no need for a var file. a default var file will be constructed when it's first needed
[20:18:40] <mshaver> precisely one. but, there's only one Mazak too... :)
[20:18:54] <SWPadnos> true enough
[20:19:03] <mshaver> how do I remove files from cvs then?
[20:19:11] <SWPadnos> I didn't look at the file - is there complex setup that would be useful as a general reference?
[20:19:15] <alex_joni> still.. having the file in the config dir doesn't help that one user much
[20:19:20] <SWPadnos> mshaver, you don't, that's why we want git ;)
[20:19:26] <alex_joni> sure you do
[20:19:33] <alex_joni> rm the file, then cvs rm file
[20:19:34] <SWPadnos> (actually you can, but there will still be an "attic" I think)
[20:19:40] <alex_joni> then cvs commit -m "removed file"
[20:20:12] <alex_joni> SWPadnos: on any SCM system you'll have history and files preserved, even after deleting
[20:20:31] <SWPadnos> yeah yeah - I guess it wasn't a great joke :)
[20:20:35] <alex_joni> :P
[20:21:11] <mshaver> SWPadnos: there's nothing in 924proto that isn't in the plain 924 files.
[20:21:28] <alex_joni> mshaver: make sure you remove the reference in the ini's if you also remove the emc.nml file
[20:22:04] <SWPadnos> it's no big deal, it just seems that a non-instructive config for one customer isn't of general enough use to be included. that's just IMO of course
[20:22:15] <alex_joni> the config is fine imo
[20:22:21] <SWPadnos> there you go - a tie ;)
[20:22:25] <mshaver> alex_joni: true, but where else would I put it? The user will have to be smart enough to put it into the firmware dir on his machine.
[20:22:41] <alex_joni> mshaver: exactly
[20:22:53] <alex_joni> but since he's doing that already, he can also grab it from somewhere
[20:23:02] <alex_joni> bti files don't benefit much from versioning either
[20:23:33] <alex_joni> it's not that huge, but it still adds 160k to the package for all the users
[20:24:05] <alex_joni> is the BIT likely to change?
[20:24:15] <mshaver> I guess I'll remove the whole 924proto config and send these files to the guy who got the machine with the admonition that if he ever loses them he is well and truly out of luck :)
[20:24:37] <alex_joni> mshaver: they are part of CVS now, they will exist forever
[20:24:45] <alex_joni> even if you remove them, they can be ressurected
[20:25:09] <mshaver> alex_joni: that's the problem - Peter at Mesa has made some improvements since then, and they'll probably never be backported to this firmware.
[20:25:52] <alex_joni> sounds like the best solution is to rewire the machine :D
[20:26:50] <alex_joni> anyways, joke aside, the files are now in CVS, so even if you delete them, they can be restored in the bleak future when the user loses his data ;)
[20:27:02] <mshaver> it's at a customer now. I didn't want them to sell it, but they did anyway.
[20:27:52] <alex_joni> * alex_joni runs to bed
[20:27:54] <alex_joni> good night all
[20:28:54] <mshaver> I think that's the way I'll have to go - send him the files and delete them from CVS as best as possible, along with the now amazingly unneeded emc.nml and emc.var
[20:29:08] <mshaver> nighty night alex!
[20:29:50] <SWPadnos> night Alex
[21:15:07] <mshaver> alex just said that emc.nml and emc.var weren't needed anymore in 2.3, and that I could remove the reference to emc.nml in the .ini file. I tried this with sim/axis.ini on 2.3.1 and it doesn't work. What an I doing wrong? If I just delete emc.nml from ~/emc2/configs/sim/ it complains, "can't open 'emc.nml'".
[21:21:17] <CIA-48> EMC: 03mshaver 07TRUNK * 10emc2/configs/smithy/ (README 924PROTO.BIT 924proto.hal 924proto.ini): removed 924 prototype lathe specific files
[21:23:26] <mshaver> SWPadnos: I tried removing emc.nml like alex said, but it complains. Is it actually still necessary?
[21:27:11] <jtr> mshaver: I think you have to take it out of the config as well.
[21:28:33] <jtr> 16:21:28 < alex_joni> mshaver: make sure you remove the reference in the ini's if you also remove the emc.nml file
[21:28:40] <SWPadnos> mshaver, as jtr said, you need to remove the reference from the ini
[21:28:49] <jtr> mshaver: ^^^^
[21:28:51] <SWPadnos> if emc doesn't see a file specified, it will look in the common dir for it
[21:29:26] <SWPadnos> I don't know the implementation details, so I would encourage you to try that in a ~/emc2/configs/* dir as well as a sample config :)
[21:33:31] <mshaver> I did take the reference out of the .ini, but I don't have a ~/emc2/configs/common/ directory. What happens when someone copies the sample configuration to their home directory? Does it make emc.nml and emc.var for them? I may have to play with this a bit...
[21:34:00] <jepler> mshaver: welcome back to the land of committers
[21:34:06] <jepler> * jepler disapperas again
[21:34:24] <mshaver> thanks! now I can get my statistics up!
[21:46:33] <mshaver> So, I erased my ~/emc2/configs/sim/ directory, started emc2, selected sim/axis and agreed to let it copy the sample configuration to my home directory.
[21:47:39] <mshaver> I then edited ~/emc2/configs/sim/axis.ini and removed the line, "NML_FILE = emc.nml".
[21:48:34] <mshaver> Re-running emc2 again, and selecting my, now local, sim/axis configuration results in:
[21:48:56] <mshaver> Can not find -sec EMC -var NML_FILE -num 1
[21:49:16] <mshaver> File "/usr/bin/axis", line 3609, in <module>
[21:49:21] <mshaver> etc.
[21:50:03] <mshaver> So, I believe that the reference to emc.nml is still required in the .ini file, at least if the DISPLAY is axis.
[21:50:29] <jepler> mshaver: you ran /usr/bin/axis. that's probably not TRUNK. The no-NML_FILE is on TRUNK only.
[21:51:03] <mshaver> oh, alex said this was for 2.3 and forward.
[21:52:05] <mshaver> (04:17:54 PM) alex_joni: mshaver: a couple minor nags: for 2.3.x+ we don't need emc.nml anymore (emc2 looks and uses the default emc.nml file)
[21:52:26] <jepler> I think he may have been mistaken
[21:52:26] <mshaver> maybe i misinterped this :(
[21:52:43] <mshaver> well, either way, mystery solved!
[21:52:47] <jepler> :)
[21:53:48] <mshaver> I think I'll get up and move a while. I've been linig my toolbox drawers with some rubber stuff I bought a million years ago. Be back this evening sometime...
[22:19:13] <geo01005_home_> So JanVanGlisen Sent be some code for a time series plot widget for pyvcp. I modified the look just a little and I'm trying to make a patch.
[22:19:16] <geo01005_home_> I'm a little lost.
[22:21:54] <geo01005_home_> is there a way that I can submit a patch of just the changes in the one file?
[23:40:10] <jepler> geo01005_home: working in a checkout, 'cvs diff -u filename'. If you are not using cvs, but have the original file in filename.orig, 'diff -u filename.orig filename'.
[23:42:54] <geo01005_home> jelper thanks, Now how do I generate the patch?
[23:43:14] <geo01005_home> or did that make it, and I just don't know where it is?
[23:46:59] <jepler> it prints it on the terminal
[23:47:11] <jepler> to put it in a file, use ">": cvs diff -u filename > my-changes.patch
[23:47:28] <jepler> if it prints nothing, then both files compared are identical
[23:48:45] <geo01005_home> Ahh I see. Well, now that I have the patch where should I put it? Here?
[23:48:54] <geo01005_home> Or at sourceforge?
[23:51:48] <jepler> e-mail to the developers list
[23:52:40] <geo01005_home> ok, thanks.