Back
[03:24:47] <SWPadnos> is cia dead?
[03:27:01] <mozmck> who's cia?
[03:27:43] <SWPadnos> the bot that sends IRC messages when things are committed to the repo
[03:27:51] <mozmck> oh yeah.
[03:27:56] <SWPadnos> CIA-2, what's up?
[03:28:06] <SWPadnos> * SWPadnos kicks CIA-2
[03:28:06] <CIA-2> ow
[03:30:21] <mozmck> I'm looking through the emc code... is there any reason that some stuff in motion, task, etc can't be written in C++?
[03:30:58] <SWPadnos> anything in the kernel can't be c++
[03:31:20] <SWPadnos> therefore anything that talks to things in the kernel has to use C declarations
[03:31:38] <SWPadnos> other than that, I don't know of any reasons why it can't be C++
[03:31:44] <mozmck> that was my next question. so those parts are in kernel space (I'm not sure what that even means)
[03:31:54] <SWPadnos> motion is, task isn't
[03:32:08] <cradek> implicit in your question is the assumption that using C++ is better, and you will find some firm opposition to that, especially in the areas of motion and hal :-)
[03:32:22] <mozmck> :)
[03:32:40] <SWPadnos> actually, the userspace part (that deals with all the metadata) of HAL could be C++, and it would probably end up a lot cleaner
[03:32:45] <cradek> cia was working 4-5 hrs ago
[03:32:48] <SWPadnos> except for the interface to all the C code in RT
[03:32:57] <SWPadnos> yeah, your commit was the last it saw though
[03:34:12] <mozmck> actually, orocos uses c++ in realtime motion control, and from anything I've read, if done correctly there isn't much if any performance hit.
[03:34:47] <mozmck> I'm mainly looking at comments such as at the top of command.c
[03:35:04] <SWPadnos> comments can be in C or C++ :)
[03:35:32] <SWPadnos> there is limited support for "C++ in the kernel" in the RTAI patches, but I don't know how limited it is
[03:35:41] <SWPadnos> of course we have additional requirements:
[03:35:42] <mozmck> and thinking some sort of object oriented approach may help the problems mentioned there.
[03:36:01] <SWPadnos> no malloc, no blocking, no library calls ...
[03:36:46] <SWPadnos> oh yeah, and half the stuff recently committed for clearing structs and such
[03:37:22] <mozmck> I see.
[03:38:24] <mozmck> just thinking out loud and trying to learn. things can be abstracted more in C.
[03:39:29] <SWPadnos> ++
[03:39:47] <SWPadnos> you'll find that the c++ code isn't very c++-ish
[03:40:20] <SWPadnos> it uses classes and some inheritance, but otherwise it's not using the language features well
[03:40:36] <mozmck> yeah, but I meant that you can actually do object oriented code in straight c
[03:40:57] <SWPadnos> sure
[03:41:13] <mozmck> no inheritance, but at least fairly good abstraction. gtk does a pretty good job at that last I looked
[03:41:25] <SWPadnos> there are a couple of things to keep in mind when looking at this stuff
[03:41:37] <SWPadnos> first, EMC2 is a distributed system
[03:42:01] <SWPadnos> there are separate tasks which communicate via NML
[03:42:16] <SWPadnos> it's not always easy to figure out what gets done where (at least not for me)
[03:42:24] <mozmck> I'm learning that slowly.
[03:42:35] <SWPadnos> some of those tasks need to be able to run on separate physical computers
[03:42:53] <mozmck> not that it's not easy to figure out, but how stuff works
[03:42:56] <SWPadnos> so you can't rely on pointers and RTTI to help you
[03:43:30] <SWPadnos> I have some sort of mental block on this actually, I've been looking at it and having it explained to me for years, and I still don't know for sure where all the parts go :)
[03:44:16] <mozmck> yeah. I've not used RTTI much anyhow. I think I mentioned to you at the fest a method of dynamic construction that I have used in the past
[03:44:50] <mozmck> I don't know how something like it would fit yet, but I'm slowly learning how things work (I think)
[03:45:08] <mozmck> so does HAL communicate with emc via nml also?
[03:45:08] <SWPadnos> yep, it was me
[03:45:12] <SWPadnos> no
[03:45:31] <SWPadnos> HAL is another beast entirely, and at the moment can only communicate within one PC
[03:45:44] <mozmck> ok, so how does it do it? function calls?
[03:45:52] <SWPadnos> though I think someone made an ethernet-based remote HAL driver, I don't know where it is
[03:45:53] <SWPadnos> no
[03:45:55] <SWPadnos> data only
[03:46:02] <SWPadnos> and functions which get added to RT threads
[03:46:23] <SWPadnos> in userspace, it's strictly via shared memory, no function calls across the kernel/user boundary
[03:46:53] <mozmck> doesn't nml use shared memory?
[03:47:15] <mozmck> is it separate from the hal shared memory?
[03:48:39] <SWPadnos> yes, they are separate
[03:48:47] <SWPadnos> NML uses shared memory on the same machibne
[03:48:49] <SWPadnos> machine
[03:49:00] <SWPadnos> but it can use TCP/IP or serial as well
[03:49:18] <SWPadnos> and you can share the same data over multiple channels simultaneously
[03:49:52] <SWPadnos> so you can have a local user interface and a remote one (on a separate PC) running at the same time, using the same control and status channels
[03:50:21] <mozmck> so does hal not use nml because it needs to be faster?
[03:50:45] <SWPadnos> hmmm. no, I wouldn't say that's the reason
[03:50:51] <SWPadnos> though it is part of it
[03:51:01] <mozmck> is there any kind of block diagram of emc2?
[03:51:04] <SWPadnos> yes
[03:51:13] <SWPadnos> it'll take a minute or three to find though
[03:51:38] <mozmck> I've been looking.
[03:52:18] <mozmck> trying to understand the overall structure of the code
[03:52:44] <SWPadnos> well, "the code" and "the system" don't really look quite the same
[03:53:26] <SWPadnos> at least not in my view
[03:53:51] <SWPadnos> I almost never know where to look for source files related to a particular part of EMC, but it could just be me
[03:53:58] <mozmck> hmm, I'd like to understand both!
[03:55:09] <SWPadnos> http://www.linuxcnc.org/content/view/42/13/lang,en/
[03:55:23] <SWPadnos> several block diagrams
[03:56:46] <SWPadnos> take those with a grain of salt though, I think they're pre-HAL
[03:57:18] <SWPadnos> I think they're diagrams jmkasunich made for himself when designing HAL
[03:57:31] <mozmck> yeah, it says they are from emc1
[03:57:43] <mozmck> but they're a start
[03:58:22] <SWPadnos> the second one has HAL in a big interface layer
[08:45:59] <micges1> micges1 is now known as micges_emc
[12:15:53] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: add g90.1 g91.1 to quick reference and add label and index
[12:21:17] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/html/gcode.html: make link for g90.1 g91.1 match new label
[12:22:27] <BigJohnT> Hi Ho, Hi Ho it's off to work I go :)
[12:29:45] <skunkworks_> logger_dev: bookmark
[12:29:45] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-06-19.txt
[13:11:59] <SWPadnos> alex_joni, if you're around, it looks like CIA is screwed up
[13:15:11] <cradek> BJT-Work: thanks for cleaning up after my doc change - I didn't know what I was doing.
[13:15:38] <BJT-Work> np
[13:17:36] <alex_joni> SWPadnos: how so?
[13:17:57] <SWPadnos> well, I'm not seeing any messages from all of seb's commits
[13:18:20] <alex_joni> sure, but they didn't happen now :)
[13:18:27] <alex_joni> so CIA probably was screwed up
[13:18:50] <SWPadnos> heh - oh look, there are a couple from bigjohnt :)
[13:19:03] <SWPadnos> I'll just drink my coffee now ...
[13:20:12] <alex_joni> heh
[13:20:25] <alex_joni> otoh, I just got an email from a change seb did more than 26h ago
[13:20:42] <SWPadnos> yeah, I just got a couple of those too
[14:04:24] <cradek> yuck, I think micges's bug report is right, tolerance mode doesn't work right for arcs
[14:05:01] <cradek> the derivation is only right for lines making corners
[14:06:21] <jepler> I hate sourceforge's bug tracker
[14:06:28] <jepler> why is everything hidden by default?
[14:06:36] <jepler> why doesn't it show the image in the browser?
[14:08:18] <cradek> I agree firmly
[14:16:30] <CIA-2> EMC: 03cradek 07v2_3_branch * 10emc2/src/emc/kinematics/tp.c:
[14:16:30] <CIA-2> EMC: fix typo in a comment that might become important
[14:16:30] <CIA-2> EMC: to understand if someone wants to tackle bug #2808858
[15:10:02] <BJT-Work> is M100-199 in 2.2 ?
[15:10:39] <SWPadnos> yes
[15:10:46] <BJT-Work> thanks
[15:10:49] <SWPadnos> it's been in EMC since about 1.0.0.0.0 :)
[15:11:00] <SWPadnos> (maybe slightly later, but you get the idea :) )
[15:11:08] <BJT-Work> I've slept since then :)
[15:27:01] <skunkworks_> bjt-work: couldn't he use they pyvcp?
[15:27:09] <skunkworks_> and put buttons on that?
[15:44:13] <skunkworks_> can you 'dock' a pyvcp pannel to screens othet than axis?
[15:46:47] <SWPadnos> I don't think so, that's a feature of AXIS, not pyvcp
[15:47:15] <skunkworks_> That I what I was thinking.
[16:03:00] <BJT-Work> skunkworks_ if I could figure out what he is trying to do it would easier to help him :/
[16:04:19] <cradek> uh-oh, you're sounding like me
[16:04:28] <BJT-Work> LOL
[16:06:03] <cradek> I think the remaining question is whether he wants to do that with gcode. if so, it's easy to use the gcode multipurpose digital outputs
[16:06:52] <BJT-Work> I asked him that and he said he wants to push a button and activate an output...
[16:07:14] <cradek> oh, ok
[16:08:25] <SWPadnos> if he needs to use tcl and software he writes, he might want to look at how halshow does it
[16:08:34] <SWPadnos> he can just exec a halcmd command from tcl
[16:09:02] <BJT-Work> SWPadnos: can you explain that to him?
[16:09:13] <SWPadnos> um. it's possible
[16:09:20] <BJT-Work> thanks
[16:09:31] <SWPadnos> I'd have to look up my login details for the website though, and I have no idea where that stuff is
[16:10:07] <SWPadnos> oh. lucky that Firefox remembers
[16:10:20] <cradek> "but I am using tcl" vs "I added stuff to iocontrol" makes no sense
[16:10:51] <SWPadnos> he may have been using emcsh, which would only be able to do things via NML
[16:10:58] <BJT-Work> it makes even less sense to me :)
[16:11:16] <skunkworks_> heh - around and around we go. ;)
[16:11:33] <BJT-Work> :0
[16:18:09] <SWPadnos> well, let's see if I stopped the merry-go-round
[16:18:33] <BJT-Work> I hope so
[16:19:37] <BJT-Work> I think I'll celebrate early and have a radish for lunch...
[16:19:50] <SWPadnos> um. yay. maybe
[16:53:36] <cradek> lerman: I think it was me who put your "in favor" because of my memory of your opinion at fest. Originally we were using that as a list to keep track of the opinions we'd heard -- later, people added their own to it.
[16:57:14] <cradek> some other opinions I recall: "anything is better than cvs" and "the board should decide, and then do it; that's why we elected you", heh
[20:54:03] <rob> rob is now known as robh_
[20:59:20] <micges> jepler: have you any info about task delay gliches?
[21:00:33] <SWPadnos> it's not realtime, so there's no guarantee that it will execute at any particular time
[21:01:38] <alex_joni> but I think cradek confirmed there's something funky going on with circles and tolerance-mode
[21:01:47] <alex_joni> 17:02 < cradek> yuck, I think micges's bug report is right, tolerance mode
[21:01:47] <alex_joni> doesn't work right for arcs
[21:01:47] <alex_joni> 17:03 < cradek> the derivation is only right for lines making corners
[21:02:02] <micges> alex_joni: I saw that
[21:02:12] <alex_joni> ok.. off to bed for me
[21:02:14] <alex_joni> good night
[21:02:19] <micges> good night
[21:03:22] <micges> SWPadnos: yes but if my yesterday "bug" was 1s delay of task that is also bad
[21:03:40] <SWPadnos> well, it's annoying but not catastrophic
[21:03:55] <SWPadnos> the machine would still follow the correct path, but the backplot would be wrong
[21:04:03] <SWPadnos> unless you see the machine actually doing those incorrect moves
[21:04:41] <micges> so you can't rely on preview and it's hard to debug
[21:05:35] <SWPadnos> well, preview is different from backplot
[21:06:02] <SWPadnos> the backplot is sampled in userspace, so it's only as reliable as your userspace timing
[21:06:20] <micges> SWPadnos: point is that my machine actually doing these incorrect moves, so I think trace task gliches would be first to do
[21:06:39] <SWPadnos> ok, if the machine does them then it's not a sampling problem :)
[21:07:19] <SWPadnos> task can delay (or be crashed) for all the RT system cares - the program will continue to run as long as there are operations in the queue
[21:08:02] <micges> SWPadnos: yes I know
[21:10:43] <micges> It would be easier if rt modules can print to console
[21:11:03] <SWPadnos> tail -f /var/log/messages or similar
[21:12:35] <micges> SWPadnos: thanks, I didn't know that
[21:12:55] <SWPadnos> sure
[21:13:19] <SWPadnos> there may be some things that don't look the same as dmesg - some timestamp formatting will be different or something
[21:14:37] <micges> ok
[21:15:30] <SWPadnos> but you won't want to have anything print too regularly
[21:15:37] <SWPadnos> anything RT anyway
[21:16:44] <micges> I know I tested that few times :)
[21:18:04] <SWPadnos> heh
[21:18:25] <SWPadnos> you can increase the size of the message log, though I think it requires a kernel recompile
[21:18:39] <SWPadnos> it may have been made into some /proc or /sys setting though, I'm not sure
[21:33:27] <CIA-2> EMC: 03micges 07TRUNK * 10emc2/src/emc/task/taskintf.cc: Always update ferror info
[21:53:45] <micges> cradek: is this intentional (spelling) in src/configure: Report bugs to <emc-developer@lists.sourceforge.net>. ?
[21:54:29] <jepler> I am sure it's supposed to be a working address, not a broken one
[21:54:55] <micges> ok
[21:55:33] <micges> I'll fix it
[21:58:17] <CIA-2> EMC: 03micges 07TRUNK * 10emc2/src/configure: fix typo in email address
[22:14:07] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/configure.in: fix an e-mail address that was wrong
[22:14:10] <jepler> micges: "configure" is a generated file. never edit it directly.
[22:14:12] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/configure: regenerate
[22:15:08] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[22:15:34] <micges> err sorry..
[22:54:56] <KimK> KimK is now known as KimK_afk
[23:03:07] <micges> good night