Back
[00:13:33] <jepler> jthornton: don't you use g92? want to run with that patch ^^ and let us know if it creates problems?
[00:14:05] <jepler> only wrinkle we're aware of is the first time you run after applying the patch, g92 won't be in effect. after that it'll be in effect if it was active when you exited the previous time..
[00:54:00] <andypugh> xie on #emc turns out not to want to write a new gui, but to localise it to chinese. Any links/suggestions?
[00:57:13] <andypugh> Which raises another question, should I be considering internationalisation when writing my stuff?
[02:19:04] <jepler> many parts of emc can be localized. see src/po/README for details
[02:44:01] <voxadam> Is there any work being done to port EMC to CONFIG_PREEMPT_RT Linux systems?
[03:17:54] <jepler> voxadam: not actively. I dabbled with it back in 2007 -
http://emergent.unpy.net/01190912545 - but the major problems with that work are that it's not low-jitter enough for software step generation (probably still the majority of our users) and it requires rewriting our hardware drivers to run as userspace programs. I also dabbled in 2009 with an in-kernel approach (which would mean very little driver rewriting) but never integra
[03:18:56] <voxadam> I guess the RTAI approach works. there's no real reason to screw with it.
[03:19:35] <jepler> personally I worry that if we got PREEMPT_RT working it would still be very confusing for our users; if you have a parport stepper machine and download the wrong emc, it'll work much less well or not at all than emc on top of rtai
[03:20:00] <jepler> link to in-kernel approach, called kth (for the abstraction like hal threads) + kshm (for the abstraction like rtai shared memory:
http://git.unpy.net/view?p=kshm.git;a=summary
[03:21:37] <SWP_Away> SWP_Away is now known as SWPLinux
[03:23:00] <jepler> if I believed that PREEMPT_RT would work for our stepper users without sacrificing step rates I'd be much more interested; if we could get away with support for PREEMPT_RT only it would take away the major pain of supporting new ubuntu releases which is preparing a kernel that will run on a substantial fraction of users PCs
[03:23:18] <jepler> night
[03:23:21] <voxadam> ight.
[12:05:48] <jthornton> jepler, I can try the patch later today when it is too hot to work outside
[12:07:08] <jthornton> just trying to install mozmck emc2.4.1 and I get "Error: Dependency is not satisfiable: bwidget (>= 1.7)"
[12:07:45] <jthornton> I've installed headers, image, tools, and rtai and rebooted...
[12:11:21] <cradek> ii bwidget 1.9.0-2 A set of extension widgets for Tcl/Tk
[12:11:52] <cradek> ah - it's in universe - enable that
[12:12:04] <jthornton> ok, I forgot to do that
[12:13:00] <jthornton> hmm universe is all ready enabled
[12:15:49] <jepler> had you installed 2.4.0 earlier on that machine? if so I can't imagine why bwidget would be a problem now.
[12:17:55] <jthornton> no this is a fresh install... I just found bwidget in the synaptic package manager and am installing it now
[12:18:30] <jepler> well great -- now cl is just crashing
[12:18:30] <jepler> ==8670== Invalid read of size 1
[12:18:30] <jepler> ==8670== at 0x41A28C: TreatModbusMasterResponse (protocol_modbus_master.c:492)
[12:18:39] <jepler> ==8670== Address 0x634000 is not stack'd, malloc'd or (recently) free'd
[12:23:01] <jthornton> installing bwidget with the synaptic package manager fixed that... 2.4.1 is installing now
[12:24:04] <jepler> unsigned short CalcCRC = CRC16( &Response[ 0 ], LgtResponse-2 ) ;
[12:24:14] <jepler> INFO CLASSICLADDER- Modbus I/O module received: Lgt=1 -> (Slave address-A -
[12:24:18] <jepler> aha, it becomes clear
[12:31:42] <jepler> (passing a length of -1 to CRC16 is bad)
[13:52:53] <cradek> jepler:
http://timeguy.com/cradek-files/emc/0001-Normalize-access-to-q_number-q_flag.patch
[15:32:03] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[16:11:17] <cradek> jepler: I think I should push the g92 fix to v2.4 (and merge to master) - ok with you?
[16:25:25] <CIA-4> EMC: 03cradek 07master * r5ac91f2d7835 10/src/emc/ (5 files in 4 dirs): remove SPLINE canon calls and use NURBS instead
[16:25:26] <CIA-4> EMC: 03cradek 07master * r5f64a07f5997 10/src/emc/task/emccanon.cc: avoid division by zero
[16:25:27] <CIA-4> EMC: 03cradek 07master * r7ed7a64c8446 10/src/emc/rs274ngc/ (interp_internal.cc interp_internal.hh interp_read.cc): Make it possible to check whether Q is specified
[16:25:31] <CIA-4> EMC: 03cradek 07master * r1897c1992869 10/src/emc/rs274ngc/interp_convert.cc: G5 without P, Q is an error; diagnose it
[16:25:32] <CIA-4> EMC: 03cradek 07master * r8cdc465a037c 10/src/emc/rs274ngc/gcodemodule.cc: remove outdated comments
[16:25:32] <CIA-4> EMC: 03cradek 07master * r5ee9249f3bb7 10/src/emc/ (3 files in 3 dirs): provide a function to calculate nurbs tangent
[16:25:43] <CIA-4> EMC: 03cradek 07master * rd27fb2504436 10/src/emc/task/emccanon.cc: fix G1 followed by G5.x
[16:25:55] <CIA-4> EMC: 03cradek 07master * r677e20ce008f 10/src/hal/utils/comp.g: don't emit MODULE_LICENSE repeatedly
[16:25:55] <CIA-4> EMC: 03cradek 07master * r610a4726b394 10/src/emc/rs274ngc/ (interp_array.cc interp_convert.cc rs274ngc_pre.cc): Save state of G92 correctly across restarts
[16:25:57] <CIA-4> EMC: 03cradek 07master * rf5ed00277d39 10/src/ (12 files in 5 dirs): Merge branch 'v2.4_branch'
[18:08:39] <SWPLinux> http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/id,3126/catid,27/
[18:55:51] <Roguish> got them.. thanks
[18:56:43] <Roguish> i am trying to drive simple bldc's without spendign $200+ per motor on drives.
[18:57:31] <Roguish> 7i39 is $75 per motor.
[18:58:06] <andypugh> They work nicely, and do two motors each.
[18:58:45] <Roguish> i think they will plug into the 5i20 directly..... and go.
[18:58:53] <andypugh> If you want even cheaper, there are off-the-shelf power modules
[18:59:30] <andypugh> But yes, 7i39 plugs straight into 5i20 and works. That is exactly what is in that HAL file you haven't picked up yet.
[19:36:40] <andypugh> Hmm,
[19:36:41] <andypugh> checking whether to build documentation... HTML requested
[19:36:42] <andypugh> checking for lyx... /usr/bin/lyx
[19:36:42] <andypugh> checking for LyX version... 1.5.3
[19:36:42] <andypugh> checking for convert... none
[19:36:42] <andypugh> configure: error: no convert, documentation cannot be built
[19:37:23] <andypugh> Any cue what package "convert" is part of?
[19:40:15] <cradek> imagemagick
[19:41:00] <andypugh> Thanks
[19:41:38] <andypugh> dvipng?
[19:43:04] <andypugh> As in, it gets 5 lines further and gives up on dvipng
[19:44:02] <andypugh> Ah, OK, that one finds itself
[20:15:14] <cradek> origin = self.to_internal_units(s.g5x_offset + s.g92_offset)[:3]
[20:16:06] <jepler> [a+b for a,b in zip(s.g5x_offset, s.g92_offset)]
[20:22:02] <SWPLinux> andypugh: it may not always work, but if you type a command at a bash prompt, and it's not installed, you'll get a list of packages that might provide that command/program
[20:22:25] <andypugh> Ah, OK.
[20:23:17] <andypugh> I am a Linux noob, as you can tell. Heck I am a command-line noob. Part of the GUI generation me. (I lied about my age when I applied)
[20:41:25] <cradek> that's a fun difference: a = b = [] vs a = [], b = []
[20:42:10] <jepler> cradek: sure is
[21:02:01] <tom3p> m5i20 P2 pin1 "B1" according to SVST*_$.PIN
[21:02:02] <tom3p> m5i20 P2 pin1 "B1" according to
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Mesa_Cards#5i20
[21:02:02] <tom3p> m5i20 P2 pin1 "enc01 A input" www.linuxcnc.org/docs/EMC2_Intergrator_Manual.pdf
[21:02:02] <tom3p> i think its really B1 ( B phase of 2nd encoder )
[21:02:31] <tom3p> argh SVST8_4.PIN on 1st line, sorry
[21:07:47] <SWPLinux> quit using your Windoe
[21:07:50] <SWPLinux> oops
[21:08:58] <SWPLinux> tom3p: dmesg will be correct. I think the HM2 drivers print their pinouts when they load
[21:10:59] <tom3p> SWPadnos, will look at dmesg, thx, i didnt load them, i was trying to layout the panel and was stumped at 1st connector 1st pin.
[21:13:49] <SWPLinux> hrh
[21:13:50] <SWPLinux> heh
[21:13:54] <SWPLinux> baad start, eh?
[21:13:56] <SWPLinux> -a
[21:14:49] <tom3p> i spose thats why they make wires bendy :)
[21:15:02] <SWPLinux> heh, and screw terminals :)
[21:21:17] <alex_joni> so they can screw you?
[21:21:28] <SWPLinux> bendy over, I Guess
[21:21:56] <alex_joni> ouch :D
[21:25:00] <tom3p> bendy so they can go to the real destination rather than what document # 1 says
[21:49:14] <tom3p> thx all
[22:48:54] <andypugh> I am baffled. Perhaps I am addressing something wrong?
[22:49:06] <andypugh> gain = 0.0001 * sqrt((pos->tran.x - old.x) * (pos->tran.x - old.x)
[22:49:06] <andypugh> + (pos->tran.y - old.y) * (pos->tran.y - old.y));
[22:49:18] <andypugh> And then DX = DX + gain * (DX - (pos->tran.x - old.x));
[22:50:15] <andypugh> I am seeing DX = -2263969 which seems implausible in the context of something that only adds and subtracts joint positions.
[22:50:54] <andypugh> Oh, DX is a macro for legibility: #define DX (*(haldata->dx))
[22:52:17] <andypugh> If I was dividing anywhere then the number might be possibly a result of maths. As it is I assume it is a result of faulty coding?
[22:53:38] <SWPLinux> hmm
[22:54:03] <andypugh> How does C tell the difference between unary * and binary *?
[22:54:20] <SWPLinux> operator precedence rules
[22:54:34] <SWPLinux> also, "*4" makes no sense
[22:54:40] <SWPLinux> or *fred
[22:54:52] <SWPLinux> unless fred is a pointer
[22:55:24] <andypugh> Yeah, I can't think of a valid statement where it is ambiguous, but then I am a boob.
[22:55:43] <andypugh> A noob, even. I might be a boob too, of course.
[22:55:47] <SWPLinux> heh
[22:55:49] <SWPLinux> a boob noob
[22:56:21] <andypugh> Anyway, I guess that you can't see how those statements can do that?
[22:58:11] <andypugh> X and Y appear to be 0.6 and -2.8 respectively, oldx and oldy are unlikely to be very different.
[22:58:31] <andypugh> Ah, perhaps I am guilty of a misunderstanding of C?
[22:58:54] <SWPLinux> I don't know what that haldata is, so I'm at somewhat of a disadvantage
[22:59:13] <andypugh> Is the problem in a much later line? old = pos->tran ?
[22:59:19] <SWPLinux> is there a copy of some relatively recent code online?
[22:59:26] <SWPLinux> yes that could be a problem
[22:59:56] <andypugh> Can I do that? old and pos->tran are both PmCartesian objects, but maybe I cant set one equal to the other like that?
[23:00:07] <SWPLinux> it can't be C++, so you probably don't get the default element by element copy
[23:00:17] <SWPLinux> no, they're structs, not objects
[23:00:20] <SWPLinux> this is kernel code :)
[23:00:27] <andypugh> Bah!
[23:00:47] <andypugh> OK, that has to be worth a try then.
[23:01:13] <andypugh> I guess old.x = pos->tran.x will be OK?
[23:01:26] <SWPLinux> well, it may work, hold on a sec
[23:01:37] <SWPLinux> or maybe it's supposed to work
[23:02:34] <SWPLinux> sure
[23:03:18] <andypugh> What's the point of structs if you can't handle them like discrete objects?
[23:03:56] <SWPLinux> heh
[23:04:05] <SWPLinux> well, supposedly you can, I was wrong
[23:04:21] <andypugh> Oh.
[23:05:07] <andypugh> OK, perhaps is it because I forgot to static old?
[23:05:23] <andypugh> It has file-level scope, but perhaps that isn't enough?
[23:06:03] <SWPLinux> it shouldn't matter
[23:06:31] <SWPLinux> actually, maybe you should have two old vars, one for forward and one for inverse kins
[23:06:32] <andypugh> So, it should have the value it was last given next time the function is called?
[23:06:38] <SWPLinux> one for joints, the other for the post
[23:06:40] <SWPLinux> pose
[23:06:57] <SWPLinux> those would go inside the functions, but would still be static so they retain their values between invocations
[23:07:12] <andypugh> Forward kins doesn't need to know the old position.
[23:07:45] <SWPLinux> ok, in that case you might as well put "old" In the inverse kins function, since it isn't needed elsewhere
[23:07:59] <andypugh> There is an unambiguous solution to the forward kins
[23:08:08] <andypugh> But static, right?
[23:08:21] <SWPLinux> yes
[23:08:29] <SWPLinux> that's what makes it keep its value
[23:09:24] <andypugh> OK, 'tis now static and the .x and .y are set explicitly. If it still goes wrong I will assume I am indirecting or pointering wrong somewhere
[23:09:39] <jepler> put each input into the suspect equation onto a pin and scope it
[23:09:44] <SWPLinux> yeah, and post the whole code somewhere if you still need help :)
[23:10:18] <jepler> imo it's more likely that you're mistaken about the value of something than that you're dereferencing a pointer you didn't mean to.
[23:10:47] <andypugh> Here is all the code.
http://www.pastebin.ca/1887384
[23:12:17] <andypugh> I am mostly interested in how taperkins.dx and taperkins.dy as HAL pins start off sensible (tiny little values as you would expect for how far an axis moves in a millisecond) then suddenly hit 22 million.
[23:13:22] <andypugh> I am in the process of going through the actual geometry, but can't even test at the moment as stupid DX and DY values f-error things as soon as I go to world mode.
[23:18:59] <SWPLinux> is the dx pin attached to anything?
[23:19:05] <SWPLinux> or dy
[23:19:19] <andypugh> In HAL? No
[23:19:33] <andypugh> They are put there purely so I can see what is going on
[23:19:58] <andypugh> So they are attached to a HALmeter, but are RO pins anyway.
[23:19:59] <SWPLinux> then maybe they should be output pins instead of input ...
[23:20:05] <SWPLinux> like they are
[23:20:08] <SWPLinux> * SWPLinux learns to read
[23:21:10] <SWPLinux> well, it is an accumulator
[23:21:17] <SWPLinux> DX=DX+(xxx)
[23:21:52] <jepler> if you're not moving DX=DX + gain*DX
[23:21:56] <jepler> so it will "fly away" from 0
[23:22:16] <andypugh> Yes.
[23:22:21] <SWPLinux> if it ever got nonzero
[23:23:53] <andypugh> It is meant to converge to (pos->tran.x - old.x)
[23:24:24] <andypugh> IIt appears I might have got it wrong.
[23:24:52] <andypugh> Though it isn't running away now.
[23:25:36] <andypugh> I might well have the terms back to front in my lowpass.
[23:26:46] <SWPLinux> DX = DX * (1-gain) + (new_target * gain)
[23:27:00] <andypugh> Yes, I misread the Wiki page (I was too lazy to work it out from first principles)
[23:27:06] <SWPLinux> assuming you want DX to eventually be new_target
[23:27:09] <SWPLinux> heh
[23:28:31] <andypugh> Wiki gas y[i] := y[i-1] + α * (x[i] - y[i-1])
[23:29:07] <andypugh> which is pretty much the same as yours expanded, but neglecting a term
[23:32:38] <andypugh> I misread the Wiki page while composing code in an email with no access to a compiler, or EMC. I should know better reallt.
[23:38:33] <andypugh> I wonder which pin is best to look at to see what is exceeding the positive soft limit on Joint 0? axis.0.motor-pos-cmd is showing 0.0048 as are all the other position and feedback pins.
[23:40:30] <andypugh> axis.0 has the limits set -500 to +500 in the INI, and homes to zero.