Back
[03:42:26] <jmkasunich> cradek wins the quickest answer contest
[03:42:45] <jmkasunich> by 1 minute ;-)
[03:48:33] <cradek> haha
[03:50:13] <cradek> you have to learn to type fewer words if you hope to beat me
[03:50:46] <jmkasunich> heh
[09:01:49] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[15:39:16] <SWPadnos> hmmm. I just got an ad from IMService, which mentions the ncPod. what ever came of that GPL question with them?
[15:40:13] <jepler> SWPadnos: alex_joni found that they had the source code for their modified version of the gcode interpreter somewhere
[15:40:22] <SWPadnos> ah. ok
[15:40:33] <cradek> http://www.oemtech.com/gcodecompiler/
[15:40:34] <jepler> as far as I know there's still no GPL notice with the executable that came in their SDK, I don't know if he raised that issue when he corresponded with them
[15:40:44] <cradek> it was here, but that website doesn't work for me now
[15:41:03] <SWPadnos> I thought we had found the Windows source, but Fred had mentioned (possibly erroneously) that the ncPod uses the EMC2 trajectory planner
[15:41:11] <SWPadnos> Fred Smith, not Proctor, of course
[15:41:20] <cradek> yes, it actually does use the EMC2 traj planner
[15:41:30] <jepler> it looks like the emc-derived .exe file produced time quantized position output -- that's where the trajectory planner "is"
[15:41:35] <cradek> it generates the trajectory offline
[15:41:39] <SWPadnos> ok, but that's in the Windoes interp, and "pre-planned" segments are aent to the pod?
[15:41:40] <SWPadnos> ok
[15:41:48] <SWPadnos> sent, not aent
[19:29:27] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[19:37:07] <alex_joni> SWPadnos: yeah, just like that
[20:23:13] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[20:39:21] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[20:43:55] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[20:57:29] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[21:40:08] <alex_joni> away lp
[21:40:30] <alex_joni> freaking keyboard
[21:40:33] <alex_joni> night all
[21:57:34] <tomp> regarding Fred Smith and the windows exe using the emc2 tp: if a given ini file and .ngc code file were passed thru the emc software, wouldnt the resulting segments be the same on the 1st, 2nd and nth run ( wouldnt it always produce the same result) ?
[21:57:58] <SWPadnos> not in EMC, due to feed override and such
[21:58:06] <SWPadnos> but the planning may all be the same
[21:58:40] <tomp> assuming feedrqte override wasnt touched, i cant think of any other variable
[21:59:21] <SWPadnos> yeah - I think feed related things are the only ones that can change planning on the fly
[22:00:18] <tomp> my thought is that some work done in realtime may not need to be done in realtime. i had asked before about this possibility and didnt grok the reply ( basicly the replay said 'twe talked about that before' )
[22:00:41] <tomp> and that if things were not done in realtime, then throughput might benefit
[22:00:48] <SWPadnos> you can try to pre-plan everything, but when you throw in the concept of "arbitrarily large files", you have a problem
[22:01:23] <SWPadnos> so if the idea is to pre-process a 1GB .nc file before running it, it may take a while
[22:03:13] <tomp> thats not really a lot of time ( i've pre-processed >500Mb file to hard blend corner radii fer instance ) , but maybe there's some real advantage to doing it on the fly that i amy not seeing
[22:03:47] <SWPadnos> well, let me ask it the other way - what's the advantage of pre-processing?
[22:04:01] <tomp> less work in the interpreter
[22:04:10] <tomp> faster thruput
[22:04:09] <SWPadnos> no, the interp still does all the work
[22:04:29] <SWPadnos> or are you saying that you'd use a fast machine to pre-process, then a slower one as the machine control?
[22:04:50] <tomp> it does sub-interpolate the snmall segmants if the small segments are handed to it ( i think this is what we speak of right now )
[22:05:04] <tomp> it does >not< sub-interp
[22:05:19] <tomp> and so has less to do
[22:05:32] <SWPadnos> "it" being the machine controller?
[22:06:05] <tomp> yes, i speak of what 'tpRunCuclye and tcRunCycle do a lot of times for a single line or arc
[22:06:31] <tomp> they both run a lot of times for a single line or arc in queue
[22:07:27] <tomp> tpRuncycle determines thext postion ( this is posn interpolate) and tcRunCyucle calcs the new velocity ( this is velocity adjust, not quite interp)
[22:07:40] <SWPadnos> heh - I sort of have a mental block on how TP/TC/task split work, so I may not be very coherent on the subject :)
[22:08:03] <tomp> me too; but been spending a bit o time in there recently ;)
[22:08:09] <SWPadnos> heh
[22:10:23] <SWPadnos> I think that the RT code isn't starving for work most of the time, so if the interp can keep up, I'm not sure what preprocessing buys you
[22:11:56] <SWPadnos> I'm not sure if preprocessing may have negative effects on feedback-controlled systems as well (I think the TP ignores errors until they become too large - that's left to the PID, but it's possible to make systems that change speed based on dynamic feedback fromt he machine)
[22:13:37] <tomp> i'm thinking to allow the feedback and correction, and to stop on excessive errors ( lagg too high , Vcmd out of range ), but pre-crunch. i hadnt considered Fovr tho
[22:14:24] <tomp> or Sovr (spindle override )
[22:16:17] <tomp> Sovr wouldnt change the positions pre-calced for the time slice (update rate ) that was used. but Fovr would mess up all the pre-crunching
[22:16:18] <SWPadnos> right - CSS and FPR can't be pre-planned, I think ...
[22:16:31] <SWPadnos> but it depends on how you define pre-planning
[22:18:29] <tomp> the idea is if the result of emc is consistant, then the segments are the same. I think CSS and FPR would be consistant. I only see intrevention( change) with Fovr ( and damaged equipment, like amplifier failure, encoder failure )
[22:19:57] <SWPadnos> I don't know how much of a change there is from G-code (which is consistent) through the various levels of planning and motion control
[22:20:50] <SWPadnos> I think the rewriting of paths (due to accel constraints and path tolerance, for exmple) isn't a real CPU burden, and I believe it's only done once per segment (or segment pair)
[22:21:26] <SWPadnos> and I'm not sure how much further it micght make sense to go for a preprocessor
[22:22:19] <tomp> oh, tcRunCycle and tpRunCycle ( the thingys that determine the next little line to move and the velocity to use going there ) these are done tens to thousands of times for a single line or circle ( and even more is done in the blends between )
[22:22:37] <tomp> regards 'once per segment'
[22:23:22] <tomp> the length of the segment is related to the time ds;ice and the time slice to the servo update rate aka trajectory period
[22:24:06] <tomp> thats a lot of crunching
[22:25:07] <tomp> ok, i go think about it ... and take a shower (phew today was esp hot & dirty work ) bbl
[22:27:23] <SWPadnos> indeed - it is hotter than hell here
[23:21:16] <cradek> something tells me the CSS docs are ... well, nonexistent
[23:23:33] <SWPadnos> heh
[23:24:57] <cradek> it might be obvious to me that you have to home X for it to work, but it would be nice if that were written somewhere too
[23:25:51] <SWPadnos> I had thought about home and offsets when he first posted the problem, but I didn't (and don't) know enough to describe (a) what to check or (b) how to correct it
[23:26:02] <SWPadnos> so yes, docs would be good :)
[23:56:51] <jmkasunich_> jmkasunich_ is now known as jmkasunich