Back
[00:00:04] <alex_joni> ok
[00:13:14] <cradek> http://cats.iamnear.net/?q=68502
[00:13:30] <cradek> I guess this is supposed to show you five photos of cats near you
[00:13:45] <cradek> ... what a failure in my case
[00:29:33] <alex_joni> good night ;)
[00:34:45] <cradek> goodnight, thanks again
[01:33:04] <pminmo> I have started writing an article targeted at Windows users that don't realize what they are missing it's not done, but thought I would solicit input as to if it's worthwhile or succestions or....critisism welcome
http://pminmo.com/emc.pdf
[01:33:44] <pminmo> suggestions
[01:34:21] <jepler> heh .. I'll have a look, but my ability to relate to the windows crowd is so bad that I wouldn't trust anything I have to say about the article
[01:35:33] <jepler> looks good, needs a picture
[01:36:41] <pminmo> needs lots of things......
[01:36:55] <pminmo> :-)
[01:38:23] <jepler> this all reminds me (for no good reason) .. I still haven't tried out the linux sheetcam
[01:39:27] <pminmo> I get the impression most of the people here are Linux savvy, spend little time in MS world. Probably just me, but I hit lots of frustrations making the transition
[01:40:02] <rayh> What kinds of frustrations?
[01:40:19] <SWPadnos> I'm not sure anyone here has used MS Word in a decade or more (except maybe Alex and Jymmm)
[01:40:40] <SWPadnos> I used to use WordPerfect, but I think the last time was about 5 years ago
[01:40:54] <pminmo> hardware incompatabilities to start, dual boot issues
[01:41:15] <rayh> I moved quite a few wordperfect files over to oo not long ago.
[01:41:43] <SWPadnos> yep - once OO got a mostly working WP import filter, I was able to dump WP completely
[01:41:50] <pminmo> not know linux at all, its a whole different language
[01:41:55] <rayh> pick one hw incompatability or dual boot and describe briefly.
[01:41:57] <SWPadnos> the one thing it still does better is envelopes - getting them right in OO is tricky
[01:42:04] <SWPadnos> (and of course there's "reveal codes" :) )
[01:42:14] <jepler> hm this isn't a good sign. on the first run, sheetcam says "the plugin has thrown an error. do you want to edit the macro?" and the default seems to be "yes".
[01:42:18] <rayh> That one I can understand why why would you need to know Linux to run a ubuntu pc.
[01:42:28] <pminmo> video, wireless
[01:42:53] <pminmo> grub, lilo
[01:42:58] <pminmo> gparted
[01:43:04] <rayh> okay video. What about simply using a generic.
[01:43:14] <rayh> like vesa
[01:43:34] <pminmo> when the pc comes up and you fave 640 x 480 and can't scroll your toast
[01:43:38] <pminmo> have
[01:44:13] <rayh> I guess I've not seen that low a resolution from an install in a while.
[01:44:16] <pminmo> I'm not sure I would be running today if it wasn't for your classes at the workshop ray
[01:44:31] <rayh> Ah. Okay.
[01:44:59] <rayh> Did 8.04 fail to set up your wireless.
[01:45:06] <pminmo> yes it did
[01:45:17] <pminmo> three different "compatable" cards
[01:45:46] <rayh> I do favor external boxes but have worked at least two cards.
[01:46:09] <rayh> One took a bunch of hunting and a wrapper compile.
[01:46:30] <pminmo> yes I've given up , will order an access point
[01:46:34] <rayh> Do you use the live cd and run from it to see how the install might go.
[01:46:44] <pminmo> yes I did
[01:46:52] <pminmo> four different pc's
[01:46:52] <rayh> and that failed?
[01:47:09] <rayh> How old were they?
[01:47:15] <pminmo> the one I first started with was the one I spent sooo much time one
[01:47:17] <pminmo> on
[01:47:24] <pminmo> the last three went smoother
[01:47:38] <rayh> Ah that is a good sign.
[01:48:05] <pminmo> but I had to decide I REALLY wanted EMC to go through the hassle
[01:48:34] <rayh> Yep and apparently you wanted it bad enough.
[01:49:10] <pminmo> I'm still struggling with stuff from time to time, but I'm getting there
[01:49:32] <rayh> One real problem with MS tm loaded boxes is that they tend to be much to much and much to new.
[01:49:45] <rayh> You mentioned grub issues?
[01:49:48] <pminmo> decided to order an Atom board to dedicate
[01:50:02] <rayh> Atom?
[01:50:16] <pminmo> little Intel itx board
[01:50:36] <rayh> Okay? On board video?
[01:50:46] <rayh> If so what's the chipset?
[01:50:53] <pminmo> http://www.newegg.com/Product/Product.aspx?Item=N82E16813121342&Tpk=atom
[01:51:01] <rayh> looking
[01:51:29] <SWPadnos> http://www.newegg.com/Product/Product.aspx?Item=N82E16813135091
[01:51:32] <SWPadnos> try that one :)
[01:51:53] <SWPadnos> I haven't ordered one yet, but the price is staggeringly low
[01:52:37] <pminmo> ouch, the otherone is already on order
[01:53:00] <SWPadnos> they're both good deals, but T80 (less $20) including MB/CPU/RAM... O_O
[01:53:10] <SWPadnos> at $80 -20 ...
[01:53:28] <pminmo> actually I wanted an itx though
[01:53:43] <SWPadnos> ah, it is a little smaller
[01:54:01] <pminmo> just not sure about how the onboard video and rtai, but it has one pci slot
[01:54:13] <pminmo> if needed
[01:54:28] <SWPadnos> yep - the GOAL3+ also has a PCI and a PCIe x16 slot
[01:54:46] <SWPadnos> I should just order that and be done with it :)
[01:55:06] <SWPadnos> (but I'm leaving for Germany in a week, and there's no use having it gather dust while I'm gone)
[01:55:19] <SWPadnos> oh hmm - 2 PCI slots
[01:55:54] <rayh> I see some issues with that Intel GMA 950 chipset
[01:55:56] <pminmo> well I'm painting my house, replacing some siding, landscaping while the weather is nice........same dust
[01:56:03] <SWPadnos> heh
[01:56:53] <pminmo> somebody has an atom running emc2
[01:57:12] <rayh> Something about display and having to get a newer drive software for wide displays.
[01:57:17] <rayh> Not emc ubuntu.
[01:57:24] <rayh> I search there first.
[01:57:34] <pminmo> yes, it's on the linuxcnc website
[01:57:59] <pminmo> I just don't remember where
[01:58:31] <pminmo> and I still can't navigate it well
[01:59:13] <rayh> Ah maybe the wiki.
[02:03:34] <pminmo> need to run....stuff to prep for tomorrows tasks...I'm ready for winter and I don't like cold weather
[02:04:01] <rayh> take care.
[02:04:05] <SWPadnos> see you
[02:11:46] <seb_kuzminsky> hi guys
[02:11:52] <SWPadnos> hi
[02:28:23] <jepler> darn, missed seb
[02:30:53] <SWPadnos> hmmm - I wonder if you have a minute to talk about a lyx problem I'm having
[02:33:42] <rayh> lyx problem?
[02:38:26] <seb_kuzminsky> hi eric
[02:38:33] <ehj> I am here
[02:38:54] <seb_kuzminsky> hey, thanks for testing out the hostmot2 driver, sorry it's not going smoother ...
[02:38:55] <ehj> Did the dmesg output tell you anything?
[02:39:03] <ehj> np
[02:39:36] <seb_kuzminsky> not really, it ends without any output from the hostmot2 driver
[02:39:43] <seb_kuzminsky> hm, try this:
[02:40:11] <seb_kuzminsky> echo 4 | sudo dd of=/proc/rtapi/debug
[02:40:26] <seb_kuzminsky> that will turn on all debug output, that's how i normally run when debugging stuff
[02:40:39] <seb_kuzminsky> then re-load the hostmot2 driver with those debug flags and try to make the pwm move
[02:40:50] <seb_kuzminsky> then pastebin *that* dmesg output
[02:41:00] <ehj> k, give me a minute. It is on another computer.
[02:41:57] <SWPLinux> pastebin has a 20k limit - it may just truncate
[02:42:15] <SWPLinux> so maybe paste only the juicy parts :)
[02:42:27] <SWPLinux> (or maybe it's >20k, but issy ran into that earlier today)
[02:46:28] <ehj> Checking for a typo, I am getting no such directory.
[02:46:51] <seb_kuzminsky> it appears when the realtime kernel is loaded
[02:48:37] <ehj> Oh, sorry. I thought I had to run that before emc.
[02:48:54] <seb_kuzminsky> after starting emc but before loading hostmot2
[02:51:41] <ehj> oh, ok, don't have it set up that way. Running a full configuration. Let me do it that way.
[02:55:59] <seb_kuzminsky> fwiw, here's the script i use to play with hostmot2 on my development machine:
[02:56:04] <seb_kuzminsky> http://highlab.com/~seb/bzr/fabrication/projects/mesa-electronics/test
[02:56:27] <seb_kuzminsky> that's using the hm2.hal that's in configs/hostmot2
[03:10:16] <seb_kuzminsky> is there a way to set the rtapi debug level in a full-up machine config? there's got to be
[03:11:05] <SWPadnos> does DEBUG=0x7FFFFFFF in the ini file not do what you want?
[03:12:12] <SWPadnos> actually, you should be able to change the realtime script to do that echo for you (probably doesn't need root either, just echo)
[03:13:00] <seb_kuzminsky> i have no idea what that DEBUG statement would do in an ini file, i've never used one ;-)
[03:13:02] <jmkasunich> echo 4 >/proc/rtapi/debug should do it
[03:13:14] <ehj> I am doing something wrong. After I do the "loadrt hm2_5i20 ..." I am getting no pins.
[03:13:19] <SWPadnos> I guess you could put that in a HAL file
[03:13:26] <jmkasunich> DEBUG in an ini file sets a number of debugging flags for the user parts of EMC
[03:13:32] <jmkasunich> no connection with rtapi debug level
[03:13:35] <seb_kuzminsky> ah
[03:13:40] <SWPadnos> ok, I wasn't sure if the RTAPI stuff was also connected to that
[03:13:54] <jmkasunich> it probably should be, but isn;t
[03:13:56] <jmkasunich> '
[03:13:59] <seb_kuzminsky> ehj: does the hm2_5i20 driver load at all?
[03:14:56] <seb_kuzminsky> if you get no pins then it didnt load and the problem is probably earlier...
[03:15:14] <seb_kuzminsky> is the hostmot2 driver successfully loaded, along with the rest of the realtime environment?
[03:19:31] <ehj> Yes, the driver loads, because if I try to load it again I get an error. I can then unload it.
[03:21:02] <ehj> I will have to pick this up later. It is getting too late. I will try again tomorrow.
[03:21:26] <seb_kuzminsky> ok, anytime you get to a place where it's not doing what it aught, pastebin the dmesg and we'll take a look
[03:21:33] <ehj> k
[03:21:38] <SWPadnos> the tail end of the dmesg ;)
[03:21:42] <ehj> yes
[03:21:49] <ehj> thanks
[03:21:57] <SWPadnos> see you later
[03:21:59] <seb_kuzminsky> sure, we'll get it squared
[03:22:01] <seb_kuzminsky> goodnight
[03:22:07] <jmkasunich> hint: "dmesg -c" to clear the log, then run, then dmesg to see only stuff since you cleared it
[03:22:18] <seb_kuzminsky> jmk ftw
[03:22:35] <ehj> later
[03:22:52] <seb_kuzminsky> man what a strange bug
[03:23:04] <seb_kuzminsky> pwm works fine on mine here
[03:23:28] <seb_kuzminsky> i'm suspecting cables & connectors right now
[03:23:42] <SWPadnos> except that it works with the old 5i20 driver
[03:23:56] <seb_kuzminsky> oh yeah...
[03:24:01] <SWPadnos> heh -sorry ;)
[03:24:13] <seb_kuzminsky> *pop* went my thought-ballon
[03:25:00] <cradek> does it help if I said hm2 pwm didn't work for me either?
[03:25:13] <seb_kuzminsky> really?
[03:25:26] <seb_kuzminsky> yes that does help...
[03:25:26] <cradek> yes
[03:25:37] <seb_kuzminsky> didnt know you'd tried it
[03:25:43] <cradek> jepler and I were trying to get dac output from the 7i33 and there was none
[03:26:00] <seb_kuzminsky> same symptoms as ehj? /enable works, dir works, pwm does nothing
[03:26:34] <cradek> I did not check the pwm dir, I only had the 7i33 output to test
[03:26:52] <seb_kuzminsky> was this with a 5i20?
[03:26:54] <cradek> it stayed at 0v but the enable did come on
[03:26:56] <cradek> yes
[03:27:24] <seb_kuzminsky> have i lost my head?
[03:27:27] <SWPadnos> I wonder if you had the 7i33 jumpered for external power
[03:27:42] <seb_kuzminsky> hold on, let me go try this out in the garage, back in 5
[03:27:47] <SWPadnos> or did it work with old 5i20 with no changes?
[03:27:48] <cradek> no it is jumpered for internal
[03:27:51] <SWPadnos> ok
[03:27:54] <cradek> yes it works fine with the old driver
[03:28:24] <SWPadnos> seb_kuzminsky, one thing to check - make sure that the md5sum from your bitfile matches the one in CVS/the deb package
[03:28:26] <SWPadnos> ok
[03:31:38] <SWPLinux> here are the sums from my CVS checkout:
http://www.pastebin.ca/1200708
[03:34:36] <garage_seb> hey
[03:34:52] <jmkasunich> hey yourself
[03:35:31] <SWPLinux> here are the sums from my CVS checkout:
http://www.pastebin.ca/1200708
[03:35:55] <SWPadnos> in case you want to compare to yours (probably not the problem, but might as well check)
[03:36:19] <garage_seb> that's what i get here too
[03:37:53] <garage_seb> cradek: which firmware did you try?
[03:40:19] <SWPadnos> I think there's an error in hostmot2.vhd in the 5i20 dir
[03:40:48] <SWPadnos> oh hmm - maybe not
[03:42:15] <garage_seb> well its still working here
[03:42:53] <SWPadnos> do you have all the PWMs on?
[03:42:58] <SWPadnos> /enabled
[03:43:00] <garage_seb> 2 pwms
[03:43:04] <SWPadnos> hmmm
[03:43:29] <garage_seb> & 3 encoders & 2 stepgens
[03:43:34] <garage_seb> i'll try it with just one pwmgen
[03:44:43] <garage_seb> still no problem
[03:45:16] <SWPadnos> have you checked the md5sums? :)
[03:46:37] <garage_seb> i compared mine to the ones you pastebinned and they're the same
[03:48:52] <SWPadnos> ok, so we know there's a problem :)
[03:53:19] <garage_seb> hm, cradek, are you on CVS TRUNK? or 2.2?
[03:56:58] <garage_seb> behavior of encoders has changed (current top-of-tree TRUNK differs from hm2-0.10)
[03:57:20] <garage_seb> looks like jeff's encoder index changes had unintended consequences
[03:57:36] <garage_seb> but i dont think that's related to the pwm problem people are having
[03:57:58] <garage_seb> both top-of-tree TRUNK and hm2-0.10 have working pwm for me here
[03:59:33] <garage_seb> jmkasunich: you're right that i dont need sudo to write to /proc/rtapi/debug, but i *do* need dd:
[03:59:50] <garage_seb> > echo 4 > /proc/rtapi/debug
[03:59:50] <garage_seb> bash: /proc/rtapi/debug: cannot overwrite existing file
[03:59:52] <SWPadnos> that's odd
[04:00:08] <garage_seb> i've got noclobber on, hold on...
[04:00:21] <SWPadnos> you could try echo 4 >> /proc/rtapi/debug
[04:00:27] <garage_seb> ah yes without noclobber it works just fine:
[04:00:34] <garage_seb> echo 4 >| /proc/rtapi/debug
[04:00:39] <garage_seb> never mind me....
[04:00:42] <SWPadnos> ok
[04:00:44] <SWPadnos> :)
[04:10:45] <garage_seb> it's .scale
[04:11:40] <garage_seb> i'm an idiot
[05:34:53] <CIA-41> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/hostmot2.h: oops, i've been forgetting to update the version number
[05:37:03] <garage_seb> pwmgen should work now
[05:37:07] <garage_seb> goodnight
[09:11:18] <micges> alex_joni: what meaning have feedrate_blackout variable in axis ?
[09:11:26] <micges> in this code:
[09:11:26] <micges> if time.time() > feedrate_blackout:
[09:11:26] <micges> vupdate(vars.feedrate, int(100 * self.stat.feedrate + .5))
[09:19:23] <alex_joni> I have no idea
[09:19:32] <alex_joni> sorry.. :)
[09:20:04] <alex_joni> I think it updates the feedrate from the status buffer only ever so often
[09:20:23] <alex_joni> otherwise the feedrate would jump all over the place (very irregular display)
[09:20:28] <alex_joni> but this is just me speculating :D
[09:21:55] <micges> np
[12:09:03] <jepler> micges: after the feedrate has been modified by axis, the slider is not updated from the stat buffer until after 'feedrate_blackout' seconds have passed. If this is not done, then the slider will seem to randomly return to older values when it is being modified by axis (by clicking, dragging, keypresses, or whatever)
[12:09:15] <jepler> change that to 'if 1' and drag the slider left and right; you'll easily see the effect
[12:10:23] <jepler> (contrary to what alex said, when axis hasn't altered the feedrate recently, it immediately displays new values when they appear in the status buffer, so if you haven't touched the axis feedrate slider in the last few seconds and then you use a halui based method to change FO, it will be reflected immediately)
[12:11:46] <skunkworks> logger_dev: bookmark
[12:11:46] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-09-12.txt
[12:12:01] <jepler> good morning skunkworks
[12:12:23] <skunkworks> Good morning jepler. It is friday!
[12:12:25] <jepler> yep
[12:13:57] <micges> jepler: thanks
[13:24:08] <alex_joni> micges: see how much I know :)
[13:24:18] <alex_joni> skunkworks: even better
[13:24:25] <alex_joni> it's friday after 4PM
[13:24:52] <skunkworks> alex_joni: just means monday is coming that much faster for you ;)
[13:25:10] <alex_joni> well.. actually I still got tons of work, till I go home
[13:25:27] <skunkworks> yeck
[13:26:42] <alex_joni> yeah.. fun :/
[13:27:08] <skunkworks> I have a dell blade server that is boots the livecd to busybox. I am having trouble finding info on that.
[13:27:19] <micges> alex_joni: :)
[13:27:31] <skunkworks> *power edge
[13:30:38] <skunkworks> I get the impression that it is because it doesn't see any drives?
[13:30:50] <skunkworks> (it has 4 scsi drives in it)
[13:41:20] <fenn> maybe you pressed ctrl-alt-[1-6] on accident
[13:41:55] <skunkworks> na - rebooted a few times now. Searching the ubuntu forums again :)
[13:42:14] <fenn> maybe you can poke around in the shell to see what the prob is
[13:47:37] <skunkworks> I get to the initramfs prompt
[13:48:32] <alex_joni> skunkworks: check the log.. it probably failed on something
[13:48:46] <alex_joni> maybe try to pass some boot params, like allgenericide
[13:49:16] <skunkworks> ok - do you know who you are talking to? How do I check the log? ;)
[13:49:38] <fenn> dmesg
[13:49:46] <skunkworks> oh duh
[13:50:07] <alex_joni> or shift-page-up
[14:12:36] <skunkworks> I get a lot of sd* unknown patition table..
[14:13:25] <skunkworks> there is a driver sd needs updating entry
[14:29:12] <skunkworks> alex_joni: at a fresh boot to the busybox prompt - there isn't any errors above (shift-page-up)
[14:51:19] <skunkworks> dapper seems to boot on it :)
[14:54:16] <alex_joni> maybe try installing dapper, then upgrading :)
[14:54:39] <alex_joni> hi seb
[14:55:14] <skunkworks> * skunkworks doesn't have a problem using dapper..
[14:56:23] <seb_kuzminsky> hi alex :-)
[15:15:17] <alex_joni> seb_kuzminsky: we had a user with a small 5i20 problem yesterday
[15:15:43] <alex_joni> seems linux hotplug was picking the 5i20 card up, and the driver ended up insmod-ed on boot time
[15:16:35] <SWPadnos> little request_firmware side effect? :)
[15:22:49] <alex_joni> beats me :D
[15:47:36] <skunkworks> heh - 168 updates for dapper.
[15:53:52] <issy> can somebody tell me if is possible to run the emc tru remote x server without runing X
[15:54:33] <jepler> hooray, looks like maybe my isp got their routing issues fixed
[15:54:37] <jepler> hopefully this stays up
[15:55:02] <issy> can somebody tell me if is possible to run the emc tru x-server remote without runing X on the linux
[15:55:16] <issy> x
[15:55:51] <SWPadnos> uh
[15:57:56] <issy> d
[15:58:03] <jepler> I routinely run axis over ssh's X forwarding. X also happens to normally be running on that system, but just for grins I stopped X on that system with /etc/init.d/gdm stop and it still works fine
[15:58:35] <SWPadnos> yep - I've made an embedded system that never runs X, and graphical X apps still work remotely
[15:58:45] <SWPadnos> X is installed though
[15:59:09] <issy> my idea is to use pc104+ geode board , stopping the video , and remotely pass it to x - server
[15:59:14] <SWPadnos> I'm not sure exactly what can be removed on the "target" system
[15:59:32] <issy> no need to remove eniting
[15:59:55] <SWPadnos> ok, if there's enough space on the "hard disk" for an X install, then you're all set
[16:00:48] <SWPadnos> I changed the runlevels so that runlevel 2 is a console multiuser boot, and runlevel 3 is graphical multiuser (like everyone other than Debian does :) )
[16:01:00] <jepler> SWPadnos: the emc .deb package has concentrated on having correct dependency information and a single monolithic package. it's almost certainly a larger set than you need to just run emc plus just one of the GUIs.
[16:01:13] <SWPadnos> I got rid of a lot of junk in the startup scripts too
[16:01:23] <issy> the grafic on the rt linux is something i dont like , generaly the shared memory is not for rt linux.
[16:01:39] <SWPadnos> right
[16:01:46] <jepler> patches to configure+makefiles to make it easier to build emc subsets, and pacthes to debian/* to make non-monolithic packages with leaner dependencies would both be thoughtfully considered for inclusion
[16:01:56] <issy> another issue is that to work correctly , you have to forget the acceleratin on RT systems
[16:02:08] <SWPadnos> I also noticed that timing got worse when I was using networking, so YMMV
[16:02:21] <SWPadnos> video acceleration?
[16:02:36] <SWPadnos> jepler, OK, I'll keep that in mind
[16:02:36] <issy> yes
[16:02:56] <SWPadnos> I think we may want 3 (maybe more) packages. emc-core, emc-gui, emc-doc
[16:03:04] <jepler> emc-hal ?
[16:03:11] <SWPadnos> yeah, maybe that too
[16:03:26] <SWPadnos> actually, emc-sim-hal and emc-rt-hal
[16:03:26] <issy> the video acceleration writes to the memory directly , and stopping all the rest. otherwice will not be an acceleration
[16:03:38] <SWPadnos> but I'm not sure quite how to break it out yet
[16:04:22] <jepler> SWPadnos: yeah I'd leave that alone at first
[16:04:41] <SWPadnos> actually, HAL is not really EMC, so hal-rt and hal-sim may be appropriate (except for the fact that there are other things called HAL in Linux)
[16:05:01] <jepler> sure, there might be a better package name
[16:05:07] <SWPadnos> jepler, yep, sim can be a complete system anyway, since it isn't meant to run RT machines
[16:05:17] <SWPadnos> and it can be ignored for now also ;)
[16:08:35] <issy> ok. let's try , we need open source x-server for windows and compilation for the emc-axis
[16:08:56] <issy> I can do the windows X part as open source ,
[16:08:58] <SWPadnos> cygwin-X works fine with EMC programs
[16:09:04] <issy> forget it.
[16:10:24] <SWPadnos> some features of AXIS will be missing if you want to actually execute it on a remote PC (versus running it on the target and displaying the UI on a remote PC)
[16:10:27] <issy> jepler , can you do the compilation for the linux
[16:11:16] <issy> the axis runs on the target , only the video , keyboard , mouse and sound will be remoted out
[16:12:47] <issy> I dont know haw will be the RT linux with the net..
[16:13:13] <jepler> issy: I don't understand what you are asking me to compile
[16:13:18] <issy> the intel chips work with hardware mac hub , but most of the rest are software
[16:14:12] <issy> Well , I would like to try the emc without the x
[16:14:39] <issy> runing it with the axis guy on the local computer
[16:15:03] <issy> and transfering the video and keyboard to the
[16:15:52] <jepler> that doesn't require any change to axis; that is a basic capability of the X Windowing System.
[16:16:08] <SWPadnos> boot the EMC computer, don't log in. using a different computer, do "ssh -X ip.of.EMC.PC". run EMC from that SSH terminal
[16:16:19] <SWPadnos> done :)
[16:16:21] <issy> yes , need only to remove the x
[16:16:51] <SWPadnos> from what?
[16:17:08] <issy> from the linux emc computer
[16:17:53] <SWPadnos> ok, then on the EMC computer, switch to a console and login. do `sudo /etc/init.d/gdm stop'
[16:18:15] <SWPadnos> switch back to the X screen and hit ctrl-alt-backspace to kill the X server (or use kill from the console)
[16:18:25] <jepler> this is the top google hit for 'ubuntu disable X server', it looks relevant:
http://ubuntuforums.org/showthread.php?t=43516
[16:18:33] <SWPadnos> then go to the remote PC and use ssh -X
[16:18:51] <issy> thanks. I will try it now
[16:19:49] <issy> with realtc net chips work worse!!!!!
[16:19:58] <SWPadnos> yep
[16:20:07] <issy> the software hub
[16:20:40] <issy> WAUUUUUUUU 6000 / interupts/second....
[16:20:55] <issy> let see the intel
[16:21:10] <SWPadnos> I have an embedded PC with a core2 duo 1.8 GHz, which often has latencies less than 1000ns. if I run video or network on that machine, the latencies spike to 14000 ns several times a second
[16:21:15] <SWPadnos> mine is Intel
[16:21:35] <issy> 240 interupts/second with intel
[16:21:44] <jepler> if you want an Ubuntu installation without the X server, then you want to start with the "server" install CD from ubuntu instead of the emc2 live cd. then add emc2 by hand. this will pull in X-related libs but shouldn't pull in any X server
[16:22:02] <SWPadnos> who cares how many interrupts there are? the important thing is how long they prevent the RT kernel from doing its work
[16:22:26] <issy> too much for realtec...
[16:22:47] <issy> with intel the latency is 18000
[16:22:53] <SWPadnos> the number of interrupts from your network card will be proportional to the amount of network traffic on your ethernet segment
[16:23:06] <issy> with realtec 36000
[16:23:18] <issy> the packages and the size are the same
[16:23:51] <issy> the difference is twice.
[16:24:22] <issy> well if you intend to use mesa or pluto boards, the latency is not so important
[16:24:31] <SWPadnos> I'm not sure I know what you're saying. as long as you do, I'm OK with that :)
[16:24:40] <issy> but for steppers at hi speed ..... using the parport....
[16:25:07] <issy> welll , not the ideal
[16:25:11] <issy> solution
[16:25:26] <SWPadnos> heh - for my application, I needed 10000 interrupts/sec, and had to do floating point on a few dozen analog I/Os every time
[16:25:46] <issy> what are you using
[16:25:54] <SWPadnos> I used a Mesa card to interface to my analog card
[16:25:55] <issy> as i/o
[16:26:17] <SWPadnos> mesa + 7i37 for digital, custom board for analog
[16:26:23] <SWPadnos> also connected to mesa
[16:26:47] <issy> with the mesa you can work with latency up to 40000 , try to connect at this latency steppers to the parport... with no mesa , and you will see
[16:27:18] <SWPadnos> oh, of course. I know high latency is bad for steppers, and for servos controlled with parallel port PWM
[16:27:56] <SWPadnos> in my case, 40000 would have been way too much latency anyway - that would have been a 40% phase shift in the PID output
[16:28:09] <issy> it what i am sayng . with net using software hun , the latency junp twice
[16:29:05] <SWPadnos> I had the same problem with an Intel chipset. it only went to 14000 or so, but that's a lot compared to 600 (yes, six hundred)
[16:30:24] <issy> i see that the intel net is hardware , but many thers are software .
[16:30:54] <issy> so , when using steppers forget the net if its not hardware mac
[16:31:24] <SWPadnos> doesn't bother me - I have no intention of using steppers ;)
[16:32:04] <issy> the test machine I am using is 800 mhz via c7 , and works fine with the steppers , if the net is disabled
[16:32:20] <issy> i got speed at 14/m- min
[16:32:24] <SWPadnos> if net and video are disabled ;)
[16:32:36] <SWPadnos> (which makes it hard to see what's going on :) )
[16:33:37] <issy> seems the net drivers and the rt are not intended to work together
[16:33:48] <issy> mean net drivers
[16:34:18] <SWPadnos> I've been tempted to search various net drivers for CLI calls, but haven't gotten around to it
[16:36:03] <issy> unfortunately in the last editions of the net chips , all the manufacturers are using software mac and hub's as they are easy to use.
[16:36:28] <issy> I have to ask Peter walice if can be do inthe mesa fpga ,
[16:36:58] <SWPadnos> what, ethernet?
[16:37:08] <issy> then the remote communication well be much bether
[16:37:15] <issy> yes , ehernet
[16:37:38] <SWPadnos> you would need external hardware to do that. you can put the ethernet MAC into the FPGA, but the PHY and magnetics have to be hardware
[16:38:14] <issy> yes , this is siple to be done
[16:38:41] <issy> simple , sorry
[16:39:17] <SWPadnos> sort of. remember that the FPGA connects to the outside world over a ribbon cable. unless you make a daughteboard that plugs directly into one of the connectors, and you are careful with the termination resistors (you'd probably have to remove them), signal integrity will be a problem
[16:39:58] <issy> you can buy pc104+ cpu and mesa 7I65 (pc104) and you have 8 axis machine , little bigger than cigarette box
[16:41:16] <issy> you can put it on your machine and with single ethernet cable to connect it to the remote station
[16:41:48] <SWPadnos> yep
[16:42:02] <SWPadnos> it's expensive, but you can do it :)
[16:42:23] <issy> this is important for me , because I am manufacturer and the remote administratin wll be easy for me
[16:42:28] <SWPadnos> PC104 processor cards are very expensive compared to normal PCs
[16:42:36] <issy> not realy expencive.
[16:43:21] <issy> I have machines all over the world ,can you imagine haw much we have to pay for fixing software with no remote administration?
[16:43:26] <SWPadnos> considering that I can buy a complete motherboard+CPU+512M memory system for $80 (minus a $20 rebate for now), PC/104 is definitely "relatively" expensive
[16:43:37] <issy> the mine are 163 USD
[16:44:07] <SWPadnos> ok, that's not bad
[16:44:10] <issy> if you are doing for inhouse , it is ok.
[16:44:10] <SWPadnos> what CPU?
[16:44:20] <issy> geode 500 Mhz
[16:44:23] <SWPadnos> ah
[16:44:40] <issy> for industrial application must be fanless
[16:44:46] <SWPadnos> yep
[16:45:15] <issy> look for board 6100 at www.aewin.co.tw
[16:45:22] <SWPadnos> the Geode is a pretty slow CPU, that may be contributing to the latencies you're seeing
[16:45:43] <issy> sorry www.aewin.com.tw
[16:45:52] <SWPadnos> I guess those routing problems aren't quite completely fixed :)
[16:46:18] <issy> no idea , but I will test them
[16:46:54] <issy> The problem will be to find or to write the open source X-server for windows
[16:47:11] <SWPadnos> so you don't like Cygwin/X ?
[16:47:49] <issy> no a bunch of dll's
[16:47:59] <SWPadnos> ?
[16:48:45] <issy> lot of dll's with target to do something that is the base of the linux
[16:49:02] <issy> need to be open sources.
[16:49:17] <issy> and not bigger than 1 mega
[16:49:30] <SWPadnos> cygwin/X is open source, except that it allows linking with proprietary executables
[16:49:38] <SWPadnos> http://x.cygwin.com/
[16:49:46] <SWPadnos> they're looking fora maintainer too :)
[16:50:25] <issy> the dll\s are not open source.
[16:50:51] <SWPadnos> which dlls?
[16:52:02] <issy> tonight I have to finish the reference points of my gui , and during the wikend will work on mine idea to see haw will be with the geode and the remote
[18:40:07] <alex_joni> guess jepler's routing isn't fixed afterall
[18:41:08] <cradek> there's a lot of network trouble in lincoln this morning. it's getting better though.
[18:41:36] <alex_joni> rain?
[18:41:45] <cradek> yes
[18:48:00] <SWPadnos> similar things going on here, or between here and everywhere else
[18:48:08] <SWPadnos> but not a lot of rain to "explain" it
[18:52:28] <micges> cradek: can you tell me you ideas about run from line ? I read that you have thouths to fix it once for all
[18:58:20] <cradek> yes
[18:59:26] <cradek> I think it should do exactly what it's asked: start executing at the selected line. Any modes that are required for that to make sense (spindle, G90, tool loaded, G43, coolant) would need to be set by the operator in MDI or manual mode before running.
[19:03:20] <cradek> I think this is the only way that the operator can always get the behavior he wants.
[19:04:41] <cradek> you could write "safe start" spots in the gcode program. a "safe start" would be a place where all modal commands are set. at every tool change would be a good place for this. then starting there is very easy.
[19:10:52] <alex_joni> I still don't understand what happens if you select run from line inside a function :)
[19:11:06] <SWPadnos> neither does EMC
[19:11:09] <jepler> alex_joni: hopefully, all hell breaks loose
[19:11:18] <jepler> that's certainly what cradek is asking for
[19:11:19] <cradek> it would execute starting where you say, and then give an error when it gets to the O-endsub
[19:12:02] <cradek> obviously you would not want to do that.
[19:12:07] <SWPadnos> I can see one good use of pause/start-from-line though: to change the number of iterations of a loop
[19:12:22] <SWPadnos> or to change some endpoint for a while condition
[19:12:42] <SWPadnos> dunno how to code it though :)
[19:12:59] <cradek> I think the reality is that looping/while/sub code is fairly incompatible with restarting in the middle of the program
[19:13:30] <SWPadnos> I haven't fully convinced myself that it has to be that way, but I think you're right for the foreseeable future
[19:13:46] <cradek> also, I don't care about that, and doing what the user says is the best design that can be actually implemented (in contrast to doing what the user wants)
[19:14:00] <SWPadnos> yes, it's much easier to parse what people say
[19:15:12] <alex_joni> the current run from line, basicly starts interpreting the file from the beginning
[19:15:19] <alex_joni> and compares the current line with the preset line
[19:15:22] <cradek> yes
[19:15:41] <alex_joni> so you want to ditch that, and just start from the preset line?
[19:15:46] <cradek> yes
[19:15:57] <alex_joni> sounds good :D
[19:16:08] <jepler> it seems like the current code will work nearly as well as cradek's idea when you write "restart blocks" into your gcode
[19:16:09] <alex_joni> but I think AXIS will need to truncate the preview too
[19:16:31] <jepler> one thing I commonly have in gcode files is some settings at the top using parameters; I think that these settings would be lost under cradek's scheme, but are retained under the current scheme
[19:16:34] <cradek> jepler: yes it does.
[19:16:38] <alex_joni> jepler: with the current code you have the advantage of setting interp internal things .. like G21, etc
[19:16:51] <alex_joni> exactly, otoh one can set those in MDI
[19:16:54] <cradek> jepler: you could step through them, and then run-from-line where you want.
[19:17:15] <cradek> or, set them in mdi
[19:17:17] <jepler> I am not sure if that's true or not. These are settings in named parameters or numbered parameters that aren't written to the var file that I'm talking about ..
[19:17:59] <alex_joni> jepler: maybe cradek is saying that his run from line can work after stepping a couple of times
[19:18:06] <alex_joni> without stopping the program :)
[19:18:31] <cradek> I could be wrong about how parameter saving works
[19:19:03] <jepler> me either
[19:19:24] <jepler> it might be nice to have a wiki article or doc section about writing gcode *today* that is usable with *today's* run from line
[19:20:16] <cradek> safe start spots currently work fine. I write them at tool changes.
[19:21:07] <jepler> would you be willing to write it up? either for the wiki or for me to add to the docs?
[19:22:09] <cradek> I hesitate to document behavior we are going to ditch
[19:22:11] <SWPadnos> a utility that scans a file up to a point and prints a G-code line to set modal codes to the state they'd be in had the program been run would be useful
[19:22:21] <SWPadnos> I wonder if SAI could be coerced into doing that
[19:22:49] <SWPadnos> get the codes, stick that in MDI, remove what you don't want, then restart
[19:22:54] <SWPadnos> from line
[19:24:33] <cradek> bbl, I forgot to eat today
[19:24:46] <SWPadnos> oh. me too
[19:24:58] <alex_joni> hmm.. not me
[19:29:55] <micges> cradek: those ideas are cool
[19:30:53] <micges> this is actually the same steps to restart that I've programmed into axis
[19:30:59] <micges> 1. set params in MDI mode
[19:31:37] <micges> 2. goto safe start point (begining of selected line)
[19:31:46] <micges> 3. run program
[20:40:54] <Lerman> cradek: SWPadnos: Are you still here?
[21:21:29] <SWPadnos> Lerman, I'm back now