Back
[00:00:15] <jmkasunich> I doubt it was in DNS
[00:00:22] <jmkasunich> considering that I'm on a dynamic IP
[00:00:45] <jmkasunich> or was that just a redirect to my dyndns.org address?
[00:00:51] <SWPadnos> lemme check that. you're probably right
[00:02:17] <SWPadnos> ok - only cvs is in there
[00:05:44] <jmkasunich> yay, all the compile farm slots are current now
[00:20:49] <SWPadnos> I wonder what the assembly house is doing with my boards (and parts)
[00:41:07] <fenn> assembling them, i'd bet
[00:44:56] <SWPadnos> I sure hope so
[00:58:08] <jepler> whee, I have "test this axis" working in stpconf
[00:58:10] <jepler> stepconf
[00:58:22] <SWPadnos> nice!
[00:58:25] <jepler> it looks about like the screenshot I showed earlier
[00:58:50] <jepler> you can dynamically adjust each of the items shown and just wait for a stall
[00:59:00] <jepler> click "OK" and the accel and vel are copied back to the wizard page
[01:01:11] <jepler> when you clck "Run" it jogs back and forth in +- Test Area from the current position, with trapezoidal velocity profile
[01:02:20] <jmkasunich> jepler: I wonder if it ought to warn "the test area you are using is not long enough to allow the axis to reach full speed, the results may not be valid"
[01:03:03] <jepler> jmkasunich: yeah quite possibly
[01:06:05] <jmkasunich> d = v^2 / a = minimum distance to reach top speed
[01:06:17] <jmkasunich> (and go back down to zero)
[01:29:28] <jepler> aaaaaand now a stepconf config has run zenbot
[01:29:37] <jmkasunich> cool
[01:31:01] <jepler> http://git.unpy.net/view?p=stepconf.git;a=snapshot;h=9144eb5bf925877cdfab31fcd0ba7a98017e585b;sf=tgz <-- tar.gz snapshot of stepconf
[01:31:08] <jepler> if anybody tries it, give me a holler
[01:31:18] <jepler> even if you just want to give me crap about how the GUI looks or works
[01:42:43] <SWPadnos> hmm. I wonder if I shold whip up a quickie HAL driver that uses the 5i22 IO port config from Pete
[01:50:43] <SWPadnos> nah. it's kind of expensive for a 96-IO card
[01:51:07] <jepler> OK, it's missing one part -- in the test procedure I described in the early stepconf manual I talk about using Touch Off to set the axis zero, and returning to it when the test is done to find a stall that was too small to be heard. but there's no provision for that in the "test this axis" window...
[02:06:28] <jepler> what's nice about git's separation of commit and push is that when there is a conflict, the files you wanted to check in are already safely stored in the history
[02:06:52] <jepler> so you don't risk losing actual work while you're trying to resolve the conflict
[02:07:39] <jepler> you can also do your own work in logically separate steps (and thus several commits) and only 'push' when you're all done. others see the entire push atomically, so there is no risk of updating to an intermediate version
[02:33:45] <jepler> there are about 90 things you have to enter in stepconf...
[02:34:12] <jepler> what are the odds anybody can actually get all those right?
[02:34:24] <jmkasunich> wow
[02:34:41] <jmkasunich> that's hard to believe
[02:35:07] <jmkasunich> I guess if its N items per axis * M axes....
[02:35:19] <jepler> and I was trying to make the number as high as possible
[02:35:27] <SWPadnos> as long as they're simple questions ...
[02:35:50] <jepler> for instance I count each parport pin as two items, because there's the function and then there is the invert...
[02:43:46] <skunkworks> odd - me and lerman posted the almost exact same answers to 2 different threads.
[02:43:51] <skunkworks> Cool
[02:45:54] <jepler> hi skunkworks
[02:46:22] <skunkworks> Hi jepler
[02:48:58] <SWPadnos> at least it wasn't almost exactly opposite answers to the same thread
[02:50:46] <skunkworks> heh
[02:50:52] <jepler> ah, another blog entry finished just before bedtime.
http://axis.unpy.net/01189478247
[02:51:11] <skunkworks> jepler: I was just reading that :)
[02:51:18] <SWPadnos> luvvv-ly
[02:51:32] <jepler> skunkworks: oh really? you are *fast*
[02:51:45] <SWPadnos> jepler, "opportinity"
[02:52:18] <jepler> SWPadnos: thanks
[02:52:20] <jepler> also fixed the link "doublestep"
[02:52:21] <SWPadnos> np
[02:53:09] <skunkworks> when you said hi - I thought I would check your blogs :0
[02:53:13] <jepler> 'night
[02:53:20] <skunkworks> night
[02:53:22] <SWPadnos> good night. cool stuff with stepconf
[02:53:35] <jepler> skunkworks: if you haven't crated up hermes yet, maybe you can be a guinea pig for me
[02:53:42] <jepler> .. another day
[02:53:47] <skunkworks> tomorrow
[02:53:51] <skunkworks> I can do that.
[03:07:25] <skunkworks> bed time for me also - night
[12:47:03] <jepler> motif. we forgot to depend on motif.
[12:47:13] <jepler> and I know cradek will write an OpenLook GUI some day
[12:47:43] <SWPadnos> GnuStep
[12:47:51] <SWPadnos> I really want some objective-C stuff in there
[12:48:05] <SWPadnos> and we shouldn't leave out mono and C#
[12:50:32] <jepler> seriously, patches to make all X-using parts of emc optional at ./configure time? happily considered. Patches to build a separate emc2-nox .deb package? happily considered.
[12:51:33] <SWPadnos> yep. I think we have two opposing directions to go with EMC. one is more user-friendly, with stepconf-like wizards for things
[12:51:42] <SWPadnos> the other is toward embedded headless machines
[12:51:54] <SWPadnos> and I think both are important
[12:51:59] <fenn> i dont see a problem with emc-common and emc-gui
[12:52:53] <fenn> SWPadnos: dont forget sim mode
[12:52:55] <SWPadnos> yeah - make emc2 a metapackage that just depends on all the base parts and the GUI stuff
[12:53:04] <SWPadnos> sure
[12:53:49] <jepler> that's probably a fine arrangement too
[13:08:52] <jepler> skunkworks: there's a hal driver for that card, but it hasn't been added to emc2
[13:11:51] <skunkworks> jepler:
http://www.cnczone.com/forums/showthread.php?p=341435#post341435
[13:11:58] <skunkworks> don't know if that is what he is wanting.
[13:12:32] <SWPadnos> skunkworks, interestingly, you can use a mesa card and get much faster software stepping as well
[13:13:32] <SWPadnos> just set up the mesa FPGA as a 72 I/O unit, and if you really want to be clever, make the first 24 bits output and the rest input (or whatever)
[13:13:51] <skunkworks> SWPadnos: was not sure about that.. cool
[13:13:54] <SWPadnos> then the update to all output pins is one PCI write (which I'm not sure the CPU has to wait for
[13:13:55] <SWPadnos> )
[13:14:16] <SWPadnos> yeah - I made a program that writes to a PCI region so I could test out the 5i22
[13:15:05] <SWPadnos> a shell script like `for i in `seq 1 2048` ; do pci_write 0 2 2 8 %i ; done` takes maybe a second to run
[13:15:35] <SWPadnos> that pci_write just writes one 32-bit word to PCI space - and it takes a long time to do it :)
[13:29:08] <alex_joni> morning all
[13:29:18] <SWPadnos> hi Alex
[13:32:46] <alex_joni> what's up?
[13:33:40] <SWPadnos> not too much
[13:34:24] <skunkworks> rs274 standard issues.. emc2 is aparantly wrong.
[13:34:34] <alex_joni> huh?
[13:34:36] <skunkworks> ;)
[13:34:39] <SWPadnos> it depends on which RS274 now, doesn't it? :)
[13:34:49] <skunkworks> you would have to read back on the #emc channel
[13:34:50] <alex_joni> certainly not rs274ngc :P
[13:34:50] <fenn> round and round and round she goes
[13:34:53] <SWPadnos> it's that D != NGC thing
[13:34:54] <alex_joni> skunkworks: I would..
[13:35:06] <fenn> box != line
[13:35:23] <SWPadnos> = != ==
[13:36:31] <SWPadnos> != != ==, != == !=
[13:36:41] <SWPadnos> that could be morse code or C
[13:37:12] <alex_joni> now you're just beeing silly :P
[13:37:17] <SWPadnos> of course
[13:37:18] <alex_joni> * alex_joni goes back to his bot
[13:37:38] <alex_joni> almost finished installing another one
[13:37:50] <skunkworks> Cool
[13:37:51] <SWPadnos> nice
[13:37:58] <skunkworks> welding bot?
[13:38:00] <SWPadnos> I guess I shuold get back to modbus drivers
[13:38:09] <alex_joni> skunkworks: yeah
[13:38:16] <alex_joni> only 6 axes though
[13:38:19] <SWPadnos> wimpy
[13:38:24] <SWPadnos> :)
[13:38:25] <skunkworks> 'only'
[13:40:14] <alex_joni> well.. the control can drive up to 18 axes
[13:40:21] <alex_joni> and 6 is the minimum
[13:40:46] <SWPadnos> what kind of control?
[13:48:14] <alex_joni> SWPadnos: it's called rotrol II
[13:48:25] <SWPadnos> ok. never heard of oit :)
[13:48:27] <alex_joni> the language is similar to pascal
[13:48:28] <SWPadnos> it
[13:48:31] <SWPadnos> bummer
[13:48:42] <SWPadnos> have you ever use Delta Tau controllers?
[13:48:44] <alex_joni> not really, it's quite nice
[13:49:14] <SWPadnos> and remember - FreePascal is the only Free compiler that targets 64-bit Windows :)
[13:49:15] <alex_joni> it's not very different from g-code, but you have variables & such
[13:49:22] <alex_joni> functions, procedures, etc
[13:49:33] <alex_joni> this is running on iRMX
[13:49:37] <alex_joni> some RT OS
[13:49:50] <SWPadnos> ok - similar to (but hopefully better than) the Yaskawa controller I have here (with software made by Galil)
[13:49:52] <alex_joni> the interface is xp embedded
[13:50:07] <SWPadnos> ewww
[13:50:17] <alex_joni> well.. touch screen & colourfull buttons
[13:50:21] <SWPadnos> though for the UI, it's not necessarily abominable
[13:50:24] <SWPadnos> right
[13:50:39] <alex_joni> although in this case there's no real advantage for it
[13:50:54] <alex_joni> nothing that could remind people of windows
[13:50:59] <SWPadnos> heh
[13:51:09] <alex_joni> so it could just have been some linux
[13:51:16] <alex_joni> too bad they didn't ask me :))
[13:51:46] <rayh> not looking like MS-Windows might be thought of as a real advantage.
[13:52:01] <SWPadnos> in som circles, surely
[13:52:04] <SWPadnos> some
[13:52:16] <alex_joni> rayh: they do advertise windows on their flyers
[13:52:27] <alex_joni> but it's really a custom interface
[13:52:32] <alex_joni> so the OS is irrelevant
[13:52:39] <jepler> 28 minutes wall time to 'git clone' emc2 over my slow dsl line
[13:52:53] <SWPadnos> ok. that's not too bad
[13:53:03] <SWPadnos> as long as we're not all doing it at the same time
[13:53:09] <alex_joni> only once ;)
[13:53:24] <jepler> 15 seconds to 'git pull' with no new revisions
[13:53:47] <alex_joni> cvs up is a BIT FASTER ISN'T IT?
[13:53:51] <alex_joni> argh.. sorry
[13:53:57] <SWPadnos> SOMETIMES!
[13:54:23] <jepler> 8 seconds
[13:55:55] <SWPadnos> 12.297 seconds here
[13:57:42] <jepler> git over http is a bit slower than git: or git+ssh: "native" protocols. git+ssh pull over the network is 2.5s
[13:58:09] <cradek> alex_joni: don't send html to the lists please!
[14:01:33] <jepler> the longest step of an http pull is that it re-fetches information about a bunch of unused CVS tags, one http request at a time. By removing the undesired tags from the file .git/remotes/origin, 'git pull' over http and the network takes 1.3s
[14:04:52] <alex_joni> cradek: sorry, forgot to check
[14:05:09] <cradek> hi alex :-)
[14:05:12] <alex_joni> hi
[14:52:18] <SWPadnos> heh - so skunkworks, do you see a spike of traffic after the CCED engraver announcement?
[14:53:19] <skunkworks> heh - have not looked. :)
[14:57:40] <SWPadnos> oooh - he's got two underscores now :)
[15:17:58] <SWPadnos> man. just unzipping the Xilinx webpack takes forever
[15:43:34] <skunkworks> I think most of the time I have posted to the cadcammumble list - I was selling something. is that wrong?
[15:48:50] <SWPadnos> yes
[15:48:54] <SWPadnos> but don't stop on my account :)
[15:48:59] <skunkworks> heh
[15:53:44] <SWPadnos> oh now thats funny. I decided to uninstall a few things, and just started to kill off LabView 6
[15:54:15] <SWPadnos> so a dialog pops up: "The installer is completing the uninstall. Please do not reboot while this dialog is being displayed"
[15:54:28] <SWPadnos> "currently uninstalling feature 1 of 7."
[15:54:49] <SWPadnos> no options, not description of what the 7 "features" are - nothing else
[15:55:11] <skunkworks> sounds like microsoft. or is it?
[15:55:29] <SWPadnos> it's National Instruments software on Microsoft Windows (tm)
[15:55:40] <skunkworks> well - that explains it ;)
[15:55:46] <SWPadnos> twice
[16:03:36] <SWPadnos> well, I probably need to reboot a couple of times. bbl
[16:04:13] <cradek> that would be so annoying
[16:38:41] <alex_joni> heh
[16:39:02] <alex_joni> cradek: stop laughing at other peoples deficient OSes :P
[16:51:34] <alex_joni> interesting mail from mariss, he's finally running a stepper as a servo
[16:55:06] <alex_joni> http://f1.grp.yahoofs.com/v1/gLvmRvVOpkg0j6xy08axtpqw_xn9quB4LOo519Wx4ls63eKuyFpp_4tKqv8DuCLc1ksGllx5MLaaYyw_XsGbrNy4tgIkUZw/Stepper%20Servo/test%20setup.jpg
[17:25:21] <skunkworks> alex_joni: that is neat.
[17:31:16] <skunkworks> I think though he is skewing the info into his favor.
[19:02:20] <rayh> Nah. Mariss wouldn't do that. He's a professional engineer.
[19:02:46] <skunkworks> heh
[19:03:10] <rayh> Oh you heard that back story, 'eh.
[19:04:15] <skunkworks> I seem to remember a pow-wow with roland and such ;)
[19:06:59] <jepler> alex_joni: url doesn't work for me
[19:07:09] <jepler> Document Not Found
[19:07:45] <skunkworks> jepler: you might have to be a member of the gecko drive list (if that is what your talking about)
[19:10:49] <jepler> skunkworks: ah .. oh well
[19:11:38] <rayh> Hey how come each time I post to the user list I get this, "Sorry. Your message could not be delivered to:
[19:11:40] <rayh> brian barker,University of Maine (The name was not found at the remote site. Check that the name has been entered correctly.)"
[19:12:24] <SWPadnos> rayh, does that happen for any message, or only replies to certain threads?
[19:12:31] <rayh> Does brian need to fix up his addy at sf?
[19:12:50] <rayh> I get a copy every time I post to him.
[19:13:14] <SWPadnos> I've seen that on various lists, not just SF. I'm not sure what causes it
[19:13:49] <SWPadnos> it could be that there are multiple reply-to lines, and your mail is getting sent to both the list and his address
[19:16:15] <rayh> Got it just now with my reply to watchman1 and I don't see anything there.
[19:16:42] <SWPadnos> it does show that it's to him and the list
[19:18:21] <SWPadnos> looking in my email client, this is the To line:
[19:18:24] <SWPadnos> To: watchman1@fastmail.fm,
[19:18:24] <SWPadnos> "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
[19:18:43] <rayh> Sure but why would that also raise an error at the University of Maine.
[19:18:51] <SWPadnos> I have no idea :)
[19:19:15] <rayh> me either.
[19:23:33] <jepler> rayh: In the case of an error, a proper SMTP server will send a message to the mailing list administrator. It sounds like University of Maine has a bad SMTP server if you are the one who gets the error when the mailing list tries to deliver a message to this "brian barker"
[19:25:32] <cradek> it used to be that universities were the ones you could trust to be clueful about how the net works
[19:25:55] <jepler> it might be worth asking someone who can remove subscribers to try to remove brian barker's subscription or set him to nodeliver
[19:27:38] <rayh> i think you guys are admins as sf
[19:28:11] <rayh> at sorry
[19:44:40] <tomp2> ray: same here, i even emailed him with the error... bounced !
[19:45:27] <tomp2> (gotta go m$ to talk to some machines... bbl)
[19:54:05] <jepler> rayh: I've disabled delivery for brian barker, so you shouldn't see any more of those messages
[19:54:10] <jepler> until he reenables delivery without fixing the problem, anyway
[20:18:18] <SWPadnos> hmmm. I've just compiled an SMP RT kernel plus RTAI, and I think I've done the right thing for recompiling EMC, but for some reason the latency test tries to load some modules from the old 2.6.15-magma dir instead of the new 2.6.20-magma-2 dir
[20:18:47] <SWPadnos> I did make clean, configure --with-the-right-dirs, make, sudo make setuid
[20:19:13] <cradek> configure --with-rtai=/usr/your-rtai?
[20:19:35] <SWPLinux> I may have used --with-realtime=
[20:19:46] <cradek> ok maybe that's it, I dunno
[20:20:18] <cradek> um, you must have done something wrong [duh]
[20:20:20] <SWPLinux> yep - --with-realtime
[20:20:24] <SWPLinux> oh, thanks
[20:20:46] <cradek> what does it try to load?
[20:20:49] <SWPLinux> steve@steve-xpc:/Project/emc2/src$ ./configure --with-realtime=/usr/realtime-2.6.20.14-magma-2/ --with-kernel-headers=/usr/src/linux-source-2.6.20.14-magma-2/ --enable-run-in-place
[20:20:56] <SWPLinux> that's what I did
[20:21:17] <alex_joni> SWPLinux: can you paste the error msg?
[20:21:29] <SWPLinux> steve@steve-xpc:/Project/emc2/src$ ../scripts/latency-test insmod: can't read '/usr/realtime-2.6.20.14-magma-2/modules/rtai_shm.ko': No such file or directory
[20:21:32] <SWPLinux> insmod: error inserting '/usr/realtime-2.6.15-magma/modules/emc2/threads.ko': -1 Invalid module format
[20:21:33] <SWPLinux> HAL:1: ERROR: systemv failed, returned 1
[20:21:36] <SWPLinux> HAL:1: ERROR: insmod failed, returned -1
[20:21:36] <SWPLinux> and various other modules missing after that
[20:21:50] <alex_joni> I guess you did make clean and make?
[20:21:52] <SWPLinux> yes
[20:21:56] <alex_joni> after the new configure?
[20:22:03] <alex_joni> check src/Makefile.inc
[20:22:07] <alex_joni> and see if the paths are ok
[20:22:12] <SWPLinux> though I've just noticed that it fails to find the module in the first dir
[20:22:22] <SWPLinux> the first being the correct dir
[20:22:43] <alex_joni> sounds like rtai isn't installed properly?
[20:22:55] <SWPLinux> it does sound that way, doesn't it
[20:22:56] <cradek> run from emc2/, not emc2/src/
[20:23:00] <cradek> scripts/latency-test
[20:23:14] <SWPLinux> same problem
[20:23:20] <cradek> did you try scripts/emc-environment?
[20:23:27] <SWPLinux> but it's right - there is no rtai_shm in the correct module dir
[20:23:37] <cradek> oh, hmm
[20:23:57] <jepler> looks like latency-test assumes that emc-environment has been .'d
[20:24:12] <SWPLinux> I used jeplers configure-realtime script to configure RTAI
[20:24:25] <jepler> if you're getting some other version of halcmd that would explain why the second insmod error refers to /usr/realtime..../threads.ko
[20:24:32] <SWPLinux> ok, that makes sense
[20:24:55] <jepler> but that doesn't clear up the first problem (missing rtai_shm)
[20:24:56] <SWPLinux> hmm. that did it
[20:26:08] <SWPLinux> weird. there isn't an rtai_shm.ko file, but the latency test runs fine
[20:26:41] <SWPLinux> I think I can definitively say that isolcpus is the thing that makes this machine perform well
[20:27:02] <jepler> that's sure the obvious thing to try if you aren't also itching to run 'make -j' fast
[20:27:23] <SWPLinux> ?
[20:28:03] <SWPLinux> it is pretty quick to compile EMC - about 1:10 after a make clean
[20:28:18] <jepler> all I'm saying is that isolcpus means you can't run normal linux tasks on that CPU -- such as "make -j2"
[20:28:38] <SWPLinux> right
[20:28:39] <SWPLinux> ok
[20:30:42] <cradek> aha! jepler publicly admits to knowing about coordinate systems!
[20:31:24] <jepler> ack
[20:31:29] <jepler> I thought I posted that as "anomymous"
[20:31:59] <cradek> haha
[20:32:15] <alex_joni> :-)
[20:32:17] <jepler> cradek: more importantly did I botch any important factual details?
[20:32:26] <cradek> I don't know - too many words to read
[20:32:40] <jepler> yeah that's kinda what I was going for
[20:33:30] <cradek> argh I want emc on my mill
[20:33:38] <jepler> cradek: I'll come over tonight and we can get started
[20:33:39] <SWPLinux> ok, time to check isolcpus. bbiab
[20:33:41] <jepler> you have all the parts right?
[20:33:46] <cradek> nope
[20:33:48] <jepler> oh .. darn
[20:34:34] <skunkworks> you have the pluto...
[20:34:37] <skunkworks> :)
[20:35:04] <skunkworks> what more do you need?
[20:35:39] <cradek> you typoed G93
[20:36:12] <cradek> otherwise it looks great
[20:36:27] <cradek> I might have mentioned that G92 moves all the G5x systems
[20:36:31] <skunkworks> I think that should be on the wiki
[20:36:51] <cradek> I agree
[20:37:11] <jepler> I tried to cover that, but maybe not in the most obvious way
[20:37:13] <jepler> All three of these (G5x coordinate system (one is always in effect), G92
[20:37:13] <jepler> coordinate offset (unless disabled by G92.1 or G92.2), and G43 tool
[20:37:13] <jepler> offset (when enabled)) are combined to get the coordinate value
[20:37:15] <jepler> shown on the AXIS DRO </>
[20:38:29] <cradek> if you wikify it, we could add my post from a while ago (the demo using systems.ngc)
[20:38:53] <cradek> maybe we should make a youtube training video (nngrnnghhh)
[20:39:07] <skunkworks> offsets and you
[20:39:26] <jepler> hahaha cradek
[20:39:26] <cradek> "coordinate systems aren't scary if you'd just pay attention"
[20:39:41] <cradek> "oh for gods sake, now listen"
[20:39:54] <cradek> * cradek <- not a very good trainer
[20:49:17] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CoordinateSystems
[20:50:01] <skunkworks> holy crap - that was quick - and it looks nice. great job (you type way too fast)
[20:50:51] <jepler> that was a cut and paste job (I *do* know how to use cut and paste) plus a bit of time to do markup
[20:51:14] <alex_joni> the link to the gcode manual is not 100% right
[20:51:22] <alex_joni> mind if I try to fix it?
[20:51:31] <jepler> no sorry, I already did
[20:51:49] <jepler> but thanks
[20:52:07] <alex_joni> ah, coo
[20:53:50] <jepler> but fix any other typos or bad markup you find
[20:54:31] <alex_joni> I'm close to falling asleep, hardly I'll find typos you didn't see yourself
[21:02:53] <alex_joni> http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all
[21:07:53] <rayh> Hey jepler just read your fascinating post.
[21:08:30] <alex_joni> good night all
[21:08:30] <rayh> Do you know for certain that the result of g92.1 gets written to var.
[21:08:51] <rayh> Night alex
[21:09:06] <cradek> To reset axis offsets to zero, program G92.1 or G92.2. G92.1 sets parameters 5211 to 5216 to zero, whereas G92.2 leaves their current values alone.
[21:09:17] <cradek> http://linuxcnc.org/docs/html/gcode/main/#sub:G92_-G92.1_-G92.2_
[21:10:45] <rayh> I'm aware of that stuff but found a while back that setting global variables to zero did not do the same for the values in var until shutdown.
[21:11:20] <cradek> the var file is not necessarily written immediately
[21:11:37] <rayh> If an abort or estop got in the way the resulting var file could be in error.
[21:12:30] <rayh> That's why I suggested a direct read edit of that file.
[21:12:32] <cradek> the var file's only job is to preserve the state of the internal variables across runs of emc - the exact time it's written out is not important as long as it's written on exit
[21:13:03] <rayh> Nice in theory.
[21:14:32] <cradek> bbl
[22:49:06] <jepler> cradek: fwiw axis also reads (copies) the var file and does a trick to try to make it be up to date...
