Back
[03:50:17] <SWPadnos> hmmm - cradek, shouldn't those chown/chmod lines use $(DESTDIR)$(bindir)?
[03:50:44] <SWPadnos> (or just $(BIN_DIR) )
[03:51:24] <cradek> well, they're a hack for run-in-place
[03:52:07] <SWPadnos> ah - OK
[03:52:25] <cradek> make install sets everything right using DESTDIR etc
[03:52:46] <SWPadnos> ok - I just saw the commit, didn't see which part of the file it was in
[03:53:37] <SWPadnos> out of curiosity, do you know a reasonably easy way to boot an old computer from CDROM (using some form of grub boot disk or the like)?
[03:53:53] <cradek> there's a floppy that sometimes works
[03:53:56] <SWPadnos> actually, to start a CDROM, booting from floppy
[03:54:16] <SWPadnos> I tried grub and isolinux, but neither knows about my SCSI CDROM
[03:54:21] <cradek> http://timeguy.com/cradek/smartboot
[03:54:24] <SWPadnos> sorry - syslinux
[03:54:33] <cradek> SCSI CDROM will need support in the SCSI card's BIOS
[03:54:40] <cradek> it rarely works.
[03:54:51] <cradek> try smartboot...
[03:55:02] <SWPadnos> got that, but the mainboard BIOS doesn't seem to like it (even though it has CDROM and lots of other boot options)
[03:55:31] <cradek> drop an IDE CD in it temporarily
[03:55:34] <SWPadnos> heh
[03:55:40] <cradek> really
[03:55:46] <cradek> booting from SCSI CD usually doesn't work.
[03:55:51] <SWPadnos> you'd think that Adaptec and Supermicro parts would work, but oh, well
[03:55:59] <SWPadnos> (and an NEC CDROM)
[03:56:07] <SWPadnos> maybe I should throw in the Toshiba?
[03:56:16] <SWPadnos> hmmm - I think it's in the Indigo2 right now
[04:06:38] <SWPadnos> hiya Ray
[04:07:51] <rayh> Hi Steven
[04:08:57] <SWPadnos> did you see the post on CCED from the guy who wrote software to run the Galil motion cards (in Windows)?
[04:09:34] <rayh> No I don't go there much anymore.
[04:09:43] <rayh> What was the gist of it.
[04:10:48] <SWPadnos> well - he wrote software that can drive the Galil DMC18xx PCI servo cards
[04:10:58] <SWPadnos> plus some CAM sofwtare to convert DXF to G-Code
[04:11:12] <SWPadnos> it's a work in progress though
[04:11:26] <rayh> both or the converter?
[04:12:27] <SWPadnos> both, I gather
[04:12:46] <SWPadnos> though apparently the card works well enough for his laser machine
[04:13:17] <SWPadnos> I emailed him asking if he'd open-source the driver and DXF converter, and gave him links to EMC info
[04:13:36] <rayh> Mitts had a Galil clone and 95 long years ago.
[04:13:42] <SWPadnos> (haven't heard back yet)
[04:13:59] <SWPadnos> Mitts?
[04:14:09] <rayh> Mittsubishi
[04:14:20] <rayh> maybe that's one t
[04:14:22] <SWPadnos> - got one of their VFDs
[04:14:27] <SWPadnos> ah ...
[04:14:33] <SWPadnos> one day, I'll hook it up
[04:14:47] <rayh> They build the control and drive hardware for Mazak.
[04:15:02] <SWPadnos> cool
[04:16:06] <rayh> You and jmk get anywhere with halwatch?
[04:16:13] <SWPadnos> not really
[04:16:44] <SWPadnos> I'm making some benchmarking code, so I can see just how bad the name-based searches are
[04:17:13] <rayh> I'll put a wait statement in the watch stuff and see if that cures the early return problem.
[04:17:38] <SWPadnos> hmm - can you refresh my memory about the "early return problem" ??
[04:18:06] <rayh> it's a race condition I think.
[04:18:35] <rayh> I set up a loop with after x000 {loopWatch}
[04:18:57] <rayh> Then proceed to add additional variables with a mouse click.
[04:19:13] <rayh> Great when it works but...
[04:20:15] <rayh> One problem with tcl is that you can't stop the after command.
[04:20:24] <rayh> It has to complete.
[04:20:56] <rayh> So you sit there twiddling thumbs until x000 time has passed.
[04:21:22] <SWPadnos> so after ... isn't a "yield" - it spins?
[04:21:41] <rayh> It looks like that to me.
[04:21:59] <SWPadnos> ok, where's the race?
[04:22:00] <rayh> after registers the script after it with the event handler.
[04:22:12] <SWPadnos> ok - so it shouldn't be spinning - it's a timer
[04:22:29] <rayh> Well if the click to add a new signal is very close to the end of the time
[04:22:46] <rayh> you get overlapping or missed returns from halcmd.
[04:23:23] <SWPadnos> ah - OK. you're calling exHAL from both WatchHAL and watchloop
[04:23:36] <SWPadnos> naughty naughty
[04:23:42] <rayh> I tried putting a flag in the system. To redirect the return.
[04:23:49] <rayh> that was a bust.
[04:24:04] <rayh> yep.
[04:24:12] <rayh> and several other places as well.
[04:24:14] <SWPadnos> actaully, either of those should work fine
[04:24:32] <SWPadnos> lemme look at this for a sec
[04:25:47] <SWPadnos> exHAL should protect itself with a "busy" flag
[04:26:41] <rayh> Yes it should.
[04:27:08] <SWPadnos> presumably, if exHAL is executing (because of the after clause), and someone clicks on a new watch (causing WatchHAL to riun exHAL), they'll be different instances of the function?
[04:27:21] <SWPadnos> (ie, local variables will be different)
[04:28:26] <rayh> true for building the new widgets but the return from the timer
[04:28:48] <rayh> seems to get seen by the new.
[04:29:50] <SWPadnos> watchHAL should just add to the list, and let the next refresh take care of the data update
[04:30:46] <rayh> But it must read a return from the var to know what kind of widget to use to show it.
[04:31:42] <SWPadnos> ah - watchloop doesn't create widgets, it only changes their appearance
[04:32:27] <SWPadnos> ok - so the thing to do is make a separate list of watch variables in watchHAL "newWatches"
[04:32:58] <SWPadnos> and watchloop actually creates widgets for anything in newWatches, and removes the items from that list as the widgets are created
[04:33:48] <SWPadnos> as long as watchHAL is appending, and watchLoop is taking off the front of the array, it should work even if watchHAL is called during a run of watchLoop
[04:34:14] <rayh> values converted to led or value
[04:34:32] <SWPadnos> ?
[04:35:03] <rayh> all watchHAL does is read values and set widgets.
[04:35:22] <SWPadnos> right - I'm saying that it should be the "watch display manager"
[04:35:30] <rayh> I has to do it for the entire list of displayed vars on each loop.
[04:35:38] <SWPadnos> anything you want to display should be created in that function
[04:36:20] <rayh> sort of an "oh this is new, let's make a display for it.
[04:36:24] <SWPadnos> yep
[04:36:44] <SWPadnos> or "here's the list of new things to add widgets for"
[04:37:00] <SWPadnos> watchloop moves items from the new list to the displayed list
[04:37:05] <rayh> so watchHAL sets its list of vars to oldlist and compares each loop?
[04:37:05] <SWPadnos> as it creates the widgets
[04:37:29] <SWPadnos> it could do that, but a "newWatches" list would do just as well
[04:37:36] <rayh> You can't click leaves fast enough to get a list of new.
[04:37:53] <SWPadnos> it may be one element long then ;)
[04:38:09] <rayh> I don't understand "newWatches" at all
[04:38:28] <rayh> How does a newWatch get merged with the running list.
[04:38:38] <SWPadnos> ok - here's how I envision it
[04:39:09] <SWPadnos> when the user clicks on a tree node, the item gets added to "NewWatches" by WatchHAL
[04:39:32] <SWPadnos> WatchHAL no longer creates the widgets, so it doesn't need to run exHAL to get the type
[04:40:19] <SWPadnos> watchLoop will run through the normal watch list ($which), just like it does now
[04:41:08] <SWPadnos> after doing that, it will run through $NewWatches, and will add widgets for each item in that list (and delete the item from the list as the widget is added)
[04:41:56] <SWPadnos> since you get the data value when you get the type from exHAL, it hardly takes any extra effort
[04:42:39] <SWPadnos> I'd still have watchHAL check both the NewWatches list and the "which" list for duplicates, so that watchLoop doesn't have the burden
[04:43:06] <SWPadnos> (though it might be more efficient for weatchLoop to check when it's about to move an item from $NewWatches to $which)
[04:43:15] <SWPadnos> did that make sense?
[04:44:23] <rayh> sorta. I'll copy it and read over in the morning.
[04:44:28] <SWPadnos> heh - OK
[04:44:36] <SWPadnos> there are probably details that I haven't thought through
[04:44:46] <SWPadnos> (almost guaranteed, in fact)
[04:45:03] <rayh> That is exactly how I feel about my own work.
[04:45:30] <SWPadnos> well - those get sorted out eventually
[04:46:28] <rayh> By the time they do, I usually have such a glob of junk that it is hard to make sence of any of it.
[04:47:02] <rayh> Thanks for the ideas.
[04:47:17] <SWPadnos> well - this stuff is sensible, but tcl/tk doesn't seem to have any good synchronization primitives (semaphores / mutexes), so it makes pseudo-multi-threaded stuff hard
[04:47:23] <SWPadnos> sure - happy to help
[04:48:03] <rayh> Yes. I wonder how it does real threading.
[04:48:18] <rayh> For a while we got 3 versions of emcsh each startup.
[04:48:31] <SWPadnos> weird
[04:48:36] <rayh> They wouldn't shut down using the emc script either.
[04:48:46] <SWPadnos> weirder
[04:48:56] <SWPadnos> it uses killall, doesn't it?
[04:49:09] <rayh> Had to recompile the tcl source without multiple threading.
[04:49:35] <SWPadnos> hmm
[04:49:39] <rayh> Yes it does but the threads were interlocked so you could not kill except by starting at one end.
[04:49:52] <SWPadnos> wish has near-threading, since events cause non-linear execution
[04:50:07] <SWPadnos> but it's only "near"
[04:50:15] <rayh> Yep.
[04:50:44] <rayh> I've often wished that we could marry emc's status variables with corresponding
[04:51:11] <rayh> tcl vars. Then we could just register all the variables with the event loop
[04:51:25] <rayh> and forget the after and that update proc.
[04:51:32] <SWPadnos> that would be nice
[04:52:02] <rayh> I tried it on some test stuff but don't know c well enough to pull it off.
[04:52:16] <SWPadnos> I wonder if a check of chanflag at the beginning of exHAL would help anything
[04:52:36] <SWPadnos> like (while chanflag == rd) wait
[04:52:57] <rayh> I tried something like that but don't remember the result.
[04:53:04] <rayh> I'll try that in the morning as well.
[04:53:35] <rayh> While is so prone to locking up the system that I try to avoid it.
[04:53:50] <SWPadnos> do global variables get created when they're first referenced as globals in a function?
[04:53:51] <SWPadnos> heh
[04:53:54] <rayh> My use of while needs a watchdog.
[04:53:59] <SWPadnos> gotta love possibly-infinite-loops
[04:54:04] <SWPadnos> yep
[04:54:05] <rayh> Yes.
[04:54:21] <SWPadnos> ok - I didn't see a declaration of chanflag anywhere
[04:54:59] <SWPadnos> the loop could be while (chanflag == rd && count < 100000) { after 100 count = count + 1}
[04:55:11] <SWPadnos> make that count < 100
[04:55:37] <rayh> sure.
[04:56:12] <rayh> chanflag is global in exHAL
[04:56:27] <SWPadnos> I saw that - that's why I asked about creation
[04:57:00] <rayh> Some coders do tend to put a global list at the start of their program.
[04:57:17] <SWPadnos> probably people who are used to C ;)
[04:58:31] <rayh> Don't you type the vars there also.
[04:58:50] <SWPadnos> yep - hence the global list at the beginning of the program
[04:59:27] <SWPadnos> you don't need to explicitly declare them as globals in functions though - they'll be used automatically (unless there's also a local variable of the same name)
[05:00:07] <rayh> Using namespaces it is possible to work vars from a distance but I've never gotten the hang of it.
[05:00:18] <rayh> Almost like pointers.
[05:00:22] <SWPadnos> heh
[05:00:27] <SWPadnos> almost
[05:00:50] <SWPadnos> I'd say C++ is better with pointers, but somebody might throw things at me
[05:01:25] <rayh> not me.
[05:01:30] <SWPadnos> nope
[05:01:57] <SWPadnos> it's funny - a lot of the stuff that jmk did with pin types and that kind of thing would be nearly automatic in C++
[05:02:09] <rayh> Gotta get out of here. Hope to finish up most of halconfig tomorrow
[05:02:13] <rayh> Really.
[05:02:20] <SWPadnos> ok - see you. have a good night
[05:02:26] <rayh> like inheritance
[05:02:47] <SWPadnos> yes - inheritance, "virtual tables", run-time type information ...
[05:03:00] <SWPadnos> the ability to "overload" functions
[05:03:15] <SWPadnos> (some people hate it, but I think it's great)
[05:03:22] <rayh> "overload" ?
[05:03:43] <SWPadnos> yep - you can define several functions with the same name, but different arguments
[05:04:13] <SWPadnos> so you can have, say, 6 versions of hal_pin_new, each of which takes a differnet pin type, and does the right thing with it
[05:04:38] <SWPadnos> but you always call a function called "hal_pin_new" with your type that inherits from "hal_pin"
[05:05:03] <SWPadnos> (or signals - call one version with a bool, one with an int, and one with a float ...)
[05:05:27] <SWPadnos> you can even add definitions for symbols, like +, - * etc
[05:05:36] <rayh> I can feel nightmares on the horizon.
[05:05:40] <SWPadnos> heh
[05:05:56] <rayh> I remember some discussion about redefining things like +
[05:05:58] <SWPadnos> I wouldn't suggest that HAL be rewritten in C++, don't worry
[05:06:16] <SWPadnos> like I said - it's great if used well, but it does hide what's "actually happening"
[05:06:30] <SWPadnos> Paul made a C++ class out of the emcPose, remember?
[05:06:53] <SWPadnos> so you can say "Pose1 = Pose2+Pose3", and it does the right thing
[05:06:53] <rayh> vaguely
[05:07:20] <SWPadnos> but it's a function call hidden behind a plus sign, so some people don't like it
[05:08:07] <SWPadnos> what's interesting about it is that you could also do things like having kinematics be automatic
[05:09:00] <rayh> by automatic you mean ready to be used if needed or defined.
[05:09:05] <SWPadnos> reassign the = so that a variable of WorldPoseType can be directly assigned to MachinePoseType, and the correct kinematic transform gets called
[05:09:31] <SWPadnos> so "MachinePose = WorldPose" would just work
[05:09:44] <SWPadnos> it would call the kinematic transform function
[05:10:10] <SWPadnos> (if you write the overloaded = correctly)
[05:11:27] <SWPadnos> I wish I could find my C++ book - I should read up on this stuff more
[05:11:32] <rayh> I can see how the line reads okay to represent the transform.
[05:12:07] <SWPadnos> yep, but it can be hard to tell how much work a simple little '=' will have to do, hence the issues
[05:12:21] <SWPadnos> conceptually, it's great
[05:12:27] <SWPadnos> in RT, it can be deadly
[05:12:27] <rayh> I can also see how the overload of the function can cause massive debug issues.
[05:13:07] <SWPadnos> yeah - though a debugger will show the real function call (to the function "operator=" )
[05:14:19] <SWPadnos> anyway - you wanted to get to bed, I should stop blathering
[05:14:28] <rayh> It's a question of getting from the simple looking formula "MachinePose = WorldPose" down to the function and back.
[05:14:46] <SWPadnos> how do you mean?
[05:15:34] <rayh> Well machinepose is made up of many elements/variables
[05:15:46] <SWPadnos> when the source code "MachinePose = WorldPose" is encountered, the compiler inserts the function call "MachinePose.operator=(&MachinePose, &WorldPose)"
[05:16:26] <SWPadnos> so it's just a function call, as though one had done "InverseKinematics(&MachinePose, &WorldPose)"
[05:16:38] <SWPadnos> (the ampersand means "the address of")
[05:17:31] <SWPadnos> the programmer still writes those functions though, there's no way around that ;)
[05:17:53] <rayh> I guess I was thinking of the load of variables on each side of the equals
[05:18:02] <SWPadnos> right
[05:18:14] <SWPadnos> even worse is the fact that a machine may not be cartesian
[05:18:19] <rayh> and how each is properly handled by the maths hidden behind it.
[05:18:38] <SWPadnos> right. hiding complexity is good at some levels, and bad at others
[05:18:47] <rayh> Well trivkins is a bit easier although genhexkins isn't that bad conceptually.
[05:19:10] <SWPadnos> "octapodkins" would still look the same, which is a benefit and a problem
[05:19:22] <SWPadnos> depending on how you look at it
[05:19:32] <rayh> Sagar's scarakins was really quite easy to see.
[05:19:52] <SWPadnos> that's the radial arm with a quill-like Z?
[05:20:02] <SWPadnos> actually, two horizontal joints
[05:20:04] <SWPadnos> ?
[05:20:50] <rayh> Yes. Looks like a shoulder and elbow
[05:21:06] <rayh> with z at the hand and no wrist
[05:21:08] <SWPadnos> right - I saw that one. looks cool for some PCB-style applications
[05:21:10] <SWPadnos> yep
[05:21:29] <rayh> gotta crash. see you guys.
[20:39:31] <rayh> I see that we are missing the old help files from emc.
[20:40:02] <rayh> what do you think of emc2/docs/help as a location for these.
[20:40:18] <alex_joni> fine with me
[20:40:46] <rayh> I'd like to make the names of each help file refer to the program that uses it.
[20:41:22] <rayh> so one file might look like emc2/docs/help/tkemchelp.txt
[20:41:28] <rayh> or some such.
[20:41:57] <alex_joni> how about tkemc.help (or tkemc.hlp) ?
[20:43:11] <rayh> that should be okay. If we expanded the help function in tkemc to include html we'd name it tkemc.html
[20:43:57] <alex_joni> right
[20:44:24] <rayh> Okay. If others don't object, I'll do that bit of work tomorrow.
[20:44:46] <rayh> Then modify all the ini files to find it there.
[20:45:01] <alex_joni> don't
[20:45:15] <alex_joni> that complicates run-in-place vs. install
[20:45:24] <alex_joni> I'd rather have tkemc find it on it's own
[20:45:36] <alex_joni> maybe based on the runscript
[20:49:28] <alex_joni> how does that sound?