Back
[06:52:03] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/hal/pyvcp_fr.lyx: oops ! file missing -- french translation
[08:15:15] <micges> when I change soft limit in run time and after change machine is outside the table then I can't smoothly jog into the table
[08:15:35] <micges> jogging is in steps about 0.1 mm
[08:15:58] <micges> what's going on ?
[08:18:54] <alex_joni> well.. sounds like a "don't do that" to me
[08:19:20] <alex_joni> setting the soft limit outside the current position will cause all kinds of strange problems
[08:21:12] <micges> I see
[08:21:39] <micges> error that were added to jog are working fine:
[08:21:40] <micges> [1220343517.93] INFO: CommandThread: EXECUTION TIME: 0.32 sec
[08:21:40] <micges> Can't jog joint 1 further past max soft limit.
[08:21:40] <micges> emc/task/taskintf.cc 601: Error on axis 1, command number 1072
[08:22:34] <micges> And after setting limit:
[08:22:34] <micges> [1220343517.61] INFO: CommandThread: LIMIT_MAX
[08:22:34] <micges> Exceeded soft limit
[08:23:14] <micges> alex_joni: anyway thanks
[08:30:24] <alex_joni> micges: this is something that might need fixing
[08:30:35] <alex_joni> as it is now it wasn't possible to get outside the soft limits
[08:30:56] <alex_joni> did you try to activate override limits?
[08:31:03] <alex_joni> maybe that helps
[08:54:59] <micges> override limits doesn't help
[08:55:47] <micges> surely it is wrong state or simmilar becouse milltask take 15% of cpu(normally 1%)
[08:56:56] <micges> and exec_state is fast switching switching (done<=>error)
[09:11:53] <alex_joni> right
[09:49:01] <micges> mdi commands are executed without error outside soft limits
[10:04:55] <alex_joni> it's probably only jogging related
[10:53:25] <alex_joni> for jogging there is a different planner called the free planner
[10:53:39] <alex_joni> in src/emc/motion/command and control you'll probably find the problems
[10:58:02] <micges> thanks I'll look there
[11:34:48] <cradek> I've seen this behavior without changing the soft limits
[11:35:20] <cradek> it is always possible to get outside the limits
[11:36:03] <cradek> I've seen the tiny jogs when it happens. it is surely a bug but I haven't looked for it
[11:36:34] <cradek> I think going into estop and back, then homing, "fixes" it
[11:54:54] <micges> cradek: restoring limits that you are again into table fixes it also
[12:12:33] <cradek> I think the intent is that you can jog in the correct direction to go back inside limits
[12:12:40] <cradek> bbl
[12:56:41] <alex_joni> I'd expect that it's somewhere around jog_ok()
[12:57:41] <alex_joni> micges: I suspect the problem is because the jog limits aren't set right
[12:58:29] <alex_joni> there is a function called refresh_jog_limits() which gets called when you home
[12:59:40] <micges> that function then must be called when sending EMC_AXIS_SET_MAX_POSITION_LIMIT
[13:00:03] <micges> i think..
[13:02:55] <jepler> patches welcome
[13:07:14] <alex_joni> and the micges only if homed already
[13:07:23] <alex_joni> err.. that didn't come out right
[13:08:36] <alex_joni> micges: try to add in emc/motion/command.c at case EMCMOT_SET_POSITION_LIMITS:
[13:10:01] <alex_joni> hmm.. I see that refresh_jog_limits() gets called quite often, so it probably will update itself after a while
[13:12:35] <micges> no effect
[13:38:55] <alex_joni> micges: sorry, can't look & test right now
[13:41:08] <micges> np
[15:02:42] <skunkworks_> SWPadnos:
http://www.cnczone.com/forums/showpost.php?p=496222&postcount=286
[15:02:57] <skunkworks_> http://www.safeguardrobotics.com/default.aspx?tab=cncbrain
[15:03:08] <skunkworks_> thought you would get a kick out of that.
[15:05:28] <cradek> The Brain uses true HUGE floating point signal generation. Also, the signals for each axis are generated by independent processors giving very fine resolution (unshared processing power). Between these two aspects, the signal transistion from one interpolation to the next is very fine.
[15:05:44] <cradek> what a lot of ... words
[15:05:57] <SWPadnos> the degree of parallel better when informing the working piece process
[15:06:31] <SWPadnos> (paraphrase from the polygon turning video, don't bother searching for it :) )
[15:07:10] <skunkworks_> the zone is all a buzz
[15:07:18] <SWPadnos> yes, it is
[15:08:07] <skunkworks_> I also had visions of what you said - inputs and outputs going right to the proccessor
[15:08:23] <skunkworks_> *whateverssor
[15:08:32] <SWPadnos> heh
[15:08:36] <jepler> does their website look this good to the rest of you?
http://emergent.unpy.net/files/sandbox/html-layout-brain-medium.png
[15:09:05] <cradek> jepler: yeah pretty much.
[15:09:47] <SWPadnos> oh yes, you get some interesting overlays when you change window size
[15:10:23] <SWPadnos> http://www.vault.oseland.net/2005/03/washington-post-mensa-invitational.html
[15:10:29] <SWPadnos> a lighter note
[15:10:49] <skunkworks_> I think others have complained that the site only looks correct in IE
[15:10:49] <SWPadnos> also poorly formatte dfor me
[15:12:45] <SWPadnos> it sounds like there's either something really interesting being invented, or somebody doesn't know the difference between path planning and path following
[15:20:21] <skunkworks_> I sounds interesting.. I wonder if a huge fpga is used with multible soft proccessors
[15:20:49] <skunkworks_> there is not a picture of the actual board
http://www.safeguardrobotics.com/gallery/cncbrain/yes_e_stack.jpg
[15:22:45] <jepler> I think that a half dozen CPUs fit comfortably on even modest FPGAs
[15:23:13] <jepler> xilinx picoblaze: "The result is a microcontroller that occupies just 76 Spartan-IIE slices, which is 9% of the smallest XC2S50E device"
[15:24:34] <SWPadnos> picoblaze isn't exactly blazingly fast with HUGE floating point numbers though :)
[15:24:51] <jepler> well, no
[15:25:11] <jepler> having a half dozen blazing fast huge FPUs on an fpga is another dish of worms altogether
[15:26:01] <SWPadnos> if you're doing specific operations, it shouldn't be too bad
[15:26:17] <SWPadnos> if you want a general-purpose FPU, it's a bit harder
[15:26:24] <SWPadnos> several of them especially
[15:36:46] <jepler> hm, dividers take up a lot of FPGA real-estate -- a 32/32 divider takes 1713 slices on Spartan-3
[15:38:45] <SWPadnos> yow
[15:38:59] <jepler> http://www.xilinx.com/support/documentation/ip_documentation/div_ds530.pdf
[15:41:18] <jepler> or if you use spartan3a and the 'high radix solution', a 36/36 divider can take 541 FF + 1 BRAM + 13 DSP48
[15:41:51] <SWPadnos> yeah - 1716 is for a single-cycle quotient+remainder, which can run at 206MHz
[15:42:50] <SWPadnos> err -134MHz in the Spartan
[15:42:58] <jepler> that's throughput, not latency, I think
[15:43:44] <SWPadnos> dunno - I didn't read what they mean by "clocks_per_division"
[15:43:49] <jepler> latency is about 66 clocks (?) M+F+2
[15:43:52] <jepler> see table 3
[15:44:18] <SWPadnos> ah, okl
[15:44:20] <SWPadnos> -l
[15:45:16] <jepler> I guess maybe for the radix-2 version you can choose a space/throughput trade off clocks_per_division, they just don't show it except for small divisors
[15:49:06] <SWPadnos> right
[15:49:42] <SWPadnos> I don't see how you can get lower than 1 clock per bit + some setup/finishing time, if you're doing a sequenced divide
[15:49:47] <jepler> anyway, I think you'd want one CPU plus logic for stuff like stepgen.
[15:50:10] <SWPadnos> then again, I only know one relatively good algorithm, and it's meant for sequential CPUs :)
[15:50:23] <SWPadnos> stepgen + PID + autotuning
[15:50:40] <jepler> it's for steppers -- why does it have PID?
[15:52:55] <SWPadnos> damfino
[16:31:02] <skunkworks_> we need to come out with a quad loop controller..
[17:52:16] <jepler> cradek: (the specs page for teh "cnc brain" makes it clear that the I/O are directly connected to logic, even if you didn't think it based on the photo)
[17:53:29] <jepler> skunkworks_: I think that technically speaking a quad loop controller would be a "jerk controller". The first PID is position, the second is velocity, the third would be acceleration, and the fourth would be jerk.
[17:54:55] <skunkworks_> that is also a buzz - jerk limited..
[18:09:45] <jepler> hi matt!
[18:09:58] <mshaver> That was quick!
[18:10:07] <SWPadnos> it's a hotkey :)
[18:10:10] <jepler> it's the magic of dual montiors
[18:10:20] <mshaver> <laughing>
[18:10:34] <jepler> I can have the my hopeless attempts at writing C++ code on one monitor, and IRC as a constant distraction on the other
[18:10:52] <SWPadnos> you need to upgrade to triple monitors
[18:11:04] <skunkworks_> same here actually.. (just vba in the other..)
[18:11:08] <SWPadnos> that way you can have a web game on one, IRC on another, and the C++ somewhere on the third
[18:11:25] <SWPadnos> (in case you get bored with one distraction, you know)
[18:11:43] <mshaver> Here, I'll make you feel better (my hapless attempts at writing Javascript):
http://www.mattshaver.com/ecmacam/ecmacam.htm
[18:13:29] <SWPadnos> just add 3D preview, and clickable/editable dimensions on the preview, and it'll be finished! :)
[18:14:04] <mshaver> OK, hold on a minute...
[18:14:22] <jepler> with canvas3d that should be pud!
[18:14:42] <mshaver> Are you actually waiting? :)
[18:15:08] <jepler> well -- I am not the target audience for this software
[18:15:35] <mshaver> Well, we'll see. Maybe I can do some sort of SVG thing.
[18:15:41] <SWPadnos> I'm waiting, but I have decided to continue breathing during the waiting period :)
[18:15:54] <mshaver> Smart move!
[18:16:03] <SWPadnos> thanks
[18:16:48] <mshaver> Anyway, just sort of lurking/logging - got to go drill some holes and connect some wires!
[18:16:53] <jepler> that reminds me that I should either figure out how to resolve the self-intersection bugs in offs, or start over with a different approach to offsetting
[18:19:41] <cradek> it would sure be neat if that worked...
[18:19:55] <cradek> I've been trying to figure out how to make something at least as useful as REALIZE but for lathe
[18:20:00] <skunkworks_> hey - the java page actually does stuff
[18:22:06] <jepler> ahah, I spotted my typo
[18:22:11] <jepler> man I hate C++
[18:22:12] <mshaver> (came in to grab a pair of calipers) - Yes, it actually "does stuff"! Good grief! There are some unimplemented operations, but the page "infrstructure" works pretty well!
[18:23:18] <mshaver> (going back out to measure drill bits...)
[19:34:03] <jepler> I wish somebody would contribute improvements to the debian packaging of emc to get a "minimal" package, and commit to providing debian stable precompiled packages of it, so that everyone who complains about ubuntu minimum hardware requirements would just shut up
[19:35:10] <jepler> (emc-minimal = core functionality + keystick, emc-{xemc,tkemc,axis} as separate installable packages)
[19:40:43] <skunkworks_> is that a lot of work?
[19:42:28] <cradek> which, making some packages, or getting it right?
[19:42:40] <jepler> skunkworks_: thanks for offering!
[19:42:49] <cradek> haha
[19:43:56] <jepler> two main things apply when supporting a new distro (or new version of distro): the building the realtime kernel until it works for everyone, and building every release
[19:44:06] <jepler> for the hand-holding distro there's also building the live CD
[19:44:36] <jepler> for me it's the idea of the ongoing work (and little payoff personally) that keeps me from doing it, because the kernel and package could be done in a weekend
[19:47:35] <skunkworks_> heh - I don't know what to say about that
[19:48:39] <skunkworks_> cradek: what is left on the lathe?
[19:49:11] <skunkworks_> also.. jepler is wondering if you got the bridgeport hooked back up
[19:50:38] <cradek> the lathe is working and I've made a few things on it... the bridgeport just needs to be wired back up to power
[19:50:54] <cradek> and then move some stuff so I can get to it...
[19:51:50] <skunkworks_> heh - neat
[19:52:02] <skunkworks_> what have you been making - if I could ask
[19:52:25] <cradek> so far, only some bushing/ring shaped things
[19:53:00] <cradek> have some material ordered - I only have a few more inches of 1" aluminum
[19:54:34] <skunkworks_> is the backlash an issue in the one axis?
[19:55:19] <cradek> yeah I wish it was better. it is .002 or even 3
[19:55:38] <cradek> the X is perfect, maybe .0002, the Z has a problem
[19:57:49] <jepler> hm, I see the dumpstercnc guy has added 4-start 1/4-16 antibacklash leadnuts to his catalog. I think that'd be a little too coarse for a 1.8 degree stepper, though -- that's .00125 per full step
[19:57:59] <jepler> I bet it'd go fast
[20:04:21] <skunkworks_> yah - I think that would be too coarse
[20:04:32] <skunkworks_> what is your max speed right now?
[20:26:35] <alex_joni> jepler: where can I find a screenshot of offs?
[20:37:15] <jepler> skunkworks_: 60 lowersk60
[20:37:18] <jepler> argh
[20:37:20] <jepler> skunkworks_: 60
[20:38:05] <jepler> alex_joni: here's one:
http://emergent.unpy.net/files/sandbox/offs-one-more-bug-fixed.png
[20:39:02] <cradek> interesting - they are closed paths so you can use gopt.
[20:39:52] <jepler> cradek: yeah I suppose that's true
[21:17:43] <alex_joni> jepler: love the title on your AXIS :)
[21:18:52] <jepler> alex_joni: the original path was from cradek ..
[21:19:00] <jepler> dunno about the 'include(../VERSION)' bit
[21:19:03] <jepler> ooh time to go home!
[21:35:46] <jepler> skunkworks: before I turned on backlash compensation I got 72ipm, but I found that it was necessary to lower maximum acceleration and velocity with backlash comp
[21:55:42] <alex_joni> sounds like a small decrease
[22:12:12] <skunkworks> that should be a nice speed for a machine that size
[22:12:45] <skunkworks> the hermes was a 4 start iirc - that thing zipped along but had pretty low full steps per inch
[22:24:51] <alex_joni> good night all
