Back
[00:01:27] -!- aude has quit [Read error: Operation timed out]
[00:03:49] -!- mhaberler has quit [Remote host closed the connection]
[00:03:50] -!- logger[mah]_ has quit [Remote host closed the connection]
[00:03:56] -!- logger[mah] [logger[mah]!~loggermah@ns2.mah.priv.at] has joined #linuxcnc-devel
[00:04:07] -!- mhaberler [mhaberler!~mhaberler@213-33-16-125.adsl.highway.telekom.at] has joined #linuxcnc-devel
[00:11:42] hdokes|werkin is now known as hdokes
[00:25:23] -!- Nick001-Shop has quit [Ping timeout: 252 seconds]
[00:25:38] Nick001-Shop_ is now known as Nick001-Shop
[00:28:54] -!- neverho02 has quit [Ping timeout: 240 seconds]
[00:29:40] -!- mhaberler has quit [Ping timeout: 248 seconds]
[00:33:51] zz_satyag is now known as satyag
[00:38:56] satyag is now known as zz_satyag
[00:40:40] -!- bradsimantel has quit [Quit: bradsimantel]
[00:43:18] hdokes is now known as hdokes|werkin
[00:46:24] -!- erictheise has quit [Quit: erictheise]
[00:55:26] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:55:39] -!- asdfasd has quit [Ping timeout: 260 seconds]
[00:57:24] hdokes|werkin is now known as hdokes
[01:31:41] -!- rob__H has quit [Ping timeout: 255 seconds]
[01:40:14] -!- adb has quit [Ping timeout: 240 seconds]
[01:52:43] hdokes is now known as hdokes|werkin
[01:53:17] -!- neverho01 has quit [Ping timeout: 255 seconds]
[01:53:28] -!- ve7it has quit [Remote host closed the connection]
[02:00:29] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[02:00:29] -!- ybon has quit [Quit: WeeChat 0.3.8]
[02:08:02] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:22:43] -!- FinboySlick has quit [Quit: Leaving.]
[02:26:19] -!- pjm__ has quit [Read error: Connection reset by peer]
[02:36:16] -!- andypugh has quit [Quit: andypugh]
[03:12:46] -!- Nitrus^ has quit [Quit: Leaving.]
[03:20:37] zz_satyag is now known as satyag
[03:41:20] -!- ryan_ has quit [Quit: Leaving]
[03:47:30] -!- archivist has quit [Ping timeout: 264 seconds]
[03:51:12] -!- tjb1 has quit [Ping timeout: 264 seconds]
[03:51:14] tjb1_ is now known as tjb1
[03:53:24] -!- c60 has quit [Quit: leaving]
[04:08:25] -!- Keknom has quit [Quit: Leaving.]
[04:23:50] -!- Loetmichel has quit [Ping timeout: 252 seconds]
[04:31:02] -!- pjm has quit [Read error: Connection reset by peer]
[04:37:37] -!- skunkworks has quit [Ping timeout: 265 seconds]
[05:09:53] -!- tayy has quit [Remote host closed the connection]
[05:22:28] -!- automata_ has quit [Read error: Connection reset by peer]
[05:38:07] -!- Connor has quit [Ping timeout: 246 seconds]
[06:01:04] -!- dhoovie has quit [Ping timeout: 246 seconds]
[06:02:07] -!- jmkelly has quit [Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032]]
[06:02:14] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:12:07] satyag is now known as zz_satyag
[06:13:48] -!- bradsimantel has quit [Quit: bradsimantel]
[06:35:58] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[06:37:43] -!- Cylly has quit []
[06:46:29] -!- ve7it has quit [Remote host closed the connection]
[06:48:19] -!- dhoovie has quit [Ping timeout: 246 seconds]
[07:03:01] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[07:03:14] -!- kwallace1 [kwallace1!~kwallace@smb-250.sonnet.com] has joined #linuxcnc-devel
[07:05:30] -!- kwallace has quit [Ping timeout: 264 seconds]
[07:10:38] -!- mhaberler [mhaberler!~mhaberler@178-191-190-80.adsl.highway.telekom.at] has joined #linuxcnc-devel
[07:19:18] -!- MattyMatt has quit [Ping timeout: 264 seconds]
[07:25:34] -!- tjb1 has quit [Remote host closed the connection]
[07:26:41] -!- ink- has quit [Ping timeout: 245 seconds]
[07:26:54] -!- fatpandas has quit [Ping timeout: 240 seconds]
[07:32:47] -!- tjb1 has quit [Quit: tjb1]
[07:38:59] theos is now known as Guest15965
[07:41:50] -!- Guest15965 has quit [Ping timeout: 252 seconds]
[07:46:31] -!- kmiyashiro has quit [Quit: kmiyashiro]
[07:47:29] -!- kwallace1 [kwallace1!~kwallace@smb-250.sonnet.com] has parted #linuxcnc-devel
[07:50:31] -!- Poincare has quit [Ping timeout: 260 seconds]
[07:52:20] -!- archivist_herron has quit [Ping timeout: 248 seconds]
[07:55:03] zz_satyag is now known as satyag
[08:02:49] satyag is now known as zz_satyag
[10:26:49] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[10:31:52] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[10:45:40] -!- alpha1125 has quit [Ping timeout: 250 seconds]
[10:54:48] -!- mhaberler has quit [Read error: Connection reset by peer]
[11:10:03] -!- mhaberler [mhaberler!~mhaberler@089144206029.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[11:24:32] jthornton_ is now known as jthornton
[11:27:59] -!- archivist_herron has quit [Ping timeout: 260 seconds]
[11:28:02] -!- mhaberler has quit [Read error: Connection reset by peer]
[11:50:56] -!- the_wench has quit [Ping timeout: 240 seconds]
[11:52:52] -!- archivist has quit [Ping timeout: 248 seconds]
[12:48:52] -!- putnik has quit [Ping timeout: 248 seconds]
[12:50:59] -!- putnik has quit [Changing host]
[12:54:44] -!- the_wench has quit [Ping timeout: 248 seconds]
[12:56:30] -!- archivist has quit [Ping timeout: 264 seconds]
[13:37:35] -!- Thetawaves has quit [Ping timeout: 259 seconds]
[13:42:42] -!- psha[work] has quit [Quit: Lost terminal]
[14:04:10] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[14:04:10] -!- archivist_herron has quit [Ping timeout: 255 seconds]
[14:17:29] -!- hdokes|werkin has quit [Ping timeout: 255 seconds]
[14:31:54] -!- MattyMatt has quit [Ping timeout: 264 seconds]
[14:33:59] -!- synrat has quit [Remote host closed the connection]
[14:46:26] -!- automata_ has quit [Ping timeout: 252 seconds]
[14:56:02] -!- Wildhoney has quit [Ping timeout: 276 seconds]
[14:56:43] -!- vladimirek has quit [Remote host closed the connection]
[15:03:11] -!- syyl has quit [Read error: Connection reset by peer]
[15:12:18] -!- riz_ [riz_!457c0137@gateway/web/freenode/ip.69.124.1.55] has joined #linuxcnc-devel
[15:17:57] -!- acdha has quit [Quit: Leaving...]
[15:25:04] -!- rasher has quit [*.net *.split]
[15:25:04] -!- Ekken has quit [*.net *.split]
[15:25:04] -!- ciluu has quit [*.net *.split]
[15:26:04] -!- JT-Shop has quit [Read error: No buffer space available]
[15:26:06] -!- Ekken [Ekken!ekke@hilla.kapsi.fi] has joined #linuxcnc-devel
[15:26:30] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[15:27:15] <riz_> I am having a little trouble understanding hal_export_funct(). The thing I dont understand is how the function is identified so that it can be used or called somewhere else. One example is in hal_motenc.c, which says: halError = hal_export_funct(name, Device_DacWrite, this, 1, 0, componentId)
[15:28:33] <riz_> What in that hal__export_funct() call tells you how to use/call the function Device_DacWrite?
[15:28:56] -!- emel has quit [Ping timeout: 240 seconds]
[15:30:55] -!- rasher has quit [*.net *.split]
[15:30:55] -!- Ekken has quit [*.net *.split]
[15:30:55] -!- ciluu has quit [*.net *.split]
[15:32:01] -!- Ekken [Ekken!ekke@hilla.kapsi.fi] has joined #linuxcnc-devel
[15:35:53] <riz_> I am assuming that the 'name' is used int he ini file
[15:36:21] <riz_> I just dont know how they specify what the unique "name" is
[15:37:57] -!- adb [adb!~IonMoldom@178-211-235-11.dhcp.voenergies.net] has joined #linuxcnc-devel
[15:53:50] -!- phillipadsmith has quit [Remote host closed the connection]
[15:53:50] -!- beawesomeinstead has quit [Remote host closed the connection]
[15:53:51] -!- bartek_ has quit [Remote host closed the connection]
[15:56:40] zz_satyag is now known as satyag
[16:01:51] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[16:05:55] -!- zzolo has quit [Quit: zzolo]
[16:07:01] -!- Delysid has quit [Ping timeout: 244 seconds]
[16:15:47] -!- wboykinm has quit [Remote host closed the connection]
[16:17:50] -!- bmwyss has quit [Quit: bmwyss]
[16:18:55] -!- kmiyashiro has quit [Quit: kmiyashiro]
[16:38:35] <riz_> I would like to know what is the difference between using the HAL function addf and the function add_funct_to_thread?
[16:40:59] <riz_> Is it that the function call is only used if something needs to be added to a thread in run-time code whereas the HAL call is for initialization?
[16:41:18] <riz_> It doesnt seem like add_funct_to_thread is ever used...
[16:42:47] <seb_kuzminsky> riz_: did you look at the documentation for hal_export_funct()?
[16:43:15] <seb_kuzminsky> man hal_export_funct
[16:44:31] <riz_> Yes, I see that it is a call to be used after hal_export_funct(), but I dont see it ever being used
[16:44:43] <seb_kuzminsky> 'addf' is a command in the 'halcmd' utility, which handles our .hal files at startup
[16:44:47] <riz_> It seems that the addf HAL call takes care of this upon initialization
[16:45:06] <seb_kuzminsky> when halcmd gets an addf command from the .hal file, it calls hal_add_funct_to_thread()
[16:45:13] <seb_kuzminsky> this is in src/hal/utils/halcmd_command.c
[16:45:38] <riz_> Ohh, yes. I see
[16:48:20] <riz_> Actually, I see the hal
[16:48:33] <riz_> ...hal_add_funct_to_thread
[16:48:52] <riz_> but I still dont see where add_funct_to_thread is used
[16:49:11] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[16:50:04] <seb_kuzminsky> i don't think there's a function called "add_funct_to_thread()". I only know about "hal_add_funct_to_thread()". Where do you see add_funct_to_thread()?
[16:50:22] <seb_kuzminsky> or maybe i'm misunderstanding your question
[17:01:54] -!- Simon2 has quit [Ping timeout: 240 seconds]
[17:03:12] -!- r00t4rd3d has quit [Ping timeout: 252 seconds]
[17:05:47] -!- rogge [rogge!~rogge@mail.tormach.com] has joined #linuxcnc-devel
[17:06:09] <seb_kuzminsky> hi rogge
[17:06:36] -!- abetusk has quit [Quit: Leaving]
[17:07:05] <riz_> No, you are right, I just documented it in my notes incorrectly
[17:07:10] <riz_> sorry
[17:07:23] <seb_kuzminsky> heh no problem
[17:07:36] -!- soooge has quit [Max SendQ exceeded]
[17:09:06] <rogge> Hi seb!
[17:09:57] <seb_kuzminsky> how are things at tormach these days? :-)
[17:10:06] <rogge> Very busy!
[17:10:10] <seb_kuzminsky> good!
[17:10:38] <seb_kuzminsky> how is linuxcnc working out for you all so far?
[17:10:50] <rogge> I love it...
[17:11:08] <rogge> It's been really wonderful to work with...
[17:11:19] <seb_kuzminsky> cool, glad to hear it
[17:11:54] <rogge> I'm hoping for a bit of advice...
[17:12:11] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[17:12:25] <rogge> I'd trying to come up with the best way to start LCNC in whichever G20/21 mode was current when the machine was shut down.
[17:12:38] <seb_kuzminsky> hm
[17:13:02] <seb_kuzminsky> you can set a single value as the default in the .ini file, but it doesn't change when the user changes it
[17:13:26] <rogge> Yeah - plus we don't hav the kind of users who want to poke around in ini files.
[17:13:38] <seb_kuzminsky> heh
[17:13:58] <seb_kuzminsky> if you're on 2.6 (aka the master branch) you could do this kind of gross thing
[17:14:24] -!- soooge has quit [Max SendQ exceeded]
[17:14:39] <seb_kuzminsky> remap G20/G21 to your own function, and have that function save the value that the user selects (imperial or metric) to a file (or maybe to a numbered parameter)
[17:14:48] <seb_kuzminsky> then at startup... somehow read that and restore the setting
[17:14:51] <rogge> Hmmm....
[17:14:59] <seb_kuzminsky> not sure how that second step would work :-/
[17:15:12] <rogge> saving the value is easy enough (we're using redis to save off a bunch of other data - thanks MAH!)
[17:15:21] <seb_kuzminsky> cool
[17:15:22] <rogge> but that restore business is tricky
[17:15:39] <rogge> It seems clean enough to do it via an MDI command,
[17:15:50] <seb_kuzminsky> you could use halui to define an mdi command, and have the hal file trigger it at load time
[17:15:57] <rogge> But of course that requires that the machine is up
[17:16:18] <seb_kuzminsky> it'd happen early in the startup of linuxcnc, before the user started using the machine
[17:16:47] <rogge> can't do mdi before that machine state I think.
[17:17:18] <seb_kuzminsky> right, you can't do mdi before homing
[17:17:34] <seb_kuzminsky> and afaik there's no way to "force home at startup"
[17:17:38] <seb_kuzminsky> which is probably a good thing
[17:17:46] <seb_kuzminsky> the user should command that motion explicitly
[17:18:08] <seb_kuzminsky> so the mdi way won't work, sounds like you'll have to modify linuxcnc itself
[17:18:12] <rogge> I think I've got a kludge...
[17:18:39] <rogge> I'll try it out and let you know if it worked...
[17:18:57] -!- gmouer has quit []
[17:19:36] <cradek> whether g92 offset is in effect is saved in the var file. you could do something similar to that.
[17:21:04] <cradek> if a user asked for this though, I'd want to know why they think they want it. often they are confused about what g20/g21 means and doesn't mean (for instance they don't affect the coordinate readouts)
[17:22:29] <rogge> in our implementation the G20//21 status does change the readouts.
[17:22:39] <cradek> if they've got different gcode programs with different units that don't specify g20/g21 those programs are broken
[17:22:40] <seb_kuzminsky> the DRO is always in the machine's native units, right? (aka "user units")
[17:23:22] <cradek> seb_kuzminsky: no, you can change it with a gui setting in at least axis and touchy
[17:23:32] <seb_kuzminsky> oh, ok
[17:24:03] <seb_kuzminsky> a/msg cradek i guess we should ask for access to their branches?
[17:24:10] <seb_kuzminsky> heh oops
[17:24:21] <cradek> rogge: ouch. I think that's a really bad idea. just because you're running gcode in g21 doesn't mean your calipers changed to metric. you'll be unable to use touch off without dancing around, for instance
[17:24:30] <cradek> seb_kuzminsky: hahaha
[17:24:39] * cradek points at seb_kuzminsky
[17:25:02] <seb_kuzminsky> rogge: can we see your linuxcnc branches?
[17:25:09] <seb_kuzminsky> ;-)
[17:25:16] <rogge> of course...
[17:25:24] <rogge> can I ask one small favor...
[17:25:44] <rogge> let us finish development (should be closer in two weeks time)
[17:25:56] <seb_kuzminsky> fine by me
[17:27:44] -!- soooge has quit [Max SendQ exceeded]
[17:28:56] -!- mackerski has quit [Quit: mackerski]
[17:29:33] <cradek> we carefully separated the three kinds of units: the units the machine's screws are calibrated in, the units the user's eyes and tools are calibrated in, and the units the gcode programmer used (often part units)
[17:30:00] <cradek> these can all be different and when you swirl them together I think you get something worse
[17:30:26] <cradek> (often all three are the same, of course)
[17:31:07] satyag is now known as zz_satyag
[17:31:53] <rogge> If nasa has a hard time keeping track I'm sure we'll manage to make mistakes as well.
[17:32:10] <cradek> long ago in emc history they were all swirled together, and things were strange: even tool lengths and offsets changed by 25.4 when you changed units.
[17:32:33] <cradek> so the advice was to have T1 with length 1 and T2 with length 25.4 and use the right one depending on what units you were in... same for offsets.
[17:33:02] <cradek> I unswirled all of that
[17:34:44] <cradek> ok, rant over
[17:35:03] <cradek> cradek: not everyone has to agree with you, you know
[17:35:18] <rogge> ha!
[17:35:48] <rogge> I like the idea of being able to switch DRO readout units on G20/21 modality switch
[17:35:57] <rogge> but I can see how a separate setting might seem safer to some
[17:36:24] <cradek> g20/g21 don't stop readahead when running a program do they?
[17:36:46] <rogge> I don't think so...
[17:37:04] <rogge> Are you hinting at a conflict between machine and interp time on a G20/21 switch?
[17:37:45] <cradek> well aside from thinking swirling them together is a bad design, I think you have an implementation problem in that the dro will change back and forth at seemingly-crazy times
[17:38:06] <rogge> agreed if there are programs that mix the two.
[17:38:36] <cradek> it would be sad to break the ability to have such programs
[17:39:14] <rogge> it would be great to have a hook into interp status that occured in motion time.
[17:39:35] <cradek> well in reality they'd still run, but your gui would appear to be crazy
[17:39:38] -!- soooge has quit [Max SendQ exceeded]
[17:40:01] <cradek> yes I agree that would be very nice.
[17:40:57] <cradek> I've been tempted to move the whole interp into realtime for that reason, and run in lock-step
[17:41:13] <cradek> but of course that's pretty darn impossible now that we have subroutines and such
[17:42:02] <rogge> I though you and Michael discussed this a few months back?
[17:42:10] <rogge> virtual paper tape?
[17:43:07] <cradek> yeah we've thrown around new design ideas
[17:44:40] <cradek> VPT is about unrolling the program into the flattest simplest gcode-like language possible... but that language probably wouldn't know about units other than native
[17:45:19] <cradek> either way, that wouldn't help you with your current task, though. you have to use the implementation that exists in the real world :-)
[17:45:32] <rogge> true!
[17:46:04] <cradek> I love the term "reality-based community" that's being thrown around in politics now
[17:46:25] <cradek> I am a member :-)
[17:47:30] <rogge> at least in this community we can change things with relative ease...
[17:47:30] -!- kwallace [kwallace!~kwallace@smb-153.sonnet.com] has joined #linuxcnc-devel
[17:47:46] <rogge> hi kirk
[17:51:48] -!- soooge has quit [Excess Flood]
[17:51:56] -!- Wildhoney has quit [Ping timeout: 245 seconds]
[17:53:56] <kwallace> Good Morning
[17:57:04] <kwallace> I'm working on front and back OD turn.
[17:57:50] <cradek> kwallace: you mean X mirroring?
[17:58:24] <rogge> cradek: kirk is doing some work for Tormach on conversational programming
[17:58:42] <rogge> I'm off to lunch...
[17:58:47] <rogge> bbl
[17:58:57] -!- rogge has quit [Remote host closed the connection]
[17:59:58] <kwallace> bon appétit
[18:04:45] <kwallace> cradek: What's X mirroring?
[18:05:17] <cradek> I was going to ask you that :-)
[18:05:55] <cradek> as I picture it, if you load a tool that's on the back side of the work, you wouldn't have to program it in negative X coordinates ... somehow
[18:06:43] <cradek> bbl
[18:06:50] <kwallace> I just need to make a script that can deal with turning an OD on the plus or minus side of the spindle axis.
[18:09:19] -!- Delysid has quit [Ping timeout: 244 seconds]
[18:10:56] -!- JT-Shop-2 [JT-Shop-2!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[18:10:57] -!- JT-Shop has quit [Read error: Connection reset by peer]
[18:12:30] -!- Wildhoney has quit [Ping timeout: 276 seconds]
[18:27:59] -!- tronwizard has quit [Ping timeout: 260 seconds]
[18:30:06] -!- zzolo has quit [Ping timeout: 252 seconds]
[18:34:15] <riz_> In the .ini file under the section [EMCMOT] it says EMCMOT = motmod. And in section [EMCIO] it specifies EMCIO = io. Where are these programs (motmod and io)?
[18:34:50] <seb_kuzminsky> src/emc/motion and src/emc/iotask, i think
[18:36:02] <riz_> I looked there, but I could not find them
[18:36:20] <riz_> I found motmod referenced in a hal_init("motmod") in motion.c. But I dont see where motmod is...
[18:37:15] <riz_> I also see a hal_init("iocontrol") in iocontrol.cc
[18:37:48] <seb_kuzminsky> grep for motmod in src/Makefile, you'll see the object files that are linked together to make it
[18:39:42] <seb_kuzminsky> and in src/emc/iotask/Submakefile, you'll see that it's ioControl.cc (and some other stuff) that makes the program 'io' that the .ini snippet you mentioned above uses
[18:40:42] <riz_> ahhhh yes. I see now. So motmod is an object that is combines all the main motion programs
[18:41:08] <riz_> and the same for io
[18:41:17] <seb_kuzminsky> motmod is an executable that implements the motion control part of linuxcnc
[18:41:38] <riz_> ok. understoofd
[18:42:17] <seb_kuzminsky> this is the best diagram we have to explain the architecture, it may be a little out of date but it's mostly right:
[18:42:21] <seb_kuzminsky> http://www.linuxcnc.org/docs/2.5/html/code/Code_Notes.html#_architecture_overview
[18:43:12] <riz_> got it!
[18:44:28] -!- alpha1125 has quit [Quit: Computer has gone to sleep.]
[18:44:56] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[18:46:22] <riz_> does ioControl_v2 supersede ioControl?
[18:48:18] <seb_kuzminsky> i think both are available as options. ask mhaberler, i think he knows
[18:49:23] <mhaberler> it has a bit more functionality, but I never documented it
[18:49:48] <mhaberler> because that overlapped with the remapping functionality, so there isnt much point
[18:50:12] <riz_> So there isnt really any point for me to use it i guess??
[18:50:20] <mhaberler> you can do everything iov2 added with a remap, just more flexible
[18:50:21] <mhaberler> yes
[18:50:33] <seb_kuzminsky> are you planning to remove iov2?
[18:50:40] <seb_kuzminsky> or is there some reason to keep it?
[18:50:54] <mhaberler> I have the suspicion some folks use it
[18:51:20] <mhaberler> well I dont think it is a good idea to force them to change to a remapping config if they do
[18:51:44] <seb_kuzminsky> bummer
[18:53:06] <mhaberler> I would think other pieces of work should go more urgently, like the tcl UI's - these in essence stop fixing the tooltable mechanism
[18:53:34] <mhaberler> or we can bring someone back from retirement to fix emcstatus access in tcl
[18:54:57] <mhaberler> btw how did your fix turn out, is that done?
[18:55:01] <seb_kuzminsky> and we should spin off a sub-committee to work on advancing the TCL languate while we're at it
[18:55:14] <seb_kuzminsky> the fix is not done yet...
[18:55:16] -!- soooge has quit [Quit: Leaving]
[18:55:20] <seb_kuzminsky> i keep finding more bugs :-/
[18:55:33] <mhaberler> oh, so you're really on the case
[18:55:43] tetjerk is now known as P46_
[18:55:50] <seb_kuzminsky> i'm still working on it
[18:55:57] <mhaberler> did you actually look at the tcl emcstat bindings too?
[18:55:58] <riz_> This may be a dumb question, but I see the following in the io submake file: ../bin/io: $(call TOOBJS, $(IOSRCS)) ../lib/liblinuxcnc.a ../lib/libnml.so.0 ../lib/liblinuxcnchal.so.0 ../lib/liblinuxcncini.so.0
[18:56:06] <riz_> What are these files that are being referred to?
[18:56:07] <mhaberler> yes
[18:56:12] <seb_kuzminsky> mhaberler: no, i'm allergic to tcl
[18:56:15] <mhaberler> the .so files?
[18:56:21] <riz_> yes
[18:56:23] <mhaberler> I'll buy you a drink
[18:56:25] <riz_> and .a
[18:56:33] <mhaberler> riz: those are shared libraries
[18:56:42] <mhaberler> nml, HAL access, ini file access
[18:56:45] <seb_kuzminsky> riz_: those are the object files and libraries that are linked together to make the io executable
[18:57:11] <riz_> where are they found?
[18:57:19] <mhaberler> in lib
[18:57:20] <seb_kuzminsky> riz_: in ../lib
[18:57:23] <seb_kuzminsky> heh
[18:57:40] <riz_> I looked there but maybe I am looking in the wrong spot
[18:57:41] <seb_kuzminsky> oh, relative to the src directory
[18:57:46] <riz_> yes
[18:57:53] <seb_kuzminsky> so it's in the root dir of the checkout
[18:58:06] <seb_kuzminsky> those are generated files, they won't exist unless you've built the software
[18:58:40] <riz_> where are they generated from is my question i guess?
[18:59:01] <seb_kuzminsky> other places in src
[18:59:06] <mhaberler> well cnchal… in hal/ - see the Submakefile there for instance
[18:59:07] <seb_kuzminsky> you'll have to trace the makefiles
[18:59:25] <riz_> ok thanks
[18:59:39] <mhaberler> we suffer with you - it is quite confusing to trace whats happening during a build
[18:59:53] <riz_> yes it is haha
[19:00:17] <mhaberler> seb: I would be interested to see if your fixes have any fallout on the tcl ui's
[19:00:42] <mhaberler> do we actually know somebody is using those?
[19:01:46] <mhaberler> I mean to really fix the tt issue we need to rework emcstatus, so we need to find somebody who can fix the tcl parts or dump them
[19:02:12] <seb_kuzminsky> my changes are all in interp and below
[19:02:41] <seb_kuzminsky> but of course the bugs are visible up in the ui
[19:02:45] <seb_kuzminsky> so that goes away
[19:02:52] <mhaberler> do you modify any interpretation of emcstatus.tooltable?
[19:04:35] <seb_kuzminsky> yeah, some of the code in interp and canon were using the tooltable wrong
[19:05:17] <mhaberler> are you modifying emcstatus at some point?
[19:05:33] <mhaberler> reword: will you be ..
[19:05:39] <seb_kuzminsky> i'm not changing the emcstatus structure itself, if that's what you're asking
[19:05:47] <mhaberler> yes, thats what I meant
[19:05:50] <seb_kuzminsky> i'm chaning a little bit how it's used in a few places
[19:06:07] <seb_kuzminsky> but i'm not adding or removing any fields
[19:06:16] <mhaberler> then you get to keep the tcl uis ;)+
[19:06:25] <seb_kuzminsky> ugh :-/
[19:06:47] <seb_kuzminsky> this is the problem with writing software: people use it, and then we're stuck with it ;-)
[19:07:22] <mhaberler> I would be interested how much that is still used (like tkemc)
[19:07:41] <seb_kuzminsky> or keystick? :-)
[19:08:13] <seb_kuzminsky> sometimes i wish we had something like the debian 'popularity-contest' program, that reports back to the devs what parts of the sw are actually getting used
[19:08:22] -!- Delysid has quit [Ping timeout: 246 seconds]
[19:08:28] <seb_kuzminsky> bbl, lunch
[19:08:30] <mhaberler> cu
[19:09:37] <mhaberler> I understand Colorado is chipping in, too:
http://mah.priv.at/gallery2/main.php?g2_itemId=39272
[19:16:20] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[19:16:24] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 16.0.2/20121025205401]]
[19:19:20] -!- jthornton has quit [Read error: Connection timed out]
[19:20:57] <riz_> in the task module submake file it seems that they disable iotaskintf.c. Why is it not being included?
[19:21:09] -!- yuvipanda has quit [Ping timeout: 265 seconds]
[19:21:10] yuvipanda_ is now known as yuvipanda
[19:27:45] <mhaberler> you mean emc/task/Submakefile ?
[19:31:21] <mhaberler> if you look at taskclass.cc you see that that functionality is subsumed there and can be switched to Python callouts ; see configs/sim/remap/iocontrol-remove how that could be used; this would in essence remove the need for iocontrol altogether
[19:34:45] <riz_> yes
[19:35:25] -!- elk [elk!ae2c7071@gateway/web/freenode/ip.174.44.112.113] has joined #linuxcnc-devel
[19:36:04] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[19:36:09] <mhaberler> you're doing some serious codereading!
[19:36:55] <riz_> Hahah. I am trying to fully understand this. It looks like it would be fun if I could understand it and try and manipulate it
[19:37:12] <riz_> I dont quite understand you last comment though
[19:38:13] <riz_> Do you mean that it is basically within taskclass.cc?
[19:38:31] <mhaberler> yes
[19:38:51] <mhaberler> iotaskintf.cc has some free functions
[19:38:51] <mhaberler> +
[19:39:17] -!- maximilian_h [maximilian_h!~bonsai@f051197043.adsl.alicedsl.de] has joined #linuxcnc-devel
[19:39:28] -!- maximilian_h has quit [Client Quit]
[19:39:29] <mhaberler> those are methods in taskclass and if no Python instance of that class is instantiated, they are used; else the Python callouts override them
[19:39:30] <riz_> And a very general question...Why are we even using python? What is the need for it?
[19:40:07] <riz_> Is it possible to strip away Python completely?
[19:40:34] <mhaberler> because by opening these API's you make it possible to restructure the code, for instance get rid of iocontrol
[19:41:29] <riz_> What API's? Sorry for my ignorance :(
[19:41:42] <mhaberler> application programming interface
[19:42:00] <riz_> No I meant whic API's
[19:42:20] <mhaberler> basically the CustomTask module in the example I referred to enables you to customize what iocontrol does
[19:42:20] <riz_> What are we interfacing to?
[19:42:48] <mhaberler> between task and iocontrol, and in reality there isnt a very good reason to have iocontrol to start with
[19:43:02] <mhaberler> which is why I introduced this API
[19:44:18] <riz_> I might have missed that CustomTask module you referred to...
[19:44:33] <riz_> Where is that?
[19:44:35] <mhaberler> what before was some C module which nobody touches becomes amenable to integrator adaptation - many more people can modify Python than write C
[19:44:49] <mhaberler> somewhere there: configs/sim/remap/iocontrol-remove
[19:44:53] <mhaberler> let me see
[19:45:50] -!- tjb1 has quit [Quit: tjb1]
[19:46:14] <mhaberler> right, configs/sim/remap/iocontrol-removed/python/customtask.py
[19:47:07] <mhaberler> if you look at that you will find for instance emcIoInit(self): which happens to use a completely different storage mechanism than iocontrol
[19:47:27] <mhaberler> in that case I used an SQL db as example
[19:48:11] <mhaberler> you could slide in _any_ storage mechanism at this point and the rest of LinuxCNC need not know (except for the tooltable editor)
[19:50:46] <mhaberler> while not touching a line of C
[19:52:10] <riz_> hmmm
[19:52:23] <elk> interesting discussion, it says that iocontrol's purpose is to accept NML messages sent to the IO controller and output those to a HAL pin. Is that really the only purpose?
[19:52:38] <mhaberler> pretty much so
[19:53:06] <mhaberler> if you look at customtask you will find that pin wiggling is done with a few lines of python
[19:54:30] <mhaberler> so you gain two things: separate policy from mechanism ('need to store' vs 'how to store') and dont embed that in (more or less immutable) C, and you enable integrator choice
[19:56:17] <elk> Oh ok, and how does this interface with the real-time stuff? I'm assuming since there is python involved that it isn't involved with anything that requires real-time
[19:56:35] <mhaberler> how often do you change tools?
[19:56:40] <mhaberler> that often
[19:56:53] <mhaberler> so there is no RT requirement here
[19:57:24] <mhaberler> you definitely dont want to do a stepper or encoder in Python for production
[19:57:49] <mhaberler> the common interface is HAL pins
[19:59:46] -!- syyl_ws has quit [Quit: Verlassend]
[20:00:35] <elk> I thought if you were monitoring certain inputs for the PLC that iocontrol would be involved, not just slow tasks like changing tools, but any fast input (sensor or something)
[20:01:17] <mhaberler> plc and iocontrol are involved only through connected pins
[20:01:34] <seb_kuzminsky> elk: io has no realtime stuff in it, never has
[20:01:38] <seb_kuzminsky> http://www.linuxcnc.org/docs/2.5/html/code/Code_Notes.html#_architecture_overview
[20:02:07] <seb_kuzminsky> the only thing inside the realtime box in that diagram is Motion
[20:02:09] <mhaberler> and those would like be the tool number and -prepare/prepared and change/changed
[20:04:21] <elk> oh ok, so the I/O that come from the break-out boards (not the encoder feedback) are included under "Motion" not IO in the diagram? Or are they just slow I/O as well
[20:05:20] <mhaberler> the distinction isnt really speed
[20:05:21] <seb_kuzminsky> elk: the encoders and limit switches go straight into the motion controller
[20:05:41] <elk> ok great
[20:05:42] JT-Shop-2 is now known as JT-Shop
[20:06:03] <mhaberler> you have say feed hold go into motion (slow) and tool-changed go into iocontrol (slow too)
[20:06:38] <mhaberler> lets call it 'functional aggregates' (BS bingo!)
[20:07:34] <elk> hah ok
[20:14:12] -!- jp_ has quit [Read error: Connection reset by peer]
[20:14:38] -!- jthornton has quit [Read error: Connection reset by peer]
[20:15:07] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:15:45] <elk> So for real-time motion stuff, the breakout boards basically take the motion commands from a buffer or shared memory in real-time? A future plan would be to communicate with drives over ethernet. If that is the case then it would be simple to just take the commands from the buffer (the ones from the PID prior to the DAC conversion) and send them as packets through ethernet. Has anyone attempted this or am I wrong with how the ou
[20:15:57] -!- alpha1125 has quit [Ping timeout: 252 seconds]
[20:17:55] <seb_kuzminsky> not quite
[20:18:24] <seb_kuzminsky> the motion planner decides where it wants the machine to be at *this* moment, and it presents that information on a bunch of HAL pins
[20:18:52] <seb_kuzminsky> those hal pins are read by the stepgen component (for steppers) or the pid component (for servos)
[20:18:55] <andypugh> ethernet is not so future as all that, it is actively being worked on at the moment.
[20:19:19] <seb_kuzminsky> the output of those components gets sent to the motor drivers
[20:19:30] <riz_> Has anyone looked into Ethercat?
[20:19:31] -!- jthornton has quit [Read error: Connection reset by peer]
[20:20:05] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[20:20:21] <seb_kuzminsky> sometimes the signals from the stepgen component go back to HAL and get routed to an i/o pin (like a parallel port) via another component (parport in this case)
[20:20:26] <andypugh> Yes, there has been some work done on EtherCAT, but I seem to recall some woerd licence thing. (or is that some other protocol?)
[20:20:52] <seb_kuzminsky> sometimes the stepgen is tied to its own i/o pins (as in the case of mesa hostmot2 hardware stepgens and I think ppmc hardware too)
[20:21:28] <seb_kuzminsky> once the signal makes it out of the control computer's i/o pins it can go to a breakout board or a motor driver
[20:21:46] <andypugh> riz_:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EtherCatDriver (Not sure if it works, or got finished, or if it is the only attempt)
[20:22:08] <riz_> Interesting...
[20:22:37] <andypugh> But I was actually talking about the driver for the Mesa 7i80 board, which connects via ethernet.
[20:24:14] -!- alpha1125 has quit [Ping timeout: 240 seconds]
[20:29:43] <mhaberler> elk: you want to google for 'sercos' and ethercat
[20:31:03] <elk> so are the hal pins located in shared memory? the access to it would be in real-time by the different things accessing it? So motion planner writes to shared memory via hal pins, and the same halpins are read by the pid code. The pid then communicates with the driver of the breakboard through halpins again?
[20:31:47] <elk> just trying to understand if the interface between the working parts is simply halpins, or NML messages, I'm not sure what is used when
[20:32:52] -!- tjb1 has quit [Client Quit]
[20:33:36] <mhaberler> between drivers and modules its halpins
[20:34:17] <mhaberler> whenever commands / status queries from higher level components are involved its NML messages (mostly)
[20:36:35] <mhaberler> yes, hal pins are in shared memory
[20:37:00] <elk> ok so the real-time stuff uses solely hal pins in shared memory
[20:37:04] <mhaberler> a pin is named, typed blob of shm with extra attributes like direction
[20:37:08] <mhaberler> yes
[20:37:31] <mhaberler> nml is way too slow for RT, and it doesnt work in-kernel ; HAL does
[20:38:10] <elk> and the stuff involved with the task commands is user space?
[20:38:40] -!- neverho02 has quit [Quit: leaving]
[20:40:10] <mhaberler> yes, solely
[20:40:55] <mhaberler> when task schedules a command to motion it uses shm too because NML wont work there
[20:40:59] <mhaberler> tah
[20:41:05] <mhaberler> that is in usrmotif.c
[20:41:41] <mhaberler> emc/motion/usrmotif*
[20:42:18] -!- tjb1 has quit [Client Quit]
[20:44:14] <mhaberler> and tonight: a guided safari through linuxcnc cde
[20:44:35] <mhaberler> it is very hard to put pieces together
[20:45:03] <riz_> haha
[20:46:20] <andypugh> I ought to keep a log of this.
[20:48:15] <elk> ok I think I get it, but you said it uses shared memory between the tasks and motion, why doesn't NML work there? From the code notes it looks like NML communicates to the shared memory (not in realtime) from EMCTASK, and shared memory is accessed by the motion code in real-time
[20:48:27] <mhaberler> logger[mah]: burp
[20:48:27] <logger[mah]> mhaberler: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2012-12-11.html
[20:49:19] <mhaberler> it uses shm between 'milltask' and motion
[20:49:31] <mhaberler> milltask is the result of building emc/task
[20:49:38] <mhaberler> now milltask is userland
[20:49:47] <mhaberler> motion is kernel in rtai
[20:49:51] -!- joeg has quit [Ping timeout: 260 seconds]
[20:50:06] <mhaberler> NML isnt designed to work in kernel context
[20:50:24] <mhaberler> it is C++ - no C++ in-kernel
[20:50:48] <mhaberler> not designed for that
[20:51:58] <mhaberler> elk: the path from/to kernel is extremely convoluted
[20:52:18] <elk> so NML is used just to store commands in the shared memory
[20:52:19] <mhaberler> example: motion status -> emcstatus NML message
[20:52:54] <mhaberler> well NML is really just a named buffer, message queues arent used except for error printing
[20:53:05] <mhaberler> now motion-> say gui:
[20:53:38] <mhaberler> motion writes say commaned position to shared memory (the usrtaskintf shared memory, which isnt HAl and not NML)
[20:54:10] <mhaberler> milltask pulls the value out of usrmotif shm, writes it into emcstatus
[20:54:24] <mhaberler> now gui sees updated values in emcstatus
[20:54:42] <mhaberler> the design principle is called 'Rube Goldberg'
[20:55:49] <mhaberler> if one would put all motion status into HAL pins, you could dump most of NML emcstatus
[20:55:56] <mhaberler> why? beats me
[20:56:26] <mhaberler> no copying, no coding errors copying
[20:56:59] <elk> so are you saying this can all be done using shared memory and no NML? that sounds easier to me
[20:57:11] <seb_kuzminsky> are you asking why motion puts its status in NML instead of HAL? because when motion was written, HAL didn't exist but NML did
[20:57:25] <mhaberler> the status reporting part of emcstatus IMO could well be done by HAL pins, yes
[20:57:50] <elk> what can't be done with HAL, making NML necessary?
[20:57:54] <mhaberler> this isnt all of emcstatus though (look at the definition, it is the kitchen sink of everything of remote interest)
[20:58:11] <mhaberler> HAL isnt network capable (not yet)
[20:58:35] <seb_kuzminsky> one thing NML can do that HAL can't easily do is compound messages
[20:58:44] <mhaberler> then some message contents dont go well with HAL pins, for instance text strings
[20:58:48] <riz_> What do you mean by network capable?
[20:59:03] <seb_kuzminsky> in HAL, you read one simple variable (s32/float/etc), then you read another, but you don't know if the two values you read "go together"
[20:59:18] <mhaberler> access HAL pins remotely - there's just halrmt which has room for improval
[20:59:43] <seb_kuzminsky> in NML, the entire message is sent & received together, so the values are all part of the same message
[20:59:48] <mhaberler> the architecture _was_ intended to be separatable onto different machines
[20:59:49] <seb_kuzminsky> this is often very important
[21:00:08] <mhaberler> right, atomic compound messages
[21:01:11] <mhaberler> so it's types (HAL wont do strings eg) and structures which can be conveyed in one go instead of looking at pins in turn - the 'in turn' delay might change the meaning
[21:01:18] -!- ybon has quit [Quit: WeeChat 0.3.8]
[21:01:23] <seb_kuzminsky> yeah
[21:02:28] <elk> Why can't linuxcnc just have one big bucket of shared memory that the different parts access and communicate through (not HAL I suppose). Like different ring buffers between the different components of the software that need to share memory.
[21:02:43] <mhaberler> good point
[21:02:49] <elk> It just seems that it can be done easier
[21:03:05] <riz_> I believe that is how commercial CNC's do it now. I could be wrong
[21:03:32] <seb_kuzminsky> one can imagine a HAL pin of type 'struct', with special semantics (probably a rw lock in the accessor function)
[21:03:36] <mhaberler> note the HAL execution model needs queues and buffers only at the outside interface - commands in, status out
[21:04:21] <mhaberler> motion has queues, but it is _very_ special
[21:04:59] <elk> what makes it special
[21:05:17] <mhaberler> I'll come to that
[21:05:37] <mhaberler> its really the middleware question, and that in turn raises the question whether you can assume a shared memory model (= single cpu) or not
[21:06:17] <mhaberler> single shared memory for everything from hard RT to UI clicking doesnt scale
[21:06:38] <mhaberler> and you dont get flexibility in UI's (what shall I say.. 10.04LTS)
[21:07:18] <seb_kuzminsky> what do you mean by that?
[21:07:24] -!- joeg has quit [Ping timeout: 252 seconds]
[21:07:39] <mhaberler> because you are limited by the RT OS requirement
[21:08:01] <elk> what is limiting you with the RTOS
[21:08:05] <mhaberler> with this model you cant glue an ipad to your mill and run the interp and gui on it even that isnt RT
[21:08:36] <seb_kuzminsky> yuck
[21:08:37] <mhaberler> you get RT with very few linux versions
[21:08:48] <elk> the model being a single shared memory space?
[21:08:53] <mhaberler> you dont get it on windoze, ios, android
[21:09:11] <mhaberler> you mean the current de-facto model ? yes
[21:09:18] <mhaberler> its not a model, it happened
[21:09:24] <seb_kuzminsky> i can see maybe putting the UI on another box, but not interp
[21:09:44] <elk> what do you mean by another box, another processor?
[21:09:55] <mhaberler> any processor/os, yes
[21:09:56] <seb_kuzminsky> elk: another computer
[21:10:13] <mhaberler> what is special about interp? any hard RT requirements?
[21:10:19] <seb_kuzminsky> one computer controls motion on the machine, another computer talks to the human
[21:10:23] <mhaberler> the interp isnt limiting you, its the middleware
[21:10:41] <riz_> Why dont you just use a multicore with the RT on one and the non-RT stuff on the other?
[21:10:57] <seb_kuzminsky> what good does it do to move interp off the control computer?
[21:11:08] <mhaberler> look at the jepler patch for improving task/motion speed. Do you remember what he measure before his patch (commands/second)?
[21:11:09] <seb_kuzminsky> riz_: that's what we do now
[21:11:22] <seb_kuzminsky> mhaberler: i dont know anything about that patch
[21:11:49] <mhaberler> if you grep for 'taskEager' in task you'll find it.
[21:11:55] <riz_> Where is that code that does this within linuxcnc code?
[21:12:16] <mhaberler> Fact was: the rate of commands task -> motion maxed out at 20-30/sec
[21:12:29] <mhaberler> you could do that over a serial line, almost
[21:12:42] <mhaberler> what I'm saying: the coupling requirement is actually very low
[21:12:56] <elk> when you mention the term "middleware" what is that referring to, i guess that's most important if thats the limiting factor
[21:13:31] <mhaberler> the glue between distributed components - what is now a variety of mechanisms: NML plus HAL plus usrmotif shared memory
[21:13:37] <mhaberler> all a tad different
[21:14:01] <elk> ok, but HAL itself is also shared memory
[21:14:03] <riz_> the Do you mean usermotintf?
[21:15:01] -!- FinboySlick has quit [Quit: Leaving.]
[21:15:01] <mhaberler> seb: the only reason why interp needs to run on the rt os (ie motion + comps CPU) is the usrmotif assumes shm and hence cannot be separated
[21:15:18] <riz_> mhaberler: What exactly is limiting the command tasl -> motion to 20-30/sec?
[21:15:22] <mhaberler> what I meand: from the interaction rate there is no reason whatsoever to use shared memory
[21:15:32] <mhaberler> let me explain
[21:15:56] <mhaberler> task works with a fixed cycle of say 10msec
[21:16:26] <mhaberler> it used to process one command per cycle, and didnt look ahead if more could be stuffed towards motion
[21:17:13] <mhaberler> that means this interface was actually operated at very slow speed, but it looks nobody complained - its just that motion didnt get much to look ahead
[21:17:40] <riz_> When you say commands, you mean G/M code commands?
[21:17:44] <mhaberler> due to the fix it can go up an order or two of magnitude, but its still nothing
[21:18:09] <mhaberler> commands at the usrmotif layer are LINE, ARC etc
[21:18:21] <mhaberler> decomposed into geometric primitives
[21:18:43] <riz_> oh the canon outputs?
[21:18:45] <mhaberler> G/M is fed into the interpreter
[21:18:54] <seb_kuzminsky> by usrmotif you mean Canon commands?
[21:19:28] <mhaberler> again, its not the same structures, but in contents at least the movement canon commands map pretty direct on usrmotif commands
[21:19:38] <riz_> I am confused what usermotif is haha. I only see usermotintf
[21:19:56] <seb_kuzminsky> oh, i bet that's what he means
[21:20:01] <mhaberler> that is in fact a very good question: why usrmotif dont use canon + a bit extra
[21:20:07] <seb_kuzminsky> the usr/motion interface
[21:20:12] <seb_kuzminsky> maybe mah?
[21:20:18] <mhaberler> yesm between task and motion
[21:21:05] <mhaberler> usr.. means userland in that case; motion assumed to be kernel - this isnt enduser accessible (it should though)
[21:21:52] <mhaberler> the amount of structural translation with dubious value in linuxcnc code is staggering
[21:24:12] <mhaberler> riz: it took me quite a while to understand why it is there; it's because the mechanism the other parts use isnt usable there, so here comes another round of copying values from structure a to structure b
[21:25:49] <mhaberler> I need a break.. nice campfire this evening ;)
[21:26:36] <riz_> So usermotintf just copies from one structure to the other?
[21:26:44] <riz_> And yes, it is a well deserved break haha
[21:30:23] -!- mhaberler has quit [Ping timeout: 252 seconds]
[21:32:24] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[21:37:28] -!- motioncontrol has quit [Quit: Sto andando via]
[21:37:54] -!- tjb1 has quit [Ping timeout: 276 seconds]
[21:43:50] -!- DJ9DJ has quit [Quit: byte]
[21:54:16] <riz_> I cant find any call for hal_init("milltaksk")
[21:54:32] <riz_> I see it for "iocontrol" and "motmod", but not "milltask"
[21:54:43] <riz_> Does anyone know where it is?
[21:56:01] <riz_> Or is it not needed because it does not use HAL since there is not hardware communication with TASK
[21:58:08] -!- r00t4rd3d_ has quit [Quit: Leaving]
[21:58:26] -!- skunkworks has quit [Read error: Connection reset by peer]
[22:13:13] -!- jthornton_ [jthornton_!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[22:13:14] -!- jthornton has quit [Read error: Connection reset by peer]
[22:31:54] -!- syyl has quit [Quit: Leaving]
[22:34:23] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[22:38:36] -!- yuvipanda has quit [Quit: yuvipanda]
[22:45:08] -!- sumpfralle1 has quit [Ping timeout: 248 seconds]
[22:45:13] -!- Valen has quit [Quit: Leaving.]
[22:56:49] -!- acdha has quit [Quit: Leaving...]
[22:58:23] <mhaberler> riz: around
[22:58:37] <mhaberler> ?
[23:13:17] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[23:13:18] <andypugh> he's riz_ (just to ping him)
[23:13:39] <riz_> hello
[23:13:45] <riz_> sorry, haha
[23:13:48] <andypugh> (Does that make him a global?)
[23:14:08] <andypugh> We probably lost mhaberler now...
[23:15:25] <mhaberler> nope
[23:15:47] <mhaberler> re hal_init() - which file are you referring to?
[23:15:57] <mhaberler> customtask,py?
[23:16:46] <riz_> ino
[23:16:48] <riz_> no
[23:16:56] <riz_> Let me find it..
[23:17:18] <mhaberler> I'm not aware of a module named 'milltask'
[23:17:48] <riz_> For each of the three hal components (motmod, io, and milltask) that are referenced in the ini file we found motmod in motion.c, iocontrol in iocontrol.cc (not io)
[23:17:58] <riz_> not hal components sorry
[23:18:15] <riz_> I didnt mean hal components. I meant linuxcnc components
[23:18:21] <mhaberler> I see
[23:18:58] <mhaberler> well milltask doesnt talk hal in the original design, it only talks to nml-speakers
[23:19:21] <mhaberler> I dont see a very good reason for this but this is what the design seems to have been
[23:20:21] <riz_> Yeah, that is what I figured
[23:20:40] <mhaberler> task is if you will the coordinating entity, which keeps overall state (mdi,auto etc)
[23:21:10] <mhaberler> it calls upon interpreter if needed and funnels its output to motion
[23:21:38] <mhaberler> and also iocontrol - which is also a component for which no clear design reason I can discern
[23:22:33] <mhaberler> iocontrol only makes sense if moses said there shall be no hal in task; however when she designed it there was no hal
[23:22:59] <mhaberler> so I though - lets try what happens when we dump it
[23:23:03] -!- ybon has quit [Quit: WeeChat 0.3.8]
[23:23:05] <mhaberler> result: it all becomes easier
[23:23:09] <andypugh> our Moses, or the original Moses
[23:23:16] <andypugh> ?
[23:23:28] <mhaberler> no, the original designers of emc
[23:23:54] <mhaberler> I mean if there was a strong design reason for this I cant see it
[23:23:57] <riz_> Is there a version with no iocontrol?
[23:23:59] <andypugh> and iocontrol looks after a moon of Jupiter, and not a lot else :-)
[23:24:17] <mhaberler> so you read that code, clearly ;)
[23:25:41] <mhaberler> that taskclass thing happened in during writing of the remapping code, and I took a stab at doing remapping and toolchange in one go but it got too much
[23:26:11] <mhaberler> 750 commits later I decided it was time to wrap up remapping and leave toolchange for a second coding djihad
[23:30:16] <riz_> OK. Thanks for all the help. My day is done...
[23:31:21] <mhaberler> you are a tough code reader
[23:31:32] <mhaberler> not many of those around
[23:32:16] <andypugh> Yeah, I wish I could do that. It all becomes a blur rather rapidly.
[23:32:37] <andypugh> Partly because I don't really read Python, or C++ very much,
[23:34:29] <seb_kuzminsky> i like cscope for this kind of code archeology
[23:37:19] -!- racycle has quit [Quit: racycle]
[23:58:07] -!- r00t4rd3d has quit [Quit: Leaving]