jon is funny
BigJohnT_ is now known as BigJohnT
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/User_Concepts.lyx: add info on rapids and path following and markup changes to the override section
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: add info on rapids and path following and markup changes to the override section
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
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
EMC: 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/rs274ngc_pre.cc: revert to r1.70 to fix test failures
jmkasunich: did you see these. (probably too small for anything you would need) http://www.skycraftsurplus.com/index.asp?PageAction=VIEWPROD&ProdID=1877
jepler_: I think the naive cam tolerance is fine
both the tolerance and the mode get saved in emccanon
and they are correct even on abort's
the problem is with motion, that changes to the default mode (blending) on abort
the change I suggested to micges simply sends a canon call which triggers the change to the current mode in the motion controller
skunkworks: yeah, I saw those when they were posted a couple weeks ago - I have them bookmarked
I haven't decided what I'm going to use to drive Z on my pcb mill yet, those might be a candidate
I have the ok to buy some ;) but I have not yet.
It is one of those deals that are just too good to pass up.
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.
it is pretty light - 18"X18" work evelope with .75 shafts.
How is the drive coming?
I am just prying my eyes open.... coffee has not kicked in yet (local time 7:45)
heh - working on the second.
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
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
to speed things up, I'll just unplug and program.... or maybe jury rig an icsp header on the board
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
LawrenceG: what does your driver do? doesn't look like it has any power stuff...
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
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
no need to leave #emc though
Goslowjimbo: you can have more than one channel open ;)
OH. Didn't know that.
I see Seb isn't here right now. Does anyone else want to discuss structure of EMC/HM2/SPI?
seb and PCW are the experts on that
seb is usually around in the evening
Thanks, I'll check then.
Any certain time? (I'm on Eastern time.)
pretty late usually
he's in colorado, and usually shows up "after dinner", sometimes "after kids are in bed"
Mine got to bed around 1:00 to 2:00 in the morning (as near as I can tell). College agers.
I assume his are younger.
so the loop is closed in your drive?
what makes it smart compared to a gecko?
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.
interesting. are going to make these to sell?
what is the quadrature input from the pc? not step and dir signals?
sorry for the ignorant questions, but I'm trying to overcome some ignorance :-)
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
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
I see. The more noise immunity the better from my experience. thanks for the info. bbl
no problem ... cheers
jepler_ is now known as jepler
EMC: 03mshaver 07TRUNK * 10emc2/docs/NEWS: doing this mainly to test CVS commit ability
now I need to read that "bean book" or whatever it's called...
don't spend too much time learning cvs at this late stage in the game.
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
mshaver: also, nowadays (as you can see) we use mainly debian/changelog to take care of news
cvs add folder
cvs add folder/*
cvs commit -m "added folder"
that takes care of 1. and 2.
if you want 3, you need a v2_3_branch checkout
cvs -d:ext:firstname.lastname@example.org/cvs co -rv2_3_branch -d emc2.v2_3_branch emc2
it will be a bit easier with git ;)
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?
new features are committed to TRUNK
bugfixes are committed to TRUNK and the branch, usually by the developer
OK, I guess what I have would be a "new feature" - a new config sample
the main reason we don't add new features to the released branch is to make sure we don't break anything
a new sample config is pretty safe against that kind of breakage
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
unless it breaks something
you should of course test your config under both TRUNK and 2.3.x
usually a config shouldn't be able to break anything, but it happened in the past iirc
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?
the release manager usually announces an upcoming release to see if anyone wants to do last-minute backports
* alex_joni thinks we are talking slightly sideways
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
when there's a new majour version coming out (2.3.0, 2.4.0, etc) there is a period of stabilisation on TRUNK
then a feature freeze,
after that the respective branch is created v2_3_branch for 2.3.x releases
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
ok, minor version releases are more up to the release manager
they usually contain only bugfixes
alex_joni: that is very informative!
mshaver: the 2.4.0 "major revision" release is a long way off
new features aren't part of a minor release..
I don't even have a guess as to when it will be - might not even happen during 2009
config files should be acceptable though
2.3.2 is the next "minor version", which will be happening soon
otoh, I volunteered as a RM for 2.4
the #1 rule for a minor version is "don't break things"
so new features inside EMC2 proper are not allowed
the #2 rule is have enough stuff to make the release worthwhile
yea, I'd really like to start maintaining these configs as part of emc, rather than something that lives on my personal website
but a new sample config won't break any existing configs, so it is allowed in a minor release
either a serious bugfix, or enough little fixes
as a sidenote I have some config updates for cooltool/ that will be part of 2.3.2
i have no version control on my website, and it's a problem...
mshaver: short answer - the smithy stuff should probably be in the 2.3.2
commit it ti TRUNK first
then backport it to the 2.3.2 branch
alex_joni: it was one of your posts about the cooltool configs that pushed me to do this now
there are different ways to do the backport
I just have two completely independent checkouts, one for TRUNK and one of the 2.3.x branch
jmkasunich: either way is kinda pita with CVS :)
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
if you are changing the contents of existing files, then it can be trickier
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.
make sure that when you copy them to 2.3.x, they work with that version
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
(probably not an issue, but test it anyway)
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.
if the eztrol is not part of EMC, then (IMO only), none of our sample configs should invoke it
as you say, the users can edit it themselves
you can go as far as to put in the eztrol line, commented out, with another comment telling them what to do
that's my thinking as well. Of course, they'll also fail on non-5i20 equipped computers, but that's unavoidable
remember to add a proper README file ;)
alex_joni: it's in there!
EMC: 03mshaver 07TRUNK * 10emc2/configs/smithy/ (29 files): adding smithy machines to sample configs
that's a lot of files
well, it's all over now...
it's a lot of machines
what's 924proto.bit ?
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)
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
that one file should maybe not be in the distro
if there's exactly one user
also, there's no need for a var file. a default var file will be constructed when it's first needed
precisely one. but, there's only one Mazak too... :)
how do I remove files from cvs then?
I didn't look at the file - is there complex setup that would be useful as a general reference?
still.. having the file in the config dir doesn't help that one user much
mshaver, you don't, that's why we want git ;)
sure you do
rm the file, then cvs rm file
(actually you can, but there will still be an "attic" I think)
then cvs commit -m "removed file"
SWPadnos: on any SCM system you'll have history and files preserved, even after deleting
yeah yeah - I guess it wasn't a great joke :)
SWPadnos: there's nothing in 924proto that isn't in the plain 924 files.
mshaver: make sure you remove the reference in the ini's if you also remove the emc.nml file
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
the config is fine imo
there you go - a tie ;)
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.
but since he's doing that already, he can also grab it from somewhere
bti files don't benefit much from versioning either
it's not that huge, but it still adds 160k to the package for all the users
is the BIT likely to change?
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 :)
mshaver: they are part of CVS now, they will exist forever
even if you remove them, they can be ressurected
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.
sounds like the best solution is to rewire the machine :D
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 ;)
it's at a customer now. I didn't want them to sell it, but they did anyway.
* alex_joni runs to bed
good night all
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
nighty night alex!
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'".
EMC: 03mshaver 07TRUNK * 10emc2/configs/smithy/ (README 924PROTO.BIT 924proto.hal 924proto.ini): removed 924 prototype lathe specific files
SWPadnos: I tried removing emc.nml like alex said, but it complains. Is it actually still necessary?
mshaver: I think you have to take it out of the config as well.
16:21:28 < alex_joni> mshaver: make sure you remove the reference in the ini's if you also remove the emc.nml file
mshaver, as jtr said, you need to remove the reference from the ini
if emc doesn't see a file specified, it will look in the common dir for it
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 :)
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...
mshaver: welcome back to the land of committers
* jepler disapperas again
thanks! now I can get my statistics up!
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.
I then edited ~/emc2/configs/sim/axis.ini and removed the line, "NML_FILE = emc.nml".
Re-running emc2 again, and selecting my, now local, sim/axis configuration results in:
Can not find -sec EMC -var NML_FILE -num 1
File "/usr/bin/axis", line 3609, in <module>
So, I believe that the reference to emc.nml is still required in the .ini file, at least if the DISPLAY is axis.
mshaver: you ran /usr/bin/axis. that's probably not TRUNK. The no-NML_FILE is on TRUNK only.
oh, alex said this was for 2.3 and forward.
(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)
I think he may have been mistaken
maybe i misinterped this :(
well, either way, mystery solved!
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...
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.
I'm a little lost.
is there a way that I can submit a patch of just the changes in the one file?
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'.
jelper thanks, Now how do I generate the patch?
or did that make it, and I just don't know where it is?
it prints it on the terminal
to put it in a file, use ">": cvs diff -u filename > my-changes.patch
if it prints nothing, then both files compared are identical
Ahh I see. Well, now that I have the patch where should I put it? Here?
Or at sourceforge?
e-mail to the developers list