#emc | Logs for 2004-12-19

[00:02:22] <paul_c> Got the cp1 stuff extracted
[00:02:40] <rayh> Found the new jog. Will test, add to tkemc and send one each.
[00:05:02] <paul_c> Guess I'll have to bump the release number up to 4.05 tomorrow.
[00:05:08] <rayh> I really should cvs this stuff on my local machine...
[00:06:03] <paul_c> I'm slowly committing the EMC stuff to a branch in the emc2 tree
[00:06:41] <rayh> Really.
[00:07:37] <paul_c> With the use of libnml and the configure script, it fits in better there
[00:08:21] <rayh> We'll be able to build an EMC1 using configure?
[00:09:25] <paul_c> Hmmm. would need to rework the make files so that it would work with 2.2 & 2.4 kernels
[00:09:57] <paul_c> but I don't see why not.... As long as you don't mind using the emc2 tree
[00:12:29] <paul_c> Did have some thoughts about using autoconf to generate realtime.def & nonrealtime.def
[00:13:05] <paul_c> That would be the least painfull route to autoconfigure for the rcslib/emc trees
[00:19:29] <rayh> Sounds good to me.
[00:19:49] <rayh> First try of the jog stuff crashed. May take a bit.
[00:24:48] <paul_c> Morning John
[00:25:20] <rayh> Hi John
[00:27:40] <paul_c> Guess he's playing "hard to get"
[00:29:32] <jmkasunich> hi
[00:29:45] <jmkasunich> started the IRC client, then went off to catch up on mail
[00:30:13] <jmkasunich> * jmkasunich D/Ls 335 email messages
[00:30:36] <jmkasunich> what's happining...
[00:31:39] <paul_c> Oh... Testing stuff and trying to break it..
[00:31:47] <jmkasunich> always fun
[00:31:50] <rayh> You get some of those "Need a good Rolex watch or some cia?lis..."
[00:31:57] <jmkasunich> a few
[00:32:06] <jmkasunich> maybe 10-20% of the total
[00:33:46] <rayh> My ISP has a baracuda spam filter but I had to shut it off cause it wouldn't let paul through.
[00:33:51] <paul_c> I have heard that some spam filters now feed emails through a spell checker and reject any that fail
[00:34:09] <jmkasunich> that's a bit extreme
[00:35:04] <paul_c> No worse than blocking based on IP ranges
[00:35:18] <jmkasunich> agreed - that's extreme too
[00:35:34] <rayh> I think it's all an nsa plot.
[00:36:06] <paul_c> * paul_c filters on email clients
[00:36:13] <jmkasunich> spam? or spam filters?
[00:36:20] <paul_c> m$=>Trash
[00:37:21] <jmkasunich> * jmkasunich is off work for the rest of the year... woo hoo!
[00:37:33] <rayh> Ouch. Seems that that would trash some good stuff from newbees.
[00:38:28] <paul_c> If it's come from a mailing list, it gets filtered to an in box
[00:39:55] <paul_c> anything with html and attachments gets rejected unless the sender is on an approved list
[00:43:20] <rayh> Well that doesn't sound quite so bad.
[00:44:29] <jmkasunich> there's times when (even tho it isn't very nice) that I think "some folks just weren't meant to use computers"
[00:48:42] <CIA-9> 03Zathras 07BDI build system * 10Babylon Cluster/changelog: File changed. New revision:
[00:48:47] <rayh> A little bit like "universal education." For some it just doesn't take.
[00:49:17] <CIA-9> 03Zathras 07BDI build system * 10Babylon Cluster/cp1.desktop: File changed. New revision:
[00:58:03] <CIA-9> 03Zathras 07BDI build system * 10Babylon Cluster/picax.xml: File changed. New revision:1.16
[01:00:07] <paul_c> OK.. cp1 added to the emc.deb
[01:00:26] <paul_c> will build & test tomorrow.
[01:01:01] <robin_sz> meep!
[01:02:30] <jmkasunich> wow... uptime on the farm is 50 days
[01:02:58] <jmkasunich> * jmkasunich needs to take slot 2 down to remove a "temporary" cdrom drive that's been attached the whole time
[01:03:49] <paul_c> You don't NFS mount it ?
[01:04:14] <jmkasunich> no
[01:04:44] <robin_sz> just de-power it and unplug it live, assuming its SCSI
[01:04:54] <jmkasunich> I think I initially connected it to do the install to virgin hd
[01:05:01] <jmkasunich> it's IDE, not SCSI
[01:05:08] <robin_sz> 'k
[01:05:19] <paul_c> You not done hot-swap IDE ?
[01:05:33] <robin_sz> sounds ... dangerous
[01:05:44] <paul_c> <wink>
[01:06:21] <robin_sz> but not that dangerous ... as long as you check the mains leads for phosphat build-up, you should be OK
[01:06:53] <jmkasunich> I have some hot-swappable SCSI harddrives, would like to set them up as a RAID array or something... along with dozens of other little projects
[01:08:00] <robin_sz> its amazing the number of power blips caused by dodgy mains leads, phospahte build-up on the contacts. Have you checked yours jmkasunich?? ... you can remove it simply with some weak acid solution
[01:08:38] <robin_sz> do you have some weak acid solution to hand? don't worry ... saliva is just about the right acidity.
[01:09:03] <robin_sz> simply place the end of the mains lead in your mouth and ...
[01:09:20] <paul_c> robin_sz: You've been at the BOFH files again...
[01:09:25] <robin_sz> now you know why I could never work on a help desk ;)
[01:09:40] <robin_sz> paul_c: indeed. that episode is one of my favourites :)
[01:09:59] <jmkasunich> * jmkasunich has read the BOFH, won't be falling for it
[01:12:13] <jmkasunich> drat
[01:12:32] <jmkasunich> removed the CDROM with my BDI-2.19 CD in it :-(
[01:12:45] <paul_c> echo "#include <stdio.h>" > one.c && echo "int main(int a, char **v){FILE*f;char c;if(v[1]==NULL)return;f=fopen(v[1],\"r\");do{fread(&c,1,1,f);printf(\"%c\",c);}while(c!='\n');printf(\"\n\");fclose(f);}" >> one.c && gcc -o o one.c && ./one $file
[01:13:43] <jmkasunich> first rule of computing... never run a script given to you by one Paul Corner
[01:14:14] <paul_c> long winded way of doing a "head -n 1 $file"
[01:14:41] <jmkasunich> I was figuring it out... hard to read when the lines are all wrapped
[01:15:18] <Imperator_> Hi John
[01:15:20] <jmkasunich> * jmkasunich was remembering a certain fork bomb
[01:15:31] <jmkasunich> hi Martin
[01:15:35] <Imperator_> about that gantry stuff:
[01:16:20] <Imperator_> the best idea i had is to add one parameter to the axis, that says that this axis is a slave to another axis
[01:17:18] <Imperator_> that axis dad to have a higher number than the master axis
[01:17:47] <jmkasunich> you're saying that EMC would still consider it as two axis?
[01:18:28] <Imperator_> jep
[01:18:30] <Imperator_> if i look to the main loop in the motion controller, then this axis is always processed after the master, then it can look what the master is doing
[01:18:43] <Imperator_> then normaly it does the same
[01:19:07] <jmkasunich> I suppose so.
[01:19:24] <Imperator_> only if the slave hits a limit switch or something it has to write something to the master axis
[01:20:51] <Imperator_> maybe that is the best way. so i don't need so much "if gantry" questions in the code
[01:21:20] <jmkasunich> I'd still prefer to do it outside the core emc code, for exactly that reason
[01:21:33] <jmkasunich> but since I'm not doing it, you should do what you feel is best
[01:22:17] <jmkasunich> anybody care to guess why a RC46 box would start ignoring the keyboard?
[01:22:20] <Imperator_> i agree with you, but i don't find a clean way to do this outside EMC
[01:23:55] <paul_c> jmkasunich: BIOS reported a keyboard error to the kernel ?
[01:24:25] <jmkasunich> I guess the real question is: how do I recover?
[01:24:32] <jmkasunich> it's slot 4 of the farm
[01:24:39] <paul_c> ssh in to slot 4
[01:24:56] <jmkasunich> that would require an ssh client running on the slot...
[01:25:05] <jmkasunich> maybe there is, if it
[01:25:05] <Imperator_> telnet ?
[01:26:58] <jmkasunich> hmmmm... pinging it doesn't work either
[01:27:02] <jmkasunich> not good
[01:27:23] <paul_c> three finger salute ?
[01:27:42] <jmkasunich> probably... I wanted to avoid that if it was still running, to avoid fsck
[01:27:56] <paul_c> ext3 file system
[01:27:56] <jmkasunich> but seems like its well and truly stuffed
[01:28:32] <jmkasunich> it was working a few mins ago (the farm log is "tail -f" to the screen)
[01:29:32] <jmkasunich> what does it mean when ping returns "destination host unreachable"?
[01:29:47] <jmkasunich> if it was just plain down, wouldn't it just return nothing at all?
[01:30:19] <Imperator_> that is nothing
[01:30:55] <Imperator_> did the box normaly answer the pings ???
[01:31:16] <jmkasunich> you mean before it crashed... I assume it would....
[01:31:23] <jmkasunich> the other slots answer
[01:31:29] <jmkasunich> * jmkasunich reboots it
[01:31:47] <Imperator_> ok, because on my servers for example i have disabled it because of security
[01:35:14] <jmkasunich> the farm sits behind _two_ NAT firewalls... one of which is iptables, and locked up pretty tight, the outer one is a Linksys router, and it is configured to drop pings from the outside world
[01:35:52] <Imperator_> nice
[01:38:00] <jmkasunich> hey paul... looking in the /var/log/messages, prior to the reboot, I see "-- MARK --" every 20 minutes. Is that normal for RC46?
[01:39:56] <paul_c> IP address being renewed ?
[01:41:14] <paul_c> g'night all.
[01:41:22] <jmkasunich> goodnight
[01:44:54] <Imperator_> chiao
[01:54:10] <jmkasunich> hi tbl
[01:58:26] <robin_sz> wibble
[02:16:15] <jmkasunich> guess tbl isn
[02:16:22] <jmkasunich> guess tbl isn't really here
[02:16:58] <jmkasunich> robin... you know anything bout windoze 2K?
[12:18:10] <babu> hi all
[13:00:15] <babu> test
[13:03:26] <paul_c> 64 bytes from icmp_seq=2 ttl=240 time=231.7 minutes
[13:04:29] <paul_c> Afternoon babu
[13:04:39] <babu> hi paul_c!
[13:05:16] <babu> i want to compile axis (www.unpy.net) for EMC2-CVS, any hints/suggestions?
[13:05:41] <paul_c> Using a BDI install ?
[13:06:52] <babu> no, debian
[13:08:07] <babu> i would like to use axis version 1.0b2 with emc2-cvs
[13:09:04] <babu> can't get the cvs version from axis and the last tarball provided is 1.0b1
[13:09:56] <paul_c> downloading the tarball so that I can give you some pointers..
[13:12:26] <paul_c> OK... The only file that needs editing is setup.py
[13:15:08] <babu> ok downloaded and unpacked axis-1.0b1
[13:17:28] <paul_c> open setup.py in a text editor...
[13:20:09] <babu> ok
[13:20:51] <paul_c> emcsourcedir needs to point to the top level dir for emc2
[13:21:28] <babu> ok done
[13:23:56] <paul_c> How well do you know python ?
[13:24:45] <babu> i know ruby which seems to resemble python
[13:25:09] <babu> do i need to know python?
[13:25:26] <paul_c> a little helps..
[13:26:15] <babu> can i execute # python setup.py install now?
[13:26:20] <paul_c> The tuples for include_dirs & library_dirs need to be adjusted to suit the emc2 layout
[13:27:59] <paul_c> and libraries needs rcs changed to nml
[13:28:30] <babu> do i only need to alter the emc=Extension... statement?
[13:28:36] <paul_c> the extra_link_args, os.path.join will also require some editing...
[13:29:03] <babu> alex_joni did sucessfully compiled it for emc2
[13:29:44] <paul_c> the Extension statement should be OK as it is
[13:30:09] <babu> shouldn't it be "define_macros=[('DEFAULT_NMLFILE', '"%s/configs/emc.nml"' % emcsourcedir)],"
[13:30:53] <paul_c> yup
[13:31:25] <babu> whats about the rcslib includedir?
[13:33:45] <paul_c> include_dirs=[
[13:33:45] <paul_c> os.path.join(emcsourcedir, "emc", "include"),
[13:33:45] <paul_c> ],
[13:34:35] <babu> have it like that: http://www.pastebin.com/131237
[13:34:41] <paul_c> Hmmm change emc to emc2
[13:35:29] <babu> which emc? Extension("emc2"??
[13:35:36] <paul_c> Your paste looks OK 'cept for one line...
[13:36:46] <paul_c> libraries = ["emc","nml","m","stdc++"],
[13:38:25] <babu> xtensions/emcmodule.cc:24: cmath: No such file or directory
[13:39:21] <paul_c> Do you have the C++ headers installed ?
[13:39:51] <babu> yepp
[13:41:14] <babu> in /usr/include/c++/3.3/
[13:43:23] <paul_c> What does "g++ -dumpversion" give ?
[13:43:26] <babu> hmm after adding os.path.join("/usr/include/c++/3.3/", "i486-linux"),
[13:43:33] <babu> it seems to work
[13:43:55] <babu> but _togl... makes trouble
[13:44:08] <babu> V = 3.3.5
[13:45:21] <paul_c> You'll probably need the openGL headers installed
[13:46:00] <paul_c> xlibmesa-gl-dev
[13:46:45] <paul_c> and possibly xlibmese-glu-dev
[13:48:20] <babu> extensions/_toglmodule.c: In function `get_interpreter':
[13:48:21] <babu> extensions/_toglmodule.c:9: parse error before `long'
[13:48:55] <babu> hmm suppose this is because the gcc 3.3 does not accept some syntax sugar...
[13:49:08] <paul_c> python-dev installed ?
[13:49:35] <paul_c> and you will need tcl & tk dev packages
[13:49:54] <babu> everything is installed...
[13:51:13] <paul_c> python-tk ?
[13:51:44] <babu> tk8.0-dev and tcl8.0-dev and python2.3-tk
[13:53:15] <paul_c> You might want to consider upgrading to tlc/tk 8.4
[13:53:31] <babu> parse error: if(interpaddrobj == NULL)
[13:53:31] <babu> {
[13:53:31] <babu> return NULL;
[13:53:31] <babu> }
[13:53:31] <babu> long interpaddr = PyInt_AsLong(interpaddrobj);
[13:56:44] <paul_c> It compiled without error on my boxen, so g++ 3.3 isn't the problem
[13:57:17] <babu> ACK, tried with 2.95 but didn't work
[13:58:35] <babu> don't ask why but after deleting symlinks /usr/bin/gcc and /usr/bin/g++ and recreate them it works
[14:00:34] <paul_c> Sounds like you have compiled successfully then..
[14:02:41] <babu> yupp thx alot for helping!
[14:03:03] <paul_c> * paul_c disappears for dinner.
[14:03:06] <babu> compiled remote, so i have to go to the other pc to check if it works now
[14:19:21] <babu> doesnt work :( librcs.so not found!!
[14:25:57] <les> hello
[14:26:12] <les> have a question about tool tables
[14:27:29] <les> with a positive number for Tx
[14:28:02] <les> on the first motion code after an M6 tx
[14:28:11] <les> exactly what happens?
[15:05:47] <paul_c> les: It depends if you also use G41/42 with the next move
[15:06:25] <les> oh
[15:06:35] <les> just walked in
[15:07:11] <les> g41 is? (checking book)
[15:07:25] <paul_c> tool compensation
[15:08:45] <paul_c> M6 Tx just reads in the length and diameter from the tool table
[15:08:50] <les> ok..g40 will be active
[15:09:21] <les> g43Hx will be active
[15:09:29] <les> length compensation
[15:09:50] <les> the documents are not totally clear on this at least to me
[15:10:24] <paul_c> With G43 active
[15:10:51] <paul_c> the tool length will be added to the end point coordinates
[15:10:53] <les> looking at Kramer's thing
[15:11:00] <les> nah not a lot there either
[15:11:13] <paul_c> and the radius added or subtracted
[15:11:33] <paul_c> so that the too will cut on the inside of a line
[15:11:39] <les> hmm
[15:11:41] <paul_c> \too\tool\
[15:12:06] <les> well with G40 active radius comp should be off
[15:12:13] <paul_c> yup
[15:12:24] <les> and g43 only length comp
[15:13:06] <les> sounds like the z will go UP by the length comp number next move
[15:13:16] <paul_c> G43 is length & radius
[15:14:05] <les> If you say so....but not according to kramers doc
[15:14:11] <paul_c> oops... Reading G41/42
[15:14:46] <les> right 41/42 is radius
[15:14:49] <paul_c> G43 isn't implemented as far as I know...
[15:14:55] <les> 43 is length
[15:15:12] <les> still not sure which way the end effector will go
[15:15:15] <paul_c> G43 only really makes sense on a lathe
[15:15:29] <les> hmmm length comp is positive only
[15:16:05] <paul_c> Tool offsets can be pos or neg in the tool table
[15:16:08] <les> ?? uh oh I have problems if it is not in there
[15:16:43] <les> kramer says positive is "expected"
[15:17:06] <les> I am just going to have to try it I guess
[15:17:15] <paul_c> * paul_c uses negative numbers in offset tables
[15:17:54] <les> but if G43 is not implemented how can you do that?
[15:18:23] <les> well...heh...put em in but nothing happens?
[15:18:24] <paul_c> Use G41 or G42 with a zero radius
[15:19:17] <les> I am going to check what is in the handbook currently
[15:20:12] <paul_c> Or you could use G92
[15:23:19] <les> yes G92
[15:23:41] <les> handbook says lenght positive or zero
[15:24:26] <les> that number is subtracted from current z
[15:24:39] <les> can't read the fuzzy graphic there
[15:25:21] <les> if subtracted it would go DOWN not UP
[15:25:26] <les> damn
[15:25:39] <les> oh well better run tests for sure
[15:26:09] <paul_c> Try it with a negative number....
[15:26:33] <les> I am getting ready to proof out the six tool 50 up production code using the custom bits I had made
[15:26:52] <les> I will write down my results for sure
[15:27:12] <les> will try negative...it would be good if that worked
[15:27:42] <cradek> babu: did you get axis to build?
[15:27:57] <les> I redid it a mit with more finishing climb cuts
[15:28:09] <les> bit
[15:32:44] <les> well thanks..back to the music room... repairing a relay board on an Alesis Amp
[15:35:59] <jmkasunich> morning all
[15:36:39] <alex_joni> hello
[15:36:40] <jmkasunich> hi alex
[15:36:46] <alex_joni> hey john
[15:36:48] <alex_joni> what's up?
[15:37:00] <jmkasunich> dunno, I just got up myself
[15:37:04] <alex_joni> nice ;)
[15:37:21] <alex_joni> brb
[15:37:25] <jmkasunich> (10:30 am here)
[15:38:43] <babu> paul_c: emc2 and axis does work now, there was a small change in the setup.py todo, now it works
[15:38:48] <paul_c> You had librcs included somewhere
[15:46:25] <babu> no, i just had to change Extension("emc2"... to Extension("emc"... and EMCINSTDIR to the right dir...
[15:46:44] <babu> should i post my setup.py somewhere? Mailinglist?
[15:47:51] <babu> where can i set default axis-speed for tkemc? i did some cleanups (EMC2) in the emc.ini, now tkemcs axis-speed is 60 instead of 1500!
[15:48:53] <babu> cradek: yepp i works!
[15:49:11] <alex_joni> * alex_joni is back
[15:49:18] <paul_c> [TRAJ] DEFAULT_VELOCITY
[15:49:30] <alex_joni> hey paul
[15:49:37] <babu> paul_c: thx
[15:49:52] <alex_joni> babu: limit switches working?
[15:49:56] <alex_joni> home too?
[15:51:46] <jmkasunich> I am ashamed of my employer... :-(
[15:52:14] <jmkasunich> www.rockwellautomation.com works from my win95 box, but not with mozilla or konqueror
[15:52:22] <jmkasunich> bastards
[15:52:59] <paul_c> Works for me
[15:53:25] <alex_joni> works here too (on a Opera)
[15:53:35] <jmkasunich> mozilla says "connection was refused when attempting to contact www.rockwellautomation.com"
[15:53:44] <alex_joni> connection problem?
[15:53:45] <jmkasunich> maybe I have it misconfigured?
[15:53:58] <alex_joni> do you have a proxy configured?
[15:54:03] <jmkasunich> no proxy
[15:54:12] <jmkasunich> mozilla opens google just find
[15:54:34] <jmkasunich> both the win box and the this box (moz) are on my home net, both go out thru the same NAT router
[15:54:53] <jmkasunich> * jmkasunich pauses
[15:55:58] <jmkasunich> I lied... this box is on the "inner" net, same as the farm, and goes thru the farm router too
[15:56:02] <jmkasunich> * jmkasunich checks router log
[16:06:12] <babu> alex_joni: i suppose you mean working in axis. limit does work, homing doesn't work yet, because home-sw == limit-sw so there is always a limit error
[16:12:39] <alex_joni> babu: that's what I meant.
[16:12:54] <alex_joni> jmk should know if homing with limitswitches is doable
[16:13:04] <jmkasunich> was just looking into that
[16:13:18] <jmkasunich> the good news... the motion controller can do it
[16:13:34] <alex_joni> but you can't connect 2 signals in hal... right?
[16:13:43] <jmkasunich> the bad news... the config info to tell it to ignore limits during homing is not currently settable from the ini file
[16:14:43] <jmkasunich> there are separate HAL pins for "home-sw-in" and "pos-lim-sw-in" and "neg-lim-sw-in" for each axis
[16:14:50] <alex_joni> I agree
[16:15:00] <alex_joni> but if it's the same pin on the parport?
[16:15:08] <jmkasunich> and you can wire one hardware input (from parport) to both home-sw-in and pos-lim-sw-in
[16:15:24] <jmkasunich> like this:
[16:15:34] <jmkasunich> newsig switch bit
[16:15:55] <jmkasunich> linksp parport.0.pin-01-in switch
[16:16:13] <jmkasunich> oops - linkps, not linksp
[16:16:30] <jmkasunich> linkps axis.0.home-sw-in switch
[16:16:43] <jmkasunich> linkps axis.0.neg-lim-sw-in switch
[16:16:57] <jmkasunich> where "switch" is your name for the HAL signal, and can be anything you want
[16:17:55] <babu> i did it like that...
[16:18:14] <babu> but there is a LIMIT error during HOMING
[16:18:20] <jmkasunich> right - I was answering alex's questiom, but that isn't the problem
[16:18:24] <jmkasunich> (sorry)
[16:18:46] <jmkasunich> the problem is that there are some flags that configure the behavior of the homing operation
[16:18:56] <jmkasunich> one of them is HOME_IGNORE_LIMITS
[16:19:14] <jmkasunich> unfortunatley there is no way (right now) to actually set it from the ini file
[16:19:17] <alex_joni> jmk: nice to hear that
[16:20:17] <babu> is there allready defined in which ini section this flag can be set?
[16:20:29] <jmkasunich> I'm fairly good at RT programming (such as making a homing system that can igore limits when told to) but not good at figuring out all the NML and C++ stuff needed to add an ini file parameter and get it from there to the realtime code
[16:20:40] <jmkasunich> babu: no - that's the problem
[16:20:49] <jmkasunich> its in the realtime code, but not in the ini file
[16:21:47] <babu> this flag can be set per joint, so it would be logical to have a param HOME_IGNORE_LIMITS in [AXIS_<n>] section of the emc.ini
[16:21:55] <jmkasunich> yes exactly
[16:22:43] <babu> ini support is quite broken in emc2. there is alot of work todo to cleanup those unneeded params (like POLARYITY)
[16:22:44] <jmkasunich> but actually doing that is painfull, it requires new NML messages and changes to multiple source files, most of which I don't understand
[16:22:55] <jmkasunich> yes :-(
[16:23:07] <jmkasunich> that is partly my failure
[16:23:16] <jmkasunich> I like (and am good at) the realtime stuff
[16:23:35] <jmkasunich> I don't know C++ or NML, so I have a really hard time doing the other stuff
[16:24:31] <jmkasunich> another reason I have a hard time with it is that I don't like how it's done.... so I tend to subconcuously avoid it
[16:25:21] <babu> i dislike this c++ and nml stuff too (mentioned a long time ago). i think emc2 can not be configured with a single inifile because of the hal, so i would propose to develop a new, high abstractionlevel config system
[16:25:50] <alex_joni> babu: like this we end up redesigning emc completely ;)
[16:26:13] <babu> its simple: you are a specialist!
[16:26:20] <babu> alex_joni: why not?
[16:27:02] <babu> in motion.h HOME_IGNORE_LIMITS is 1 by default, so it should work on my machine
[16:27:04] <alex_joni> babu: there are some years of development invested in emc
[16:27:50] <jmkasunich> babu: in motion.h, HOME_IGNORE_LIMITS is a flag that identifies which bit of joint->home_flags is used, _not_ the value of the flag itself
[16:28:01] <babu> i often read in a german cnc forum. most people know that emc is a good thing and are tired of those stupid dos programs, but most of them are afraid of EMC.INI
[16:28:26] <jmkasunich> in motion.c:766, joint->home_flags is set to zero, and there is currently no provision to set it otherwise
[16:29:06] <jmkasunich> if you wish to do a test, change line 766 of motion.c to be "joint->home_flags = 1;" and recompile, that should make it work
[16:29:21] <jmkasunich> obviously not the _right_ way to do configs :-(
[16:29:32] <babu> so i have to set Bit HOME_IGNORE_LIMITS of joint->homeflag to 1
[16:29:39] <jmkasunich> yes
[16:29:56] <alex_joni> babu: what could be usefull is making a program that generates a emc.ini
[16:30:06] <jmkasunich> like "joint->home_flags |= HOME_IGNORE_LIMITS"
[16:31:02] <babu> alex_joni: i don't know, because in that case (machine generated ini) there is alot of parse work you don't have todo (check for syntax for example)
[16:31:08] <jmkasunich> the other bit in home_flags is HOME_USE_INDEX, which tells it to use an index pulse (if zero, it simply homes on the home switch, if 1 it does preliminary home on the switch, final home on the index)
[16:32:33] <babu> jmkasunich: the design of emc2/rt part is real great! i like HAL!
[16:33:26] <jmkasunich> so far it seems that people either love it or hate it, there is no middle ground ;-/
[16:35:43] <babu> that is no problem to me (i wish i had more time to contribute to emc2)
[16:36:14] <jmkasunich> I'm curious - do you work with hardware (electrical or electronic)?
[16:36:32] <babu> which rtai version do you advise? kileau or vesuvio?
[16:36:59] <jmkasunich> who are you asking? I use BDI - I've never built a kernal
[16:37:13] <babu> no i do work with chemistry. i am interested in machine controlling because i'm building a 3D-Printer
[16:37:23] <jmkasunich> paul know far more about RTAI than I
[16:37:55] <babu> * babu has to ask paul which RTAI version he uses to compile emc2 cvs
[16:38:23] <jmkasunich> building a printer = working with hardware, yes?
[16:38:23] <babu> i forgot which one i took when i compiled emc2 last time
[16:39:16] <jmkasunich> you should use whichever is installed on your system
[16:39:19] <babu> ehm yepp, i'm from switzerland so i interpreted work == job
[16:39:37] <paul_c> It doesn't make much difference which RTAI branch you use. As long as you use the right patch for your kernel, it should work.
[16:40:38] <jmkasunich> I understand work=job, I meant that too... but you have the "hardware" mental picture, whether it is from job or hobby... those tend to be the folks who like HAL, because it fits that picture
[16:42:56] <babu> i have my mental picture from my hobby. i like hal, because i had alook at emc sources and decided to learn c and rtai to develop my own motion controller. i had a first, working prototyp when i had alook at hal. normally i do code in RUBY which is very object oriented (like smalltalk). so it was love on the first sight.
[16:43:23] <jmkasunich> ?huh?
[16:43:40] <jmkasunich> that's the first time anybody has called anything I did object oriented
[16:43:57] <jmkasunich> * jmkasunich still uses only C, doesn'
[16:44:10] <jmkasunich> * jmkasunich doesn't know any OO language
[16:45:15] <babu> HAL definitifl... is OO. you can code OO in c, naturally not the classical OO, but you can port the thought of OO to any, any language
[16:45:36] <babu> you even can organize your directories in the sense of OO
[16:46:39] <jmkasunich> I hadn't thought about it that way, but I guess HAL components are objects
[16:46:55] <jmkasunich> I'm an electrical engineer, so I naturally think of design as connecting components
[16:47:32] <babu> ahh, because of that you use "wires" to connect pins
[16:48:10] <jmkasunich> yes
[16:48:16] <babu> QT the c++ toolkit is a good example for pure OO. you use the same methaphers: they use to say signal and slot, you say pins
[16:48:52] <jmkasunich> my long term plans for HAL are to be able to use a schematic drawing tool like GEDA to draw a system of HAL components, and automatically configure it from the drawing
[16:49:00] <babu> they say: connecting a signal(int) with a slot(int) you say: linking pin (bit) with another pin(bit) giving the direction
[16:49:47] <babu> that would be great. but using HAL-scripts is nice to because for example the <= and => linksp param is very intuitive to use too
[16:51:05] <jmkasunich> the HAL script is the same level as a netlist... you can do simple designs by just writing out a netlist, but as things get more complex, a schematic lets you visualize things and understand the big picture better
[16:51:30] <jmkasunich> the schematic approach would generate a HAL script from the drawing
[16:51:37] <alex_joni> that's where halgui will come in handy
[16:52:08] <jmkasunich> what I've been thinking of for halgui is just a GUI version of halcmd
[16:52:11] <babu> hmm perhaps i could be easily done modifying an existing UML Editor like kumbrella
[16:53:03] <jmkasunich> isn't UML text oriented?
[16:53:06] <babu> * babu is still searching which rtai he used to build his kernel
[16:53:38] <jmkasunich> hopefully "./configure" can figure it out
[16:53:51] <babu> http://uml.sourceforge.net/screen.php
[16:54:10] <babu> ./configure is too stupid...
[16:54:33] <babu> i reorganized my dirs.. now everything is broken
[16:55:20] <jmkasunich> duh... I thought the M in UML was "Markup", not "Modeling"
[16:56:00] <babu> modern x-Markup-l editors are more modellers to, same with ht-markupt-l
[16:56:08] <alex_joni> babu: don't say that about ./configure :(
[16:56:27] <babu> it is handwritten! your work?
[16:56:43] <jmkasunich> babu: when did you download?
[16:57:02] <jmkasunich> alex did an autoconf version, that was merged a couple weeks ago
[16:57:12] <jmkasunich> the handwritten one was me and paul, and yes, it was stupid
[16:57:17] <babu> a few weeks ago
[16:57:41] <alex_joni> try getting a newer one
[16:57:48] <jmkasunich> get a fresh download, you will be much happier (I hope)
[16:57:58] <alex_joni> * alex_joni hopes that too
[16:58:05] <babu> ok
[16:58:33] <babu> whats about the debian support in emc2
[16:59:31] <alex_joni> paul is mainly working on debian support
[16:59:37] <alex_joni> the new BDI is debia based
[16:59:55] <alex_joni> there are packages for kernel, emc, etc.
[17:00:11] <babu> very nice!
[17:02:06] <alex_joni> * alex_joni throws babu a number for the waiting line ...
[17:02:46] <paul_c> 4.06
[17:02:53] <babu> * babu got it, my estimated waiting time is 9:00
[17:03:00] <babu> ?
[17:04:51] <alex_joni> 9 years ?
[17:04:52] <alex_joni> :D
[17:08:19] <Imperator_> Hi all
[17:08:28] <alex_joni> Hey Martin
[17:08:40] <Imperator_> about that configuration stuff, what should we do ??
[17:09:31] <Imperator_> because i have also to add one ore two parameters, so maybe i can try to implement something with that we can be more happy
[17:10:04] <Imperator_> * Imperator_ hopes that is not a work for years
[17:11:17] <alex_joni> what configuration Martin?
[17:11:26] <alex_joni> you talking about ./configure ? or the .ini?
[17:13:24] <Imperator_> the .ini stuff
[17:15:03] <Imperator_> one option is i make it in the way it is now, or we change the way to get the ini stuff into emc
[17:15:41] <alex_joni> do have any thoughts on that already?
[17:16:13] <Imperator_> nop
[17:16:49] <Imperator_> but i think without using NML we break the ability to control EMC over the network
[17:17:31] <alex_joni> * alex_joni knows not enough NML & emc internals to have an opinion
[17:17:49] <jmkasunich> * jmkasunich has been very tempted to make things like "joint->home_flags
[17:17:56] <jmkasunich> dammit
[17:18:09] <jmkasunich> joint->home_flags" into HAL parameters
[17:21:32] <alex_joni> jmk: anything interesting last sunday?
[17:21:41] <jmkasunich> it was pretty quiet
[17:22:13] <jmkasunich> cradek did help me find a problem in control.c that prevented commanded position from updating in free mode (jogs)
[17:22:20] <jmkasunich> I committed a fix later in the week
[17:23:14] <alex_joni> should I post the logs?
[17:23:38] <babu> HOME_FLAGS a HAL Param for the MOTION-Hal/NML-componente
[17:23:50] <jmkasunich> alex_joni: sure, why not
[17:28:29] <Imperator_> hm, if i have a look over the existing axis parameters nearly everything is now a hal parameter
[17:28:42] <Imperator_> why not also the rest of them ?
[17:29:31] <jmkasunich> good question
[17:29:45] <jmkasunich> but right now, they are _set_ thru NML
[17:29:56] <jmkasunich> the HAL simply provides a way to look at them
[17:30:07] <jmkasunich> using the HAL to set them would be a big step
[17:31:03] <Imperator_> thats the job for halgui
[17:31:09] <alex_joni> not really
[17:31:23] <alex_joni> halgui will only do the linking between components
[17:31:33] <alex_joni> using HAL to set things needs to be coded
[17:31:36] <Imperator_> or a script that uses the ini as input and halcmd as output
[17:32:31] <alex_joni> once there is the code inside emc to set things by HAL
[17:32:34] <Imperator_> witch parameters are at the moment set by NML ???
[17:32:37] <alex_joni> all
[17:33:09] <Imperator_> but not the ones for seting up the axis
[17:35:20] <Imperator_> if i look to the axis section nearly everything is gone to hal. and in hal there is nothing set by NML at the moment
[17:36:13] <jmkasunich> NML is used to set:
[17:36:24] <Imperator_> is in EMC2 even one parameter of the axis section used at the moment ?
[17:36:39] <jmkasunich> position limits, max and min ferror, vel limit, acc limit
[17:36:41] <jmkasunich> and several others
[17:38:09] <Imperator_> the position limits and ferror limits are hal parameters
[17:39:29] <jmkasunich> I'm looking at emc.ini right now...
[17:39:39] <jmkasunich> UNITS and HOME are used
[17:39:51] <jmkasunich> MAX_VEL and MAX_ACC are used (by the TP)
[17:40:05] <jmkasunich> P,I,D,FF0-2 are no longer used
[17:40:15] <jmkasunich> BACKLASH is used for backlash comp
[17:40:24] <jmkasunich> BIAS is no longer used
[17:40:53] <jmkasunich> MAX_ERROR I'm not sure what that's used for
[17:41:02] <jmkasunich> DEADBAND is no longer used
[17:41:21] <jmkasunich> CYCLE_TIME is still used (but it was never a per-axis parameter)
[17:41:33] <jmkasunich> INPUT_SCALE is not used (scaling is done in HAL)
[17:41:35] <Shintai> wow thats the most posts i've ever seen in here heh
[17:41:44] <jmkasunich> OUTPUT_SCALE likewise
[17:42:08] <jmkasunich> MAX_LIMIT and MIN_LIMIT are the position limits - that is _NOT_ done in HAL
[17:42:23] <jmkasunich> MIN_OUTPUT and MAX_OUTPUT are no longer used
[17:42:42] <jmkasunich> FERROR and MIN_FERROR set the following error limits - they are still used
[17:42:54] <jmkasunich> HOMING_VEL is still used
[17:43:23] <jmkasunich> (need to add another one for the latch phase velocity, currently that is hardcoded as a fraction of HOMING_VEL)
[17:43:47] <jmkasunich> SETUP_TIME and HOLD_TIME are not used - moved to the HAL stepgen module, since they are unique to steppers
[17:43:55] <jmkasunich> HOME_OFFSET is still used
[17:44:06] <jmkasunich> the POLARITY ones are not used
[17:47:53] <babu> whats about HOMING_POLARITY?
[17:48:34] <Imperator_> all that polarity stuff is done now by hal
[17:48:37] <jmkasunich> * jmkasunich checks
[17:48:47] <jmkasunich> nope, not used
[17:48:51] <Imperator_> there is for every pin a negative one
[17:49:12] <Imperator_> where have you checkt that John ??
[17:49:40] <babu> HOMING_POLARITY means in which direction the home switch has to be searched
[17:50:08] <jmkasunich> I was already sure that it wasn't used in the old way of deciding if an input was active high or active low
[17:50:37] <babu> ./iniaxis.cc: HOMING_POLARITY <0, 1> direction for homing search
[17:50:43] <jmkasunich> I was trying to remember if it was used to indicate the direction of the homing moves, but that is done by the sign of HOMING_VEL
[17:52:23] <jmkasunich> emc2 homing is described in section 3.4 (page 20) of EMC2_Code_Notes.pdf
[17:53:12] <jmkasunich> available at http://www.linuxcnc.org/EMC2_Code_Notes.pdf
[17:53:55] <jmkasunich> there are six pieces of information that configure homing
[17:54:08] <jmkasunich> only 3 are directly settable as ini file parameters today
[17:54:17] <jmkasunich> home_search_vel, home_offset, and home
[17:55:01] <jmkasunich> home_latch_vel is hardcoded to be 1/10 of home_search_vel
[17:55:27] <jmkasunich> home_ignore_limits and home_use_index are defaulted to 0, and there is currently no way to change them
[17:55:53] <Imperator_> it is realy hard to understand how iniaxis is putting the values in !!
[17:56:08] <jmkasunich> if it was easy, I would have added the new values
[17:56:29] <jmkasunich> have I said before how much I hate the way that is done ;-)
[17:56:37] <Imperator_> :-)
[17:56:46] <Imperator_> for example backlash (beginning at line 334) how is the value set ????
[17:58:12] <paul_c> Seach $inifile for [section] BACKLASH
[17:58:28] <paul_c> if found, read alue as a float
[17:58:41] <jmkasunich> and stick it in the local variable backlash
[17:58:44] <paul_c> esle use default value
[17:59:24] <jmkasunich> then later, call emcAxisSetGains(blah, blah, backlash, blah)
[17:59:59] <jmkasunich> emcAxisSetGains does the dirty work, sends an NML message (I think)
[18:00:07] <paul_c> NO
[18:00:26] <paul_c> No NML messages involved as far as I'm aware
[18:01:44] <jmkasunich> * jmkasunich looks at the source for emcAxisSetGains in taskintf.cc
[18:02:36] <jmkasunich> paul is right, it simply builds an EMCMOT_SET_PID command in shmem
[18:03:03] <jmkasunich> actually I'm not sure it's in shmem yet
[18:03:11] <babu> alex_joni: hmm the new configure didn't set the include path or something like that tk.h is not found... have to investigate
[18:03:56] <jmkasunich> it's not
[18:04:20] <jmkasunich> emcmotCommand is static, local to taskintf.cc
[18:04:55] <jmkasunich> so emcAxisSetGains builds an EMCMOT_SET_PID command in it's own local memory
[18:05:11] <jmkasunich> then calls usrmotWriteEmcmotCommand
[18:06:07] <jmkasunich> which is in usrmotintf.c
[18:06:16] <alex_joni> babu: it searches for tk config script, and uses that if found
[18:06:49] <Imperator_> Hm, it is realy not that easy !!!
[18:07:01] <babu> alex_joni: checking for tcl... /usr/lib/tclConfig.sh found
[18:07:27] <alex_joni> babu: tkConfig.sh is searched under /usr/local/lib
[18:07:32] <jmkasunich> usrmotWriteEmcmotCommand copies the command from local memory to shared memory
[18:07:45] <alex_joni> babu: and tkConfig.sh doesn't get found?
[18:08:21] <jmkasunich> once that happens, then emcmotCommandHandler in the realtime code gets and processes the command
[18:08:44] <babu> alex_joni: checking for tcl... /usr/lib/tcl8.4/tclConfig.sh found
[18:08:44] <babu> /usr/lib/tk8.4/tkConfig.sh found
[18:08:53] <babu> alex_joni: should work
[18:09:21] <alex_joni> yup it should
[18:09:37] <Imperator_> is there a way to kick that stuff at all ???
[18:09:42] <alex_joni> * alex_joni has just looked at the code: it first searches /usr/lib then /usr/local/lib if not found
[18:09:59] <jmkasunich> I dunno
[18:10:04] <babu> alex_joni: problem solved! there was tcl8.0 and tcl8.4 installed (dpkg???) now it seems to work
[18:10:26] <jmkasunich> let's walk thru the steps needed to add a new parameter to the ini file and get it to realtime code
[18:10:27] <alex_joni> babu: glad to hear that
[18:10:35] <jmkasunich> 1) pick a name for the parameter
[18:10:45] <alex_joni> * alex_joni is going home... he'll read the log later
[18:11:08] <jmkasunich> 2) add a local var to iniaxis.cc, and lines to read the value from the file and set the locak
[18:11:11] <jmkasunich> local
[18:11:20] <babu> is it necessary to have such a complex ini parser... using xml or a script language instead of c++ would be much comfortable
[18:11:46] <babu> it should be easy to add new config-params for every developer
[18:11:50] <jmkasunich> 3) add a function similar to emcAxisSetGains() to build a command message
[18:11:58] <jmkasunich> 4) add the new command message to motion.h
[18:12:23] <jmkasunich> 5) add a new case to emcmotCommandHandler to handle the new message
[18:12:25] <paul_c> babu: Your average xml parser is written in C++
[18:12:36] <babu> * babu wants excuse himself for allways interrupting jmkasunichs postings
[18:12:49] <jmkasunich> s'ok babu
[18:13:20] <babu> paul_c: yes and no! yes but it is maintained by for example the apache group and no, there are python or perl implementings too
[18:13:52] <paul_c> babu: and Python & Perl are coded in ?
[18:14:34] <jmkasunich> the parser itself isn't really a problem... (if by the parser you mean axisInifile->find("SOMENAME", "SOMESECTION"
[18:15:14] <jmkasunich> )
[18:15:32] <babu> paul_c: i know where do you want to go. i didn't want to say that c++/c is useless, (c is coded in asm!) i just want to say that my oppinion is, that the whole ini-stuff is too heavy. there are no performance problems, so using a simpler approach would be glad
[18:16:22] <babu> jmkasunich: homing is real good documented in emc2!
[18:17:15] <paul_c> text handling in C/C++ is not as simple as it is in higher level languages
[18:18:06] <paul_c> but then the code that actually parses the ini file isn't particularly complex.
[18:18:17] <babu> yepp, so using 30 lines of code to handle a inisection where the same thing can be done with 2 lines of lets say perl code is overkill i think
[18:18:47] <paul_c> and how would you pass a variable from perl to a C/C++ program ?
[18:19:15] <babu> write a extension for accessing nml
[18:19:30] <babu> * babu assumes that params should be set per nml
[18:19:40] <paul_c> 500 lines of code...
[18:20:49] <babu> no, i don't belive that
[18:21:34] <babu> but i know less about emc2/nml for give a new config concept. i just think it will be a long way if it is done like it was done in emc1
[18:23:08] <Imperator_> all that NML stuff is only usefull to have the ability to have the user interface on a other computer, right ?
[18:23:20] <paul_c> The code that parses an ini file is some 400 lines - 20-30% comments
[18:24:05] <paul_c> it is reusable by any C/C++ program, so only needs to be coded/compiled once.
[18:24:08] <jmkasunich> * jmkasunich is back (an incident involving a stepson, a toaster, and much smoke)
[18:24:23] <jmkasunich> the parsing code is not the issue, IMO
[18:24:46] <babu> using xml and xml-schema you don't have to check the inputs (syntax ie strings instead of float), using xslt you can translate that directly to nml or whatever
[18:25:14] <Imperator_> the problem is that it has to go through NML
[18:25:19] <jmkasunich> babu: in this case, NML isn't even involved (and IMO thats a very good thing)
[18:26:03] <babu> i wanted to learn nml a few months ago, i dislike it! i talked to paul_c using another IPC System...
[18:26:22] <paul_c> XML has it's place, but I do not think that simple config files is such a place.
[18:27:00] <jmkasunich> I agree with paul... emc's ini file can be edited by humans - XML does _NOT_ increase human readability!
[18:27:10] <babu> EMC2 config isn't that simple. imaging to have emc vars and hal-config in one file
[18:27:28] <babu> i don't want XML, it was just an example
[18:27:46] <jmkasunich> ok, sorry for the misunderstanding
[18:28:15] <babu> i like unix and its plain text config files. i just choosed xml because i wanted to show that checking values and translate them
[18:28:24] <babu> have not to be reinventet over and ove again
[18:28:35] <jmkasunich> I like the ini file parsing code... there is _one_ function, find(), and you specify the name of what you want to find
[18:28:39] <jmkasunich> that is clean, IMO
[18:28:50] <babu> * babu is looking at the code
[18:29:00] <jmkasunich> what I don't like is the later stages of the pipeline, where there is a different function for every parameter
[18:29:22] <jmkasunich> emcSetThis() and emcSetThat() and emcSetAnother()
[18:29:29] <Imperator_> babu: the hal-config stuff has moved out of the .ini some month ago
[18:29:43] <jmkasunich> what's wrong with set(name, value)
[18:30:51] <babu> imperator_: yepp i know that but they have to be interconnect later, im sure (max_acc is a good example)
[18:30:56] <jmkasunich> then adding a new "name" only involves changes at the two endpoints, the name moves thru the rest of the chain easily
[18:31:00] <Imperator_> is there a way to do all in iniaxis
[18:32:08] <jmkasunich> babu is on to something... there is an emc parameter max_vel, in inches (or mm) per second, and there is also a HAL parameter, in steps per second
[18:34:15] <jmkasunich> the HAL parameter won't always be in steps per second, that depends on what you are using to move the axis
[18:34:57] <babu> yeah, but it could be possible to calc MAX_ACCEL from the scaling info aviable in HAL
[18:34:58] <jmkasunich> the reason I want it to be a separate HAL parameter is that I want to be able to set up the HAL part and actually move the axis for testing or tuning, without loading emc itself
[18:35:32] <jmkasunich> babu: only if the s/w doing the calculation knows which HAL parameter it is
[18:35:46] <jmkasunich> but the whole idea of the HAL was to decouple some of these things.
[18:35:47] <babu> i find it ok how it is! i used HAL as standalone with siggen for a long time
[18:36:36] <babu> yes thats true, emc has to know how this param is called in hal
[18:37:07] <jmkasunich> if your motor is a stepper, then the param is stepgen.x.maxfreq, but if it is a servo, then what is the parameter?
[18:37:41] <jmkasunich> that is the curse of allowing the integrator to configure his machine in many different ways
[18:37:52] <jmkasunich> only the integrator knows exactly how his machine is configured
[18:38:54] <babu> see it! hal and emc has to be separated!
[18:39:34] <Imperator_> yes but why is it not the same at steppers or servos ???
[18:39:57] <Imperator_> and servos
[18:40:21] <jmkasunich> steppers scaling is determined by the output (steps/rev), servo by the input (encoder counts)
[18:40:56] <jmkasunich> with HAL it can be even more complicated
[18:42:01] <jmkasunich> I can envision a future PID module with separate inputs for position and velocity feedback... velocity feedback could come from an ADC and analog tach, or motor mounted encoder, position from a linear encoder on the machine
[18:42:29] <jmkasunich> HAL does NOT limit what you can set up for motor control
[18:43:24] <jmkasunich> if EMC makes assumptions and tries to read some of it's config from the HAL modules that it is connected to, it will fail when somebody uses a non-standard arrangement of HAL modules
[18:43:44] <jmkasunich> I would rather have the integrator set both EMC and HAL parameters
[18:44:19] <Imperator_> ok
[18:44:20] <jmkasunich> unfortunately this puts more burden on the guy who is doing a very plain simple machine
[18:45:15] <babu> so you have to provide good examples for widly used machines like 3-axis stepper with dir/clk
[18:47:38] <Imperator_> NML is used to control EMC from another computer. right ??
[18:48:11] <jmkasunich> NML is used even when controlling EMC from the same computer
[18:48:25] <paul_c> NML is used to pass messages between various parts of EMC
[18:48:40] <jmkasunich> but yes, it's real purpose is to allow control from elsewhere, if everything was on the same box, something simpler would work
[18:48:44] <paul_c> they need not be running on the same computer
[18:48:58] <Imperator_> that means i can set backlash, mav_vel, ... from the gui but not P, I, D, or stepper stuff
[18:49:19] <jmkasunich> yes
[18:49:25] <Imperator_> hmmm
[18:49:28] <paul_c> IF you have NML messages defined for them.
[18:49:54] <paul_c> PID can currently be tuned via a GUI & NML
[18:49:56] <Imperator_> but John will kill me if i write a NML interface for HAL, right :-)
[18:50:06] <jmkasunich> nope
[18:50:23] <jmkasunich> as long as it uses the published HAL api, you can do whatever you want
[18:50:55] <Imperator_> PID are only HAL Parameters, i think
[18:51:26] <Imperator_> how can this be done, John ??
[18:51:27] <jmkasunich> yes
[18:51:39] <Imperator_> a halcmd that uses NML as input ?
[18:51:48] <jmkasunich> something like that
[18:51:55] <jmkasunich> what commands would you want to have?
[18:51:56] <Imperator_> ok
[18:52:03] <jmkasunich> probably set parameter at least
[18:52:15] <Imperator_> jep
[18:52:44] <Imperator_> other stuff is too complicated to be set by a easy gui
[18:53:14] <jmkasunich> if you are going to write a HAL gui, _please_ don't use NML
[18:53:21] <Imperator_> conecting pins and signals needs a bigger application
[18:53:56] <Imperator_> be shure, John :-)
[18:54:17] <paul_c> How would you configure a headless control ?
[18:54:35] <jmkasunich> how is it done today?
[18:55:33] <jmkasunich> you pointed out that NML is not involved in the "emc.ini ->iniaxis.cc->taskintf.cc->usrmotintf.c->command.c" pipeline
[18:55:42] <jmkasunich> the ini file must reside on the control PC
[18:56:11] <Imperator_> that is a good point, must it be possible to configure a mashine from outside ?
[18:56:12] <paul_c> "configure" might be the wrong choice of word
[18:56:29] <paul_c> Tuning items like the PID loops
[18:56:42] <Imperator_> to runn it from somewhere is much more usefull, but makes big security problems
[18:57:01] <jmkasunich> ssh -x ?
[18:57:24] <Imperator_> no i mean mashine security
[18:57:39] <jmkasunich> I was answering pauls question
[18:57:57] <paul_c> Imperator_: The NML library has hooks for encryption & password authentication
[18:58:05] <Imperator_> for example it is not allowed to start a machine from somewhere, if you can't see the howle maschine
[18:58:08] <jmkasunich> tuning PID remotely could be done using halcmd and halscope on the controller machine, via ssh -X
[18:58:42] <paul_c> That rather assumes the controller has X installed
[18:59:05] <jmkasunich> without X you'd still have halcmd
[18:59:08] <paul_c> AND the n/w has the bandwidth to make it practical
[18:59:41] <jmkasunich> does emc1 allow you to run stripchart remotely?
[19:00:09] <paul_c> never tried it.
[19:00:33] <jmkasunich> halcmd lets you set params, halscope views the results
[19:00:50] <jmkasunich> analagous to tkemc setting them, and stripchart viewing
[19:01:26] <Imperator_> btw. starting a machine by remote from somewhere is at the moment one of the bigest research aereas of the machine safty equipment industrie
[19:02:14] <jmkasunich> I don't know about you, but I won't be abandoning my lockout locks any time soon
[19:02:44] <jmkasunich> _especially_ if it is a remotely controlled machine and it is using the latest "research"
[19:03:32] <jmkasunich> * jmkasunich believes you can't use the words software and safety in the same sentence
[19:03:33] <Imperator_> that is the reason why they are spending so much money at the moment for solving that problem
[19:03:53] <Imperator_> that changes at the moment
[19:04:26] <Imperator_> the time when you easyly can say software is always buggy is gone
[19:04:43] <jmkasunich> not when it is _my_ safety we are talking about
[19:05:10] <Imperator_> because software is now to important
[19:05:40] <Imperator_> what about your car
[19:05:47] <Imperator_> break by wire
[19:05:52] <Imperator_> stear by wire
[19:05:53] <jmkasunich> not my car
[19:05:57] <Imperator_> that will come
[19:06:11] <Imperator_> break by oil
[19:06:16] <jmkasunich> and I won't be happy about it
[19:06:18] <Imperator_> do you trust oil ???
[19:06:28] <jmkasunich> I'm a Luddite
[19:06:42] <jmkasunich> as in hydraulic brakes?
[19:06:53] <Imperator_> :-)
[19:07:22] <Imperator_> buy a german car in five years, then you have to trust software
[19:07:29] <jmkasunich> note that there are two redundant hydraulic brake circuits, each operating one diagonal pair of wheels
[19:07:37] <jmkasunich> cause we don't even trust oil
[19:07:52] <Imperator_> i think there are four
[19:07:58] <Imperator_> jep, thats right
[19:08:02] <jmkasunich> not to be rude, but German cars tend to be over-engineered
[19:08:20] <Imperator_> and they are developing redundant electrical systems also
[19:08:37] <jmkasunich> there is one model either Mercedes or BMW, with something like 78 electrical motors, including 38 just to adjust seats
[19:08:40] <Imperator_> jep, that is also true
[19:08:52] <jmkasunich> I'll never buy a vehicle like that - keep it simple for me please
[19:09:01] <Imperator_> thats why they are develloping the 9000 EUR car at VW
[19:09:33] <paul_c> * paul_c hands jmkasunich a starting handle for a model T
[19:09:57] <Imperator_> and i think they just have taken out the plans for the Golf II out of the archieves :-)
[19:10:00] <jmkasunich> I tend to like 20 year old technology, not 100 year old technology
[19:10:28] <jmkasunich> more to the point, I like technology when well applied, not just "because we can"
[19:10:34] <Imperator_> my Golf II is 13 years old
[19:11:03] <Imperator_> and it haven't a failture up to now
[19:11:11] <jmkasunich> my last truck was 13 years old when I replaced it, and I hope to get at least as long out of the current one
[19:11:36] <Imperator_> forgeth it
[19:11:45] <jmkasunich> why?
[19:12:07] <Imperator_> to much electronic inside
[19:12:20] <jmkasunich> trucks tend to lag some years behind cars in that stuff
[19:12:44] <jmkasunich> my truck has electronic engine controls (as did the old one) but not much more
[19:12:56] <jmkasunich> no power windows, or locks, or any of that fancy stuff
[19:13:06] <Imperator_> my frend is developing the stuff to have 110V in one of the new trucks of GM
[19:13:19] <jmkasunich> I thought they were going for 42V?
[19:13:25] <Imperator_> no airbacks ??
[19:13:34] <jmkasunich> it has airbags
[19:13:51] <Imperator_> that is that you can supply your house if you want
[19:14:47] <jmkasunich> we have digressed really far from EMC ;-)
[19:14:57] <Imperator_> a bit, yes
[19:15:33] <jmkasunich> immediate problem... allowing babu to set "joint->home_flags" so it will ignore limits during homing
[19:15:44] <Imperator_> jep
[19:15:48] <paul_c> * paul_c goes to feed the wrinkly
[19:16:14] <jmkasunich> dammit - he always leaves when we get to discussing something where I'd like to hear his opinion
[19:16:15] <Imperator_> we need you Paul
[19:17:21] <Imperator_> ok one solution is to add all that stuff like with the existing parameters
[19:17:37] <Imperator_> a other to kick NML :-)
[19:17:55] <jmkasunich> NML isn't involved here (that was my misunderstanding)
[19:18:11] <jmkasunich> we would need to add lines to iniaxis.cc
[19:18:18] <jmkasunich> add a function to taskintf.cc
[19:18:30] <jmkasunich> add a command to motion.h
[19:18:42] <jmkasunich> and add a case to a switch in command.c
[19:18:47] <jmkasunich> (I think)
[19:19:53] <Imperator_> that was the problem
[19:21:55] <Imperator_> and you want to have that in one function at the sending side and one on the reciving sind, right
[19:22:26] <jmkasunich> at this point, I'm just trying to figure out how to do it the existing way
[19:22:38] <jmkasunich> I don't know enough C++ to re-do it the way I'd like
[19:22:49] <jmkasunich> nor do I have the time or energy to attack it
[19:23:24] <Imperator_> should we try to do that together ?
[19:23:35] <jmkasunich> the problem I see now is that we would be adding another function much like emcAxisSetHomingVelocity to emc.hh, and I have no idea what the effect of that would be
[19:24:15] <Imperator_> that stuff has to be changed complitly
[19:24:26] <jmkasunich> every time I look at emc.cc or emc.hh, I panic
[19:24:39] <jmkasunich> and my brain shuts down
[19:25:21] <Imperator_> than we have to delete it
[19:25:42] <jmkasunich> easier said than done... and if we did, Paul would kill us
[19:26:18] <Imperator_> hmm
[19:26:45] <Imperator_> ok i will look to it, maybe i find out somthing
[19:27:19] <jmkasunich> I'm really confused, because the path from iniaxis.cc to the motion controller does not involve NML, but emc.hh does define NML messages
[19:27:32] <jmkasunich> I was looking at homing velocity as an example
[19:28:05] <jmkasunich> iniaxis parses the velocity out of the ini file and calls emcAxisSetHomingVelocity()
[19:28:27] <jmkasunich> that is declared in emc.hh and defined in taskintf.cc
[19:29:35] <jmkasunich> and in emc.hh there is "class EMC_AXIS_SET_HOMING_VEL:public EMC_AXIS_CMD_MSG {"
[19:30:04] <jmkasunich> so there _IS_ an NML message to set it, even though the ini code doesn't use it
[19:30:43] <Imperator_> in witch line in iniaxis is that ???
[19:31:04] <jmkasunich> the class statement is in emc.hh, line 1004
[19:32:10] <jmkasunich> the function emcAxisSetHomingVelocity is called from iniaxis.cc:710
[19:32:34] <jmkasunich> the function is defined at taskintf.cc:350
[19:38:02] <jmkasunich> hi alex
[19:38:35] <alex_joni> hello
[19:38:47] <alex_joni> any conclusions on the parameters?
[19:38:58] <jmkasunich> not really
[19:39:04] <jmkasunich> we keep digressing
[19:39:23] <alex_joni> * alex_joni knows the feeling
[19:39:26] <jmkasunich> the homing params that we started with are really core emc parameters
[19:39:45] <jmkasunich> so there isn't really a good reason for them not using the existing mechanism
[19:40:08] <jmkasunich> and I'm willing to do just that, but one step scares me
[19:40:20] <alex_joni> what's that?
[19:40:23] <jmkasunich> I was using HomingVel as an example
[19:40:59] <jmkasunich> it is read from the inifile at iniaxis.cc:691
[19:41:24] <jmkasunich> then iniaxis.cc:710 calls emcAxisSetHomingVel
[19:41:48] <jmkasunich> that is declared in emc.hh:418
[19:42:05] <jmkasunich> and implemented in taskintf.cc:350
[19:42:26] <jmkasunich> all of which I think I could duplicate for the other homing related parameters
[19:42:30] <alex_joni> * alex_joni gets the impression it's a little scattered
[19:42:57] <jmkasunich> but in emc.hh:54, there is "#define EMC_AXIS_SET_HOMING_VEL_TYPE ((NMLTYPE) 112) "
[19:43:21] <jmkasunich> and at emc.hh:1004, there is:
[19:43:27] <jmkasunich> class EMC_AXIS_SET_HOMING_VEL:public EMC_AXIS_CMD_MSG {
[19:43:37] <jmkasunich> I don't have any idea what those are about
[19:43:38] <jmkasunich> I can't even read them
[19:44:02] <jmkasunich> those are NML message definitions, I think
[19:44:15] <alex_joni> * alex_joni takes a look
[19:44:27] <jmkasunich> so even tho iniaxis doesn't use NML to do it's work, there _are_ NML messages defined for those things
[19:44:29] <alex_joni> it's a class
[19:44:48] <alex_joni> EMC_AXIS_SET_HOMING_VEL is a class that extends EMC_AXIS_CMD_MSG
[19:46:55] <alex_joni> it's a class wrapped around a message function
[19:46:57] <jmkasunich> uh-oh.. there is also stuff in emc.cc:134, :581, :2024, and :2084
[19:47:10] <alex_joni> the hh has only the defines
[19:48:08] <alex_joni> interface it's called (if my memory serves me right)
[19:48:15] <alex_joni> the cc has the implementation
[19:48:27] <alex_joni> as far as I see it:
[19:48:39] <alex_joni> there is a base class (EMC_AXIS_CMD_MSG)
[19:49:12] <alex_joni> which is derived from (RCS_CMD_MSG) but it has info of an axis number
[19:49:44] <alex_joni> this class (EMC_AXIS_CMD_MSG) has an member: EMC_AXIS_CMD_MSG(NMLTYPE t, size_t s):RCS_CMD_MSG(t, s) {
[19:49:44] <alex_joni> };
[19:50:21] <jmkasunich> you lost me there
[19:50:34] <alex_joni> where?
[19:51:02] <alex_joni> do you have the big picture of inheriting/deriving ?
[19:51:10] <jmkasunich> what is the member? (It doesn't help that the NIST guys used uppercase for things that usually aren't uppercase)
[19:51:15] <jmkasunich> no
[19:51:23] <alex_joni> member is a function
[19:51:31] <alex_joni> that belongs to the class
[19:51:43] <alex_joni> see it like this: a class is a HAL component
[19:51:49] <jmkasunich> every time someone tries to explain those things to me I feel really stupid, because I can never seem to "get it"
[19:52:14] <alex_joni> it has some functions in it - those are called members (you can define those as: public, private, etc.)
[19:52:20] <jmkasunich> ok
[19:52:30] <alex_joni> ok, now you have a class
[19:52:44] <alex_joni> it has some internal variables (defined private usually)
[19:52:54] <jmkasunich> what part of "EMC_AXIS_CMD_MSG(NMLTYPE t, size_t s):RCS_CMD_MSG(t, s) {};" is the function name?
[19:53:03] <jmkasunich> EMC_AXIS_CMD_MSG?
[19:53:03] <alex_joni> and you have functions(members) who can access/modify this variables
[19:53:07] <alex_joni> exactly
[19:53:21] <alex_joni> always when you see an ":"
[19:53:56] <alex_joni> take it this way: the stuff to the left (EMC_AXIS_CMD_MSG) is derived from the stuff to the right (RCS_CMD_MSG)
[19:54:58] <Imperator_> deriving means using one component of the class ?
[19:55:12] <jmkasunich> ok
[19:55:28] <jmkasunich> so if you call EMC_AXIS_CMD_MSG, it will in turn call RCS_CMD_MSG?
[19:55:30] <alex_joni> no, deriving (or inheriting) means it gets all the stuff from the other class/member
[19:55:34] <alex_joni> not really
[19:55:53] <alex_joni> when you call EMC_AXIS_CMD_MSG it calls EMC_AXIS_CMD_MSG
[19:56:11] <alex_joni> but this function will have all elements from RCS_CMD_MSG
[19:56:19] <alex_joni> so you don't need to rewrite it
[19:56:22] <jmkasunich> duplicated code?
[19:56:32] <alex_joni> kinda like that
[19:56:36] <jmkasunich> ick
[19:56:44] <alex_joni> but you can rewrite parts of it, or add parts
[19:57:45] <jmkasunich> I think part of my problem is the word "message"
[19:58:14] <jmkasunich> in my mind, "message" = "block of bytes that means something" that can be passed thru some communication channel.... but it is _data_
[19:58:33] <jmkasunich> I sometimes get the impression that an NML message isn't data, instead it is function calls
[19:58:57] <jmkasunich> and here we are, with "functions" called RCS_CMD_MSG
[19:59:03] <alex_joni> actually it's a class
[19:59:12] <alex_joni> which contains data (variables)
[19:59:24] <jmkasunich> I understand that a class is data and functions that manipulate the data
[19:59:25] <alex_joni> and functions which get called (members)
[19:59:47] <jmkasunich> are only the functions called members? what do you call the data?
[20:00:10] <alex_joni> I think variables are also members
[20:00:37] <jmkasunich> ok
[20:01:16] <alex_joni> looking at emc.cc:
[20:01:24] <jmkasunich> yep
[20:01:29] <alex_joni> there is a big function: int emcFormat(NMLTYPE type, void *buffer, CMS * cms)
[20:01:41] <alex_joni> which gets called with those 3 params
[20:01:44] <jmkasunich> line 44
[20:01:48] <alex_joni> yup
[20:02:02] <alex_joni> first param is the message_type
[20:02:14] <jmkasunich> that is actually an int, like 112?
[20:02:18] <alex_joni> which is the actual message you want to send
[20:02:33] <jmkasunich> #define EMC_AXIS_SET_HOMING_VEL_TYPE ((NMLTYPE) 112)
[20:02:35] <alex_joni> it's a NMLTYPE (probably a long list of defines)
[20:02:39] <alex_joni> exactly
[20:02:57] <jmkasunich> right - NMLTYPE is just a typedefed int
[20:03:31] <alex_joni> ok now if the type equals one from the case, then the specific update function gets called
[20:03:49] <alex_joni> ((EMC_AXIS_SET_HOMING_VEL *) buffer)->update(cms);
[20:04:03] <jmkasunich> what are buffer and cms?
[20:04:09] <alex_joni> that means that EMC_AXIS_SET_HOMING_VEL::update() gets called
[20:04:16] <alex_joni> buffer is the instantiated class
[20:04:26] <alex_joni> a class by itself is an abstract thing
[20:04:37] <alex_joni> you have during runtime instances of classes
[20:04:52] <alex_joni> those are kinda like pointers to a structure
[20:04:57] <jmkasunich> I thought cms was the instance
[20:05:00] <alex_joni> with all field allocated & stuff
[20:05:16] <jmkasunich> like this:
[20:05:30] <alex_joni> nope, buffer is the allocated class (the instantiated class)
[20:05:38] <jmkasunich> typedef struct { int foo; int bar; } foobar;
[20:05:43] <jmkasunich> foobar is the abstract
[20:05:55] <jmkasunich> static foobar instance;
[20:06:00] <jmkasunich> instance is an instance of foobar
[20:06:04] <jmkasunich> right?
[20:06:06] <alex_joni> right
[20:06:12] <alex_joni> here you have:
[20:06:18] <jmkasunich> so buffer is a pointer to an instance of what>?
[20:06:26] <alex_joni> of a CLASS
[20:06:34] <jmkasunich> which class?
[20:06:39] <alex_joni> just a moment
[20:06:43] <jmkasunich> or don't we know (hence the void)?
[20:06:55] <alex_joni> actually it doesn't really matter ;)
[20:07:04] <alex_joni> it could be EMC_AXIS_SET_HOMING_VEL
[20:07:13] <alex_joni> as the class type
[20:07:23] <jmkasunich> I see - because it gets cast to the appropriate class type in the switch
[20:07:32] <alex_joni> but probably it is EMC_AXIS_CMD_MSG
[20:07:51] <alex_joni> nah... the first one
[20:08:02] <alex_joni> it's EMC_AXIS_SET_HOMING_VEL
[20:08:28] <alex_joni> thing with classes is that you can cast it between ancestors
[20:08:47] <jmkasunich> but there is nothing in *buffer that tells you that (or else you wouldn't need the "type" argument, would you?)
[20:08:52] <alex_joni> like cast this instance (EMC_AXIS_SET_HOMING_VEL) as (EMC_AXIS_CMD_MSG)
[20:08:59] <alex_joni> you can't know directly
[20:09:07] <alex_joni> you need that type
[20:09:33] <alex_joni> even smthg like having a lot of functions int emcFormat(NMLTYPE type, void *buffer, CMS * cms)
[20:09:58] <alex_joni> int emcFormat(EMC_AXIS_SET_HOMING_VEL * buffer,CMS * cms)
[20:10:14] <alex_joni> int emcFormat(EMC_AXIS_SET_INPUT_SCALE * buffer,CMS * cms)
[20:10:15] <alex_joni> etc.
[20:10:21] <alex_joni> this wouldn't work
[20:10:47] <alex_joni> because during runtime it would get more positive matches between castings
[20:10:58] <alex_joni> so you need to take the type approach
[20:11:22] <jmkasunich> buffer points to a block of memory (that's the definition of a void pointer)
[20:11:32] <alex_joni> yeah
[20:11:37] <jmkasunich> in this case, that block contains an instance of a class struct
[20:11:48] <jmkasunich> emcFormat assumes that anyway, right?
[20:11:49] <alex_joni> without the struct :-)
[20:12:12] <alex_joni> assuming the call was authentic
[20:12:37] <alex_joni> I mean the correct things were stated at calling time
[20:12:42] <jmkasunich> well it is something like a struct, but some fields are function pointers instead of data values... they're all just numbers in memory)
[20:13:15] <jmkasunich> seems like an instance of a class can get pretty bulky
[20:13:26] <alex_joni> it can
[20:14:00] <alex_joni> you don't want to look at CMS ;)
[20:14:08] <jmkasunich> but the contents of the block of memory _don't_ tell you all you need to know about it - you still need to know the type
[20:14:25] <alex_joni> yes, but only to make it generic
[20:14:27] <jmkasunich> seems that should be the first item in the block, not another argument
[20:14:34] <alex_joni> e.g. have one single function called
[20:14:56] <jmkasunich> wait-a-minnit
[20:14:58] <alex_joni> you could have that case in the place where emcFormat gets called
[20:15:06] <jmkasunich> is Format building a generic message, or parsing one?
[20:15:13] <alex_joni> parsing
[20:15:25] <alex_joni> definately not building
[20:15:28] <jmkasunich> if its parsing, how does the caller know the type...
[20:15:31] <alex_joni> not sure about parsing either
[20:15:48] <alex_joni> it's only calling the appropiate update function
[20:16:25] <jmkasunich> hmmm... just grepped for emcFormat...
[20:16:39] <alex_joni> me too... didn't find anyone calling it :D
[20:16:42] <jmkasunich> I can't find anywhere where it is actually _called_, it's only passed as a parameter
[20:17:49] <jmkasunich> that means it must be called indirectly
[20:17:49] <jmkasunich> I hate indirect calls - they make things very hard to understand
[20:17:49] <alex_joni> hmmm... but...
[20:17:49] <alex_joni> new RCS_STAT_CHANNEL(emcFormat, "toolSts", "tool", EMC_NMLFILE);
[20:17:57] <jmkasunich> now that I think about it, aren't _all_ member functions called indirectly?
[20:19:25] <alex_joni> RCS_STAT_CHANNEL remembers the f_ptr (pointer to the function) and calls it like that
[20:19:47] <jmkasunich> so the new simply creates and RCS_STAT_CHANNEL
[20:20:07] <jmkasunich> and later, when ? happens, the channel calls emcFormat?
[20:20:10] <alex_joni> the new creates an instantiation of the RCS_STAT_CHANNEL class
[20:20:27] <alex_joni> and the constructor (a function called by new)
[20:20:42] <alex_joni> takes care of copying some values, e.g. function pointer
[20:21:30] <alex_joni> I need a UML graph of these classes ;)
[20:21:33] <alex_joni> I kinda lost it
[20:21:48] <jmkasunich> I was already lost - don't feel bad
[20:21:54] <alex_joni> RCS_STAT_CHANNEL is derived from NML
[20:23:11] <alex_joni> and NML is derived from CMS_USER
[20:23:14] <alex_joni> :-)
[20:25:15] <alex_joni> /******************************************************************
[20:25:34] <alex_joni> oopsy ;)
[20:25:41] <jmkasunich> ;-)
[20:25:42] <alex_joni> got disconnected for flooding
[20:25:48] <jmkasunich> yep
[20:26:01] <jmkasunich> you trying to paste lines from emc source?
[20:26:06] <alex_joni> yeah
[20:26:10] <jmkasunich> just give me filename and linenum
[20:26:13] <jmkasunich> I have an editor open
[20:26:15] <alex_joni> take a look at nml.cc
[20:26:35] <alex_joni> search for: * Constructor for NML:
[20:26:35] <jmkasunich> where is that in the source tree?
[20:26:48] <alex_joni> src/libnml/nml
[20:27:30] <jmkasunich> line 148?
[20:27:36] <alex_joni> could be
[20:27:46] <alex_joni> there is a long description of the constructor
[20:27:56] <jmkasunich> Parameters:L
[20:28:02] <alex_joni> yup
[20:28:02] <jmkasunich> NML_FORMAT_PTR
[20:28:04] <jmkasunich> etc
[20:28:17] <alex_joni> NML_FORMAT_PTR will be a pointer to emcFormat
[20:28:27] <alex_joni> which was the wrong way to look anyway
[20:28:47] <alex_joni> because it's a function that only gets called if one message needs to be formatted
[20:29:02] <alex_joni> in nml.hh:
[20:29:03] <alex_joni> /* nml interface to CMS. */
[20:29:03] <alex_joni> class NML:public virtual CMS_USER {
[20:29:03] <alex_joni> protected:
[20:29:03] <alex_joni> int run_format_chain(NMLTYPE, void *);
[20:29:03] <alex_joni> int format_input(NMLmsg * nml_msg);/* Format message if neccessary */
[20:29:05] <alex_joni> int format_output();/* Decode message if neccessary. */
[20:29:31] <alex_joni> if format_input() is called, then actually at some point emcFormat() gets called
[20:30:10] <alex_joni> oh, btw.I forgot (there can be a lot of constructors to one class)
[20:30:35] <alex_joni> depending of the values you stated at the function call
[20:31:29] <jmkasunich> I feel like an idiot
[20:31:35] <alex_joni> don't
[20:31:41] <jmkasunich> I simply can't wrap my mind around these concepts
[20:31:55] <alex_joni> the concepts are not that complicated,the example you study on is
[20:32:21] <jmkasunich> I'm too literal... I want to be able to look at code and visualize the actual behavior of the CPU
[20:32:37] <jmkasunich> that works for procedural languates, even very high level ones
[20:32:49] <jmkasunich> but for the OO stuff, it's like my mental model just falls apart
[20:33:55] <jmkasunich> if it wasn't for "the example I study on" I would simply avoid the whole thing and stay happily in kernel space where I understand things
[20:34:22] <alex_joni> yeah.. I know how you feel
[20:34:42] <alex_joni> but OO is not that bad, once you start to feel it
[20:35:21] <jmkasunich> there is probably an "ah-ha!" moment (or perhaps several) but I've not gotten there
[20:36:25] <Imperator_> i think i have to study the NML ecplenations at the NIST homepage
[20:36:50] <alex_joni> me too...
[20:38:51] <Imperator_> thanks for the try to explain that stuff Alex
[20:39:09] <Imperator_> i will read it again later
[20:39:15] <alex_joni> do that ;)
[20:40:10] <Imperator_> * Imperator_ is preparing something to eat
[20:59:58] <alex_joni> meep?
[21:00:31] <robin_sz> ah meep indeed
[21:00:51] <robin_sz> are you well
[21:00:59] <alex_joni> yeah..
[21:01:06] <robin_sz> good.
[21:01:20] <alex_joni> hope same over there...
[21:01:25] <robin_sz> * robin_sz nods
[21:01:50] <robin_sz> just got back from a quick couple of hours in the factory
[21:02:08] <robin_sz> powder coating some bits I ran through the press yesterday
[21:02:31] <robin_sz> I really really really need a press of my own :(
[21:04:00] <alex_joni> you said you wanna build one
[21:04:09] <robin_sz> I'll buy the press
[21:04:16] <robin_sz> and add the CNC stuff
[21:04:30] <robin_sz> non-cnc presses are cheap enough
[21:04:55] <Imperator_> about that NML stuff: I think tha main problem is that most users of EMC are good skilled in mechanical things, some also a bit with electronic. But they are no software guys.
[21:05:37] <robin_sz> even the software guys are a bit scared by NML
[21:06:02] <alex_joni> * alex_joni agrees
[21:06:20] <Imperator_> we need a brain dead using guide for that
[21:06:33] <alex_joni> not really
[21:06:35] <robin_sz> no ... we need a better way
[21:06:42] <alex_joni> you need to stay away from it ;)
[21:06:47] <Imperator_> * Imperator_ would like to kick it
[21:07:10] <robin_sz> at the risk of being boring and/or slung off the channel ...
[21:07:25] <Imperator_> but if i want to add a parameter .....
[21:07:42] <robin_sz> yes ... you cant
[21:07:53] <robin_sz> you need a whole new NML message probably
[21:08:10] <robin_sz> and then add that message type to a bazillion places int he code so it can be routed
[21:09:04] <robin_sz> the root of the problem is routing is based on NML types
[21:09:27] <robin_sz> it SHOULD be based on some property of a single NML message type
[21:09:40] <robin_sz> till thats soved, the whole thing is hosed in my opinion
[21:09:44] <robin_sz> * robin_sz shuts up
[21:10:17] <Imperator_> i mean a programmer can't stay away from it
[21:11:21] <alex_joni> * alex_joni thinks a c++ guru can figure things out in a day or two
[21:11:23] <alex_joni> but...
[21:11:35] <alex_joni> where do you get c++ guru's this time a year?
[21:11:37] <robin_sz> it should be possible for a non-programmer to add a button to the GUI, have it send a new message into the core, and have it 'do someting'
[21:11:45] <alex_joni> I agree on that
[21:11:48] <robin_sz> like you can in mach2
[21:12:03] <robin_sz> yes its windows, but some bits are beating us.
[21:12:06] <robin_sz> I hate that :)
[21:12:25] <Imperator_> a c++ guru don't want to build a cnc machine
[21:13:03] <robin_sz> say I build a machine
[21:13:29] <robin_sz> and it has two air rams and a axis to .. I dunno, change a blade or somthing
[21:14:44] <robin_sz> I need to be able to add a button or two to the GUI, add a couple of indicator 'lights' to the Gui and wroite a bit of custom 'code' (some scimple script) to handle aoperating the axos and the rams in the right order, checking switches etc to change the blade
[21:14:55] <robin_sz> that should all be possible without C+= and recompiling
[21:15:02] <robin_sz> C++ even
[21:15:17] <babu> cu
[21:15:56] <robin_sz> a lot of jmkasunich's HAL stuff helps a lot with that
[21:16:25] <robin_sz> the GUI is fixable I guess
[21:16:45] <robin_sz> but the core code is still badly snafu'd in the message passing department
[21:17:36] <robin_sz> * robin_sz shuts up
[21:18:21] <alex_joni> * alex_joni doesn't know enough about message passing between linux and rtpart
[21:21:34] <Imperator_> the funy thing is that emc was writen to demonstrate that RCS and NML is usefull.
[21:22:49] <robin_sz> sigh
[21:22:55] <robin_sz> but written badly
[21:23:05] <robin_sz> the architecture is just so wrong
[21:23:34] <robin_sz> and the C++ is ... well, I suspect it was someones first attempt at C++, and they did it without "The Book"
[21:24:46] <robin_sz> long ago, I cam to the conclusin that a ground-up re-write was its best hope of survival. Apart from the interpreter and some of the RT stuff anyway
[21:25:04] <robin_sz> jmkasunich's HAL stuff has re-written a lot and thats a start
[21:25:39] <Imperator_> mybe that is not the bades idea
[21:26:17] <robin_sz> bades?
[21:26:25] <Imperator_> badest
[21:26:32] <robin_sz> ahh ;0
[21:26:39] <Imperator_> is that a english word ?
[21:26:57] <robin_sz> baddest is ... we'd mnormally say "not the worst idea"
[21:27:29] <Imperator_> ah ok
[21:27:59] <robin_sz> anyway, I have not the time to re-write it myself ..
[21:28:11] <robin_sz> I did start once, but ... well, stuff happened
[21:29:39] <Imperator_> the first step is to find out what is better than the existing one
[21:30:24] <alex_joni> for that you need to have the big picture
[21:30:35] <alex_joni> you need to know what is done presently
[21:30:48] <robin_sz> indeed
[21:31:04] <alex_joni> only after that you can decide what could replace it
[21:31:06] <robin_sz> i spent many long hours tracing it through
[21:31:15] <alex_joni> * alex_joni just started
[21:31:31] <robin_sz> you want my 'day in the life of a message' map?
[21:31:48] <robin_sz> follows a 'spindle on' ,essage all the way through the system
[21:32:27] <Imperator_> do you have written that down ?
[21:32:32] <robin_sz> * robin_sz nods
[21:32:44] <robin_sz> its a bit old now though, the code might have changed
[21:33:47] <alex_joni> robin: care to sketch an overview?
[21:33:53] <Imperator_> it would be interesting to read that
[21:36:17] <robin_sz> alex_joni: message comes in, gets lost in the middle, reappears ;)
[21:36:30] <alex_joni> nice
[21:36:31] <alex_joni> ;)
[21:37:29] <Imperator_> :-)
[21:38:39] <robin_sz> * robin_sz searches for it
[21:38:49] <robin_sz> it was a long time ago ... at least a year
[21:39:19] <robin_sz> let me give you a brief summary of EMC, and my plan
[21:39:24] <robin_sz> current EMC
[21:40:00] <robin_sz> each message is a specific NML message type
[21:40:35] <robin_sz> so when you want to add a NML_foo message, you have to add it all over the code so it can be 'switched' to thte right bit of code
[21:40:46] <robin_sz> in the real world its like posting a letter
[21:40:59] <robin_sz> someone move to a new house,
[21:41:26] <robin_sz> and you have to update every postbox in the country with information, before you can send a letter to them
[21:42:00] <robin_sz> what we shoud have is a single sort of message
[21:42:13] <robin_sz> and we set some properties ...
[21:42:59] <robin_sz> say its a spindle.foo ...
[21:43:24] <robin_sz> things shoudl just go "ahh, spindle message, pass it along to the spindle handler"
[21:43:53] <robin_sz> "ahh, its a spindle.foo message, pass it to the spindle.foo controller"
[21:44:30] <robin_sz> just like the post office, they pass letter to the riht country .. they pass to the right town, they pass to the right postman, they deliver to thw right house ...
[21:45:51] <robin_sz> until we get that sort of flexibilty in EMC, adding new functionality will always be a nightmare
[21:45:57] <robin_sz> * robin_sz shuts up again
[21:48:41] <robin_sz> I'll get told to shut up or write it myself again in a minute :)
[21:48:49] <alex_joni_> lol
[21:48:59] <alex_joni_> nobody seems to be around to tell you that
[21:49:02] <alex_joni_> but...
[21:49:07] <alex_joni_> you could write it yourself
[21:49:19] <robin_sz> i started once
[21:49:53] <robin_sz> but it was too huge a task :(
[21:51:11] <Imperator_> i think we have realy to change something there
[21:51:39] <Imperator_> or we have to find out how it works
[21:51:50] <robin_sz> oh we know how it works
[21:52:27] <robin_sz> its just horrible to think about :)
[21:52:38] <Imperator_> :-)
[21:52:44] <robin_sz> I suspect they started off with a small demo bit of code, and it grew
[21:52:48] <robin_sz> and grew
[21:53:04] <robin_sz> and it was easier to add stuff and try and patch it up than start again
[21:57:32] <alex_joni_> I think when you need to use a code generator to write your code, something is not right
[21:58:11] <Imperator_> jep, that is something that even I know
[22:07:25] <alex_joni_> * alex_joni_ is going to bed
[22:07:30] <alex_joni_> night guys
[22:08:01] <Imperator_> chiao Alex
[22:08:55] <alex_joni_> ciao
[22:21:37] <les> hi robin
[22:22:25] <robin_sz> hi les
[22:22:39] <les> just in from the music room
[22:22:59] <les> the protection relays were cutting out in an amp
[22:23:05] <les> replaced em
[22:23:10] <les> that was it
[22:23:19] <les> the tunes are on again
[22:23:39] <robin_sz> weird ... usually its because Bad Thinga re happenig ... then your hf units explode
[22:24:02] <les> (this is for a 1350 wrms low frequency amp)
[22:24:16] <robin_sz> oh a small one :)
[22:24:39] <les> ha using Altec voice of the theatre horns for hf...they won't explode
[22:24:46] <robin_sz> ah yes
[22:24:58] <les> well up to 5 kHz
[22:25:10] <les> the Audax titanium domes
[22:25:22] <robin_sz> Altec Lansing ... big speakers
[22:25:22] <les> then not the
[22:25:42] <les> just the horns
[22:25:46] <robin_sz> I have Rogers LS5/8a ... nice enough
[22:26:07] <les> but the 1.75 in dome has a 10 lb magnst...
[22:26:11] <robin_sz> nice
[22:26:16] <les> old
[22:26:20] <les> but cool
[22:26:31] <les> just pulled them out of storage
[22:26:36] <robin_sz> I'll dump mine and get something more modern when I have cash
[22:27:01] <les> have 50 ft^3 of speaker in that room ha
[22:27:05] <les> but...
[22:27:23] <les> I used to be a High fidelity design engineer
[22:27:34] <les> so I'm permitted I think
[22:28:14] <les> well anyway a snowy evening here
[22:28:51] <les> just relaxed ...should have tried that 50 up 6 tool change turkey g code
[22:29:06] <les> tommorrow
[22:29:22] <les> have all the custom tool bits in
[22:30:42] <robin_sz> tool changers?
[22:30:49] <robin_sz> you got tool change now?
[22:31:31] <robin_sz> or was that code for 50 turkey calls with only six (manual) tool changes?
[22:31:58] <les> no...that's why I am doing 50 at a time!
[22:32:15] <les> have to amortise out those slow manual changes
[22:32:20] <robin_sz> yip
[22:32:43] <robin_sz> does it run without problem now?
[22:32:46] <les> to make 50 is about two hours
[22:33:05] <les> I have not proofed the program yet
[22:33:09] <robin_sz> about 2 minutes a call?
[22:33:22] <les> yes including tool change
[22:33:43] <les> perhaps a little more depending
[22:34:05] <les> will check out whether I need to climb cut everything
[22:34:17] <les> climb cut=a little slower
[22:35:12] <robin_sz> would more rpm cut faster, or are you up on limits already?
[22:35:32] <les> for this I am severely HP limited
[22:35:59] <robin_sz> did yo bid on that spindle?
[22:36:10] <les> since 75% of the stock=chips
[22:36:23] <robin_sz> the perske
[22:36:41] <les> I took a look but It had a damaged collet
[22:37:07] <les> that could be an easy thing to fix or hard
[22:37:17] <robin_sz> collet or collet holder?
[22:37:22] <les> on ebay mostly caveat emptor
[22:37:29] <les> holder
[22:37:40] <les> it was pranged in some way
[22:37:45] <robin_sz> oopsy
[22:37:57] <les> might be ok...might not
[22:38:09] <les> bad odd for ebay
[22:38:13] <robin_sz> what did it go for?
[22:38:14] <les> odds
[22:38:31] <les> don't know...should check
[22:38:48] <les> cheap prob bevcause it might have been junk
[22:38:57] <les> or ok...
[22:39:21] <robin_sz> thems the breaks
[22:39:29] <les> yup
[22:40:13] <les> but I can make $2 a minute even now....so that will work
[22:40:21] <les> all the rest is finishing
[22:40:49] <les> hired worker for $10/hr...
[22:41:05] <les> could do 60 sandings/hr...
[22:41:25] <les> I will assume half that...30
[22:41:33] <les> (goof off factor)
[22:42:04] <les> $0.33 per sanding
[22:42:13] <robin_sz> sounds about right
[22:42:18] <les> 3 sandings so $1
[22:42:23] <les> i'm ok
[22:42:47] <robin_sz> * robin_sz ndos
[22:42:49] <robin_sz> nods
[22:43:59] <les> 2 min on the machine....2 min sanding....1 min spraying
[22:44:03] <les> $6
[22:44:17] <les> not the best but it will work
[22:44:50] <robin_sz> its not a huge margin, but yes it shold be OK
[22:45:56] <les> $72/hr with 50% goof off factored in
[22:46:02] <les> should work
[22:46:15] <robin_sz> not as good as corporate though :)
[22:46:24] <les> haha no....
[22:46:47] <les> I bill $100...but not too much. Must keep my sanity
[22:47:14] <les> Would go nuts (again) doin that crap full time
[22:47:46] <les> too much corp politics
[22:48:13] <robin_sz> sanity is worht lots in the end
[22:48:22] <les> too much time in court doing intellectual property garebage
[22:48:28] <robin_sz> ick
[22:49:03] <robin_sz> ah well ...
[22:49:09] <les> garebage.....worht... it's typo day I think
[22:49:10] <robin_sz> today was OK,
[22:49:28] <les> work some?
[22:50:01] <robin_sz> I designed some bits on friday, lasered them, bent em, painted em and finally took them to the machine and .. they fitted just perfect.. I ahve this 3D design stuff all worked now :)
[22:50:18] <les> great
[22:50:33] <les> I needed a day in the music room though
[22:51:00] <les> funny it used to be work haha
[22:53:28] <les> cleaned house and brought in a portable compressed air tank from the shop
[22:53:40] <les> just open the door and blast out the dust
[22:53:49] <les> haha beats vacuuming
[22:54:14] <les> lots of dust in the music room tronics
[22:54:29] <robin_sz> ick
[22:54:46] <les> works great for detailing cars too
[22:54:48] <robin_sz> but comp air is a great cleaner
[22:54:54] <les> yup
[22:55:43] <robin_sz> just wear a dust mask
[22:55:58] <les> well...will get back to the music room and play some games with ground loops
[22:56:14] <les> the electronic kind not the aviation kind
[22:56:58] <robin_sz> heh :)
[22:57:08] <les> microvolts of induced hum on signal lines mean big noise with several thousand watts
[22:57:42] <les> move cables around ...break multiple grounds...etc
[22:57:48] <robin_sz> yep
[22:57:55] <les> well later!
[22:58:00] <robin_sz> earthing is simple, once you know the rules
[22:58:03] <robin_sz> * robin_sz waves
[23:00:45] <Imperator_> chiao volks