Back
[00:00:57] <jmkasunich> it looks like probes involve two canon calls? one to make the move and capture the value, and one to return the value?
[00:01:10] <cradek> yes
[00:01:13] <jmkasunich> so the sai and preview versions just complete the move and capture the endpoint
[00:01:22] <jmkasunich> they don't need any special tricks to return something sane
[00:01:30] <cradek> yes they will just show the entire move
[00:01:45] <jmkasunich> and return the coord of the endpoint
[00:02:08] <jmkasunich> have you ever written a "smart probing" program?
[00:02:18] <jmkasunich> (where it doesn't go all the way up every time)
[00:02:21] <cradek> yes
[00:02:32] <jmkasunich> it seems like the preview for that would be rather nutty
[00:02:34] <cradek> it works great
[00:02:53] <cradek> preview for that kind of thing is hopeless
[00:03:28] <cradek> http://timeguy.com/cradek-files/emc/smartprobe.png
[00:03:53] <cradek> probing up and over a (simulated) hemisphere
[00:04:09] <cradek> http://timeguy.com/cradek-files/emc/probe-results.png
[00:04:12] <jmkasunich> this is the actual run, not the preview, right?
[00:04:14] <cradek> connect the resulting points
[00:04:17] <cradek> yes that's the run
[00:06:25] <cradek> brb
[00:08:15] <jmkasunich> the more I think about it, the more I prefer passing a default value to the canon function
[00:08:23] <jmkasunich> the pointer trick is exactly that, a trick
[00:11:47] <jepler> jmkasunich: why does the interpreter know a better default answer than whatever is using it?
[00:12:12] <jmkasunich> the interp doesn't, but the g-code programmer does
[00:12:26] <jmkasunich> and he can stick that better answer into #5399 before invoking M66
[00:13:03] <jmkasunich> in my case, I'm pausing to let the user measure the part, then doing spring passes or whatever based on the result of the measurement
[00:13:28] <jmkasunich> I'd like to load the nominal value into #5399, so during preview it will just say "all is well" and carry on
[00:13:28] <jepler> oh, hm
[00:14:33] <jepler> without changing canon, you could make axis pay attention to special comments (AXIS,next-analog-value,3.141)
[00:14:35] <jmkasunich> an alternative would be to have the (AXIS, hide) and (AXIS, show) operators turn off/on evaluation of M66
[00:14:57] <jepler> (but maybe you want it to be a computed value, in which case that won't work)
[00:16:40] <jmkasunich> something tells me that "suppress" isn't available in gcodemodule.cc
[00:17:13] <jepler> nope
[00:17:53] <jmkasunich> actually, that would violate the meaning of hide/show anyway
[00:18:12] <jmkasunich> they don't mean "ignore", they mean "execute but don't display"
[00:19:15] <jepler> yeah
[00:19:55] <jmkasunich> the more I think about it, the more I like passing a default value to the input canon functions
[00:20:08] <jmkasunich> in SAI and preview, use it, in canon ignore it, done....
[00:21:49] <jepler> go for it
[00:22:39] <jmkasunich> I think I will
[00:23:21] <jmkasunich> is default a reserved work in C++?
[00:23:35] <jmkasunich> my editor highlighted it when I tried to use it as an argument name in a prototype
[00:25:16] <jepler> it is in C
[00:25:18] <jepler> (for case statements)
[00:25:23] <jmkasunich> oh, duh
[00:25:32] <jmkasunich> I'm just using def
[00:39:38] <CIA-40> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/nml_intf/canon.hh: allow SAI and preview M66 commands to leave the value in #5399 untouched - this lets the g-code programmer pre-load a reasonable default
[00:39:39] <CIA-40> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/rs274ngc/ (gcodemodule.cc rs274ngc_pre.cc): allow SAI and preview M66 commands to leave the value in #5399 untouched - this lets the g-code programmer pre-load a reasonable default
[00:39:39] <CIA-40> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/sai/saicanon.cc: allow SAI and preview M66 commands to leave the value in #5399 untouched - this lets the g-code programmer pre-load a reasonable default
[00:39:41] <CIA-40> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/task/emccanon.cc: allow SAI and preview M66 commands to leave the value in #5399 untouched - this lets the g-code programmer pre-load a reasonable default
[00:42:16] <jmkasunich> so much for that excuse - now I have to bite the bullet and make this g-code work
[00:42:33] <jmkasunich> trying to thread a springy part
[00:43:43] <cradek> hmm, guess who touched task and the interpreter last
[00:44:41] <jmkasunich> oh noes!
[00:51:48] <jmkasunich> how do I stop an infinite loop in axis?
[00:51:56] <jmkasunich> the preview is going and going and going
[00:52:02] <cradek> hit escape
[00:52:19] <jmkasunich> duh
[00:52:26] <jmkasunich> I was hitting just about everything else
[00:52:36] <jmkasunich> I realised just as I hit reload that it was gonna do that
[00:53:05] <jmkasunich> I need to load trunk on the shoptask to use the fix I just added
[00:53:30] <jmkasunich> before it was annoying - I was using the #5399 value to calculate an offset for the final pass
[00:53:33] <jepler> alex_joni: mind if I commit you to making a new kernel release that fixes the arduino problem? :-P
[00:53:47] <jmkasunich> now I'm doing "take spring cuts till the measured value is <= target value"
[00:53:59] <jmkasunich> since measured value is 1.0, and target is 0.23something......
[00:54:10] <cradek> heh
[00:54:25] <cradek> bbl
[00:56:21] <jmkasunich> I think I'm doing this all wrong
[00:56:39] <jmkasunich> I should let the human do the thinking, and provide a couple of checkboxes
[00:56:44] <jmkasunich> 1) do a spring pass
[00:56:53] <jmkasunich> 2) infeed by (X) and do a pass
[00:57:16] <jmkasunich> actually, radio buttons
[00:57:22] <jmkasunich> 3) acceptable, continue with program
[04:20:36] <CIA-40> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/pwmgen.c: decode PWM Value Register in pwmgen debug output
[09:12:32] <alex_joni> jepler: on principle I have no problem with it
[09:12:50] <alex_joni> the problem is that I am travelling this week, and I don't think I can spare the time to properly do it
[11:43:40] <BigJohnT> does the TODO list in the uppermost level of trunk and 2.2.7 need to be updated?
[11:52:59] <jepler> BigJohnT: if only we knew what to write in it :-P
[11:53:02] <jepler> alex_joni: ok
[11:55:44] <BigJohnT> I was just wondering if some of those tasks had been completed and could be deleted :)
[12:02:49] <BigJohnT> * BigJohnT has to go to work now :)
[12:04:52] <issy> Hi all
[12:06:32] <alex_joni> hi
[12:58:46] <cradek> jepler: with new-run-from-line I wonder if you could do those things fairly easily if emc would remember the line where it was aborted. the BOSS does this (there is a reset button that puts you back at the beginning of the program.)
[12:59:06] <cradek> abort would also need to not reset the interpreter state.
[12:59:27] <skunkworks_> cradek: did you get the ballscrew back togather?
[12:59:37] <cradek> skunkworks_: it is together - I don't have the new balls yet.
[12:59:41] <cradek> maybe they will come today
[12:59:54] <jepler> m-1 "not abort, not program end, not pause, but something else"
[13:00:37] <cradek> well he proposed two problems, changing an insert, and touching off a tool
[13:00:55] <cradek> both could be handled just fine with r-f-l
[13:02:30] <cradek> say you do t2 m6, m0. gui pauses, user hits abort, abort doesn't change interp state, user jogs around, changes tool manually, touches off, gui still knows the abort line, user resumes (r-f-l abort line + 1)
[13:11:48] <alex_joni> cradek: does the interp correctly update endpoints while jogging around?
[13:11:59] <CIA-40> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_Integrator.lyx: minor edit
[13:12:31] <alex_joni> (maybe it doesn't need to.. but I imagine it would do, if the next line is an arc or a circle)
[13:34:17] <cradek> alex_joni: it synchs the current point at mode switches
[13:35:31] <cradek> contrary to what seb says, I bet an analog voltmeter (vtvm, fet-vm) is a pretty decent way to roughly measure the duty cycle of a pwm signal
[13:40:50] <alex_joni> it might get confused at certain key frequencies, but usually I agree
[13:42:10] <jepler> digital voltmeters work OK too in my experience. wikipedia says that most digital voltmeters use an input buffer followed by a dual-slope A-D. As long as the conversion time is much bigger than the PWM time, you'll get a pretty good answer. if not, you'll probably see an unstable number instead of a single wrong number.
[13:42:12] <cradek> Stupid people frusterate me! (title of a popular webbbs thread)
[13:42:42] <cradek> Replies: 54 Views: 2632
[13:44:36] <cradek> jepler: I might ask you to make a pcb for me soon.
[13:45:20] <cradek> have you made one with your new nuts yet? I'm anxious to see how round the pads look.
[13:45:35] <jepler> cradek: no, I haven't. what's the board you have in mind?
[13:46:24] <cradek> a thermostat for the solar collector. it needs to turn on the blower when heat is needed indoors (below some temperature) and the temp in the collector is higher than indoors
[13:46:37] <cradek> it will probably have a third temp sensor for the regular outside temp too.
[13:46:49] <jepler> neat
[13:46:55] <cradek> strangely, this kind of thermostat doesn't seem to exist.
[13:47:00] <jepler> I'd be happy to mill it for you or let you come over and mill it yourself.
[13:47:06] <cradek> thanks
[13:47:09] <jepler> I'll be out of town thursday-sunday though
[13:47:26] <cradek> ok
[13:48:01] <cradek> it will have an lcd readout and use those one-wire temperature sensors
[13:48:20] <cradek> I have most of the code working already
[13:50:12] <jepler> http://emergent.unpy.net/files/sandbox/tqfpboard.png
[13:50:25] <cradek> woo, looks challenging
[13:50:33] <cradek> is tqfp a lot finer than soic?
[13:50:33] <jepler> the DRC is 10/10
[13:50:51] <jepler> the pin pitch is .8mm, about 31 mils. soic is 50 mils, I think
[13:51:02] <cradek> neat
[13:51:08] <jepler> I wanna give it a try
[13:51:08] <cradek> I bet you can do it.
[13:51:36] <jepler> I'm sure the machine can cut it, I'm less sure I can solder it without bridges
[13:52:10] <cradek> the blue will just be jumper wires?
[13:52:11] <jepler> eagle is not good at boards where there are two natural grids, one based on 100mil and the other based on .8mm
[13:52:17] <jepler> cradek: yeah
[13:52:59] <jepler> those jumper wires are for the programming header
[14:02:46] <jepler> (which may never be needed, because the microcontroller comes factory programmed with a bootloader that works over usb)
[14:04:02] <jepler> * jepler tries to figure out how to add the two switches that are required to access the bootloader
[14:08:06] <alex_joni> jepler: can you put the config change in git for 2.6.24-16-rtai ?
[14:08:42] <jepler> alex_joni: sure, if that makes things easier for you
[14:09:11] <jepler> but there were other changes in git that caused an abi change on my amd64 machine
[14:09:42] <jepler> cradek: is your design going to be single-sided?
[14:11:18] <alex_joni> jepler: I was thinking about only chaing the config file
[14:11:31] <alex_joni> changing.. sorry
[14:11:43] <cradek> jepler: yes, should be.
[14:42:49] <jepler> alex_joni: I don't think you can get just one change from git (like you can 'cvs up filename') so you're better off applying the patch and not doing a 'git pull'.
[14:43:34] <alex_joni> hmm.. ok
[14:43:44] <alex_joni> anything else needed besides that?
[14:43:51] <jepler> no, just that
[14:43:52] <alex_joni> I mean enabling other modules..
[14:43:57] <jepler> not that I know of
[14:44:05] <alex_joni> ok.. I
[14:44:14] <jepler> might be worth looking at a diff of the config files a second time..
[14:44:15] <alex_joni> ok.. I'll be back on my hardy machine tomorrow evening..
[14:44:25] <alex_joni> maybe I can get around to do this
[14:44:32] <alex_joni> <- right now in germany
[14:48:26] <jepler> huh, there are quite a few.
http://emergent.unpy.net/index.cgi-files/sandbox/config-changes-i386-generic-to-rtai.txt
[14:49:54] <alex_joni> hmm.. maybe they are dependent on disabling ACPI and APM ?
[14:50:05] <alex_joni> different processor type, etc
[14:50:31] <alex_joni> well.. gotta run.. (meeting is over)
[14:50:39] <alex_joni> not sure I'll have net access lateron
[14:50:56] <jepler> see you
[14:51:10] <jepler> I think it's a better test to diff the installed config files
[14:51:18] <jepler> but I don't have an installed i386 system
[14:52:13] <alex_joni> ok, I'll do that
[14:53:06] <jepler> here are the amd64 installed differences:
http://emergent.unpy.net/index.cgi-files/sandbox/config-changes-amd64-generic-to-rtai.txt
[14:53:38] <jepler> (filtering them by "grep '^CONFIG' /boot/config-whatever | sort > /tmp/config-whatever" before diffing)
[14:54:21] <jepler> I bet in the i386 case it'll give a shorter list as well
[16:16:38] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/hal/components/threads.c: give a default 1ms thread with floating point if no module commandline options are present
[19:17:43] <issy> Hi all
[19:17:58] <cradek> hi
[22:00:16] <cradek> jmkasunich: 2.000 => 2,000
[22:59:35] <jmkasunich> a pox on thousands separators
[23:14:16] <BigJohnT> now I understand
