#emc-devel | Logs for 2007-10-23

Back
[06:05:55] <alex_joni> SWPadnos: when it compiles kernel modules it actually cd's to the kernel source dir
[06:06:04] <alex_joni> maybe that's why it doesn't find it :)
[06:23:10] <SWPadnos> I just thought of that when I noticed that it was doing a make -C ...../the_kernel_dir
[06:25:41] <SWPadnos> but it doesn't choke on hal.h, which it also includes
[06:25:47] <SWPadnos> or the various rtapi*.h
[06:53:10] <alex_joni> hmm.. I did it for hal_stg.c
[06:53:13] <alex_joni> include hal_dtg.h
[06:53:17] <alex_joni> but it just worked
[06:53:20] <alex_joni> stg
[06:53:45] <alex_joni> #include "hal_stg.h"/* STG related defines */
[06:53:57] <alex_joni> nothing else added (in makefiles or submakefiles)
[07:19:15] <SWPadnos> hmmm
[07:19:38] <SWPadnos> the header was originally created in the hal/user_comps dir
[07:20:20] <SWPadnos> when the RTcomponent in hal/components couldn't find it, I looked through the makefiles, and Submakefile.skel was helpful there
[07:20:49] <SWPadnos> it mentioned that if you need headers copied, just look at the Submakefiles in rs274ngc or some other places for a sample
[07:21:39] <SWPadnos> so I added the *.h / *.hh copy targets to Submakefile in user_comps, and verified that the header was copied to ../include (right next to hal.h and the rtapi headers)
[07:21:51] <SWPadnos> but it still wasn't found
[07:21:52] <alex_joni> yeah, that's for the usercomps
[07:22:04] <alex_joni> but for the rt stuff, I think it must be in the same place as the module source
[07:22:19] <SWPadnos> hal.h isn't in hal/components
[07:22:45] <SWPadnos> I just turned off that computer (about to go to bed), so I may be wrong about that
[07:23:00] <SWPadnos> but I'm pretty sure the hal and rtapi headers are pulled from ../include
[07:24:17] <SWPadnos> incidentally, you're at least partially right - putting a symlink in hal/components to the file in hal/user_comps did make the build work
[07:24:44] <SWPadnos> so, as they say, eh - whatever. I'm going to bed :)
[07:59:56] <alex_joni> good night
[13:47:29] <skunkworks> jepler: do you want to reply to this? (it wasn't me I swear) http://www.cnczone.com/forums/showthread.php?t=45671
[13:47:41] <skunkworks> if you want to and get a chance.
[13:51:33] <jepler> sure, I'll reply
[13:51:45] <cradek> maybe you should direct him here.
[13:55:37] <skunkworks> In case anyone was wondering.. Me and my wife. http://www.electronicsam.com/images/831266105_e99605a7a6.jpg I am the one on the right. ;)
[14:10:58] <jepler> is this going to sound like a put-down, or does it sound OK? "
[14:10:59] <jepler> If you don't know the difference between a .dsc and a .deb file, the experimental gutsy packages are simply not going to be polished enough for you to use."
[14:11:25] <jepler> s/not going to be/not/
[14:12:48] <cradek> that's a little harsh unless someone is being pushy with you about it
[14:16:06] <jepler> OK
[14:22:52] <jepler> If you want an easy and user-friendly installation procedure, the Ubuntu 6.06 + EMC2 Live CD is still the best option. [url]http://www.linuxcnc.org/content/view/21/4/lang,en/[/url].
[14:22:56] <jepler> When packages for a newer version of Ubuntu [B]do[/B] reach the same level of friendlyness as the Live CD or the emc2-install.sh script for Ubuntu Dapper, there will be a big announcement.
[14:23:00] <jepler> Whether this next version will be Gutsy Gibbon, or whether it will be the next Ubuntu LTS release, remains to be seen.
[14:23:20] <cradek> much better
[14:23:54] <jepler> On the other hand, if you are already comfortable with running dpkg and apt-get at the commandline, the procedure goes something like this: ... If you do install the packages, your feedback about whether the kernel works properly and whether emc2 runs reliably are valuable to me. I'll be keeping an eye on this thread.
[14:28:38] <skunkworks> That sounds nice. Thanks for doing this.
[16:11:19] <alex_joni> hi guys
[16:11:48] <jepler> afternoon alex_joni
[16:14:10] <alex_joni> hey jeff
[16:14:16] <alex_joni> * alex_joni is waiting for a ferry
[16:14:30] <alex_joni> then I'll be out of reach for 2 days
[16:15:14] <alex_joni> question: what does "_tkinter.TclError: Togl: X server has no OpenGL GLX extension" ?
[16:15:16] <alex_joni> mean?
[16:15:48] <cradek> it means the X server has no OpenGL GLX extension
[16:15:55] <alex_joni> extension GLX .. right
[16:16:01] <jepler> it means: verify that glxgears doesn't work either, then fix your X server until it does
[16:16:13] <jepler> or give up and switch to tkemc
[16:16:48] <alex_joni> do you happen to remember what the mesa packages are?
[16:16:55] <jepler> no
[16:17:03] <alex_joni> ok, np
[16:17:32] <jepler> they are in debian/control.in or autogenerated by shlibdeps
[16:17:56] <jepler> but the X server configuration is important too .. you can disable GLX in there
[16:18:09] <jepler> particuarly if you half-install or half-uninstall nvidia or other proprietary graphics drivers
[16:19:49] <alex_joni> ok, cool.. thnaks
[16:19:55] <jepler> that error does not indicate that the client-side OpenGL libraries are missing, but that server-side support is
[16:25:13] <alex_joni> ferry is here
[16:25:17] <alex_joni> see you guys tomorrow :)
[16:27:42] <jepler> have fun whatever it is you're doing
[20:31:02] <alex_joni> yay, found some internet acces in the hotel
[20:33:44] <alex_joni> jepler: another AXIS bugreport
[20:34:18] <alex_joni> with this file (http://www.peters-cnc-ecke.de/forumupload/uploadFiles/19887_156_problemtest.zip) the guy reported he doesn't see all the 4 spirals in the preview
[20:34:36] <alex_joni> (here's a snapshot of how it looks: http://s3.bilder-hosting.de/img/1AI02.jpg)
[20:35:04] <alex_joni> however, it's not an emc2 problem, as it runs correctly (here's a snapshot after it ran: http://s3.bilder-hosting.de/img/1BK3V.jpg)
[20:35:11] <jepler> oh I bet those are very stupid arcs
[20:35:41] <alex_joni> I tried the file, and it works right for me
[20:35:44] <cradek> looks fine here
[20:35:47] <alex_joni> so did another user
[20:35:55] <alex_joni> it seems to happen on his platform only
[20:36:08] <alex_joni> (initially he had a LiveCD, and got the problem)
[20:36:19] <alex_joni> now he has a debian + latest CVS TRUNK
[20:36:26] <alex_joni> and still reports the same issue
[20:36:44] <alex_joni> any ideas what I should ask him to try?
[20:36:54] <jepler> get a pentium without the fdiv bug?
[20:37:12] <cradek> 2.000000 temp. speed up loading due to fucking sandbox
[20:37:14] <jepler> for arcs where endpoint ~ startpoint, it's necessary to test whether the arc is very nearly zero degrees, or very nearly zero degrees
[20:37:23] <alex_joni> Pentium IV 1.5gHz
[20:37:39] <alex_joni> cradek: :P
[20:37:41] <cradek> o100 sub (extremly fascinating hole milling)
[20:37:42] <cradek> haha
[20:37:44] <jepler> those tests are after the "canon" calls and the logic and rounding rules can't be exactly the same in the C and the Pyhton code
[20:37:51] <jepler> s/Pyhton/Python/
[20:37:56] <jepler> that's the only arc preview bug I'm aware of
[20:38:17] <alex_joni> "the arc is very nearly zero degrees, or very nearly
[20:38:18] <alex_joni> zero degrees"
[20:38:31] <alex_joni> is that supposed to make sense?
[20:38:51] <cradek> he should try to make the simplest possible program that reproduces the bug
[20:39:25] <cradek> O101 if [#5 eq #6]
[20:39:24] <cradek> #6 = [#6 - 0.00000001]
[20:39:24] <cradek> O101 endif
[20:39:49] <cradek> for instance, that simplest possible program wouldn't have stuff like this in it
[20:40:13] <jepler> that might be the key
[20:40:28] <jepler> "very nearly zero degrees, or very nearly 360 degrees"
[20:40:48] <jepler> suppose the start is x=0 y=0 exactly; the end is x=0 exactly and y=1e-5
[20:41:01] <jepler> was the gcode supposed to express a full circle or nearly no movement?
[20:41:53] <alex_joni> I think he might have a full circle at the end of the helix
[20:43:32] <cradek> also looks fine in emc 2.1.7
[20:43:58] <alex_joni> cradek: wonder if a work offset != 0 might affect this or not
[20:45:00] <jepler> "fix full circles not appearing on some machines" http://cvs.linuxcnc.org/cvs/axis-historical/rs274/interpret.py.diff?r1=1.10;r2=1.11
[20:45:32] <cradek> blarrrgh
[20:46:26] <alex_joni> jepler: the odd thing is that there are 4 identical helixes+circles in that program
[20:46:31] <jepler> if(rotation < 0) {
[20:46:31] <jepler> if(theta2 >= theta1) theta2 -= M_PI * 2.0;
[20:46:31] <jepler> } else {
[20:46:31] <jepler> if(theta2 <= theta1) theta2 += M_PI * 2.0;
[20:46:31] <jepler> }
[20:46:33] <alex_joni> and only one doesn't appear
[20:46:42] <jepler> here's the similar code in emccanon.cc
[20:47:51] <alex_joni> I don't understand why the helixes don't show
[20:48:02] <alex_joni> I agree the circle might be beacause of what you are saying..
[20:48:15] <alex_joni> but there should be 2 helixes before the final full circle
[20:48:35] <cradek> the rotation/theta calc would be the same whether or not it's a elix
[20:48:36] <cradek> h
[20:48:42] <alex_joni> oh, those are also with theta2=theta1
[20:48:47] <alex_joni> right
[20:48:51] <alex_joni> * alex_joni is tired :)
[20:49:03] <alex_joni> too many circles/helixes lately
[20:49:09] <jepler> for a full circle, theta2 is nearly exactly the same as theta1 (they're both at the same angle from the center)
[20:49:10] <cradek> yeah
[20:49:16] <jepler> so was a full circle or no movement intended?
[20:49:22] <alex_joni> full circle
[20:49:30] <jepler> axis thinks otherwise
[20:49:44] <cradek> ideally they would agree...
[20:49:51] <alex_joni> haha
[20:50:00] <cradek> * cradek states the obvious
[20:51:04] <alex_joni> oh, btw.. wonder who can guess where I am :D
[20:51:43] <jepler> I got it to happen
[20:51:49] <alex_joni> oh, cool
[20:52:04] <jepler> after monkeying with offsets
[20:52:17] <cradek> wild
[20:54:25] <jepler> (3.1415926535897931, 3.1415926535897931, 0.0, -1)
[20:54:34] <jepler> print (theta1, theta2, theta1-theta2, rot)
[20:55:25] <jepler> (-3.1415926535897927, 3.1415926535897931, -6.2831853071795862, -1)
[20:55:41] <alex_joni> -6 ?
[20:56:27] <alex_joni> oh, 2*pi
[20:56:59] <jepler> atan2 has a discontinuity at x<0, y=0 .. here, the two values end up straddling that discontinuity
[21:02:31] <jepler> anyway .. at machine origin, I made my x and y offsets 1.001 (I think), then reloaded the file
[21:02:35] <jepler> this seems to fix it: http://pastebin.ca/747235
[21:02:55] <jepler> in this unusual circumstance, it can require 2PI to be added twice before the angles are in the right "order"
[21:05:48] <jepler> * jepler throws caution to the wind and commits his fix
[21:07:57] <alex_joni> ;)
[21:08:01] <alex_joni> jepler: thanks for looking at it
[21:11:30] <alex_joni> good night all
[21:23:50] <jepler> good night