cradek: one of those days we should look at debugging and using the ini file DEBUG for all things
there are enough flags afailable in 0xffffff to do anything ;)
debugging as in printing debug message (re you last commit)
but for now.. off to sleep for me
good night all
EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py:
EMC: fix so written halfile uses custompanel.xml instead of panel.xml (common naming
EMC: convention) Maybe not the right thing to do? existing stepconf users will have
EMC: to rename. Add some comments in written hal files so maybe people can figure out
EMC: how to do hand edits of hal files. Added some more driver timings
EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Maybe I should save the changes before committing...
hmmm. that's not a good commit message
makes me wonder how much testing has been done
The changes I forgot to change was capitalization in some strings
hmmm cvs must be down
hmm.. it seems so
gotta run to lunch, bbl
BigJohnT: cvs is ok from here
yet another morning where I have to arrive and say: cvs service should now be restored.
good morning :-)
and cvs is ok here too... please place your seats in the upright position and stow your tray tables and prepare for take off
* BigJohnT wanders off to eat breakfast
BigJohnT: I thought we prepare for landing
EMC: 03bigjohnt 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: add -Wn to halrun help loadusr printf
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/ (drivers.lyx pyvcp.lyx): move pico driver to own file
that somehow doesn't look quite right
what's that alex_joni
pyvcp.lyx): move pico driver to own file
oh yea I fixed a small thing in pyvcp.lyx too
and din't commit the pico file
or maybe that's coming later :)
hmm I was busy jabbering :)
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/ (hostmot2.lyx pico_ppmc.lyx m5i20.lyx): add files and fix minor in m5i20
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Master_Integrator.lyx Submakefile docs.xml index.tmpl): add drivers to html and integrator
remember I'm on a string to connect to the internet
heh, sorry for that
EMC: 03alex_joni 07TRUNK * 10emc2/docs/src/hal/basic_hal.lyx: provide info for linksp, linkps and unlinkp
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/stepper.lyx: use net instead of linksp
ha I just did that alex_joni
add linksp etc to basic hal :)
I'm merging what you did with what I did I like your explanations better :)
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/basic_hal.lyx: merge what Alex did with what I did on linksp etc
ha we were both working on the same thing at the same time alex_joni :)
* BigJohnT wanders out to poke in the fire
hey seb_kuzminsky you around
if you get a chance scan over this http://www.linuxcnc.org/docs/devel/html/drivers_hostmot2.html
* BigJohnT goes out so the dog can take me for a walk
TomBrown is now known as TomBrown_
TomBrown_ is now known as TomBrown
TomBrown is now known as TomBrown_
TomBrown_ is now known as TomBrown
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Submakefile docs.xml index.tmpl): wee all the nav links go somewhere now
* BigJohnT wanders off to take a nap
see you later
Has anyone looked at injecting a package into the Hardy 8.04 tree called emc2-inst (or similar) that will allow the user to download a script that will create the file /etc/apt/sources.list.d/emc2.list and update the pgpkey(s)?
I don't think so
back in the breezy days we had people using the regular ubuntu install cd, and then adding our kernel/emc packages. I still think not redistributing an entire OS is best, but to my dismay, users really (really) want a special install cd that has no extra steps.
also, unfortunately some users do not have net access at the machine, so they have a pain getting it installed otherwise (even now, they still have the pain that upgrading versions is hard)
I think it would be terrible to create an EMC Linux distribution. I'm delighted EMC is Ubuntu friendly.
it's not so bad to change some packages and rebuild a ubuntu distribution - that's all we have to do now
(making the kernel and rtai packages is the hard part)
I'm glad we don't have to do it more often than every few years
it's takes time away from emc work
All I'm asking about is putting a motor on the apt repository update. I'm not critisizing the distribution or packaging mechanisms in any way.
what is a motor?
Also, I wish to point out that I'm not asking anyone to do this work.
I'm working on creating a first time user type document.
oh I didn't mean to sound defensive - I'm not :-)
alex_joni is smarter about apt than I am. maybe he'll be around later.
dunno about anyone else, but I'm very very out of date on things like apt
I am too. I did the initial ubuntu work in '05 but not much since. alex has mostly taken that over.
was it you who brought the new /etc/apt/sources.list.d to our attention?
I'm still running dapper on my main PC - I've thought about updating to hardy, but "if it ain't broke don't fix it" ;-)
I have webserver, vmware, and some other things that I'd probably have to reconfigure
except the lathe itself, all my machines are also still dapper
if jepler's troubles with recent vmware are any indicator, I don't want to touch my vmware install
Yes, I'm the one who mentioned the new sources.list.d directory
we'll be sure to use that next time. much better solution.
I'd like to update, since this box is also my primary machine - I bet things like GIMP have improved
GIMP has improved immeasurably.
I wish to create a USB flash drive based EMC platform.
I want a GIMP that can handle >8 bit color depth
raw images from my camera are 12 bits per color
why? you can't display it
during processing (white balance, etc) things get granulated
That is coming but is not in the 8.04 tree at this time, as far as I know. It has been developed and the GIMP project has realeased it, though.
I too wish 12 bbc.
Linux is a bit light on PP capabilities for RAW processing. It's OK but not up to Photoshop levels, yet.
if I was a photographer first, I'd pretty much have to use photoshop
but I'm a linux guy first, photog second
Me too but those days will soon be over.
In most ways, I prefer GIMP to Photoshop.
... but if you're a professional photog, you're pretty much locked into Photoshop these days.
I have no experience with photoshop, so I can't really have a preference
are you a pro?
It's an amazing piece of software with brilliant capabilities and a dog's breakfast of a user interface.
No. I used to be.
Now I'm a network designer.
Did I mention I have an interest in EMC? :D
how are you using or planning to use it?
are you in the UK?
I'd like to create a USB flash drive based EMC platform using Ubuntu, unetbootin, and EMC.
No. I'm in one of the colonies.
* alex_joni is around now
"dog's breakfast" seems like a UK saying
and all ears too :)
TomBrown: seen gimpshop?
I think it's great.. so much better than gimp's interface
but then again, using photoshop probably bias'es me
back to packaging (if you like) ..
To be honest, I don't prefer the UI but it's a good app. I do a lot of animations these days and the GIMP path utils are really good. This is embarrassing, considering my past, but I care more about convenience these days than I do about quality.
One day very soon, we will have convenience and quality. 16bbc is no easy feat, though. I joined the GIMP development discussion and learned how amazingly difficult is has been. It took af ew years to get to this point.
I think I saw the sources.list.d/ dir last time I did the hardy CD, but didn't spend too much time to worry about it
Oh yes... distribution. :D
adapting the old script seemed a bit easier/faster
and these things usually are done a bit under time & nerve pressure to get them done already
then afterwards nobody wants to fix them right :D
I'd like to create and document a system that will allow for the creation of completely USB based firmware. Perhaps there could be some NFS based productivity items such as a common part repository.
anyways.. when building a new CD we should change that
and the current install script might need work too
The idea is: you create a running USB stick based system... when you wish to upgrade, you copy the USB stick, upgrade the copy... and now you have a backout option by simply returning to the original USB stick.
"USB based firmware" ?
Yes: More or less create a single image that some might view as firmware.
like and iso for CDs
Sure but perhaps not as polished. I'm only prepared to invest so much time. :D
I can imagine :)
These days I work in the networking field as a Cisco specialist.
and it's not for the wide range of emc users
I think a lot of people would be interested in a usb-based setup
We have some security appliances that are linux based. They have a web interface and their operating load is considered "firmware".
if they can take it to their indoor (net-connected) computer and run apt-get upgrade, all the better
cradek: people beeing able to boot USB sticks
When you update the firmware, you're really updating the apps and/or distribution but that's all shielded from the users.
unetbootin makes it pretty easy. I have no wish to re-invent the wheel.
TomBrown: if you wish to work on it, by all means .. pick the stuff you like
I'm also interested in a PXE boot capability. I'd like my shop PCs to be completely solid state, right down to the PSUs.
I expect I'll have to have a fan on the stepper PSU, though.
dunno what kind of drives you are using
if you go via big transformer+rectifier bridge, etc..
I have geckos running at a large fraction of their ratings, on a lump of aluminum extrusion, no fan, no problems
I haven't played with net booting since the days you burnt an eprom and stuck it on the (isa) network card. PXE machine tools sounds very useful and if someone would figure it all out for me, I'd be tickled.
PXE is even better. We could create an image that will simply untar into a tftp accessible directory, point the client to the new image, and it's on. If it doesn't work as expected, simply point the client at the old image, reboot, and it's back to the old.
It will be done, cradek.
The only issue with PXE and USB both is that they bump up the minimum RAM requirement.
more than 384?
or lots more than 384?
It pretty much comes down to 512MB being a minimum machine and 1 GB being more realistic.
looks like the machine I'd try it on has 768 now
well.. machines beein gable to boot from USB or do PXE I expect are fairly recent
It might be possible to squeeze into 384.
I never thought I'd say it, but RAM is dirt cheap. who cares.
Intel came out with PXE a decade ago, or so, but USB has only been here the last 5, or so, years. Even at that, USB boot hasn't been universal until farily recently.
I'm a bit concerned about this effort being considered elitist and counter productive to the EMC herritage of being able to run on a TI-66 pocket calculator.
that's not quite true :)
I don't think any of this involves any change to emc2
we may lag behind the times (and I've been a big proponent of that), but there are limits
we gave up on kernel 2.4 not too long ago
I hope the efficiency of EMC and Linux continues but I'm more concerned about creating a working system and defending that system. I would like to bring some machine work in-house (I'm a private guy) and I don't want to take a recommended security update and then have to explain why I'm going to be late completing the projects I've ocmmitted to.
when I started on EMC it could be built on 2.2
I think even 2.0.x
TomBrown: no reason to update your machine if you don't feel like it
Not long ago, I received a flier for a pair of matched 1 GB - DDR2/533 memory sticks for $40. That's $20/meg.
in the last 3? years we used ubuntu I don't think I remember any updates making emc2 less usable
This is interesting and appreciated. I've found Ubuntu updates to be exceptionally well tested and stable but I don't completely trust them.
I used to be a gentoo guy so my paranoia is somewhat justified. :D
I don't either, but still, if in the middle of something important, I wouldn't change any software without good reason
well, if you're not network connected.. there's not much point in updates
... both good points.
unless you're bitten by bugs which get fixed by those udpates
anyways... back to your plans
(the only problem we have is users complaining about bugs that were discovered and fixed months ago...)
Eventually, I have an interest in working on linux based CAM. I'm not that sharp with that stuff but I'm a decent and long experienced programmer.
but that's not too common. most have grown to trust our updates. we are extremely careful.
TomBrown: can you elaborate on what you want to build?
I think CAM should be implemented on the CAD workstation first but ultimately, it would be nice if it could move to the controller.
When/if that happens, I will be extremely thankful to have a good version control mechanism.
Alex: are you asking about my CAM ideas or solid state machine control ideas?
I wish to point out that I'm not married to this USB stick based EMC idea. If the group were to suggest that I investigate CF card and CF <-> IDE adapters, or purpose built SSD devices, I would happily work in that direction. USB seems cheap, easy, and effective. That's the only reason I am looking in that direction.
Alex: Good because my CAM ideas are pie in the sky, at this point. lol!
TomBrown: CF cards + IDE adapter are probably even more universal than USB booting
No question, Alex.
... but you don't really need me to pave that road.
but ultimately it's up to who wants to do it
well.. depends what you want to put on it
one neat thing about USB is that you can sneak it into a computer store and run a latency test on the floor model ;-)
IDE+CF needs the case opened
I work for a grain handling company. We have PC based protein testers that used to have hard disks in them. I had my guys convert them to CF based IDE disks and they have become extremely reliable.
jmkasunich: I doubt they leave BIOS unsecured there
It is possible to use IDE+CF with the CF port being front plate mounted so you can easily swap CF cards for version control.
These protein testers get plugged with grain dust. They used to run 18~24 months typicall before requiring a new hard disk. Now they run indefinitely.
that is in spite of the filters o HD vents?
The key difference between the protein tester and an EMC device being the protein tester is DOS based and doesn't hit the disk very hard. EMC is linux based so a little thought on minimizing write activity willl be needed for longevity of the flash device.
The testers are vented as they do create quite a bit of heat.
someone who is building an all solid-state machine should be willing to spring for a gig of ram (cheap these days)
that should let you forgo swap
With the CF+IDE solution, they just keep going and going. The failure rate has pretty much dropped to zero. Now we just maintain the mechanical side of them (I'm not heavily involved in that side of the maintenance requirement).
That's how I think of it too, jmkasunich. I don't wish to bump the requirement to opressive levels but 1 GB is not a lot of RAM these days.
I plan to build a Joes 4x4 Hybrid gantry. The gantry itself is going to cost about $1400 to build. From there, I will need a servo or stepper based system. Being 4 feet square, I will need to provide significant power to attain reasonable speeds. That's going to mean a bunch more money.
What it all comes down to is: I don't think requiring PC hardware worth a couple of hundred dollars brand new is going to be all that significant.
requiring that for every user would be significant - requireing that if you want an all-solid-state solution isn't
* alex_joni wonders if he's back
... and I expect the actual requirement to be 512MB.
... for netboot or USB.
alex is back
Once again: I wish to enhance the EMC platform and project. I have no interest in working counter to the philosophies of the EMC team.
whee.. read the logs, so I'm back on track
TomBrown: the "philosophies" of the team are mostly towards the project itself
alex_joni: do you want me to commit my attempt at a rebase of joints_axes?
cradek: sure, why not
was it lots of work?
I'm not entirely sure of the stuff in the nml directory, but everything else I'm pretty sure is right
it was only an hour or two
ok, sounds good
go ahead, it was already in pretty bad shape.. so nothing you can break
I think the most important missing thing is a design document
that's probably what made me stop ..
well it's not much but maybe it will help you guys if you want to work on it some more.
it'll help merging it later
yes very much
Thank you, gentlemen. I feel I've presented the solid state machine idea and will now go off to actualize it. I appreciate your objectivity as well as your time.
we appreciate your interest - the devs the better IMO
TomBrown: best of luck
TomBrown: sure thing, glad to have your interest
* alex_joni passes jmkasunich a "more"
TomBrown: we're almost all the time in here, so feel free to stop by for pointers, progress or OT talk :D
EMC: 03cradek 07joints_axes2 * 10emc2/ (TODO VERSION): rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/configs/scara/ (scara.ini scara_sim_4.hal): rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/src/Makefile: rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/src/emc/canterp/canterp.cc: rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/src/emc/ini/ (6 files): rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/src/emc/motion/ (command.c control.c homing.c motion.h usrmotintf.cc): rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/src/emc/nml_intf/ (8 files): rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/src/emc/task/ (emctask.cc emctaskmain.cc taskintf.cc): rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/src/emc/usr_intf/ (7 files): rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: rebase joint_axes branch which also has the changes from new-telop branch
EMC: 03cradek 07joints_axes2 * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: rebase joint_axes branch which also has the changes from new-telop branch
oh, you made a new branch..
cradek: cool, thanks
EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr_axis.po fr_rs274_err.po): french translation update
welcome, but you shouldn't thank me before you try running it
alex_joni: I think there isn't any other way of doing it
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/man/man1/gs2.1: add gs2 man page
BigJohnT_ is now known as BigJohnT
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/GS2.lyx: missed a pin