Back
[00:00:36] -!- mhaberler has quit [Quit: mhaberler]
[00:00:37] -!- logger[mah] has quit [Remote host closed the connection]
[00:00:47] -!- toudi_ has quit [Quit: Leaving]
[00:01:48] -!- logger[mah] [logger[mah]!~loggermah@ns1.mah.priv.at] has joined #linuxcnc-devel
[00:01:55] -!- pcw_home [pcw_home!~chatzilla@ip-66-80-167-54.sjc.megapath.net] has joined #linuxcnc-devel
[00:11:29] -!- zzolo has quit [Quit: zzolo]
[00:13:19] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:17:00] -!- L84Supper2 [L84Supper2!~TheLarch@219.143.5.35] has joined #linuxcnc-devel
[00:17:00] -!- L84Supper2 has quit [Changing host]
[00:17:00] -!- L84Supper2 [L84Supper2!~TheLarch@unaffiliated/l84supper] has joined #linuxcnc-devel
[00:22:45] -!- mackerski has quit [Quit: mackerski]
[00:24:19] sliptonic is now known as sliptonic_away
[00:24:41] -!- adb has quit [Ping timeout: 252 seconds]
[00:33:05] sliptonic_away is now known as sliptonic
[00:33:39] toudi_ is now known as micges
[00:35:03] -!- zzolo has quit [Client Quit]
[00:35:26] -!- micges has quit [Quit: Leaving]
[00:42:52] <skunkworks> I have a question... we have a website with customer information on. This is something that we purchased and someone internally is administrating it. Now - You can log in and see your information (parts). The issue I see is that if you know the url - you can get directly to the information without logging in. That seems like a big hole....
[00:56:09] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[01:03:23] -!- kmiyashiro has quit [Quit: kmiyashiro]
[01:05:46] <alex4nder> yes, that is a hole.
[01:08:36] <kwallace> This is my understanding so far, if a directory doesn't have an index or default file, typically a directory pops up presenting a file list. If an index exists, the index page pops up and the file directory doesn't show, making it hard for anyone to know the file names, but if they are known, they are still available. Search engines might be able to see them too. You can hide or password protect files or directories, but you need to set it up
[01:19:33] -!- micges has quit [Quit: Leaving]
[01:25:59] -!- Sendoushi has quit [Read error: Connection reset by peer]
[01:26:02] -!- rob__H has quit [Ping timeout: 246 seconds]
[01:32:06] <skunkworks> do hackers try to guess urls?
[01:32:16] <skunkworks> 'script kiddies'?
[01:35:27] <skunkworks> the directories are not viewable that I can tell - but like I say - if you know the url - you can get there...
[01:36:29] <skunkworks> my thought is that if it is open like that - there may be other gaping holes we don't know about..
[01:39:27] -!- kmiyashiro has quit [Quit: kmiyashiro]
[01:42:45] -!- ravenlock has quit [Ping timeout: 252 seconds]
[01:43:14] -!- Sendoushi has quit [Remote host closed the connection]
[01:45:11] -!- kmiyashiro has quit [Client Quit]
[01:46:37] -!- FinboySlick has quit [Quit: Leaving.]
[02:07:55] -!- joe9 has quit [Quit: leaving]
[02:12:59] -!- kwallace1 [kwallace1!~kwallace@smb-182.sonnet.com] has joined #linuxcnc-devel
[02:14:51] -!- ybon has quit [Quit: WeeChat 0.3.8]
[02:15:06] -!- kwallace has quit [Ping timeout: 256 seconds]
[02:22:05] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[02:36:35] <kwallace1> This might be handy:
http://css-tricks.com/easily-password-protect-a-website-or-subdirectory/
[02:44:00] -!- plushy has quit [Quit: Leaving.]
[02:45:05] -!- racycle has quit [Quit: racycle]
[02:50:38] -!- L84Supper2 has quit [Ping timeout: 256 seconds]
[03:20:52] -!- sumpfralle has quit [Ping timeout: 245 seconds]
[03:41:00] -!- kwallace1 has quit [Ping timeout: 252 seconds]
[03:45:49] -!- Gene34 has quit []
[03:57:59] -!- Keknom has quit [Quit: Leaving.]
[04:08:57] -!- Tom_L has quit [Client Quit]
[04:14:56] -!- L33TG33KG34R has quit [Ping timeout: 255 seconds]
[04:15:12] -!- kwallace [kwallace!~kwallace@smb-130.sonnet.com] has joined #linuxcnc-devel
[04:17:46] -!- Tom_L has quit [Client Quit]
[04:42:50] -!- kwallace has quit [Ping timeout: 256 seconds]
[04:51:45] -!- Brandonian has quit [Quit: Brandonian]
[04:55:41] -!- zzolo has quit [Quit: zzolo]
[04:56:28] -!- kwallace [kwallace!~kwallace@smb-55.sonnet.com] has joined #linuxcnc-devel
[05:00:56] -!- AR__ has quit [Ping timeout: 255 seconds]
[05:04:23] -!- Loetmichel has quit [Ping timeout: 256 seconds]
[05:12:55] -!- tjb1 has quit [Quit: tjb1]
[05:17:32] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[05:26:35] -!- joe9 has quit [Quit: leaving]
[05:33:29] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[05:33:42] -!- joe9 has quit [Client Quit]
[05:35:00] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[05:47:36] -!- wildbilldonovan has quit [Ping timeout: 256 seconds]
[06:02:00] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:07:42] -!- capricorn_1 has quit [Quit: Konversation terminated!]
[06:16:50] -!- kwallace [kwallace!~kwallace@smb-55.sonnet.com] has parted #linuxcnc-devel
[06:37:29] eXiMeR is now known as Tecan
[06:41:06] -!- mhaberler [mhaberler!~mhaberler@extern-185.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[06:51:33] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[06:59:14] -!- dhoovie has quit [Ping timeout: 246 seconds]
[07:17:33] -!- JT-Shop has quit [Ping timeout: 252 seconds]
[07:17:35] -!- jthornton has quit [Ping timeout: 256 seconds]
[07:30:59] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[07:31:13] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[07:33:44] -!- jthornton has quit [Read error: Connection reset by peer]
[07:33:44] -!- JT-Shop has quit [Read error: Connection reset by peer]
[07:49:09] Cylly is now known as Loetmichel
[07:51:25] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[07:51:28] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[07:52:59] -!- jthornton has quit [Read error: Connection reset by peer]
[07:53:00] -!- JT-Shop has quit [Read error: Connection reset by peer]
[08:03:59] -!- mhaberler has quit [Quit: mhaberler]
[08:10:10] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[08:10:15] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[08:23:51] -!- kmiyashiro has quit [Quit: kmiyashiro]
[08:27:15] Tecan is now known as Elemnt41
[08:28:51] -!- racycle has quit [Quit: racycle]
[08:33:50] -!- emel has quit [Excess Flood]
[08:35:25] -!- jthornton has quit [Read error: Connection reset by peer]
[08:35:25] -!- JT-Shop has quit [Read error: Connection reset by peer]
[08:36:06] -!- uwe_ has quit [Read error: Operation timed out]
[08:36:51] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[08:36:56] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[08:43:39] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[08:50:40] -!- JT-Shop has quit [Read error: Connection reset by peer]
[08:50:40] -!- jthornton has quit [Read error: Connection reset by peer]
[08:51:58] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[08:51:59] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[09:03:26] -!- jthornton has quit [Ping timeout: 252 seconds]
[09:04:18] -!- JT-Shop has quit [Ping timeout: 264 seconds]
[09:10:28] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[09:10:33] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[09:14:17] -!- rob_h [rob_h!~rob_h@5e0860c9.bb.sky.com] has joined #linuxcnc-devel
[09:20:26] -!- JT-Shop has quit [Ping timeout: 245 seconds]
[09:20:27] -!- jthornton has quit [Ping timeout: 245 seconds]
[09:23:15] -!- JT-Shop [JT-Shop!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[09:23:16] -!- jthornton [jthornton!~john@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[09:25:59] -!- emel has quit [Excess Flood]
[09:32:53] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[09:33:33] Elemnt41 is now known as Tecan
[09:58:26] -!- mhaberler has quit [Ping timeout: 252 seconds]
[10:24:29] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[10:41:24] toudi_ is now known as micges
[10:41:38] -!- micges [micges!~toudi@dgx114.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[10:58:17] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[11:28:50] -!- syyl_ has quit [Ping timeout: 255 seconds]
[11:31:39] -!- sumpfralle has quit [Quit: Leaving.]
[11:59:19] -!- theos has quit [Disconnected by services]
[12:15:05] -!- phantoxeD has quit [Ping timeout: 255 seconds]
[12:18:09] -!- Sendoushi has quit [Remote host closed the connection]
[12:41:09] -!- karavanjoW has quit [Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/]
[12:47:04] -!- joe9 has quit [Quit: leaving]
[12:53:29] -!- skunkworks has quit [Remote host closed the connection]
[13:27:14] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:27:19] -!- Sendoushi has quit [Remote host closed the connection]
[13:28:08] -!- Sendoushi has quit [Remote host closed the connection]
[13:28:26] <skunkworks> logger[psha],
[13:34:58] -!- Valen has quit [Quit: Leaving.]
[13:46:33] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[14:06:14] -!- AR__ has quit [Ping timeout: 246 seconds]
[14:06:23] -!- mackerski has quit [Quit: mackerski]
[14:08:45] -!- L84Supper2 [L84Supper2!~TheLarch@unaffiliated/l84supper] has joined #linuxcnc-devel
[14:08:45] -!- L84Supper2 has quit [Client Quit]
[14:08:47] -!- TheLarch [TheLarch!~TheLarch@unaffiliated/l84supper] has joined #linuxcnc-devel
[14:12:32] -!- psha[work] has quit [Quit: Lost terminal]
[14:31:37] -!- TheLarch has quit [Ping timeout: 244 seconds]
[14:34:55] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[14:38:03] -!- dgarr [dgarr!~dgarrett@75-171-116-105.phnx.qwest.net] has joined #linuxcnc-devel
[14:46:55] -!- L84Supper2 [L84Supper2!~TheLarch@219.143.5.35] has joined #linuxcnc-devel
[14:46:55] -!- L84Supper2 has quit [Changing host]
[14:46:55] -!- L84Supper2 [L84Supper2!~TheLarch@unaffiliated/l84supper] has joined #linuxcnc-devel
[15:05:02] -!- micges has quit [Ping timeout: 246 seconds]
[15:18:07] -!- micges [micges!~toudi@epd222.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[15:25:59] -!- jackc- has quit [Ping timeout: 255 seconds]
[15:26:13] -!- kanzure has quit [Ping timeout: 248 seconds]
[15:31:46] -!- abetusk has quit [Remote host closed the connection]
[15:31:52] -!- kwallace [kwallace!~kwallace@tmb-250.sonnet.com] has joined #linuxcnc-devel
[15:38:53] -!- V0idExp has quit [Ping timeout: 252 seconds]
[15:39:46] -!- RuslanPopov has quit [Ping timeout: 256 seconds]
[15:44:53] -!- micges has quit [Ping timeout: 248 seconds]
[15:45:38] <cradek> + 347a992...1b4ed45 2.5-doc-anchors -> origin/2.5-doc-anchors (forced update)
[15:46:00] <cradek> on a pull I saw this. does it mean someone push-forced to git.linuxcnc.org?
[15:56:39] <mhaberler> if you used gitolite for user admin, you'd have not to worry about that kind of thing - you can set a user/group attribute which prevents that - allows ff only
[15:57:34] <mhaberler> the only one who can force-push to my repo is me which cuts down the search space to 1 ;)
[15:58:18] <mhaberler> which is why I can be more liberal with userid, because I dont have to worry aboute force-push breakage
[15:59:59] -!- kwallace1 [kwallace1!~kwallace@tmb-247.sonnet.com] has joined #linuxcnc-devel
[16:01:39] -!- kwallace has quit [Ping timeout: 276 seconds]
[16:09:45] <cradek> looks like the answer to my question is yes. I thought pull would not do that without coercion.
[16:10:26] <cradek> it's what I would have wanted anyway, I guess
[16:18:36] <seb_kuzminsky> i force-pushed to the 2.5-doc-anchors branch several times
[16:19:47] <seb_kuzminsky> you can see previous versions of the branch with 'git reflog origin/2.5-doc-anchors' (that'll show each tip of origin/2.5-doc-anchors that your clone has ever pulled)
[16:21:08] <cradek> just curious, do you do that mainly to poke the buildbot?
[16:26:45] -!- toudi_ [toudi_!~toudi@epd222.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[16:39:18] toudi_ is now known as micges
[16:49:25] -!- odogono has quit [Read error: Connection reset by peer]
[17:11:19] <cradek> jepler: do you remember why you/we used pid's command-derivative input for the D term but not FF1 and FF2?
[17:13:06] <cradek> hm, I guess that's probably the side of it people don't use much. feedback-deriv is the one folks hook to their encoders.
[17:13:21] <pcw_home> feedback-derivative is used for D
[17:13:40] <cradek> both are optionally used for D
[17:14:07] <cradek> neither deriv input is used for FF1,2 and that's my question why
[17:14:16] <pcw_home> That don't make sense (to me)
[17:14:35] <cradek> which part?
[17:15:17] <pcw_home> command-deriv should be just for FF1,FF2
[17:15:33] <pcw_home> (optionally for)
[17:15:41] <cradek> error_d = commandv - feedbackv
[17:15:55] <cradek> ok we've got two questions now
[17:16:14] <cradek> why not use it for d? it ought to be better than a discrete dpos/dt
[17:17:09] <pcw_home> OK for generating commandv its appropriate
[17:17:29] <cradek> yes that's how it's (optionally) used
[17:17:56] <cradek> but that optionally higher quality commandv is not being used for ff1,2
[17:18:12] <cradek> that was my original question
[17:18:34] <cradek> although it borders on moot because I don't think anyone is using the command-deriv input
[17:19:04] <pcw_home> Yes but it should be used if available
[17:20:14] <pcw_home> (which means in the future all this index M^2L might be movable to motion)
[17:21:56] <pcw_home> (that is if the derivatives always came from motion the index issues could all be fixed in one place)
[17:22:28] <cradek> I think motion already has joint velocity outputs that could be just hooked up
[17:22:43] <cradek> they are surely index-safe already
[17:22:44] <jepler> cradek: no, I do not remember.
[17:23:44] <cradek> *(joint_data->joint_vel_cmd) = joint->vel_cmd;
[17:25:18] <cradek> pcw_home: I don't think you should have seen a FF1 homing thump. If there was one it would have had P and I contributions only
[17:25:31] <cradek> I wonder if that's why I couldn't spot it in the simulator
[17:26:21] -!- V0idExp has quit [Quit: Leaving.]
[17:26:49] <pcw_home> I dont have any FF1 (but a fair amount of FF2)
[17:27:11] <pcw_home> (since this is a torque mode loop)
[17:27:43] <jepler> I'm not sure why I didn't touch FF1
[17:27:50] <jepler> I think maybe I wasn't using an FF1 term in my own configuration...?
[17:27:51] <cradek> it would also cascade into ff2's gain
[17:29:02] <KGB-linuxcnc> 03chris 05pid-ferror-fix-try2 df552d0 06emc2 10src/hal/components/pid.c * Fix index thump for pid's previous_target mode
[17:29:26] <cradek> pcw_home: could you try this one with your same test?
[17:29:37] <pcw_home> I'll try it when i get in
[17:29:55] <cradek> it's somewhat brute-force but at least is simple enough that I probably have it right
[17:30:06] <jepler> pid->cmd_d should just be assigned pid->commandv (before being clipped to its max and min)?
[17:30:53] <cradek> I still am not sure whether P, I gains should be proportional to our new type of error (previous period's command vs this period's feedback)
[17:31:33] <jepler> hm, should the D term be obeying maxcmd_d ?
[17:31:37] <jepler> I think it's not
[17:32:17] <pcw_home> Theres also the negative I term bug/feature
[17:32:30] <cradek> jepler: D is capped by maxerrorD
[17:33:36] <cradek> pcw_home: more information please
[17:34:05] <pcw_home> If you use a negative I term you lose big time (runaway)
[17:34:53] <pcw_home> (just in case you though using negative terms is a way to invert the output polarity as some customers have...)
[17:35:42] <cradek> can you say exactly what you think the bug is?
[17:36:07] -!- Sendoushi has quit [Remote host closed the connection]
[17:36:30] <pcw_home> its an error (or assumption) in the integral bounding that fails if I is negative
[17:37:27] <cradek> what do you mean integral bounding?
[17:38:00] <cradek> I'm trying to understand whether you think this is a bug in the math surrounding I, or in detection/erroring for a misconfiguration, or something else
[17:38:51] <pcw_home> the way integral accumulator is bounded fails if 'I' is negative
[17:39:19] <cradek> do you mean limiting according to the maxerrorI pin?
[17:39:29] <pcw_home> Yes
[17:40:17] <pcw_home> maybe fixable in the man page "dont use negative PID values"
[17:40:18] <cradek> that code looks correct to me. it makes sure error_i is between +-maxerror_i
[17:41:05] <cradek> over time, negative I value will drive the error to one of the two maximums
[17:41:38] <pcw_home> if I is negative its I calculation is frozen and you get a runaway
[17:42:37] <cradek> yes I agree it will probably run away if you have negative I
[17:43:09] <cradek> I am still trying to understand where/what you are saying the problem is
[17:43:43] <cradek> I do not see how a negative I could do anything other than tend to make the error worse
[17:43:56] <cradek> same for negative P
[17:44:56] <cradek> should we put lower caps on P and I? Document that negatives don't make sense? error out if we see them?
[17:44:58] <pcw_home> What I am saying is that people have used negative PID terms as a ways of inverting the PID polarity so everything works but if you bound the I term it will runaway as soon as the integral limit is reached
[17:47:51] <pcw_home> its a fault/oversight in the way the I term bounding works
[17:48:15] <pcw_home> probably just fixable in man page
[17:48:20] <cradek> (I am surprised any of the terms work right - I have never thought about this situation)
[17:48:35] -!- Tecan has quit [Ping timeout: 252 seconds]
[17:49:59] <cradek> I bet negating maxerrorI as well would fix it?
[17:51:26] <cradek> for which of the gains should the manpage say that only positive numbers make sense?
[17:53:41] <seb_kuzminsky> cradek: i force-pushed that branch each time i rebased it
[17:54:04] <seb_kuzminsky> i rebased it several times to keep it at the tip of v2.5_branch, and to keep the history tidy as i noticed mistakes i made
[17:55:01] <pcw_home> Normally they all have to be the same polarity so I would just say they must be positive
[18:14:37] -!- Tom_itx has quit [Ping timeout: 245 seconds]
[18:31:19] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[18:37:28] -!- micges has quit [Quit: Leaving]
[18:41:04] -!- toudi_ [toudi_!~toudi@epd222.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:41:08] toudi_ is now known as micges
[18:45:53] -!- Tecan has quit [Ping timeout: 246 seconds]
[18:46:11] <cradek> seb_kuzminsky: thanks, just curious
[18:53:04] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:58:17] -!- mhaberler has quit [Read error: Operation timed out]
[18:58:17] <KGB-linuxcnc> 03chris 05v2.5_branch a54ea03 06emc2 10docs/man/man9/pid.9 * It's not clear how negative gains should work. Warn about them.
[18:59:37] <skunkworks> heh - that works :)
[18:59:45] <cradek> :-P
[19:02:25] <JT-Shop> http://linuxcnc.org/docs/html/hal/rtcomps.html#_pid_a_id_sec_pid_a
[19:04:10] -!- mackerski has quit [Quit: mackerski]
[19:09:45] <cradek> that sure looks nicer than the picture I drew
[19:11:23] <cradek> but sadly it's all somewhat out of date. the man page is much closer to reality.
[19:21:06] -!- shurshur has quit [Remote host closed the connection]
[19:38:48] -!- joe9_ [joe9_!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[19:39:50] -!- mhaberler [mhaberler!~mhaberler@extern-180.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[19:42:24] -!- joe9 has quit [*.net *.split]
[19:42:25] -!- uwe_ has quit [*.net *.split]
[19:42:25] -!- capricorn_1 has quit [*.net *.split]
[19:45:15] <seb_kuzminsky> it's funny/sad that we have three copies of that image in our repo
[19:45:41] -!- pikeaero has quit [Remote host closed the connection]
[19:46:59] <cradek> I was already sad about how the list of pins was in the manpage and also the docs
[19:53:56] <seb_kuzminsky> yeah :-/
[19:53:59] <seb_kuzminsky> the manpage *is* the docs
[19:57:20] -!- Holgi has quit [Quit: Bye]
[20:21:38] <andypugh> What is 5 * 2048?
[20:22:23] <andypugh> Or, put another way. When is 5 * 2048 == 2048?
[20:22:47] <cradek> andypugh: you're drunk, go home
[20:22:57] <andypugh> http://pastebin.com/Td6A0Xmp
[20:23:48] <awallin> it rolls over at 8k ?
[20:23:57] <andypugh> Yes.
[20:24:17] <andypugh> All variables are "int"
[20:24:24] <awallin> so 5*2k, mod 8k, is 2k
[20:24:53] <andypugh> Any ideas why?
[20:25:17] <andypugh> I am distinctly baffled
[20:25:49] <awallin> this is the memory for programming a mesa card? which should be larger than 8k?
[20:25:52] <jepler> if all the ". . ." lines are actually rendered inoperative is the result the same?
[20:25:57] <cradek> the problem is probably in the code you aren't showing
[20:25:59] -!- odogono has quit [Read error: Connection reset by peer]
[20:26:07] <cradek> yeah, what jepler says
[20:26:09] <jepler> since it seems unlikely given the lines that are shown, one speculates it has to do with the lines that are not shown
[20:26:46] <andypugh> If the calculation is on one line, and the print is on the next?
[20:27:03] <andypugh> How can anything else intervene?
[20:27:40] <cradek> we are looking for a pair of gravity boots
[20:28:07] <jepler> I don't know what cradek means
[20:28:55] <andypugh> With the missing code:
http://pastebin.com/bZukwe4E
[20:29:45] <andypugh> I am puzzled how a calculation on one line can be wrong on the next, so to speak.
[20:30:11] <pcw_home> Theres a loose wire somewhere, that code sometimes just crashes as well (stack problem?)
[20:30:22] <andypugh> (Rather hoping someone has seen this before)
[20:31:30] <andypugh> I am thinking if I can make the loop actually terminate then it won't crash. I just assume something is going out-of-bounds.
[20:32:44] <pcw_home> Yes it gets to like erase block 900 on our system and then crashes (or sometime it crashes instantly)
[20:34:42] <pcw_home> if we just put a hm2print in sslbp write long, the first offset write (line 7) is correct but the
[20:34:44] <pcw_home> second (line 18) the offset has become 0 (as is block_start at that point)
[20:35:09] <jepler> well, here's one observation I have to offer: gcc will turn an expression like 'local = constant * loop_variable' into 'local += constant;' under certain conditions
[20:35:33] -!- Sendoushi has quit [Remote host closed the connection]
[20:35:44] <jepler> if (A) gcc does this in this case and (B) another programming error causes block_start to get assigned 0 unexpectedly, then you could get the behavior seen
[20:35:46] -!- kmiyashiro has quit [Quit: kmiyashiro]
[20:36:45] <andypugh> block_start is only in scope in the code shown.
[20:36:52] <pcw_home> so maybe better to precalculate the loop range and use a simpler while test?
[20:38:02] <andypugh> I guess something, somewhere, might be writing out-of-bounds into block_start
[20:38:50] <andypugh> Though erase_sz is not a constant, so GCC would be being very naughty to do that anyway.
[20:39:27] <jepler> if it can prove to its satisfaction that it doesn't change over the lifetime of the loop..
[20:39:47] <pcw_home> Its really loose wireish we had it work right exactly one time
[20:39:55] <andypugh> True, it won't change during the lifetime of the local.
[20:40:17] <micges> andypugh: did you disabled all gcc optimalisations?
[20:40:39] <andypugh> No, as I don't know how.
[20:41:07] <andypugh> However... commenting out all the loop contents fixes the issue. Now to iteratively reinstate them.
[20:43:04] <jepler> the other clue you have so far would revolve around the fact that "the problem" occurs right after the first block where you actually *do* something
[20:43:57] <cradek> although I don't see exactly an error, I'm uncomfortable with how you use the same i counter three different ways, some nested
[20:44:18] <cradek> and I also suspect the memcpys, although they still look ok no matter how many times I read them
[20:44:39] <andypugh> cradek: Hmm, yes, bad habit I picked up as a teen with a computer that could only have 26 variables...
[20:44:40] <cradek> if nothing else you've set yourself for byte order problems
[20:44:47] <cradek> up for
[20:45:25] <pcw_home> we tried commenting them out. no change (but there shoudl be a better way to extract a u32 from a byte array (is it a byte array?)
[20:45:58] <andypugh> Yes, it's a byte array
[20:46:06] <cradek> are sslbp_* inlined preprocessor stuff, or real functions?
[20:46:17] <andypugh> real functions
[20:46:44] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[20:48:16] <jepler> so anyway I wrote stranger and stranger incorrect programs until I got one that does something a lot like andypugh's situation ..
http://pastebin.com/1k3KjZf9
[20:48:40] <jepler> though it's not really the same
[20:48:47] <jepler> so forget it
[20:50:09] <jepler> andypugh: not sure if it'll move around the behavior or not, but you could try to HM2_PRINT block_start at various points and see where it gets zero'd
[20:50:30] <cradek> blocknum
[20:50:44] <cradek> err no
[20:52:02] <andypugh> I am right to think that this is basically wierd, though?
[20:52:05] <cradek> I think I want to see still more code, like all the declarations of these variables
[20:52:11] <cradek> sure :-)
[20:52:55] <andypugh> http://pastebin.com/utHvDwah
[20:52:56] <cradek> it could also be any of these function calls stepping on something
[20:53:01] <andypugh> Do you want the headers too?
[20:54:58] <andypugh> Well, uncommenting the cookie check made the problem re-emerge, so it must be in there.
[20:55:02] <jepler> if you could put your work on top of one of the userspace realtime branches and run the debugger on it
[20:55:14] <jepler> you could use gdb's 'watch' command to stop when the spurious modification of block_start occurs
[20:55:24] <jepler> I know that's a long string of hypotheticals right there...
[20:56:44] -!- tandoori has quit [Disconnected by services]
[20:57:05] <andypugh> I would have to set up a userspace realtime branch first.
[20:57:26] tandoori_ is now known as tandoori
[20:57:34] -!- tandoori has quit [Changing host]
[20:59:23] <andypugh> It looks like the culprit is ssslbp_read_cookie, though it looks pretty innocuous.
[20:59:57] -!- zzolo has quit [Quit: zzolo]
[21:00:23] <cradek> you are passing HM2READ a u8 when usually it's a u32
[21:00:30] <cradek> what is HM2READ?
[21:00:47] <andypugh> Yes, that will be it.
[21:01:01] <andypugh> HM2READ is a dodgy macro
[21:01:02] -!- skunkworks has quit [Read error: Connection reset by peer]
[21:01:17] <cradek> heh, that was why I asked earlier
[21:01:47] <andypugh> I asked if you wanted headers :-)
[21:02:03] <micges> you have also sopy/paste error in line 212
[21:02:09] <micges> copy
[21:02:18] <andypugh> cradek:
[21:02:18] <andypugh> #define HM2WRITE(a,b) hm2->llio->write(hm2->llio, a, &b, sizeof(u32))
[21:02:19] <andypugh> #define HM2READ(a,b) hm2->llio->read(hm2->llio, a, &b, sizeof(u32))
[21:02:30] <cradek> heh, I laugh at your original question "What is 5 * 2048?"
[21:02:34] <andypugh> Which is likely to break very badly indeed with a u8, isn't it?
[21:03:23] <cradek> also, sslbp_read_byte returns a u32 through a u8
[21:03:31] <cradek> does this really all compile without warnings??
[21:04:02] <andypugh> The only warnings are the FORTIFY_SOURCE ones
[21:04:59] <cradek> read_word returns a u32 through a u16
[21:05:41] <andypugh> Got that one :-)
[21:05:55] <andypugh> Nothing like copy-paste to multiply errors
[21:05:56] <cradek> if (hm2->sserial.version < 40){ rtapi_print("SSLBP Version must be at least v37
[21:06:29] <andypugh> Ah, that there is a reason for.
[21:07:00] <cradek> some of those errors return, others flash_stop and then return
[21:07:35] <cradek> (through the fail0)
[21:09:05] <andypugh> This is work-in-progress </defensive>
[21:09:42] <cradek> not being critical, just trying to help by looking for funny smells
[21:10:57] <cradek> in particular I was looking for mismatched printf % and number of arguments, which is a nice obscure stacksmashy thing
[21:10:58] <PCW> the good thing is disabling the erase and write commits means you dont brick the remote each time (took us about 30 reprograms via jtag to think of this)
[21:11:07] <cradek> haha ouch
[21:11:36] <andypugh> I ran out of 8i20s and had to ship them back to Mesa :-)
[21:11:59] <cradek> :-)
[21:12:11] <PCW> not a lot of hope getting this to work in 2 tries
[21:12:29] <cradek> PLEASE SEND TWO MORE SHIPPING CONTAINER 8I20 STOP
[21:12:54] <andypugh> OK, fixing read_cookie and friends seems to have ended the wierdness
[21:13:03] <cradek> yay for C
[21:13:32] <andypugh> I shouldn't be allowed near anything more dangerous than VB, clearly
[21:14:11] <PCW> One of our customers has a HostMot2 interface in VB
[21:14:36] <andypugh> It's actually not at all a bad language.
[21:14:39] <PCW> hostmot2 over LBP16
[21:15:23] <PCW> Seems to be well liked by some
[21:16:02] <cradek> "some people like it" is not a high bar
[21:16:12] <andypugh> Right, do I want to risk programming this 7i73 for real?
[21:16:33] <PCW> Let us do it
[21:16:53] <PCW> shipping charges alone...
[21:17:38] <andypugh> I think I want to get rid of the Memcpy. Any suggestions of better, less endian ways?
[21:18:06] -!- wboykinm has quit [Remote host closed the connection]
[21:18:27] <andypugh> Or is the obvious way the best? (a + b << 8 + c << 16 + d << 24 )
[21:18:46] <PCW> maybe there's a type casty way
[21:19:38] <andypugh> This isn't at all performance-critical, I am going to do it the clear, unambiguous way.
[21:29:47] <andypugh> Anything cool in the R11 7i73 firmware? :-)
[21:29:48] <cradek> andypugh: yes I bet that's the safe way
[21:30:12] <PCW> fewer bugs maybe
[21:31:31] <PCW> the 7I76/7I77/7I84 have added MPG mode option on the field inputs
[21:31:50] <cradek> does that mean no /4?
[21:31:59] -!- ravenlock has quit [Ping timeout: 252 seconds]
[21:32:50] <PCW> its worse than that, the encoder has all 24 possible count modes (but 1x is default)
[21:33:19] -!- norm has quit [Quit: norm]
[21:34:17] <andypugh> I am thinking that my MPG is going to get connected to a software counter, running in the servo thread. No sense wasting a resolver or the 7i73 really.
[21:42:49] <andypugh> seb_kuzminsky: Have you seen
http://www.linuxcnc.org/index.php/forum/18-computer/25961-arduino-leonardo-and-linears-encoders?start=12&lang=german#29097
[21:43:35] <andypugh> It is a wireless Mach3 pendant that appears to use a Windows driver calles Shuttle_pro.dll. I am wondering if it is related, internally, to the Shuttle Express?
[21:45:44] <jepler> Any reasonably sane USB HID input device should work with hal_input. Shuttle devices seem to be the very definition of 'unreasonably insane'
[21:46:52] <andypugh> Quite
[21:47:07] <andypugh> This one has an LCD screen, but I have no idea how that is driven.
[21:48:03] <andypugh> I sort-of hinted that they might want to send me a sample, but I might have been too subtle. They just said "any questions, please ask" while ignoring the question "Are there any technical/programming manuals"
[21:49:02] <jepler> oh hidcomp is the other "general" interface that talks to the hid layer, while hal_input (mine) talks to the linux input device later
[21:49:06] <jepler> layer
[21:50:54] <jepler> what does any of that have to do with arduino leonardo?
[21:51:06] -!- L84Supper2 has quit [Ping timeout: 264 seconds]
[21:51:34] <andypugh> He ought to have changed the thread title when the question drifted.
[22:01:03] -!- emel has quit [Excess Flood]
[22:04:46] <PCW> cradek latest pid test is good (no thump on index in either mode)
[22:07:17] <cradek> PCW: awesome, thanks
[22:07:36] <cradek> PCW: you think it looks satisfactory for the next 2.5 release?
[22:08:08] <PCW> I think so (its should be a no-op if the mode is not set)
[22:08:15] <cradek> yes
[22:08:17] -!- wildbilldonovan has quit [Quit: EOT]
[22:08:44] <cradek> I'm not worried about it breaking existing configs. If it also fixes the problem your customers are having, that's perfect
[22:10:52] <andypugh> I still have a problem with prescient pid...
[22:12:17] <PCW> well I term is prescient at least as far as tracking errors at a constant velocity goes
[22:12:58] <cradek> andypugh: what do you mean?
[22:13:01] <KGB-linuxcnc> 03tissf 05v2.5_branch e67d780 06emc2 10docs/src/index_fr.tmpl * French doc. update to follow Sebastian:simplify a link in the html front page
[22:13:01] <KGB-linuxcnc> 03tissf 05v2.5_branch 5610726 06emc2 10docs/ 10src/gcode/gcode_fr.txt 10src/gcode/m-code_fr.txt * French doc. update to follow Sebastian
[22:13:05] <KGB-linuxcnc> 03tissf 05v2.5_branch c113fc6 06emc2 10docs/src/gcode/m-code_fr.txt * French doc. update to follow Sebastian
[22:13:11] <KGB-linuxcnc> 03tissf 05v2.5_branch 5578449 06emc2 10docs/src/gcode/m-code_fr.txt * French doc. update to follow Sebastian
[22:13:17] <KGB-linuxcnc> 03tissf 05v2.5_branch 1965987 06emc2 10docs/html/gcode_fr.html * French doc. update
[22:13:23] <KGB-linuxcnc> 03tissf 05v2.5_branch e952045 06emc2 10docs/html/gcode_fr.html * French doc. update document pass w3c validator
[22:13:30] <KGB-linuxcnc> 03tissf 05v2.5_branch 1b026c3 06emc2 10docs/src/gcode/gcode_fr.txt * French doc. update
[22:13:35] <KGB-linuxcnc> 03tissf 05v2.5_branch 28389ef 06emc2 10docs/ 10html/gcode_fr.html 10src/gcode/gcode_fr.txt * French doc. update to follow Sebastian
[22:13:42] <KGB-linuxcnc> 03tissf 05v2.5_branch 636170c 06emc2 10docs/ 10html/gcode_fr.html 10src/gcode/gcode_fr.txt 10src/gcode/machining_center_fr.txt * French doc. update to follow Sebastian
[22:13:50] <KGB-linuxcnc> 03tissf 05v2.5_branch 8a2e4ca 06emc2 10docs/ 10html/gcode_fr.html 10src/gcode/gcode_fr.txt 10src/gcode/m-code_fr.txt * French doc. update to follow Sebastian
[22:13:57] <KGB-linuxcnc> 03tissf 05v2.5_branch 5fa9166 06emc2 10docs/ 10html/gcode_fr.html 10src/gcode/gcode_fr.txt * French doc. update to follow Sebastian
[22:14:04] <KGB-linuxcnc> 03tissf 05v2.5_branch edb4b85 06emc2 10docs/ 10html/gcode_fr.html 10src/gcode/gcode_fr.txt 10src/gcode/m-code_fr.txt 10src/gcode/o-code_fr.txt * French doc. update to follow Sebastian
[22:14:04] -!- FinboySlick has quit [Quit: Leaving.]
[22:14:11] <KGB-linuxcnc> 03tissf 05v2.5_branch 3b7868d 06emc2 10docs/ 10src/hal/halui_fr.txt 10src/hal/intro_fr.txt 10src/quickstart/stepper_quickstart_fr.txt * French doc. update to follow Sebastian
[22:14:17] <andypugh> PCW: 7i77 query on the other channel
[22:14:19] <KGB-linuxcnc> 03tissf 05v2.5_branch 9696224 06emc2 10docs/src/common/user_intro_fr.txt * French doc. update to follow Sebastian
[22:14:25] <KGB-linuxcnc> 03tissf 05v2.5_branch 582e7aa 06emc2 10docs/src/common/user_intro_fr.txt * French doc. update for pass w3c validator
[22:14:32] <KGB-linuxcnc> 03tissf 05v2.5_branch 064340b 06emc2 10docs/ 10src/common/User_Concepts_fr.txt 10src/config/ini_config_fr.txt 10src/gcode/machining_center_fr.txt * French doc. update for pass w3c validator
[22:14:39] <KGB-linuxcnc> 03tissf 05v2.5_branch 0006178 06emc2 10docs/src/config/stepconf_fr.txt * French doc. update for pass w3c validator
[22:14:46] <KGB-linuxcnc> 03tissf 05v2.5_branch 3686136 06emc2 10docs/ 10(7 files in 4 dirs) * French doc. fix for pass w3c validator
[22:14:52] <KGB-linuxcnc> 03chris 05pid-ferror-fix-try2 5f7a0bd 06emc2 10src/hal/components/pid.c * make sure the new pid mode defaults to off
[22:16:06] -!- DJ9DJ has quit [Quit: bye]
[22:17:16] -!- Sendoushi has quit [Remote host closed the connection]
[22:17:20] <andypugh> cradek: It is my opinion that f-error is not the same as pid-error. f-error is bad. pid-error is what produces a pid output. f-error is the delta between last commanded and current (how well did the machine do at getting to the commanded point) and pid-error is delta between new commanded and current. And that's just the way it should be.
[22:20:20] -!- JesusAlos has quit [Quit: ChatZilla 0.9.89 [Firefox 11.0/20120310193829]]
[22:31:17] -!- micges has quit [Ping timeout: 245 seconds]
[22:31:28] <PCW> but that means you have a ferror proportional to velocity*sampletime that you cannot tune out if you use any integral term
[22:32:33] <PCW> because the integral term _will_ null the PID error during motion
[22:32:34] -!- toudi_ [toudi_!~toudi@epd222.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[22:32:36] toudi_ is now known as micges
[22:33:07] <andypugh> If so, does that mean that an I term leads to poor path following?
[22:33:15] <PCW> no
[22:33:46] <andypugh> Are you sure?
[22:33:51] <PCW> with cradeks patch the paths are now the same
[22:34:09] <andypugh> If where we are now is not where we asked to be, last time we asked, then that's bad.
[22:35:17] <PCW> we are in the same place in both modes (at prev commanded pos)
[22:36:33] <andypugh> If we are at exactly previous commanded position, then I think that means that f-error should show zero. And if we want to now go somewhere else, then PID-error should be non-zero.
[22:36:38] <PCW> if you dont use the mode there is no change
[22:36:40] <PCW> if you use the mode you now can use the integral term an not show bogus ferror
[22:37:05] -!- JesusAlos has quit [Quit: ChatZilla 0.9.89 [Firefox 11.0/20120310193829]]
[22:37:32] <andypugh> I was away skiing during the bulk of the discussion, and wasn't paying much attention.
[22:37:58] <andypugh> Has pid-error calculation been changed, or f-error calculation?
[22:38:16] <PCW> PID
[22:38:26] <andypugh> So we now get laggy-pid?
[22:39:09] <PCW> yes which is exactly what you want if you have any integral term
[22:40:04] <cradek> andypugh: I think I agree with you and I'm unsure -try2 fix is right for exactly the reasons you say
[22:40:20] <PCW> otherwise the PID tracks the current position (integral nulls the error even at top rapid speed) and you show a large ferror
[22:41:30] <andypugh> PID should be chasing the next position, as I see it. And f-error should be a historical record of how it worked out.
[22:42:26] <cradek> but if it's working out perfectly, more I shouldn't be accumulating
[22:42:31] -!- odogono has quit [Read error: Connection reset by peer]
[22:42:32] <cradek> I think that's what PCW is saying
[22:43:03] <cradek> on the other hand, if it's working out perfectly, should the P contribution drop to zero? probably not I think?
[22:43:03] <andypugh> I can see the situation, yes.
[22:43:25] <PCW> imagine a long rapid (the integral term nulls the error between next pos and current encoder)
[22:43:29] <andypugh> Actually, yes, seeing P drop to zero is a good sign.
[22:43:33] <cradek> I sure see there are two kinds of error: one driving the gains, and one that shows our success or failure after the period is up
[22:43:52] <cradek> oh ok, then maybe -try2 IS right
[22:44:00] <andypugh> Arguably I-error and P-error should be different calculations.
[22:44:14] <cradek> elaborate?
[22:45:14] <andypugh> P-error should be calculated on next - now. I-error on last - now ?
[22:45:39] <andypugh> P + (next - now) + I * (last - now)
[22:46:06] <andypugh> Just a thought, I have no formal education in control systems. I wish I did.
[22:46:18] <cradek> then P contribution won't ever drop to zero if you're moving
[22:46:43] <andypugh> Which might be useful.
[22:46:47] <cradek> I'm trying to understand whether that is a feature or a bug
[22:47:03] -!- Sendoushi has quit [Remote host closed the connection]
[22:47:10] <andypugh> Having a bit of P-overhead to drop at a moment's notice might not mbe bad.
[22:47:10] <cradek> recently you said it was a good sign
[22:47:22] <andypugh> Yeah, I might be changing my mind.
[22:47:46] <cradek> let me channel rumsfeld and say that's something I know I don't know
[22:48:39] <andypugh> The controller I have been playing with most in recent months is just plain wierd, so my current perspective is a bit skewed.
[22:49:54] <andypugh> (It's an oil pressure controller that uses oil pressure to change the stroke of a pump to change the oil pressure. You can probably see where that gets wierd)
[22:50:38] -!- odogono has quit [Read error: Connection reset by peer]
[22:51:10] -!- odogono has quit [Client Quit]
[22:52:42] <PCW> I think its slightly cleaner to just apply the mode to I term calculations
[22:52:43] <PCW> But the results will probably only be a tiny amount different
[22:53:25] <andypugh> One thing that our controllers typically offer is a combined limit on P + I
[22:54:06] <andypugh> So, if you are so far off the mark that the P-term is hug then the I-term doesn't get to wind up.
[22:54:40] <cradek> I bet you run with large errors being a normal situation more than we do
[22:54:53] <andypugh> Yes.
[22:55:06] <PCW> I think the PID comp does that as well (suspends I term accumulation when output saturated)
[22:55:07] <cradek> wish the coolant was at 175, but it's at -10 now...
[22:56:24] <andypugh> Yes, that sort of thing. And "Time for some EGR, can we have 100mg now, rather than zero?"
[22:57:04] <PCW> we messed around with assymetrical I term in SoftDMC (deccumulate faster when I term is driving the wrong direction)
[22:59:00] <andypugh> My oil controller I term is the product of 3 12x12 maps, driven by 6 input variables.
[22:59:31] <cradek> other than try to tune some real setups I don't know how to evaluate these choices, and all I have is velocity mode stuff, where any of them probably work fine
[22:59:37] <andypugh> The P and D terms are only the product of 2 maps.
[22:59:39] <cradek> I don't think I am using Igain on anything
[22:59:49] <cradek> nor deadband
[23:00:00] -!- L84Supper2 [L84Supper2!~TheLarch@unaffiliated/l84supper] has joined #linuxcnc-devel
[23:00:38] <andypugh> The oil pump is basically an all-I control. It is one of those systems where when you are at the setpoint you need to hold, not back-off to zero
[23:02:16] -!- wboykinm has quit [Remote host closed the connection]
[23:06:32] <andypugh> PCW: Did you get to try the latest setsserial, or are you no longer in the office?
[23:08:02] <PCW> yes let me give it a try
[23:10:26] -!- ybon has quit [Quit: WeeChat 0.3.8]
[23:14:55] <seb_kuzminsky> three cheers for tissf, for maintaining the french docs!!
[23:15:14] <andypugh> Huzzah!
[23:15:22] -!- JesusAlos has quit [Quit: ChatZilla 0.9.89 [Firefox 11.0/20120310193829]]
[23:15:55] <PCW> Look good: finished, thinks is wrote the correct amount of blocks, 8I20 still works in both modes
[23:17:41] <PCW> probably wont know for sure until I write an old version (say with I wont start with LOW VBUS feature)
[23:18:00] <andypugh> At last, some progress!
[23:18:54] -!- joe9_ has quit [Quit: leaving]
[23:19:46] <PCW> mostly variable overlaps?
[23:20:17] <cradek> seb_kuzminsky: how is the tool table stuff coming? I think I'm happy enough with the pid thing to release.
[23:24:48] <seb_kuzminsky> that's great!
[23:25:05] <andypugh> tool table?
[23:25:06] <seb_kuzminsky> i need to dust off the tooltable stuff, i'll try to finish it this weekend...
[23:25:12] <cradek> bleh, the merge
[23:25:33] <cradek> merging docs and po is always a thorn in the side
[23:25:41] -!- mackerski has quit [Quit: mackerski]
[23:25:44] <cradek> cool, I would very much like to release this weekend.
[23:25:53] <andypugh> What tooltable stuff?
[23:26:06] <cradek> some sniggly bugs he found
[23:26:21] <cradek> I forget the details, it's been so long :-)
[23:26:31] <andypugh> Ah, OK, not the major rework I said I wanted to do and haven't even started then?
[23:26:38] <cradek> hahah no
[23:26:50] <cradek> I don't remember the details of that either
[23:27:21] <cradek> (and any major rework is not good for 2.5)
[23:27:57] <andypugh> Definitely so if I am involved in the coding, as you saw earlier.
[23:28:34] <cradek> nah, we're all like that!
[23:29:07] -!- skorasaurus has quit [Quit: left the building.]
[23:29:22] <andypugh> I am better with my own code. That was an attempt to figure out what the relevant parts of a rather byzantine structure of Pascal code was doing.
[23:30:00] <andypugh> Turned out remarkably hard.
[23:33:16] <PCW> whats done is pretty simple but the Pascal has so many layers because of universal hardware/protocol support
[23:33:19] <PCW> PCIMEM/EPP/DOS comport/OScomport/MesaUART/LBP protocol/SSLBP protocol/Hex protocol.......
[23:34:13] <andypugh> Indeed. it didn't help that my IDE isn't Pascal-aware so couldn't help with finding out where function definitions were.
[23:36:42] -!- hdokes has quit [Ping timeout: 244 seconds]
[23:38:00] <PCW> Well its nice to see it work
[23:38:02] <PCW> It was also nice to get some B rev 8I20 cards to play with since we dont have any anymore
[23:38:04] <PCW> and we were not even sure the latest code would work on them (it does!)
[23:38:19] <andypugh> Great
[23:38:34] -!- vladimirek has quit [Remote host closed the connection]
[23:38:46] <PCW> we killed our last one accidentally
[23:40:51] <andypugh> How?
[23:41:39] <andypugh> (And if you want to keep one, they are technically yours anyway)
[23:42:22] <PCW> I thing we we measuring the isolated side power consumption and applied 10V to the 3.3V bus accidentally
[23:43:14] <PCW> no they are going back (that they work with R8 code is all we really needed to verify)
[23:43:38] <andypugh> Isn't one a "collectible" 000000 serial number? :-)
[23:43:47] <PCW> we will ship them back monday
[23:44:17] <PCW> oops maybe the serial number got erased!
[23:44:35] <andypugh> I think it matches the sticker?
[23:47:00] <PCW> well it is re-writeable we will put them through the same test procedure we normally do for 8I20s so it will have its serial fixed
[23:50:27] -!- mackerski has quit [Quit: mackerski]
[23:51:32] -!- vax__ has quit [Quit: leaving]
[23:53:19] <seb_kuzminsky> andypugh: here's an older version of the toolno branch i'm working on:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/g10-toolno-pocket-differ-2
[23:53:55] <seb_kuzminsky> i discovered a bug that if the tool number and the pocket number differ on a nonrandom toolchanger machine, some parts of tool handling breaks
[23:54:20] <seb_kuzminsky> ok, i'm off! see you all later
[23:54:30] <andypugh> seb_kuzminsky:
[23:54:35] <andypugh> Afore ye go!
[23:54:52] <andypugh> I think there is a related question on the forum
[23:55:30] <seb_kuzminsky> what
[23:55:59] <andypugh> Is it the same as this?
http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/26078-m06-atc-problem-with-matsuura-fx5
[23:56:28] <seb_kuzminsky> if he's using random it's not the same bug i found
[23:56:41] <andypugh> Ah, OK.
[23:57:19] <andypugh> I would hate to think we had found all the bugs. We would have to start machining stuff!
[23:57:30] <seb_kuzminsky> heh yeah, that would suck
[23:57:45] -!- Nick001-Shop has quit [Remote host closed the connection]
[23:57:47] <seb_kuzminsky> were you able to reproduce his results with that little gcode program?
[23:57:58] <andypugh> I haven't tried
[23:58:15] <seb_kuzminsky> ok
[23:58:19] <andypugh> Too much other stuff on, and no toolchanger experience at all
[23:58:38] <seb_kuzminsky> i understand, believe me! the work is piling up all over
[23:59:16] <seb_kuzminsky> later
[23:59:22] <andypugh> Goodnight