Back
[01:21:33] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: Fix bad interaction between 'option personality' and 'option extra_setup'
[01:34:37] <jepler> hm, I guess it's not 'option personality', you get a personality by having a pin construct that requires it
[01:43:22] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: allow default personality to be specified
[01:44:50] <jepler> crap, I ran out of dapper machines to edit docs on :-/
[02:09:22] <jepler> I must have at least a VM here somewhere!
[04:22:47] <seb_kuzminsky> i can reproduce at least part of micges' problem with the hm2 stepgen reversing direction
[12:11:57] <jepler> seb: that's good to hear .. I think
[12:12:47] <jepler> there are a number of items I already want to address in 2.3.2 -- two I should have remembered for 2.3.1 but forgot, then this item and the comp bug discovered by swp yesterday
[12:12:55] <jepler> (or the one that swp's questions led me to discover, perhaps)
[12:57:32] <SWPLinux> jepler: I get these warnings, and extra_setup doesn't seem to run:
http://pastebin.ca/1426369
[12:57:39] <SWPLinux> I have to run though, so see you later :)
[12:58:41] <jepler> you didn't show me the source so I can't tell you where the problem lies
[16:53:48] <seb_kuzminsky> http://michaeldehaan.net/2009/05/17/oss-pitfalls/
[16:59:11] <cradek> seb_kuzminsky: I also liked looking through
http://producingoss.com/en/index.html
[17:37:06] <steves_logging> does anyone know about net access at Fest? wired? wireless?
[17:37:16] <steves_logging> steves_logging is now known as steve_stallings
[17:43:55] <skunkworks> steve_stallings: How is it going? My h-bridge is coming along - no smoke at 180v 20a
[17:44:15] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/schem/latestcurrentlimit/right.JPG
[17:44:30] <skunkworks> (so far)
[17:49:19] <mshaver> From the 1st link, I especially like, "...continually fight to keep things simple and keep the code extensible enough so that no addition becomes unduly burdensome. This is easier said than done".
[17:49:31] <seb_kuzminsky> so true
[17:49:59] <seb_kuzminsky> Stated another way: "Optimize for folk reading the code." -- Robert Collins
[17:56:46] <alex_joni> that was one of the earlier goals of emc2
[17:56:56] <alex_joni> choose readability in favour of performance
[18:06:25] <steve_stallings> steve_stallings is now known as steves_logging
[18:08:57] <tfmacz> Has anyone compiles EMC2 to run a Sim on 9.04?
[18:10:49] <cradek> are you having trouble? getting an error?
[18:14:51] <tfmacz> Thanks Chris, I have been able to get EMC2 to configure and compile from CVS
[18:15:07] <tfmacz> When I run it I get a bunch of errors???
[18:15:20] <cradek> and they say...?
[18:15:51] <tfmacz> ted@ve7tfm-0:~$ emc2-trunk/scripts/emc
[18:15:51] <tfmacz> EMC2 - 2.4.0~pre
[18:15:51] <tfmacz> Machine configuration directory is '/home/ted/emc2-trunk/configs/sim'
[18:15:51] <tfmacz> Machine configuration file is 'axis.ini'
[18:15:51] <tfmacz> Starting EMC2...
[18:15:53] <tfmacz> Traceback (most recent call last):
[18:15:55] <tfmacz> File "/home/ted/emc2-trunk/bin/axis", line 3790, in <module>
[18:15:57] <tfmacz> o = MyOpengl(widgets.preview_frame, width=400, height=300, double=1, depth=1)
[18:15:59] <tfmacz> File "/home/ted/emc2-trunk/bin/axis", line 345, in __init__
[18:16:01] <tfmacz> Opengl.__init__(self, *args, **kw)
[18:16:03] <tfmacz> File "/home/ted/emc2-trunk/lib/python/rs274/OpenGLTk.py", line 219, in __init__
[18:16:05] <tfmacz> apply(RawOpengl.__init__, (self, master, cnf), kw)
[18:16:07] <tfmacz> File "/home/ted/emc2-trunk/lib/python/rs274/OpenGLTk.py", line 167, in __init__
[18:16:09] <tfmacz> Togl.__init__(self, master, cnf, **kw)
[18:16:11] <tfmacz> File "/home/ted/emc2-trunk/lib/python/rs274/OpenGLTk.py", line 93, in __init__
[18:16:13] <tfmacz> Widget.__init__(self, master, 'togl', cnf, kw)
[18:16:15] <tfmacz> File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1935, in __init__
[18:16:17] <tfmacz> (widgetName, self._w) + extra + self._options(cnf))
[18:16:19] <tfmacz> _tkinter.TclError: NULL main window
[18:16:23] <tfmacz> Shutting down and cleaning up EMC2...
[18:16:25] <tfmacz> Cleanup done
[18:16:27] <tfmacz> EMC terminated with an error. You can find more information in the log:
[18:16:29] <tfmacz> /home/ted/emc_debug.txt
[18:16:31] <tfmacz> and
[18:16:33] <tfmacz> /home/ted/emc_print.txt
[18:16:35] <tfmacz> as well as in the output of the shell command 'dmesg' and in the terminal
[18:16:37] <tfmacz> ted@ve7tfm-0:~$
[18:16:53] <cradek> hmm, I haven't seen that one. does your install have working opengl?
[18:19:15] <jepler> (when pasting more than a few lines, consider using a paste website like
http://pastebin.ca/)
[18:19:28] <tfmacz> I had to install a bunch of stuff to get this to compile??? how do I checl this? sorry new to this compile stuff?????
[18:20:04] <tfmacz> sorry, will use pastebin from now on...
[18:21:56] <jepler> ubuntu 9.04 defaults to different versions of python, tcl, and tk than 8.04 and 6.06. related irc conversation:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-03-24.txt continuing to
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-03-25.txt but your error isn't quite the same as the ones SWPadnos ran into
[18:24:31] <jepler> if spending time sleuthing down which versions of which packages are required -- and which must be removed to get a working compile -- I recommend using 8.04 for emc2.
[18:25:05] <tfmacz> would this have anything to do with my nvidia graphics card driver? I am using the proprietary driver.
[18:25:41] <jepler> nothing can be ruled out
[18:25:51] <jepler> er
[18:26:07] <jepler> I meant to say: if spending time sleuthing doesn't appeal to you
[18:26:24] <cradek> nvidia should be ok for sim - IF you have their driver installed right and working
[18:27:13] <jepler> bbl
[18:27:24] <tfmacz> I was using a cvs compile on 8.04 because of video driver issues with the realtime kernel. I use the sim to verify the gcode befor I go out to the shhop to machine something.
[18:29:03] <tfmacz> A power bump trashed the operating system so jumped to 9.04. I recognise the need for the development to follow the LTS. I support that idea. I am running 8.04 on both machines in the shop.
[18:30:20] <tfmacz> just hoped to be able to continue to use an axis-sim here in the office to check out the gcode.
[19:02:34] <tfmacz> For what it is worth, I can run most of the "sim". It is on;y axis that won't run???? as you say probably an OpenGL issue. I will follow that...
[19:19:14] <tfmacz> Thanks...This machine runs very well with 9.04...gigs of ram, tb of hd, dual 21" displays. If I could just find a usb web-cam that works all would be perfect.
[19:19:41] <tfmacz> Oh, and get axis to work....
[19:38:43] <tfmacz> I must say thankyou to Jeff and Chris. read through the linked earlier discussions. adding tcl8.5-dev tk8.5-dev seems to have fixed the problem. now have sim-axis running....again thanks...U guys rock!!!
[19:42:20] <tfmacz> proof positive...
http://imagebin.ca/view/9XZc2oLf.html
[19:46:20] <BJT-Work> mad dog hockey player?
[20:12:37] <alex_joni> tfmacz: sweet
[21:42:49] <jepler> * jepler decides at the last minute to convert zenbot from pluto to hm2_pci (5i20)
[21:46:40] <seb_kuzminsky> jepler: are you bringing your zenbot to fest?
[21:47:14] <mshaver> Here's hoping he is!
[21:50:03] <mshaver> actually, on the wiki page for Fest 2009 Jeff said he would probably bring it. I'd like to see a zenbot. Mainly to find out what a zenbot is.
[21:50:29] <seb_kuzminsky> i think it's a desktop cnc router with ballscrews?
[21:55:50] <jepler> seb_kuzminsky: yeah that's the plan
[21:56:04] <seb_kuzminsky> cool :-)
[21:57:37] <jepler> it's got acme screws, originally it was just triangular
[21:58:12] <jepler> http://emergent.unpy.net/01188441458
[21:58:13] <seb_kuzminsky> oops my bad
[21:59:07] <jepler> so tonight I'll be milling a new board to go from the mesa 2x25 connector to the xylotex stepper board, the home switches, and the spindle relay, then hopefully rewiring it without any unexpected problems
[21:59:18] <jepler> I figure seb_kuzminsky would benefit from seeing hm2 actually run a stepper machine
[21:59:27] <seb_kuzminsky> heh
[21:59:50] <seb_kuzminsky> i think it's super cool that you're using the machine to build the next rev of the machine :-D
[22:00:10] <alex_joni> like a rep-rap
[22:00:27] <seb_kuzminsky> jepler: what's the torque rating on the zenbot steppers?
[22:00:28] <alex_joni> only better :D
[22:00:40] <jepler> seb_kuzminsky: 70 oz-in or so
[22:00:52] <jepler> nema 17, or whatever the size below 23 is
[22:01:00] <seb_kuzminsky> yeah, 17
[22:01:12] <seb_kuzminsky> i just milled four nema-17 mounts on my x2
[22:01:27] <seb_kuzminsky> got tired of my little steppers walking around on my workbench when testing hm2 ;-)
[22:01:59] <alex_joni> gotta use duct-tape for something
[22:02:18] <seb_kuzminsky> haven't you heard? angle-iron is the new duck-tape
[22:02:29] <alex_joni> no, really?
[22:02:36] <alex_joni> they just outlawed it over here
[22:02:43] <alex_joni> part of RoHS :D
[22:05:06] <mshaver> it looks like the machine is made from UHMW or HDPE. If so, nice!
[22:05:42] <alex_joni> night guys
[22:05:47] <seb_kuzminsky> seeya alex
[22:05:57] <seb_kuzminsky> it's not too late to buy tickets to fest ...
[22:06:10] <seb_kuzminsky> do it now, while you're sleepy and your judgement is bad
[22:11:24] <jepler> seb_kuzminsky: are 17s big enough to move the X2?
[22:11:29] <jepler> that thing's made of metal, after all
[22:11:50] <seb_kuzminsky> no they're not, these mounts are just for benchtop testing
[22:12:26] <seb_kuzminsky> the x2 is usually fitted with steppers around 275+ oz*in in X and Y, and maybe half again that in Z
[22:13:14] <alex_joni> seb_kuzminsky: luckily I don't have to rely on my judgement
[22:13:36] <alex_joni> err.. "luckily"
[22:13:48] <seb_kuzminsky> heh
[22:40:42] <alex_joni> so.. hm2-stepgen
[22:40:46] <seb_kuzminsky> right
[22:41:11] <alex_joni> I got a short report, not enough data yet, that sometimes the stepgen takes off after an emergency stop
[22:41:38] <seb_kuzminsky> dude's got a strange machine
[22:41:47] <alex_joni> the user that reported this has a machine with glass scales for feedback, so it's possible that the current location changes (from the outside) while emc2 is still off
[22:42:22] <alex_joni> I know the motion controller tracks the changing -fb (like it's normal for servo machines), and updates the internal position and pos-cmd to reflect the changing position
[22:42:37] <alex_joni> that way when the user will re-enable the machine, there won't be a sudden jump
[22:43:13] <alex_joni> if pos-cmd changes while machine is off, and the hm2-stepgen is off, I think the stepgen might also suffer from a "jump" once enabled again
[22:43:32] <seb_kuzminsky> that requires the effector (hm2 stepgen in this case) to think its current position (position-fb) tracks position-cmd while its .enable is false
[22:43:38] <alex_joni> (sorry for my way after midnight english :/)
[22:43:52] <alex_joni> seb_kuzminsky: right, and I think that the sw-stepgen does that
[22:44:08] <alex_joni> although I'm sure jmkasunich knows it for a fact, not just by guessing
[22:44:35] <alex_joni> I believe lines 854-866 from
http://cvs.linuxcnc.org/cvs/emc2/src/hal/components/stepgen.c?annotate=1.64 take care of that
[22:46:02] <alex_joni> seb_kuzminsky: this is probably the most relevant:
http://cvs.linuxcnc.org/cvs/emc2/src/hal/components/stepgen.c#rev1.31
[22:47:41] <alex_joni> and the bug report:
https://sourceforge.net/tracker/index.php?func=detail&aid=1390123&group_id=6744&atid=106744
[22:48:59] <jepler> hm, I'm surprised at the behavior I just got trying to load hm2-stepper/5i20 without a card installed
[22:49:17] <jepler> instead of an error loading hm2-pci, I got 'hm2-stepper.hal:43: parameter or pin 'hm2_5i20.0.watchdog.timeout_ns' not found'
[22:49:55] <alex_joni> what says dmesg?
[22:49:56] <jepler> I'd expect hm2_pci to fail to load when the boards listed in config= weren't detected
[22:50:02] <jepler> [ 343.008393] hm2_pci: loading Mesa AnyIO HostMot2 driver version 0.6
[22:50:02] <jepler> [ 343.367740] hm2_pci: driver unloaded
[22:50:26] <jepler> (fail by returning <0 from rtapi_app_main)
[22:52:31] <seb_kuzminsky> jepler: that's hard to do with the way hm2_pci is set up right now
[22:52:42] <seb_kuzminsky> it doesnt know, at load-time, if there are any cards
[22:52:58] <seb_kuzminsky> it uses the pci hotplug interface instead of enumerating the boards up front
[22:53:22] <seb_kuzminsky> but if it worked the way you suggest, it would be better for the users
[22:53:38] <jepler> is that code that executes before rtapi_app_main?
[22:54:29] <seb_kuzminsky> rtapi_app_main registers the PCI driver and returns
[22:54:53] <seb_kuzminsky> the pci hotplug driver then gets called with "new device" events for each board the system knows about
[22:55:00] <seb_kuzminsky> but that's async with the insmod
[22:55:02] <seb_kuzminsky> as i understand it
[22:55:18] <jepler> hm, I'm uneasy then
[22:55:27] <alex_joni> in this case it's not called at all, right?
[22:55:29] <seb_kuzminsky> you and everyone else :-/
[22:55:30] <jepler> how do you guarantee that all pins are created by the time hal_ready is executed in rtapi_app_main?
[22:55:40] <jepler> this is a requirement of hal
[22:55:47] <jepler> (and I thought violations were signalled as errors!)
[22:57:23] <seb_kuzminsky> that requirement is not met by hm2
[22:57:44] <jepler> if(comp->ready) {
[22:57:44] <jepler> rtapi_mutex_give(&(hal_data->mutex));
[22:57:44] <jepler> rtapi_print_msg(RTAPI_MSG_ERR,
[22:57:44] <jepler> "HAL: ERROR: pin_new called after hal_ready\n");
[22:58:09] <jepler> it must be that pci_register_driver actually usually registers any boards present before returning
[22:58:22] <jepler> I can well imagine why they hedged in any documentation you read, though
[22:58:39] <seb_kuzminsky> unless by luck & coincidence, pci_register_driver() doesnt return until all currently known boards have been reported to and handled by the pci_driver
[22:58:59] <jepler> you've never seen this failure mode before, I take it?
[22:59:10] <seb_kuzminsky> i've never gotten that error or a report of that error
[22:59:10] <alex_joni> http://people.nl.linux.org/ftp/pub/anoncvs/kernelnewbies/documents/kdoc/kernel-api/r8314.html
[22:59:20] <alex_joni> "Returns the number of pci devices which were claimed by the driver during registration. "
[22:59:26] <seb_kuzminsky> oh heh
[22:59:32] <seb_kuzminsky> maybe i should read the docs
[22:59:35] <jepler> so it must be that non-hotplugged devices are "done" at that point?
[22:59:45] <jepler> that's fine until people get an emc pc with a hot-plug pci bus
[22:59:45] <alex_joni> jepler: sounds like it
[22:59:46] <jepler> heaven help us
[23:00:03] <alex_joni> that should be fine too
[23:00:15] <seb_kuzminsky> i got to go guys
[23:00:20] <alex_joni> by the time you hotplug a mesa the pins are done, way before you try to run more hal files
[23:00:26] <jepler> see you seb_kuzminsky
[23:00:30] <alex_joni> see you seb
[23:00:43] <seb_kuzminsky> i'll update the hm2_pci to check the return value of pci_register_driver() and return failure if it didnt find anything
[23:00:46] <seb_kuzminsky> seeyas
[23:00:50] <alex_joni> * alex_joni runs away too
[23:01:29] <alex_joni> but before I do.. I wonder why this works;
[23:01:35] <alex_joni> if (r != 0) {
[23:01:36] <alex_joni> LL_ERR("error registering PCI driver\n");
[23:01:57] <jepler> curiouser and curiouser
[23:02:10] <alex_joni> it should at least report 1 if you have a detected card..
[23:02:15] <jepler> sounds like
[23:02:18] <alex_joni> so hm2_pci should error out
[23:02:30] <alex_joni> but people are actually using it.. so it's odd :)
[23:03:48] <alex_joni> ha.. this is even funnier:
http://mail.nl.linux.org/kernelnewbies/2006-08/msg00118.html
[23:08:24] <alex_joni> jepler: I think the docs are wrong.. it only reports 0, not the number of claimed boards
[23:08:29] <alex_joni> http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/drivers/pci/pci-driver.c#L373
[23:17:07] <jepler> it's so cool that I'm not even a little bit afraid to open my web browser while doing cnc
