it looks like probes involve two canon calls? one to make the move and capture the value, and one to return the value?
so the sai and preview versions just complete the move and capture the endpoint
they don't need any special tricks to return something sane
yes they will just show the entire move
and return the coord of the endpoint
have you ever written a "smart probing" program?
(where it doesn't go all the way up every time)
it seems like the preview for that would be rather nutty
it works great
preview for that kind of thing is hopeless
[00:03:28] <cradek> http://timeguy.com/cradek-files/emc/smartprobe.png
probing up and over a (simulated) hemisphere
[00:04:09] <cradek> http://timeguy.com/cradek-files/emc/probe-results.png
this is the actual run, not the preview, right?
connect the resulting points
yes that's the run
the more I think about it, the more I prefer passing a default value to the canon function
the pointer trick is exactly that, a trick
jmkasunich: why does the interpreter know a better default answer than whatever is using it?
the interp doesn't, but the g-code programmer does
and he can stick that better answer into #5399 before invoking M66
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
I'd like to load the nominal value into #5399, so during preview it will just say "all is well" and carry on
without changing canon, you could make axis pay attention to special comments (AXIS,next-analog-value,3.141)
an alternative would be to have the (AXIS, hide) and (AXIS, show) operators turn off/on evaluation of M66
(but maybe you want it to be a computed value, in which case that won't work)
something tells me that "suppress" isn't available in gcodemodule.cc
actually, that would violate the meaning of hide/show anyway
they don't mean "ignore", they mean "execute but don't display"
the more I think about it, the more I like passing a default value to the input canon functions
in SAI and preview, use it, in canon ignore it, done....
go for it
I think I will
is default a reserved work in C++?
my editor highlighted it when I tried to use it as an argument name in a prototype
it is in C
(for case statements)
I'm just using def
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
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
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
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
so much for that excuse - now I have to bite the bullet and make this g-code work
trying to thread a springy part
hmm, guess who touched task and the interpreter last
how do I stop an infinite loop in axis?
the preview is going and going and going
I was hitting just about everything else
I realised just as I hit reload that it was gonna do that
I need to load trunk on the shoptask to use the fix I just added
before it was annoying - I was using the #5399 value to calculate an offset for the final pass
alex_joni: mind if I commit you to making a new kernel release that fixes the arduino problem? :-P
now I'm doing "take spring cuts till the measured value is <= target value"
since measured value is 1.0, and target is 0.23something......
I think I'm doing this all wrong
I should let the human do the thinking, and provide a couple of checkboxes
1) do a spring pass
2) infeed by (X) and do a pass
actually, radio buttons
3) acceptable, continue with program
EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/pwmgen.c: decode PWM Value Register in pwmgen debug output
jepler: on principle I have no problem with it
the problem is that I am travelling this week, and I don't think I can spare the time to properly do it
does the TODO list in the uppermost level of trunk and 2.2.7 need to be updated?
BigJohnT: if only we knew what to write in it :-P
I was just wondering if some of those tasks had been completed and could be deleted :)
* BigJohnT has to go to work now :)
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.)
abort would also need to not reset the interpreter state.
cradek: did you get the ballscrew back togather?
skunkworks_: it is together - I don't have the new balls yet.
maybe they will come today
m-1 "not abort, not program end, not pause, but something else"
well he proposed two problems, changing an insert, and touching off a tool
both could be handled just fine with r-f-l
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)
cradek: does the interp correctly update endpoints while jogging around?
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_Integrator.lyx: minor edit
(maybe it doesn't need to.. but I imagine it would do, if the next line is an arc or a circle)
alex_joni: it synchs the current point at mode switches
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
it might get confused at certain key frequencies, but usually I agree
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.
Stupid people frusterate me! (title of a popular webbbs thread)
Replies: 54 Views: 2632
jepler: I might ask you to make a pcb for me soon.
have you made one with your new nuts yet? I'm anxious to see how round the pads look.
cradek: no, I haven't. what's the board you have in mind?
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
it will probably have a third temp sensor for the regular outside temp too.
strangely, this kind of thermostat doesn't seem to exist.
I'd be happy to mill it for you or let you come over and mill it yourself.
I'll be out of town thursday-sunday though
it will have an lcd readout and use those one-wire temperature sensors
I have most of the code working already
[13:50:12] <jepler> http://emergent.unpy.net/files/sandbox/tqfpboard.png
woo, looks challenging
is tqfp a lot finer than soic?
the DRC is 10/10
the pin pitch is .8mm, about 31 mils. soic is 50 mils, I think
I wanna give it a try
I bet you can do it.
I'm sure the machine can cut it, I'm less sure I can solder it without bridges
the blue will just be jumper wires?
eagle is not good at boards where there are two natural grids, one based on 100mil and the other based on .8mm
those jumper wires are for the programming header
(which may never be needed, because the microcontroller comes factory programmed with a bootloader that works over usb)
* jepler tries to figure out how to add the two switches that are required to access the bootloader
jepler: can you put the config change in git for 2.6.24-16-rtai ?
alex_joni: sure, if that makes things easier for you
but there were other changes in git that caused an abi change on my amd64 machine
cradek: is your design going to be single-sided?
jepler: I was thinking about only chaing the config file
jepler: yes, should be.
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'.
anything else needed besides that?
no, just that
I mean enabling other modules..
not that I know of
might be worth looking at a diff of the config files a second time..
ok.. I'll be back on my hardy machine tomorrow evening..
maybe I can get around to do this
<- right now in germany
huh, there are quite a few. http://emergent.unpy.net/index.cgi-files/sandbox/config-changes-i386-generic-to-rtai.txt
hmm.. maybe they are dependent on disabling ACPI and APM ?
different processor type, etc
well.. gotta run.. (meeting is over)
not sure I'll have net access lateron
I think it's a better test to diff the installed config files
but I don't have an installed i386 system
ok, I'll do that
here are the amd64 installed differences: http://emergent.unpy.net/index.cgi-files/sandbox/config-changes-amd64-generic-to-rtai.txt
(filtering them by "grep '^CONFIG' /boot/config-whatever | sort > /tmp/config-whatever" before diffing)
I bet in the i386 case it'll give a shorter list as well
EMC: 03jepler 07TRUNK * 10emc2/src/hal/components/threads.c: give a default 1ms thread with floating point if no module commandline options are present
jmkasunich: 2.000 => 2,000
a pox on thousands separators
now I understand