jthornton: don't you use g92? want to run with that patch ^^ and let us know if it creates problems?
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..
xie on #emc turns out not to want to write a new gui, but to localise it to chinese. Any links/suggestions?
Which raises another question, should I be considering internationalisation when writing my stuff?
many parts of emc can be localized. see src/po/README for details
Is there any work being done to port EMC to CONFIG_PREEMPT_RT Linux systems?
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
I guess the RTAI approach works. there's no real reason to screw with it.
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
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
SWP_Away is now known as SWPLinux
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
jepler, I can try the patch later today when it is too hot to work outside
just trying to install mozmck emc2.4.1 and I get "Error: Dependency is not satisfiable: bwidget (>= 1.7)"
I've installed headers, image, tools, and rtai and rebooted...
ii bwidget 1.9.0-2 A set of extension widgets for Tcl/Tk
ah - it's in universe - enable that
ok, I forgot to do that
hmm universe is all ready enabled
had you installed 2.4.0 earlier on that machine? if so I can't imagine why bwidget would be a problem now.
no this is a fresh install... I just found bwidget in the synaptic package manager and am installing it now
well great -- now cl is just crashing
==8670== Invalid read of size 1
==8670== at 0x41A28C: TreatModbusMasterResponse (protocol_modbus_master.c:492)
==8670== Address 0x634000 is not stack'd, malloc'd or (recently) free'd
installing bwidget with the synaptic package manager fixed that... 2.4.1 is installing now
unsigned short CalcCRC = CRC16( &Response[ 0 ], LgtResponse-2 ) ;
INFO CLASSICLADDER- Modbus I/O module received: Lgt=1 -> (Slave address-A -
aha, it becomes clear
(passing a length of -1 to CRC16 is bad)
SWPadnos_ is now known as SWPadnos
jepler: I think I should push the g92 fix to v2.4 (and merge to master) - ok with you?
EMC: 03cradek 07master * r5ac91f2d7835 10/src/emc/ (5 files in 4 dirs): remove SPLINE canon calls and use NURBS instead
EMC: 03cradek 07master * r5f64a07f5997 10/src/emc/task/emccanon.cc: avoid division by zero
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
EMC: 03cradek 07master * r1897c1992869 10/src/emc/rs274ngc/interp_convert.cc: G5 without P, Q is an error; diagnose it
EMC: 03cradek 07master * r8cdc465a037c 10/src/emc/rs274ngc/gcodemodule.cc: remove outdated comments
EMC: 03cradek 07master * r5ee9249f3bb7 10/src/emc/ (3 files in 3 dirs): provide a function to calculate nurbs tangent
EMC: 03cradek 07master * rd27fb2504436 10/src/emc/task/emccanon.cc: fix G1 followed by G5.x
EMC: 03cradek 07master * r677e20ce008f 10/src/hal/utils/comp.g: don't emit MODULE_LICENSE repeatedly
EMC: 03cradek 07master * r610a4726b394 10/src/emc/rs274ngc/ (interp_array.cc interp_convert.cc rs274ngc_pre.cc): Save state of G92 correctly across restarts
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/
got them.. thanks
i am trying to drive simple bldc's without spendign $200+ per motor on drives.
7i39 is $75 per motor.
They work nicely, and do two motors each.
i think they will plug into the 5i20 directly..... and go.
If you want even cheaper, there are off-the-shelf power modules
But yes, 7i39 plugs straight into 5i20 and works. That is exactly what is in that HAL file you haven't picked up yet.
checking whether to build documentation... HTML requested
checking for lyx... /usr/bin/lyx
checking for LyX version... 1.5.3
checking for convert... none
configure: error: no convert, documentation cannot be built
Any cue what package "convert" is part of?
As in, it gets 5 lines further and gives up on dvipng
Ah, OK, that one finds itself
origin = self.to_internal_units(s.g5x_offset + s.g92_offset)[:3]
[a+b for a,b in zip(s.g5x_offset, s.g92_offset)]
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
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)
that's a fun difference: a = b =  vs a = , b = 
cradek: sure is
m5i20 P2 pin1 "B1" according to SVST*_$.PIN
m5i20 P2 pin1 "B1" according to http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Mesa_Cards#5i20
m5i20 P2 pin1 "enc01 A input" www.linuxcnc.org/docs/EMC2_Intergrator_Manual.pdf
i think its really B1 ( B phase of 2nd encoder )
argh SVST8_4.PIN on 1st line, sorry
quit using your Windoe
tom3p: dmesg will be correct. I think the HM2 drivers print their pinouts when they load
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.
baad start, eh?
i spose thats why they make wires bendy :)
heh, and screw terminals :)
so they can screw you?
bendy over, I Guess
bendy so they can go to the real destination rather than what document # 1 says
I am baffled. Perhaps I am addressing something wrong?
gain = 0.0001 * sqrt((pos->tran.x - old.x) * (pos->tran.x - old.x)
+ (pos->tran.y - old.y) * (pos->tran.y - old.y));
And then DX = DX + gain * (DX - (pos->tran.x - old.x));
I am seeing DX = -2263969 which seems implausible in the context of something that only adds and subtracts joint positions.
Oh, DX is a macro for legibility: #define DX (*(haldata->dx))
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?
How does C tell the difference between unary * and binary *?
operator precedence rules
also, "*4" makes no sense
unless fred is a pointer
Yeah, I can't think of a valid statement where it is ambiguous, but then I am a boob.
A noob, even. I might be a boob too, of course.
a boob noob
Anyway, I guess that you can't see how those statements can do that?
X and Y appear to be 0.6 and -2.8 respectively, oldx and oldy are unlikely to be very different.
Ah, perhaps I am guilty of a misunderstanding of C?
I don't know what that haldata is, so I'm at somewhat of a disadvantage
Is the problem in a much later line? old = pos->tran ?
is there a copy of some relatively recent code online?
yes that could be a problem
Can I do that? old and pos->tran are both PmCartesian objects, but maybe I cant set one equal to the other like that?
it can't be C++, so you probably don't get the default element by element copy
no, they're structs, not objects
this is kernel code :)
OK, that has to be worth a try then.
I guess old.x = pos->tran.x will be OK?
well, it may work, hold on a sec
or maybe it's supposed to work
What's the point of structs if you can't handle them like discrete objects?
well, supposedly you can, I was wrong
OK, perhaps is it because I forgot to static old?
It has file-level scope, but perhaps that isn't enough?
it shouldn't matter
actually, maybe you should have two old vars, one for forward and one for inverse kins
So, it should have the value it was last given next time the function is called?
one for joints, the other for the post
those would go inside the functions, but would still be static so they retain their values between invocations
Forward kins doesn't need to know the old position.
ok, in that case you might as well put "old" In the inverse kins function, since it isn't needed elsewhere
There is an unambiguous solution to the forward kins
But static, right?
that's what makes it keep its value
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
put each input into the suspect equation onto a pin and scope it
yeah, and post the whole code somewhere if you still need help :)
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.
Here is all the code. http://www.pastebin.ca/1887384
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.
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.
is the dx pin attached to anything?
In HAL? No
They are put there purely so I can see what is going on
So they are attached to a HALmeter, but are RO pins anyway.
then maybe they should be output pins instead of input ...
like they are
* SWPLinux learns to read
well, it is an accumulator
if you're not moving DX=DX + gain*DX
so it will "fly away" from 0
if it ever got nonzero
It is meant to converge to (pos->tran.x - old.x)
IIt appears I might have got it wrong.
Though it isn't running away now.
I might well have the terms back to front in my lowpass.
DX = DX * (1-gain) + (new_target * gain)
Yes, I misread the Wiki page (I was too lazy to work it out from first principles)
assuming you want DX to eventually be new_target
Wiki gas y[i] := y[i-1] + α * (x[i] - y[i-1])
which is pretty much the same as yours expanded, but neglecting a term
I misread the Wiki page while composing code in an email with no access to a compiler, or EMC. I should know better reallt.
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.
axis.0 has the limits set -500 to +500 in the INI, and homes to zero.