Back
[01:38:04] <mozmck> is a python component, does it take too much cpu time to run an infinite loop such as while x == 0: pass
[01:39:14] <mozmck> in - not is
[01:59:22] <jepler> yes, just like in "C" a busy loop will take 100% CPU
[01:59:54] <jepler> in a Python hal component you should "wait a short time" after each time you handle all inputs and update all outputs. Do this with time.sleep(seconds)
[02:00:47] <mozmck> might not you miss an input?
[02:01:15] <mozmck> heh, we need interrupts :)
[02:01:29] <jepler> of course, a python component isn't realtime (even without sleeps)
[02:02:07] <skunkworks> jepler: I got a few of these that I am going to use with the surplus servos.
http://www.a-m-c.com/download/datasheet/b15a8.pdf
[02:03:02] <jepler> skunkworks: I've found the littlest mesa servo board to be adequate on zenbot, if those are the motors you're talking about
[02:03:19] <jepler> oh, brushless -- you must be talking about different motors
[02:03:34] <mozmck> yeah. The guy emailed me that was asking about bash scripts in hal components.
[02:03:46] <skunkworks> no - these will run both brushed and brushless
[02:04:02] <skunkworks> (same ones on your zenbot)
[02:04:37] <mozmck> we need a latch component - in fact I wrote one. is it alright if I commit it?
[02:04:52] <jepler> mozmck: umm
[02:05:01] <jepler> we don't have one already?
[02:05:12] <cradek> sample_hold
[02:05:58] <mozmck> let me look at that
[02:06:12] <mozmck> here's what I wrote:
[02:06:12] <mozmck> component latch "latch which sets out true if a rising edge is seen on in and reset is not true. A true value on reset sets out back to false";
[02:06:12] <mozmck> pin in bit in;
[02:06:12] <mozmck> pin in bit reset;
[02:06:12] <mozmck> pin out bit out;
[02:06:13] <mozmck> function _ nofp;
[02:06:15] <mozmck> license "GPL";
[02:06:17] <mozmck> ;;
[02:06:19] <mozmck> FUNCTION(_) {
[02:06:21] <mozmck> if (reset) {
[02:06:23] <mozmck> out = 0;
[02:06:25] <mozmck> }
[02:06:27] <mozmck> else if (in) {
[02:06:29] <mozmck> out = 1;
[02:06:31] <mozmck> }
[02:06:33] <mozmck> }
[02:06:38] <cradek> oh you mean a flipflop
[02:06:52] <cradek> we have that too :-)
[02:06:54] <mozmck> I guess :)
[02:07:20] <cradek> at least I think that's what you're describing
[02:07:59] <jepler> reset and in sound like the set/reset inputs of flipflop, including the precedence of reset over set/in
[02:08:37] <jepler> Mapping all equations...
[02:09:16] <mozmck> could be. I need to study my digital stuff more :)
[02:09:51] <cradek> (I'd switch to classicladder in a minute if I was even considering using a flipflop or latch for something)
[02:10:11] <mozmck> I needed something that would catch a fast signal and hold it for a slower process to see and handle and then reset.
[02:10:37] <mozmck> I need to look at classicladder.
[02:11:11] <cradek> for me there's no going back, it's so simple to do stuff
[02:11:27] <jepler> mozmck: what's the "fast signal"?
[02:11:44] <jepler> I didn't pay attention to the mailing list thread you alluded to, so I'm in the dark about the ultimate goal
[02:12:10] <cradek> I guess I didn't see that either
[02:12:17] <mozmck> the guy on the mailing list wants to shutdown his computer when a button is pushed.
[02:12:29] <cradek> oh, he's clearly insane
[02:12:46] <jepler> well leave it to cradek to bring instant clarity to any subject
[02:12:50] <mozmck> I can't remember right now what I was doing that I wrote that component
[02:12:57] <mozmck> :)
[02:13:19] <cradek> sometimes I wonder whether I'm missing something or he is - you click shutdown on the screen, and when the status bar drains out, you turn off the power
[02:13:39] <cradek> how many weeks of effort is it worth to save one of those steps?
[02:14:10] <mozmck> yeah. I don't know what he's thinking. He sent me his script because I helped someone else a while back.
[02:14:11] <cradek> does everyone know you can do that? (I'm being serious)
[02:14:41] <cradek> heh
[02:14:43] <jepler> or to just pay the electric bill for leaving the PC on for the next 10 years, that's only around 10 mega watt hours
[02:14:54] <cradek> be careful or you'll get a reputation :-)
[02:15:18] <jepler> of what -- being helpful?
[02:15:20] <mozmck> yes, I know.
[02:15:21] <cradek> yeah
[02:15:24] <cradek> look out
[02:15:45] <cradek> or at least be sure to be touchy and abrasive at the same time - it evens out
[02:15:50] <mozmck> yeah, people find out you can do something then everyone wants you to. I've gotten better at saying "no"
[02:16:04] <cradek> sorry, I'll quit joking
[02:16:11] <cradek> it IS important to be able to say no
[02:16:17] <mozmck> doesn't bother me!
[02:17:32] <cradek> the jr's original control could shut itself off after finishing a job. the main breaker has some kind of input that causes it to "trip"
[02:18:23] <mozmck> that's interesting. I guess you could leave it doing a job at night and it would shutdown when done?
[02:18:30] <cradek> I can (almost) understand wanting the machine to shut it off after finishing something. if you're bold enough to let it run after you go home, for instance
[02:19:13] <cradek> but this other goal I don't understand - it seems like clicking shutdown on the screen is offensive or something - I have no clue
[02:19:14] <mozmck> put a webcam watching it and have a way to shut it down over the internet....
[02:20:22] <mozmck> I didn't even think to ask him. I just looked at his script and saw he had no proper loop so it just exited.
[02:20:54] <mozmck> The newer ubuntu (9.04 and up) do make it harder to find shutdown...
[02:21:49] <cradek> huh, in my 9.04 I guess it's only on the corner thing, not the system menu, I never noticed
[02:22:02] <cradek> (still that seems like a pretty low barrier)
[02:22:21] <mozmck> yep.
[02:23:08] <cradek> the shutdown thing is so baffling I have figured so far that I just don't understand what is meant.
[02:25:30] <mozmck> I made a livecd with 9.10 that partly works :)
[02:26:01] <cradek> cool
[02:26:21] <mozmck> I uninstalled openoffice to make room for other stuff, then when I installed from my cd onto a computer it for some reason went out and downloaded openoffice and installed it!
[02:26:36] <jepler> hah, that's interesting
[02:26:45] <jepler> call it a feature
[02:27:12] <mozmck> yeah, don't know why yet. the computer also would not boot after installing even though it had run from the livecd just fine.
[02:27:51] <mozmck> I don't know if it was my kernel or that the cd drive seems a little flaky
[02:30:47] <jepler> that's OK, 8.04 with the stock ubuntu kernel doesn't even find the cd drive on one of my computers
[02:31:05] <jepler> (the installer does, but post-install there's simply no cdrom device available)
[02:32:10] <mozmck> yeah, I found a number of posts about the livecd working with 9.10 but then the computer not booting. but I reinstalled from a standard 9.10 livecd and it worked.
[02:33:02] <mozmck> so I'm not sure. 9.10 uses lzma compression for the initrd, so I had to repack it for the livecd initrd.
[02:35:32] <mozmck> but I don't think it should matter that my installed kernel has a gzip compressed initrd.
[02:40:28] <mozmck> guy just email back and said my loop made his python script work.
[02:41:18] <mozmck> he said "this was a special need because we're a little hurried with the automatization of one of our machines", so I guess it is some special deal.
[02:42:22] <jepler> oh, well if the reason is that some damned customer demanded it, then I understand totally
[02:42:53] <mozmck> yeah. it may not even have a normal interface or something.
[03:09:45] <jepler> well, just before I call it a night, let me give a mini-announcement of what I've been up to lately: automated mesa firmware building on linux
[03:09:58] <cradek> neat
[03:09:59] <jepler> actually, I had this mostly done a few weeks ago, and put on what I hope are the finishing touches tonight
[03:10:02] <jepler> http://media.unpythonic.net/emergent-files/sandbox/hostmot2-firmware-build-v0.1.tar.gz
[03:10:05] <jepler> http://media.unpythonic.net/emergent-files/sandbox/hostmot2-firmware-images-v0.1.tar.gz
[03:10:22] <jepler> ultimately this'll go in the emc2 git tree, but here's a preview ^^ source and .bin/.pin files
[03:10:56] <jepler> I have tested 5i20 and will test 7i37 tomorrow .. but I don't have any of the other boards, so specific reports on 5i22, 5i23, and the 4i6x boards would be nice if someone is watching who has one
[03:11:31] <cradek> sorry I can't help with that
[03:11:51] <jepler> assuming that updates from pcw just modify a few files without changing the structure of things, this will let him send me (e-mail or whatever) the new sources; I can build the current set of firmwares in under 2 hours of wall time on my faster machine
[03:12:19] <mozmck> using xilinx ise?
[03:12:21] <cradek> I would really love it if we could easily build them all from the source we have
[03:12:32] <jepler> yes, using the free xilinx ise on linux
[03:12:34] <cradek> that'd save him lots of effort too I bet
[03:13:06] <mozmck> why can't we?
[03:13:07] <jepler> I seem to be building 29 variants; I haven't double-checked that they match emc2 exactly
[03:13:14] <cradek> jeez
[03:14:36] <jepler> mozmck: we haven't done this before because (A) peter has always been kind enough to give us corresponding firmwares and sources, so we didn't have to
[03:14:59] <jepler> (B) because the build process was manual in the xilinx ise gui and (B.5) involved hand-editing files for each variant
[03:15:25] <cradek> mozmck: "easily" was the important word - we've always had full corresponding source
[03:15:34] <jepler> the latest revisions from pcw reduced the number of hand-edits to the point where it can be effectively scripted (a few text substitutions in one .vhd file)
[03:15:48] <mozmck> oh I see. that's really good then.
[03:20:49] <jepler> whoops, PIN files were mising from -images tarball; new version uploaded, replacing old one
[03:21:23] <jepler> 'night
[04:27:50] <Dave911> Hi guys..... any idea what emc.ini() does ??? It looks like it takes a .ini as the argument, but I am not sure which ini file it is looking for.
[04:27:52] <Dave911> This is the part of the Gwiz.py code that creates a segmentation error for me right now. I'm trying to determine why.
[04:36:23] <Dave911> Forget that question ... I've got a null string being passed to it .. not good..
[10:14:55] <mpaolini> hi all, strange emc behaviour: right after axis startup (before hitting any key) I have halui.mode.is_auto ON
[10:16:28] <mpaolini> and emcStatus->task.mode is EMC_TASK_MODE_AUTO
[10:20:07] <mpaolini> if I press F1 twice (e-stop ON and then OFF again) I should be in same state as before, but instead halui.mode.is_auto is OFF
[10:22:04] <piasdom> g'mornin all
[10:30:09] <mpaolini> question is: is it OK to have emcStatus->task.mode == EMC_TASK_MODE_AUTO at startup?
[10:30:28] <mpaolini> or is it a bug?
[10:36:04] <micges_work> mpaolini: it is in auto mode because loading gcode is done in auto mode
[10:36:26] <micges_work> when you run Axis it loads some gcode at startup
[10:36:31] <micges_work> right?
[10:37:49] <mpaolini> yes, it does indeed
[10:40:08] <mpaolini> I see your point now.. I thought it enters auto mode only when running/stepping/pausing
[10:42:33] <mpaolini> it looked strange to see auto-mode while in estop, but ok I'll live with it
[10:43:32] <micges_work> you can disable preloading gcode at startup
[10:45:00] <mpaolini> ok thanks for the explanation
[11:31:54] <micges_work> jepler: I have problem: in *.c file line 'printf("%d\n", sizeof(hal_pin_t));' returns 80, but in *.cc file it returns 88
[12:27:36] <jepler> micges_work: you've done something wrong
[12:28:16] <jepler> $ g++ -m32 -Iinclude -Isrc/hal -DSIMULATOR -DSIM -DRTAPI pinsize.cc && ./a.out
[12:28:19] <jepler> 88
[12:28:22] <jepler> $ gcc -Iinclude -Isrc/hal -DSIMULATOR -DSIM -DRTAPI pinsize.c && ./a.out
[12:28:24] <jepler> 88
[12:29:02] <micges_work> I've added this line to meter.c and halmodule.cc
[12:32:41] <jepler> http://pastebin.ca/1676342
[12:33:05] <jepler> wfm
[12:35:01] <micges_work> I'm on hardy if it's important
[12:35:56] <jepler> $ lsb_release -c
[12:35:56] <jepler> Codename:hardy
[12:36:53] <micges_work> strange
[12:40:36] <micges_work> maybe I've done sth wrong but what, I'm only edit those files and compile, standard RIP master..
[12:40:57] <micges_work> jepler: thanks for checking
[13:13:37] <micges_work> on 9.04 and 9.10 it works (88, 88)
[13:16:40] <micges_work> but on another hardy rt I have also 88 and 80
[13:34:58] <micges_work> on dapper rt also 88 and 80
[13:47:37] <jepler> to my great surprise, you are right.
[13:51:13] <micges_work> on hardy rt, rip in sim mode also 88, 80
[13:54:36] <micges_work> it has some connection with rtai then
[13:55:00] <micges_work> or our part of rt code
[14:02:43] <jepler> no, I'm drawing a different conclusion.
[14:03:05] <jepler> I didn't see it on my home system (sim, 64 bits) but I see it on two other systems (sim, 32 bits; and rt, 32 bits)
[14:04:30] <micges_work> this is strange
[14:05:14] <jepler> hal/hal_lib.c:179: hal_data_u align 4
[14:05:17] <jepler> hal/halmodule.cc:711: hal_data_u align 8
[14:05:29] <jepler> hal_data_u should be align 8, but in one case it's not
[14:55:03] <micges_work> bbl
[17:53:25] <jepler> well, micges has stumped me with his report. Here it is boiled down:
http://pastebin.ca/1676716
[17:53:42] <jepler> I am quite surprised at gcc and g++ treating __attribute__((aligned(8))) differently
[20:20:47] <CIA-40> EMC: 03cradek 07master * r698bd39d651a 10/src/emc/usr_intf/touchy/design.notes: these things are now done
[20:34:32] <skunkworks_> cradek: so touchy works for lathes also now?
[20:39:23] <cradek> yes
[20:39:30] <cradek> untested...
[20:39:42] <skunkworks_> Nice work!
[20:39:51] <cradek> if your machine has no Y, touchy assumes it's a lathe...
[20:40:05] <skunkworks_> when is the hardege(sp) getting a touch screen?
[20:40:09] <cradek> not sure if that's good enough for everyone, but it's good enough for me
[20:40:26] <cradek> not sure, but it sure might
[23:10:57] <jt-plasma> looks like you can get a 15" touch screen on flea bay for about $240 nib