Back
[00:04:27] -!-
theorbtwo has quit [Ping timeout: 255 seconds]
[00:04:36] theorb is now known as
theorbtwo
[00:14:55] -!-
Loetmichel has quit [Ping timeout: 258 seconds]
[00:21:39] -!-
andypugh has quit [Quit: andypugh]
[00:22:00] -!-
i_tarzan has quit [Ping timeout: 255 seconds]
[00:48:47] -!-
robh__ has quit [Ping timeout: 248 seconds]
[00:52:51] -!-
syyl has quit [Read error: Connection reset by peer]
[01:25:53] -!-
Tom_itx has quit []
[01:26:30] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[01:27:45] -!-
pjm has quit [Ping timeout: 258 seconds]
[01:56:29] -!-
theos has quit [Ping timeout: 252 seconds]
[02:23:30] -!-
A2Sheds has quit [Quit: puff of smoke]
[02:39:58] -!-
stormlight has quit [Quit: stormlight]
[02:45:54] -!-
atom1 has quit [Client Quit]
[03:01:52] cjdavis1 is now known as
cjdavis
[03:03:46] -!-
Guest941 has quit [Quit: Visitor from www.linuxcnc.org]
[03:09:24] -!-
Valen has quit [Quit: Leaving.]
[04:14:54] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #emc-devel
[04:14:54] <CIA-83> EMC: 03cmorley 07v2.5_branch * r6ef390c751e6 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf -fix loading of the 5i25 board
[04:38:45] -!-
ve7it has quit [Remote host closed the connection]
[04:46:46] -!-
psha[work] [psha[work]!~psha@195.135.238.205] has joined #emc-devel
[05:11:47] -!-
vladimirek [vladimirek!~vladimire@213.151.246.136] has joined #emc-devel
[05:51:43] -!-
JT-Shop has quit [Ping timeout: 256 seconds]
[05:52:17] -!-
jthornton has quit [Ping timeout: 256 seconds]
[05:52:38] -!-
JT-Shop [JT-Shop!~chatzilla@216-41-156-49.semo.net] has joined #emc-devel
[05:53:08] -!-
jthornton [jthornton!~chatzilla@216-41-156-49.semo.net] has joined #emc-devel
[06:14:10] -!-
Eartaker has quit [Quit: OOOOOO Whats that....]
[06:15:35] -!-
factor has quit [Read error: Connection reset by peer]
[07:12:19] -!-
e-ndy [e-ndy!jkastner@nat/redhat/x-rvfwslxviuydcwmn] has joined #emc-devel
[07:40:21] -!-
robh__ [robh__!~robert@5ace70a4.bb.sky.com] has joined #emc-devel
[07:59:53] -!-
ries has quit [Quit: ries]
[08:21:03] -!-
Tom_itx has quit []
[08:27:04] -!-
cassmodiah has quit [Read error: Operation timed out]
[08:36:55] -!-
mhaberler has quit [Quit: mhaberler]
[09:43:01] -!-
cevad has quit [Ping timeout: 258 seconds]
[10:09:41] -!-
vladimirek has quit [Ping timeout: 276 seconds]
[10:10:05] -!-
vladimirek [vladimirek!~vladimire@bband-dyn243.178-40-47.t-com.sk] has joined #emc-devel
[11:27:11] -!-
skunkworks has quit [Ping timeout: 248 seconds]
[11:56:13] -!-
Valen has quit [Ping timeout: 240 seconds]
[13:07:04] -!-
psha[work] has quit [Quit: Lost terminal]
[13:10:37] -!-
automata has quit [Ping timeout: 240 seconds]
[13:40:00] -!-
|n0b0dy| has quit [Ping timeout: 240 seconds]
[13:50:48] -!-
skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #emc-devel
[14:19:54] -!-
i_tarzan has quit [Ping timeout: 255 seconds]
[14:20:31] -!-
chester88 has quit [Ping timeout: 248 seconds]
[14:36:24] -!-
chester88 [chester88!~chris@64.180.204.37] has joined #emc-devel
[14:46:38] -!-
e-ndy has quit [Quit: Ex-Chat]
[14:51:51] -!-
chester88 has quit [Ping timeout: 255 seconds]
[14:52:19] -!-
jthornton has quit [Ping timeout: 256 seconds]
[14:52:26] -!-
JT-Shop has quit [Ping timeout: 276 seconds]
[15:00:55] -!-
sarariman_seb [sarariman_seb!~seb@67.51.249.130] has joined #emc-devel
[15:05:52] -!-
jthornton [jthornton!~chatzilla@216-41-156-49.semo.net] has joined #emc-devel
[15:07:42] -!-
chester88 [chester88!~chris@64.180.204.37] has joined #emc-devel
[15:12:03] -!-
JT-Shop [JT-Shop!~chatzilla@216-41-156-49.semo.net] has joined #emc-devel
[15:23:25] -!-
psha [psha!~psha@213.208.162.69] has joined #emc-devel
[15:30:37] -!-
syyl_ has quit [Ping timeout: 240 seconds]
[15:31:27] -!-
syyl has quit [Ping timeout: 248 seconds]
[15:36:15] -!-
vladimirek has quit [Ping timeout: 248 seconds]
[15:43:00] -!-
automata has quit [Client Quit]
[15:49:23] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #emc-devel
[16:22:08] -!-
The_Ball has quit [Ping timeout: 276 seconds]
[16:25:56] -!-
pcw_home has quit [Ping timeout: 258 seconds]
[16:30:20] -!-
The_Ball has quit [Ping timeout: 256 seconds]
[16:41:20] -!-
vladimirek [vladimirek!~vladimire@bband-dyn243.178-40-47.t-com.sk] has joined #emc-devel
[16:41:42] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #emc-devel
[16:43:33] -!-
LawrenceG [LawrenceG!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #emc-devel
[16:43:45] -!-
ve7it has quit [Client Quit]
[16:43:48] -!-
LawrenceG has quit [Read error: Connection reset by peer]
[16:44:00] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #emc-devel
[16:47:21] -!-
The_Ball has quit [Remote host closed the connection]
[16:52:48] -!-
The_Ball has quit [Remote host closed the connection]
[16:58:03] -!-
The_Ball has quit [Ping timeout: 260 seconds]
[17:06:50] -!-
The_Ball has quit [Ping timeout: 260 seconds]
[17:15:35] -!-
The_Ball has quit [Ping timeout: 260 seconds]
[17:25:19] -!-
The_Ball has quit [Ping timeout: 258 seconds]
[17:25:29] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust1037.basl.cable.virginmedia.com] has joined #emc-devel
[17:26:19] <andypugh> Why are the gain pin on PID defined as I/O ? It seems to make it difficult to net them to anything you might want to net them to (like GUI sliders)
[17:27:14] -!-
syyl_ has quit [Quit: Verlassend]
[17:31:13] -!-
The_Ball has quit [Remote host closed the connection]
[17:36:14] -!-
The_Ball has quit [Ping timeout: 276 seconds]
[17:54:28] <cradek> they were originally params, and for a while people were getting wild hairs and changing things from params to pins, and a lot of those changes were done without the necessary amount of care.
[17:54:57] <cradek> in particular, the pid change caused obscure bugs that took several iterations to fix.
[17:55:19] <cradek> so in summary: "no particular reason" is my guess.
[17:55:56] <andypugh> Someone on the forum wants to link them to a spinbox. Which seems reasonable, but you can't.
[17:57:35] <andypugh> You can change python code without recompiling, so perhaps he can create an IO pin spinbox? (eewww!)
[17:58:07] -!-
nullie has quit [Ping timeout: 248 seconds]
[17:59:48] <cradek> yes that would probably work, and I agree with your feelings about it.
[18:00:15] <cradek> I'm not sure I'd want to tune pids with a spinbox, but whatever.
[18:00:35] <andypugh> It probably beats typing setp all night.
[18:00:42] <sarariman_seb> but… a spinbox is a gui, and everything is better if it has a gui
[18:04:45] <mhaberler> I'v tried tuning a pid with gladevcp spinbox inputs. It's a while but I think it worked
[18:05:55] -!-
theorbtwo has quit [Ping timeout: 252 seconds]
[18:09:55] <mhaberler> nope, sorry. was a setp.
[18:18:25] <JT-Shop> do you think the reaction time of the heater varies so much you need a spinbox for P gain?
[18:20:54] <cradek> if exercising utmost care, someone could change them to inputs in trunk. I'm still singed enough from last time to not want that change in 2.5.
[18:23:21] <mhaberler> speaking of 2.5: how do we proceed on
http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg04858.html ?
[18:24:17] <mhaberler> the other open issue was: there were two requests for iov2 to be included
[18:27:39] <psha> btw any feedback on html math?
[18:27:49] <mhaberler> worked for me
[18:27:57] <cradek> I forget - what does this fix? the commit message says what the change is, not why it was done
[18:28:45] <sarariman_seb> psha: the little i saw of math-equations-in-html looked great
[18:28:58] <sarariman_seb> maybe post it to emc-developers for wider review?
[18:29:15] <cradek> psha: I don't remember a pending question - can you point me to it?
[18:29:15] <psha> probably... any brave here? :)
[18:29:24] <psha> cradek: no math in html docs
[18:29:24] <mhaberler> http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg04858.html ? this fixes
http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg04822.html
[18:29:48] <cradek> mhaberler: thanks
[18:31:40] <cradek> mhaberler: wow, what weird behavior that was - we definitely need your fix
[18:31:54] <mhaberler> oh, you saw it?
[18:32:51] <cradek> no, just reading your description.
[18:33:08] <psha> sarariman_seb: may you post something descriptive on dev list?
[18:33:40] <psha> it's night here and i need to wake early to take kid to the kindergarden
[18:33:43] <cradek> mhaberler: I am a *very* light user of any of the new interp features.
[18:33:56] <mhaberler> oword?
[18:34:04] <cradek> very light.
[18:34:57] <mhaberler> psha has looked at it; runtests is ok, but it really goes to the intestines so I'd love to have a second reviewer - unsure whom to bug though; KL seems to be less into it these days
[18:35:09] <cradek> I don't see any good reason to not include your test
[18:35:25] <cradek> yeah, I am also unsure who you should ask.
[18:36:52] <cradek> psha: seems like any fix you have for the math would be welcomed by elson and others
[18:37:41] -!-
factor has quit [Ping timeout: 260 seconds]
[18:37:49] -!-
chester88 has quit [Quit: Leaving.]
[18:38:18] <mhaberler> the other approach would be to get it in and ask people for a spin. If it turns out to be really broken (which I dont think it is, because I'm using it with some 20 other regression tests using oword in the remapping-preview branch) we could always back it out
[18:38:59] <cradek> if it was in 2.5 I would be currently using it, but like I said, I don't think I have any setups that would cause this to be triggered
[18:39:21] <mhaberler> it was really hard to come up with it, true
[18:39:48] -!-
cassmodiah has quit [Changing host]
[18:42:01] <mhaberler> ok, well then I'll apply it. any takes on the iov2 issue? I was asked but I'm lukewarm about it, I dont want to prolong iocontrol life; otoh people find it useful
[18:43:50] <cradek> can you point me to the iov2 branch again please
[18:44:40] -!-
chester88 [chester88!~chris@S010688ae1d61f51a.no.shawcable.net] has joined #emc-devel
[18:45:01] <mhaberler> it's in master:
http://git.linuxcnc.org/gitweb?p=emc2.git;a=tree;f=src/emc/iotask;h=49ce5a711e2da6f73759aba8502658f82d7f8db9;hb=18b74443d18dd0e510e54944b795c1747d56be4c
[18:54:17] -!-
PCW [PCW!~chatzilla@99.88.10.65] has joined #emc-devel
[18:54:24] <cradek> mhaberler: you think it will be ultimately abandoned?
[18:54:50] <psha> cradek:
http://psha.org.ru/emc2-docs/config/ini_config.html#c5079a3c9c992afce004df13b0838784
[18:54:59] <psha> http://psha.org.ru/cgit/psha/emc2.git/log/?h=asciidoc-latexmath
[18:55:02] <psha> not rebased though
[18:55:12] <psha> i can rebase it if it's needed
[18:56:34] <PCW> sarariman_seb the upshot of issys muxed encoder problem is that he used a RS-422 interface chip with 800 nS enable/disable times, not very worky at 6 MHz
[18:56:38] <mhaberler> to give you an idea where I'm heading: this is a iocontrol-compatible replacement which runs as Embedded Python within task (very researchy, but works) - note the method names directly plug into emctaskmain:
http://git.mah.priv.at/gitweb/emc2-dev.git/blob/8451655b450f219128f10e9c7c34aee07a433472:/configs/sim/remap/iocontrol-removed/python/customtask.py
[18:57:09] <mhaberler> no more separate process, NML queue etc
[18:58:29] <cradek> psha: is math notation used in a lot of places, or just here? I don't think this adds much or anything to the usability of this particular document. I wonder if instead of fixing it, we should eliminate the equations.
[18:59:12] <JT-Shop> it's used mostly for PID and in the HAL manual iirc
[18:59:42] <JT-Shop> and a few other places I think
[18:59:48] <psha> poweroff
[18:59:52] <psha> oops
[18:59:56] <psha> cradek: it's just an example
[19:00:07] <psha> as i understand math is used in lot of places
[19:00:14] <psha> such as PID docs etc...
[19:00:18] <psha> so it's useful
[19:00:28] <mhaberler> I think it said some 57 figures or so
[19:00:43] <psha> 120
[19:00:58] <psha> or 170
[19:01:05] <cradek> either the one in OUTPUT_OFFSET docs is typset incorrectly or I don't understand it
[19:01:13] <cradek> oh, 120-170, ouch
[19:01:21] <cradek> forget my question then
[19:01:30] <JT-Shop> a grep turned up a bunch of hits
[19:01:57] <cradek> psha: do we need to add dependencies to fix it?
[19:02:16] <psha> hm, latex is already there...
[19:02:21] <psha> due to dblatex
[19:02:27] <psha> probaly no
[19:02:43] <cradek> then I see no reason not to fix it! thanks for doing the work.
[19:02:43] <psha> i'll investigate tomorrow
[19:02:55] <psha> thx, now - real poweroff ;)
[19:02:57] <psha> bb
[19:03:00] -!-
psha has quit [Quit: leaving]
[19:03:21] <andypugh> cradek: I think "output-offset" means "output - OUTPUT_OFFSET"
[19:04:08] <andypugh> (I would have output = raw * scale - offset though)
[19:07:46] <andypugh> If I am filling an arbitrary struct byte-by-byte, then I need it passed as a void pointer, I think. Should I then initialise a char pointer from it, or should I try incrementing the void pointer itself (the internet reckons the latter is bad)
[19:08:28] -!-
The_Ball has quit [Remote host closed the connection]
[19:08:36] <cradek> I think you'll need to cast the void* to char* to do anything meaningful with it (including dereference it)
[19:08:54] <cradek> are you sure you need it as a void*?
[19:09:55] <andypugh> Not at the moment, as I am only using it to fill one type of struct at the moment, but then the code is only about 10% written.
[19:10:48] <andypugh> I would quite like to be using the type of the object passed to define the behaviour of the function, but this is C..
[19:13:02] <cradek> yeah, don't get all silly.
[19:14:49] <andypugh> I am reading data out of the sserial grand-daugher board for config, so fixing the type of the data being read seems short-sighted
[19:18:01] <mhaberler> cradek: re task shutdown. I did a little experimentation.. the best way to fast shutdown an hm2 installation when task fails was to remove the pet-watchdog function for long enough to trigger, then reenable it so HAL pins keep working . time from signal to hm2 tristate some 15msec or so.
[19:20:27] <cradek> I had not thought of halcmd delf...
[19:22:55] <mhaberler> it really depends on hw config and scenario. the task charge-pump signal is reliable and better on a real machine than I though (was really bad on mac+virtualbox sim). the watchdog hal comp can be used to detect failure of cp signal, but that component needs a makeover
[19:23:09] <mhaberler> with parport something else is needed
[19:23:44] <cradek> yeah
[19:23:54] <cradek> I wish there was a general answer, but I fear there isn't
[19:23:58] <mhaberler> re hm2: if one doesnt addf pet-watchdog again, the fact that the watchdog triggered isnt observable untile then
[19:24:19] <cradek> hmm
[19:25:19] <PCW> So the watchdog state is only read by pet-watchdog?
[19:25:24] <mhaberler> i think two scenarios can be guarded against: signal, looping. signal - fine, depending on hw config one could delf/wait/addf or hal_stop_threads
[19:25:35] <mhaberler> yes, there was a heisenberg window there..
[19:26:54] <mhaberler> I observed tristate with a LA after timer expire but HAL pin change only showed after addf pet-watchdog which is consistent with code (provided I understood the code)
[19:27:29] <mhaberler> looping: a soft watchdog observing charge-pump is fine
[19:29:42] <PCW> I dont think theres a race condition, if the watchdog ever bytes it needs fixing, not feeding
[19:30:32] <PCW> bites
[19:31:00] <mhaberler> not a race. has_bit isnt true until addf pet-watchdog servo-thread.
[19:31:26] <PCW> Right
[19:32:33] <PCW> It probably would be better if the watchdog status was always read (especially for debugging)
[19:32:39] <mhaberler> yess
[19:33:54] <mhaberler> but then delf is really a heavy-handed approach. probably it should be done in the read function
[19:35:06] <PCW> lots of time beginners have been chasing problems where they cant get outputs to work because they dont have the watchdog setup right
[19:35:07] <PCW> if it gave a nice warning it would be better
[19:36:26] <mhaberler> well I guess they get read right, so post-change they would immediately see has_bit (dontknow if it bites if it never petted, but I assume so; actually it better be)
[19:36:40] <PCW> so pet-watchdog should do only that
[19:36:42] <PCW> and watchdog status read should always happen
[19:36:55] <mhaberler> yes
[19:37:54] <mhaberler> otherwise it's cutting the branch it's sitting on ;-)
[19:38:20] <PCW> Basically it should be a fatal error
[19:39:12] <mhaberler> probably should remain tristate until first pet-watchdog, but I didnt look at that scenario
[19:39:59] <PCW> It will remain tristate until reset (different that feeding)
[19:40:05] <mhaberler> aja
[19:40:06] <PCW> than
[19:41:41] <PCW> its has bit status is latched to avoid race conditions
[19:43:01] -!-
stormlight has quit [Quit: stormlight]
[19:46:47] <mhaberler> note romantic test setup, including Red Greene-style mounting brackets:
http://imagebin.org/177300
[19:51:37] <PCW> Duct tape, what would we do without it!
[19:51:55] * skunkworks loves the foil hvac tape
[19:53:35] <mhaberler> actually, 3M made him 'Duct Tape Ambassador'
[20:03:01] -!-
syyl__ has quit [Ping timeout: 240 seconds]
[20:15:19] <CIA-83> EMC: 03mhaberler 07v2.5_branch * rbb1a2b6917d4 10/src/emc/sai/driver.cc: sai: add -i <inifile> option to rs274
[20:15:21] <CIA-83> EMC: 03mhaberler 07v2.5_branch * r786ee724e451 10/src/emc/sai/driver.cc: sai: make rs274 -h output reflect actual defaults
[20:15:23] <CIA-83> EMC: 03mhaberler 07v2.5_branch * rd595d9cc05ba 10/src/emc/rs274ngc/ (rs274ngc_interp.hh rs274ngc_pre.cc): interp: assure aborted O-word subroutines properly unwind the call stack
[20:15:27] <CIA-83> EMC: 03mhaberler 07v2.5_branch * rbc1fd41ecedc 10/tests/interp/oword-unwind/ (7 files): interp: regression test for correct unwind after failed external oword procedure
[20:25:52] -!-
The_Ball has quit [Ping timeout: 258 seconds]
[20:27:03] -!-
mhaberler has quit [Quit: mhaberler]
[20:32:00] -!-
The_Ball_ has quit [Remote host closed the connection]
[20:38:21] -!-
The_Ball has quit [Read error: Connection reset by peer]
[20:42:23] -!-
ries has quit [Ping timeout: 248 seconds]
[20:42:24] ries_ is now known as
ries
[20:49:00] -!-
syyl_ has quit [Quit: Leaving]
[20:49:21] -!-
The_Ball_ has quit [Remote host closed the connection]
[20:53:28] -!-
jepler has quit [Ping timeout: 260 seconds]
[20:53:51] -!-
FinboySlick has quit [Quit: Leaving.]
[20:53:56] -!-
rooks has quit [Ping timeout: 260 seconds]
[20:55:12] -!-
jepler [jepler!~jepler@emc/developer/pdpc.professional.jepler] has joined #emc-devel
[20:55:40] -!-
The_Ball has quit [Remote host closed the connection]
[20:58:27] -!-
bootnecklad has quit [Ping timeout: 258 seconds]
[21:00:42] -!-
The_Ball has quit [Ping timeout: 252 seconds]
[21:01:17] -!-
skunkworks has quit []
[21:05:44] -!-
The_Ball has quit [Ping timeout: 256 seconds]
[21:06:05] -!-
seb__ [seb__!~seb@67.51.249.130] has joined #emc-devel
[21:08:06] -!-
sarariman_seb has quit [*.net *.split]
[21:08:06] -!-
Loetmichel has quit [*.net *.split]
[21:10:50] -!-
The_Ball has quit [Ping timeout: 256 seconds]
[21:17:08] -!-
The_Ball has quit [Remote host closed the connection]
[21:24:31] -!-
The_Ball has quit [Ping timeout: 248 seconds]
[21:30:06] -!-
The_Ball has quit [Ping timeout: 256 seconds]
[21:36:06] -!-
The_Ball has quit [Read error: Connection reset by peer]
[21:40:17] -!-
vladimirek has quit [Remote host closed the connection]
[21:43:16] <andypugh> I am a bit concerned having just searched the src for HAL_IO. There look to be lots of inappropriate HAL_IO pins, in many components. It looks almost like there was a global search-and-replace done, despite the fact that HAL_IO isn't much use. You can setp it, but can only net it to about one other thing (index_enable)
[21:44:29] -!-
nullie has quit [Quit: Ex-Chat]
[21:44:43] -!-
grommit has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.23/20110921065534]]
[21:45:52] -!-
The_Ball has quit [Ping timeout: 255 seconds]
[21:48:02] <andypugh> It appears to have happened in 2008, so has clearly been that way for a while. I wonder what the logic was?
[21:52:09] -!-
The_Ball has quit [Ping timeout: 258 seconds]
[21:54:08] -!-
Fox_Muldr has quit [Ping timeout: 260 seconds]
[21:55:22] -!-
skunkworks [skunkworks!~chatzilla@184-158-81-121.dyn.centurytel.net] has joined #emc-devel
[21:56:27] <SWPadnos> I think some of that might have been from a general conversion of parameters to pins (maybe?)
[21:57:11] <SWPadnos> parameters are often RW, since the component might apply limits to user settings
[21:57:57] <andypugh> Components can change the values of input pins though (and of parameters)
[21:58:28] <SWPadnos> in practice, it doesn't work out
[21:58:31] <andypugh> I don't see much point changing parameters to IO pins, as almost nothing useful can write to IO pins.
[21:59:04] <SWPadnos> things like PID tuning coefficients used to be parameters, that was one thing that stimulated the conversion
[21:59:40] <SWPadnos> I don't know if that was the impetus, but that is something I recall that was a more or less mechanical operation done to pin creation
[21:59:42] <andypugh> Yes, but now they are IO pins which it appears you can't net to..
[22:00:13] <SWPadnos> well, you wondered what the logic was, I was trying to answer that from a historical perspective :)
[22:01:21] <andypugh> It is the PID gains that started me off looking at this. Someone on the forum wanted to net the PID gains to a GUI. But that doesn't work because pyvcp controls are outputs, and you can't net a plain output to an IO pin. SO it is just like a parameter in effect, but taunts you with pin-ness :-)
[22:01:37] <SWPadnos> I agree though, IO isn't needed in most cases, and pretty much all of the useful cases have exactly two IO pins, and potentially some additional R pins
[22:01:49] <SWPadnos> heh
[22:02:03] <SWPadnos> that's strange, since that's the exact reason why they were changed ...
[22:02:28] -!-
The_Ball has quit [Ping timeout: 245 seconds]
[22:02:50] <andypugh> I confess I didn't check with an actual Pyvcp, but you can't net a constant pin to them
[22:03:09] <SWPadnos> hmmm
[22:03:19] <SWPadnos> I can't check it at the moment
[22:03:28] <SWPadnos> damned cleaning projects. can't find anything any more
[22:04:09] <andypugh> Looking at the forum, JT tried it with a spinbox, and found the same problem.
[22:04:11] -!-
factor has quit [Read error: Connection reset by peer]
[22:08:54] <andypugh> Oops! [ 2682.478485] kernel BUG at /home/moses/Projects/emc2/ubuntu-lucid/mm/slub.c:2969!
[22:09:09] <andypugh> Not a kernel bug at all, it is me messing up, I feel sure.
[22:11:24] <SWPadnos> I sure hope so :)
[22:11:25] -!-
The_Ball has quit [Ping timeout: 240 seconds]
[22:13:13] <andypugh> That one was too bad to get a debug clue though :-(
[22:21:50] -!-
The_Ball has quit [Remote host closed the connection]
[22:26:45] -!-
memleak [memleak!~memleak@unaffiliated/memleak] has joined #emc-devel
[22:27:42] -!-
The_Ball has quit [Ping timeout: 255 seconds]
[22:28:10] -!-
chester88 has quit [Ping timeout: 252 seconds]
[22:33:25] -!-
The_Ball has quit [Ping timeout: 240 seconds]
[22:34:25] <memleak> Hi! I am not using a debian based distro, and I am trying to get emc branch 2.5 from git working.
[22:35:39] <memleak> the mesa_other_sserial.c file requires the #include <linux/slab.h> file to satisfy kfree and kmalloc.
[22:37:56] <andypugh> other_sserial isn't in 2.5 any more
[22:38:04] <andypugh> And we fixed that omission anyway.
[22:38:28] <andypugh> You should find the problem goes away if you pull the latest version
[22:39:49] -!-
The_Ball has quit [Ping timeout: 240 seconds]
[22:40:04] <memleak> as for siggen.ko rotatekins.ko maxkins.ko biquad.ko and 5axiskins.ko, sincos is undefined and none of the files such as siggen.mod.c don't have linux/math.h included, which is required for sincos
[22:40:47] <andypugh> don't they have rtapi_math instead?
[22:40:51] <memleak> and i cant recompile the mod.c files with my changes after running make clean because the C source files disappear, and are generated again later on.
[22:41:06] -!-
Mjolinor has quit [Remote host closed the connection]
[22:42:47] -!-
bootnecklad` has quit [Ping timeout: 244 seconds]
[22:43:18] <andypugh> sin and cos are in rtapi_math.h, and that is included in rotatekins.
[22:43:30] <memleak> sincos, not sin and cos
[22:43:42] <memleak> sincos is provided in linux/math.h
[22:43:47] <memleak> rtapi_math.h im not sure of.
[22:44:40] <andypugh> I don't see "sincos" in rotatekins.c
[22:45:18] <memleak> besides i dont see any #include lines in the files regarding rtapi_math.h maybe my tree is broken? im re-cloning to be sure because you're saying something different than what i see
[22:45:41] <andypugh> rotatekins.c line 15
[22:45:52] -!-
isssy has quit [Quit: Visitor from www.linuxcnc.org]
[22:46:16] <memleak> checking..
[22:50:07] <memleak> my tree must have been broken, im going to try recompiling now. one more thing, with a new version of ubuntu coming out with a new kernel, does the dev team have any plans moving to pci_get API?
[22:50:30] <andypugh> I thought we had :-)
[22:50:40] <memleak> when i talked to jepler a few months ago, he said its ugly just changing pci_find to get
[22:50:55] <andypugh> However, we generally only build on the LTS versions of Ubuntu
[22:54:17] <memleak> ah, emc looks for /usr/lib/emc/tcl/hal.something but my libdir for the distro is /usr/lib64. i used --libdir=/usr/lib64 on the ./configure line but it still looks for /usr/lib/emc/tcl not /usr/lib64/emc/tcl
[22:54:40] -!-
The_Ball has quit [Ping timeout: 244 seconds]
[22:54:49] <memleak> is it safe if i just symlink it?
[22:55:03] <memleak> i'd like to do something cleaner than that.
[22:55:13] <andypugh> No idea. I take the easy Ubuntu route
[22:58:07] <memleak> alright. hey just so you are aware, hal_motenc.c line 294 uses pci_find
[22:59:00] <memleak> might wanna run a git grep pci_find to find more. i just ran sed on everything in hal/drivers/*.c
[22:59:06] <JT-Shop> andypugh: did you get sserial sorted out for the 5i25?
[22:59:32] <andypugh> Still working on it.
[22:59:49] <JT-Shop> anything I can help on?
[23:00:16] <andypugh> Well, sserial works for 8i20 and 7i64. It's the new auto-config that needs help
[23:00:31] <andypugh> What peripheral cards do you have?
[23:01:00] <JT-Shop> when Peter sends it 7i76
[23:01:08] <memleak> "sincos" undefined for siggen, rotatekins, all over again..
[23:01:25] <JT-Shop> he said he would ship them Wednesday
[23:02:08] <memleak> yet i see rtapi_math.h included in the emc/kinematics files and the hal/components but src/siggen.mod.c doesn't nor src/rotatekins.mod.c
[23:03:46] <memleak> are the src/*.ko files using the -lm flag? if not, then thats the problem
[23:03:54] -!-
seb__ has quit [Quit: This computer has gone to sleep]
[23:03:57] -!-
The_Ball has quit [Remote host closed the connection]
[23:05:08] <memleak> http://joysofprogramming.com/undefined-reference-to-sincos/
[23:05:08] <andypugh> I am hoping somebody with a clue will chime in, because I don't have one.
[23:06:17] <memleak> i don't know where to throw in the flag to pass to the ld linker. i can wait. thank you for your help though.
[23:10:55] -!-
The_Ball has quit [Ping timeout: 255 seconds]
[23:17:10] -!-
The_Ball has quit [Ping timeout: 260 seconds]
[23:22:24] <SWPadnos> I don't think you want to use -lm for kernel modules
[23:22:36] <SWPadnos> that would link in the standard math library, which isn't meant for kernel space
[23:22:59] <memleak> oh. do you know a way to fix?
[23:23:15] <SWPadnos> I didn't read back far enough to see the question :)
[23:23:50] <memleak> siggen.ko rotatekins.ko maxkins.ko biquad.ko and 5axiskins.ko, sincos is undefined and none of the files such as siggen.mod.c don't have linux/math.h nor rtapi_math.h included, which is required for sincos
[23:24:18] <memleak> however in the emc/kinematics files and the hal/components, rtapi_math.h is included
[23:24:20] <SWPadnos> you need to include rtapi_math.h. I don't know the linker incantation offhand
[23:25:37] <memleak> the .c files in src do not have it, but the ones in src/hal and src/emc do have it defined. i wonder if the *.mod.c files are the ones causing the error, not the ones in the other folders.
[23:25:39] -!-
The_Ball has quit [Ping timeout: 252 seconds]
[23:26:21] <memleak> i meant to say the ones in src/hal and src/emc do have rtapi_math.h included
[23:27:08] <SWPadnos> what files in src?
[23:27:23] <memleak> src/*.mod.c
[23:27:28] <SWPadnos> hmmm
[23:27:35] <memleak> i.e. kinematics.mod.c
[23:27:38] <memleak> siggen.mod.c
[23:27:56] <memleak> oops... kinematics.mod.c was a mistake
[23:28:51] <memleak> src/rotatekins.mod.c only has linux/module.h vermagic.h and compiler.h
[23:29:36] -!-
|n0b0dy| has quit [Ping timeout: 240 seconds]
[23:29:38] <memleak> as well as siggen.mod.c, so right at the end of the compilation, i have about 6 warnings, regarding the .ko files not having sincos defined
[23:29:53] <SWPadnos> I've been out of touch for a while. I don't know why the .mod.c files are created, or why they wouldn't include the appropriate headers
[23:30:41] <SWPadnos> and I've got to run for the moment. Try asking the question on the developers mailing list
[23:30:43] <memleak> i think its odd too why the source files (not the object files obviously) are generated at compile time
[23:31:37] -!-
The_Ball has quit [Remote host closed the connection]
[23:31:38] <SWPadnos> there was an old reason why some headers and other files would be stuck in a common directory (so that they could be included anywhere without a mile of -I options)
[23:32:01] <SWPadnos> but I thought that had stopped several years ago. Are you sure you're using a recent pull of the source?
[23:32:31] <andypugh> I have never see mod.c files created.
[23:32:46] <memleak> why do i keep getting told im using an old tree.. im using the 2.5 branch from git
[23:32:48] <SWPadnos> andypugh, have you built for realtime?
[23:32:54] <andypugh> Always
[23:33:05] <andypugh> I might have overlooked them
[23:33:18] <memleak> cat VERSION says 2.5.0-pre2
[23:33:23] <SWPadnos> because you have had questions about things that are no longer valid, such as the sserial module
[23:33:49] <memleak> so for some reason git clone is pulling old code, along with new stuff
[23:33:51] <andypugh> (It would be a bit hard to be writing these drivers without compiling for realtime ;-)
[23:34:03] <SWPadnos> well, I had to ask ;)
[23:34:28] <SWPadnos> git pull gets all versions, you have to checkout the one you want to work on
[23:34:29] <memleak> git checkout -b stable origin/v2.5_branch is what i run after git clone
[23:34:35] <memleak> thats correct, right?
[23:34:46] <SWPadnos> I don't know what -b stable does, but otherwise it's fine
[23:35:07] <memleak> it creates a local branch to make git be quiet about me working on a non local tree
[23:35:49] <SWPadnos> interesting. I don't recall git making that complaint to me, but I could have bed memory
[23:35:56] <SWPadnos> or bad memory
[23:36:01] <SWPadnos> or bad memory of beds
[23:36:05] <memleak> im going to git clone again without -b <something> and see if that works, even though i've never seen -b cause problems
[23:36:17] <SWPadnos> ... checkout ...
[23:36:57] <SWPadnos> anyway, I've got to run. like I said, email the dev list
[23:37:11] <memleak> alright will do
[23:38:37] -!-
The_Ball has quit [Remote host closed the connection]
[23:43:42] -!-
The_Ball has quit [Ping timeout: 258 seconds]
[23:45:49] -!-
jstenback has quit [Ping timeout: 240 seconds]
[23:52:32] -!-
The_Ball has quit [Remote host closed the connection]
[23:53:17] -!-
chester88 [chester88!~chris@99.199.171.103] has joined #emc-devel
[23:58:44] -!-
The_Ball has quit [Ping timeout: 244 seconds]