Back
[00:03:22] -!- theos has quit [Read error: Operation timed out]
[00:03:22] -!- logger[mah] has quit [Remote host closed the connection]
[00:03:29] -!- logger[mah] [logger[mah]!~loggermah@mail.mah.priv.at] has joined #linuxcnc-devel
[00:04:52] -!- ybon has quit [Quit: WeeChat 0.3.8]
[00:12:12] -!- asdfasd has quit [Ping timeout: 268 seconds]
[00:14:36] -!- plushy has quit [Quit: Leaving.]
[00:18:22] -!- mhaberler has quit [Quit: mhaberler]
[00:39:28] -!- rob_h has quit [Ping timeout: 252 seconds]
[00:41:12] -!- vladimirek has quit [Remote host closed the connection]
[00:48:44] -!- theos has quit [Read error: Connection timed out]
[00:49:01] -!- putnik has quit [Read error: Connection reset by peer]
[00:50:52] -!- putnik has quit [Changing host]
[01:07:05] -!- Tecan has quit [Changing host]
[01:11:21] -!- Roguish [Roguish!~chatzilla@c-50-143-183-227.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[01:15:50] -!- dedis13 has quit [Remote host closed the connection]
[01:25:18] -!- adb has quit [Ping timeout: 276 seconds]
[01:26:04] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[01:35:33] -!- andypugh has quit [Quit: andypugh]
[01:40:15] -!- Roguish has quit [Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032]]
[01:40:23] -!- oyildirim has quit [Ping timeout: 268 seconds]
[02:02:02] -!- Newtonianb has quit []
[02:03:16] -!- ve7it has quit [Remote host closed the connection]
[02:03:49] -!- oyildirim_ has quit [Ping timeout: 268 seconds]
[02:09:29] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:30:54] -!- oyildirim__ has quit [Read error: Connection reset by peer]
[02:46:41] -!- oyildirim__ has quit [Ping timeout: 245 seconds]
[02:55:35] zz_satyag is now known as satyag
[02:56:43] -!- kent_ has quit [Ping timeout: 246 seconds]
[02:56:51] -!- Vq has quit [Ping timeout: 260 seconds]
[03:04:57] -!- skunkworks has quit [Ping timeout: 265 seconds]
[03:19:22] -!- FinboySlick has quit [Quit: Leaving.]
[03:25:01] sliptonic is now known as sliptonic_away
[03:25:27] sliptonic_away is now known as sliptonic
[03:34:05] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[03:34:37] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:34:46] <skunkworks> logger[psha]:
[03:34:48] -!- theos has quit [Quit: cya]
[03:38:56] -!- oyildirim has quit [Quit: Leaving]
[03:42:09] satyag is now known as zz_satyag
[04:02:04] -!- Keknom has quit [Quit: Leaving.]
[04:15:28] -!- mikegg has quit [Ping timeout: 245 seconds]
[04:20:43] -!- Loetmichel has quit [Ping timeout: 268 seconds]
[04:48:55] -!- r00t4rd3d has quit [Read error: Connection reset by peer]
[04:49:18] -!- r00t4rd3d has quit [Changing host]
[05:25:15] -!- zzolo has quit [Quit: zzolo]
[05:35:53] zz_satyag is now known as satyag
[05:39:54] -!- factor has quit [Read error: Connection reset by peer]
[06:02:34] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:04:41] -!- tjb1 has quit [Quit: tjb1]
[06:20:00] -!- plushy has quit [Ping timeout: 256 seconds]
[06:29:13] -!- Xabster has quit []
[06:33:56] -!- Aero-Tec has quit [Read error: Connection reset by peer]
[06:34:34] -!- mhaberler [mhaberler!~mhaberler@extern-181.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[06:37:03] -!- Cylly has quit []
[06:58:59] -!- kwallace1 [kwallace1!~kwallace@smb-12.sonnet.com] has parted #linuxcnc-devel
[07:04:08] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[07:09:36] -!- pfred1 has quit [Quit: nite]
[07:26:27] -!- tjb1 has quit [Client Quit]
[07:30:57] -!- mhaberler has quit [Quit: mhaberler]
[07:35:36] -!- tjb1 has quit [Client Quit]
[07:35:37] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[07:46:59] satyag is now known as zz_satyag
[07:53:34] -!- herron has quit [Read error: Operation timed out]
[08:09:39] -!- plushy has quit [Quit: Leaving.]
[08:18:46] zz_satyag is now known as satyag
[08:35:24] -!- emel has quit [Excess Flood]
[08:51:05] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[08:57:10] -!- b_b has quit [Changing host]
[08:59:05] satyag is now known as zz_satyag
[09:15:12] zz_satyag is now known as satyag
[09:20:26] -!- adb [adb!~IonMoldom@178-211-235-11.dhcp.voenergies.net] has joined #linuxcnc-devel
[09:42:40] -!- adb_ [adb_!~IonMoldom@178-211-235-11.dhcp.voenergies.net] has joined #linuxcnc-devel
[09:43:13] -!- adb_ has quit [Client Quit]
[09:55:31] theos is now known as Guest61381
[09:58:59] -!- Guest61381 has quit [Ping timeout: 246 seconds]
[10:09:12] satyag is now known as zz_satyag
[10:14:01] -!- pingufan has quit [Quit: Konversation terminated!]
[10:15:11] -!- rob_h [rob_h!~rob_h@027c00e2.bb.sky.com] has joined #linuxcnc-devel
[10:55:03] -!- sumpfralle has quit [Read error: Operation timed out]
[11:02:16] theos is now known as Guest32478
[11:04:58] -!- Guest32478 has quit [Ping timeout: 252 seconds]
[11:32:02] <cncbasher> jam628 :make your min ferror 0.5 and your ferror 1,0 for now
[11:33:06] <jthornton> wrong tab cncbasher
[11:33:12] <cncbasher> base period is not needed with the 7I43
[11:33:22] <cncbasher> HAHA
[11:33:30] <cncbasher> thanks john
[11:52:15] -!- logger[psha] has quit [Ping timeout: 256 seconds]
[11:53:30] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[11:53:35] -!- psha[work] has quit [Ping timeout: 255 seconds]
[11:53:51] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[12:14:40] -!- mutilator has quit [Read error: Connection reset by peer]
[12:31:02] -!- Tecan has quit [Quit: live long and phosphor]
[12:33:40] -!- the_wench has quit [Ping timeout: 246 seconds]
[12:34:54] -!- archivist has quit [Ping timeout: 240 seconds]
[12:47:47] -!- leehambley has quit [Quit: leehambley]
[13:34:21] -!- mackerski has quit [Quit: mackerski]
[14:01:50] -!- psha[work] has quit [Quit: leaving]
[14:02:34] -!- automata has quit [Ping timeout: 246 seconds]
[14:33:51] -!- mk0 has quit [Quit: Looking for access to www.icdd.com bases.]
[14:36:49] -!- ybon has quit [Quit: WeeChat 0.3.8]
[15:02:42] -!- ybon has quit [Ping timeout: 260 seconds]
[15:02:58] -!- psha [psha!~psha@213.208.162.92] has joined #linuxcnc-devel
[15:14:54] -!- horatio_cromwell has quit [Ping timeout: 240 seconds]
[15:41:59] -!- plushy has quit [Quit: Leaving.]
[16:00:48] -!- horatio_cromwell has quit [Read error: Operation timed out]
[16:07:15] -!- bmwyss has quit [Quit: bmwyss]
[16:32:32] -!- L84Supper has quit [Quit: <puff of smoke>]
[16:32:46] -!- Yarl has quit [Ping timeout: 260 seconds]
[16:33:01] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[16:34:39] -!- toastyde1th has quit [Read error: Connection reset by peer]
[16:38:05] <awallin> with the latest work on different RT kernels, is there any more hope for linuxcnc on Raspberry Pi or other small single-board computers?
[16:45:16] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 16.0.2/20121025205401]]
[16:45:39] -!- automata has quit [Ping timeout: 260 seconds]
[16:59:25] <seb_kuzminsky> awallin: mah will know better, but i think the answer is yes
[16:59:37] <awallin> ok
[16:59:40] <seb_kuzminsky> try the xenomai-user build
[17:00:06] <awallin> actually I was thinking of non-cnc applications where the real-time isn't that critical but having HAL and all the HAL-tools would be very useful
[17:00:41] <awallin> they DIY would then amount to writing drivers for DACs and ADCs over the ras-pi SPI or I2C bus. I don't know how hard that is
[17:02:55] <awallin> this stems from an icreasing frustration with various commercial instruments :) a lot of these could be replaced by a ras-pi with suitable software and simple adc/dac interfaces
[17:29:43] -!- zzolo has quit [Read error: Connection reset by peer]
[17:31:13] -!- mackerski has quit [Quit: mackerski]
[17:44:05] -!- paideia has quit [Quit: Leaving]
[18:05:01] charlie is now known as Guest94749
[18:13:06] -!- horatio_cromwell has quit [Read error: Operation timed out]
[18:17:57] -!- zzolo_ has quit [Ping timeout: 245 seconds]
[18:26:34] -!- pingufan has quit [Quit: Konversation terminated!]
[18:27:05] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[18:41:09] -!- tjb1 has quit [Quit: tjb1]
[18:46:31] <mhaberler> awallin: that's why I want to spin out rtapi+hal
[18:47:28] <mhaberler> that should work perfectly fine even with posix threads if its not time critical, and you dont have to fiddle with the underlying OS
[18:48:08] -!- Guest94749 has quit [Quit: Leaving]
[18:48:15] <mhaberler> there is a very minimal gpio driver for the pi which can be used as a starting point - it does wiggle pins
[18:48:52] <mhaberler> with a bit of luck pulling the right opengl package you might even get gladevcp to work on it
[18:49:24] <awallin> sounds good
[18:49:41] <mhaberler> so you get everything minus motion, rs274ngc, nml and other drag factors ;)
[18:49:48] <awallin> I think 1ms threads in HAL with reasonable latency would be a start. not sure what kernel is required for that
[18:49:49] <mhaberler> do you have a pi?
[18:50:06] <awallin> no not yet. farnell website says 3 weeks if I get inspired to order one.
[18:50:18] <mhaberler> that should run just fine, you get better latency with xenomai, thats all the difference
[18:50:29] <awallin> I was also looking at the 7" touchscreens. with usb-connection - not sure how well they work with pi
[18:50:45] <mhaberler> well the hal+rtapi thing would make a great standalone controller
[18:51:15] <awallin> I would also need something like touchy for the touch-panel. setting pid-parameters etc
[18:51:37] <mhaberler> well then gladevcp is for you
[18:51:59] <mhaberler> mind right now gladevcp shares memory with HAL so no remote
[18:52:32] <mhaberler> halrmt is possible in theory but its a dog and no API
[18:52:59] <mhaberler> I have beginnings of remote HAL with zeroMQ which I have grounded due to the linuxcnc licensing situation
[18:53:36] <awallin> remote control of HAL or the UI would not be priority at first. If I ever get this project started..
[18:53:48] <mhaberler> then you're fine
[18:54:13] <awallin> I guess it's a complete linux install so there is xvnc possibility?
[18:54:27] <mhaberler> I would think so but I havent tried
[18:54:35] <mhaberler> or just remote X display
[18:54:49] <mhaberler> that's be much faster than vnc
[18:55:01] <awallin> or running apache on the machine and developing some custom local website that sets parameters. like all routers/wifi-boxes do
[18:55:02] <mhaberler> actually I need to try this
[18:55:55] <mhaberler> btw great that you're engaging in the dxf2gcode think, I'm really looking forward the integration
[18:56:33] <mhaberler> the opengl issue is likely some package mess on my side
[18:56:39] <awallin> yeah it should be straightforward with the right interface. ofcourse openvoronoi still has bugs(failure-cases)...
[18:56:59] <mhaberler> right, but then there's visual control
[18:58:03] <mhaberler> well I'll see if I can cook up a pi standalon hal/rtapi/gladevcp thing, that would be great sales;)
[18:58:17] <awallin> yeah, +1 on that.
[18:58:48] <awallin> sorry I haven't read your timing/trajectory email with any thought yet. It's probably something that takes a while to absorb/study before I can have an opinion
[18:58:55] <mhaberler> maybe I can defibrillate our cherished community in picking up the gpl3 compatibility issue again and actually tick it off
[18:58:57] <mhaberler> dont worry
[18:59:34] <mhaberler> I think I got an answer by discussing with Amit, who really is up to speed with these things
[19:00:47] <mhaberler> it seems the actuall time critical ops in motion are: interpolating the next commanded position, and having it fed to the PID loop in the right momenet (ie without noise or you'll have to turn down pid gains)
[19:01:21] <awallin> pcw's experiments sounded plausible...
[19:02:02] <mhaberler> that means my idea of calculating the postion for the current time solve the wrong problem, it's getting out the next pos in time
[19:07:07] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 16.0.2/20121025205401]]
[19:10:03] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[19:28:07] -!- b_b has quit [Changing host]
[19:45:27] -!- micges has quit [Quit: Wychodzi]
[19:46:37] -!- b_b has quit [Changing host]
[19:48:57] -!- plushy has quit [Quit: Leaving.]
[19:49:08] -!- phantoneD has quit [Ping timeout: 248 seconds]
[19:50:11] -!- motioncontrol has quit [Quit: Sto andando via]
[19:54:29] -!- skunkworks has quit [Ping timeout: 248 seconds]
[19:59:00] -!- cradek has quit [Changing host]
[19:59:00] -!- cradek [cradek!~chris@emc/board-of-directors/cradek] has joined #linuxcnc-devel
[19:59:00] -!- mode/#linuxcnc-devel [+v cradek] by ChanServ
[20:03:18] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[20:05:12] -!- pcw_home [pcw_home!~chatzilla@ip-66-80-167-54.sjc.megapath.net] has joined #linuxcnc-devel
[20:07:15] <pcw_home> mhaberler: pretty sure what the hardware would like is current position and derivatives for next position
[20:07:58] <mhaberler> I wish we could drag automata over here to discuss this publically
[20:08:32] <pcw_home> (PID needs current position other wise motion at speed is wrong by one sample)
[20:09:28] <mhaberler> not sure anybody would notice
[20:09:39] <pcw_home> Also motion should provide derivatives so they are forward and fixed up for things like index
[20:10:08] <pcw_home> (rather than patched in various ways like in PID)
[20:11:00] <pcw_home> Somebody already noticed (ferror calc is off by one sample)
[20:12:09] <mhaberler> do you think motion (actually interpolation) on current time instead of period (which is assumed time) brings any improvement?
[20:12:43] <pcw_home> so if you use integral term so PID loop minimizes error during a high speed slew
[20:12:45] <pcw_home> you get a ferror proportional to velocity/sample time
[20:13:39] <pcw_home> I dont think the jitter is terribly important
[20:15:08] <mhaberler> my naive assumption was that once could harden this against jitter by using actual time instead of assumed time (which is probably different from being off by one sample)
[20:16:03] <pcw_home> it shows up as white noise in the PID error so at cutting speed of 60 IPM, 100 usec of jitter is only 1/10000"
[20:16:05] <pcw_home> of peak noise, but sure if you use the actual time you can get along with fairly terrible jitter
[20:16:58] <mhaberler> (the question I actually wanted to ask but didnt: why has motion to be on an RT thread to start with )
[20:17:13] <pcw_home> that is 1 ms of jitter just reduces your bandwidth, and doesn't make a huge bogus correction as it would now
[20:17:47] -!- sumpfralle1 has quit [Ping timeout: 268 seconds]
[20:18:28] <mhaberler> well we're talking different magnitudes here
[20:18:36] <pcw_home> I guess because motion reacts in real time to real time events
[20:19:16] <andypugh> Probing, starting threads, limit switch handling?
[20:19:18] <pcw_home> just saying that a servo or hardware stepgen system that uses the actual time is quite jitter tolerant
[20:19:20] <mhaberler> which are? f/o, css, at-speed, blending?
[20:19:31] <andypugh> But I am not sure that is motion or trajectory
[20:19:38] <pcw_home> Yes real time inputs
[20:20:35] <mhaberler> still this is not going to be better than servo cycle, but CV over here 50uSec latency is bad - that doesnt add up for me
[20:21:00] <mhaberler> (leaving out sw stepgen for the purpose of motion discussion)
[20:22:05] <mhaberler> for each of probing, threading, limit switch we can give an upper bound of impact given feed and jitter, but that I never heard as an argument
[20:22:12] <pcw_home> I think 50 is fine (and 200 is probably livable if actual times are used)
[20:23:17] <pcw_home> I doubt any of those care much about jitter
[20:23:24] <andypugh> tbh a real machine doesn't move very far in 1mS.
[20:23:25] <mhaberler> as for the motion 'unexpected realtime delay' message - what I _really_ would be interested in is 'is the tool on path or is it off-path by a margine more than I am willing to accept
[20:23:37] <pcw_home> Yes
[20:23:41] <mhaberler> well yes, that is the point of my argument
[20:24:05] <mhaberler> but I do not yet understand why one has to follow from the other
[20:25:18] <andypugh> Where are you having this argument? It looks like a continuation of something from elsewhere?
[20:25:40] <pcw_home> Like I said for servo or hardware stepgen devices even a ms of extra delay is not terribly important if its known and dealt with
[20:25:42] <mhaberler> I had a long private chat with automata the other day
[20:25:44] -!- Xabster has quit []
[20:25:52] <mhaberler> I probably can mail it to interested folks
[20:27:08] <mhaberler> andy: re which argument.. I meant the uppper boundary on poserr on probing, threading, limit sw
[20:27:35] <mhaberler> that doesnt add up as a 'this is sensitive to jitter' argument, thats what I meant
[20:28:21] <pcw_home> probing/limitsw actuation is normally done slowly so not much of an issue
[20:28:30] <mhaberler> right
[20:28:48] <pcw_home> and if you do it fast you need hardware anyway
[20:29:07] <mhaberler> as long as the servo frequency is well > 2* above the Nyquist limit of the hardware/pid loop then I dont see the issue - noise clearly is one, but my hope would be this could be reduced by using actual instead of assumed time
[20:31:25] <pcw_home> servo frequency needs to be much more than Nyquist limit but yes like I said 100 usec at 60 IPM is 1/10000" peak position jitter into a say 50 Hz low pass filter
[20:32:07] <pcw_home> almost vanishingly small (and largely fixable with actual time)
[20:32:32] <andypugh> I do wonder if encoder velocities are noisy because the period passed to the components isn't actually true.
[20:33:13] <pcw_home> Software or hardware? I think the hardware encoder velocity is pretty clean
[20:34:14] <mhaberler> It would be interesting to identify the spot where actual time could be inserted instead of assumed time
[20:34:29] <mhaberler> my conjecture is line 1237:
http://git.mah.priv.at/gitweb/emc2-dev.git/blob/e589823eea95c049c45f0646b71a2ab0e7a4f2d6:/src/emc/motion/control.c#l1232
[20:34:43] -!- kmiyashiro has quit [Ping timeout: 245 seconds]
[20:34:46] kmiyashiro_ is now known as kmiyashiro
[20:34:47] <pcw_home> but the software one depends on the base period so at speeds around 1count/base period its probably pretty noisy
[20:35:22] <mhaberler> it would be interesting to change that through a hal pin (actual time vs assumed period), but we need a bit of a test rig
[20:35:52] <mhaberler> pcw: do you think you can tell a difference with halscope?
[20:36:20] <pcw_home> On the hardware stepgen absolutley
[20:36:34] <mhaberler> maybe the thread invocation routine in HAL needs a configurable jitter noise source
[20:37:26] <pcw_home> That wouls help testing
[20:37:31] <pcw_home> would
[20:39:25] <mhaberler> ok I'll sleep over it. Would be very much fun if the jitter emperor had no clothes after all;)
[20:39:50] <pcw_home> the current Hostmot2 stepgen driver makes step frequency jitter proportional to the servo thread jitter
[20:39:52] <pcw_home> (when it should really only use the measure error for long time base corrections since its short term accuracy
[20:39:54] <pcw_home> is much better than the servo thread)
[20:40:58] <mhaberler> oh, the commanded velocity is here: line 1264 - here the assumed servo freq comes in
[20:41:39] <andypugh> I suspect that the period needs to be per-component
[20:41:57] <andypugh> (and, in fact, where it matters the components could perform their own system clock check)
[20:42:07] <pcw_home> where does PID get it?
[20:42:14] <mhaberler> what do you mean by that? motion gets current time anyway
[20:42:32] <mhaberler> for 'Unexpected realtime delay' (only)
[20:42:41] -!- syyl_ws has quit [Quit: Verlassend]
[20:42:59] <andypugh> I am thinking about individual HAL modules. The ones at the end of the list will potentially see quite large variations in when they get called.
[20:43:31] <andypugh> (I may be talking about a quite different thing)
[20:43:46] <mhaberler> no same thing there really
[20:43:57] <mhaberler> thats worth investigating too
[20:44:15] <pcw_home> those should be rather fixed delays (assuming no base thread to interrupt them)
[20:44:19] <mhaberler> I'd say assumed time comes in in pid.c line 300 /* precalculate some timing constants */
[20:44:51] <andypugh> You see the thread execution time vary quite a lot, presumably that affects the calling-time of the last module in the list quite badly.
[20:44:54] <pcw_home> bbl
[20:45:03] <mhaberler> that too
[20:46:00] <mhaberler> sw stepgen is quite a cpu eater btw, xenomai shows per-thread cpu usage and base-thread is > 5 times servo thread cpu use
[20:46:59] <andypugh> mhaberler: Is that with reset active? That does a busy-wait for the step time
[20:47:22] <mhaberler> I would need to check
[20:47:52] <pcw_home> Depending on hardware a LPT write might be fast because it can be posted in the hardware
[20:47:54] <pcw_home> but a lpt read will likely always stall the CPU
[20:49:35] <pcw_home> spinning on output is good argument for quadrature step drives instead of this silly step/dir nonsense
[20:49:58] <andypugh> mhaberler: Do you know anything about src/emc/toolstore/sql/schema-simple.sql ?
[20:50:23] <mhaberler> yes
[20:50:26] <andypugh> pcw_home: Very much agreed.
[20:50:26] <mhaberler> I wrote it
[20:50:36] <andypugh> Aha!
[20:50:56] <mhaberler> uh, the toolstore directory.. I thought I should have removed that
[20:51:35] <andypugh> Not so hasty. Why did you think it was a good idea then, and not now?
[20:51:59] <mhaberler> (re parport / cpu usage: that was without reset!)
[20:52:09] <mhaberler> toolstore: let me look
[20:53:30] <mhaberler> ok, what you probably want to look at: cd configs/sim/remap/iocontrol-removed and run that, and read the task python code
[20:53:42] -!- vladimirek has quit [Remote host closed the connection]
[20:53:58] <mhaberler> it completely dumps iocontrol and does it all in task, with phunny sql tool table if that mattered
[20:54:25] <mhaberler> task does direct hal i/o instead of the iocontrol wail wagging the linuxcnc dog
[20:54:34] -!- Simooon has quit [Remote host closed the connection]
[20:55:02] <mhaberler> btw I talked to Bob Yellin on the phone
[20:55:16] <mhaberler> very sensible ideas
[20:55:26] -!- wboykinm has quit [Remote host closed the connection]
[20:55:28] <andypugh> Aha! I avoided that, as I am not at all keen on speaking on the phone.
[20:55:59] <andypugh> I am planning on seeing what happens if stat only holds the current tool.
[20:56:44] <andypugh> Blunderbuss coding, change the structure and let the compiler spot the dependencies.
[20:56:48] <mhaberler> axis will break reading the tt
[20:57:00] <mhaberler> i call it dynamite fishing
[20:57:11] <andypugh> I expect that, but why does Axis need the tool table?
[20:57:23] <mhaberler> what we want is a cache of the toolinfo in the emcstatus message, and a separate pocket pointers
[20:57:38] <mhaberler> saying what is what - no more shuffling of table entries
[20:57:45] <mhaberler> for preview and offsets
[20:58:19] <mhaberler> (oh, and all the other UI's too which I never started..)
[20:58:25] <andypugh> It only shows one tool at a time.
[20:58:51] -!- postaL has quit [Remote host closed the connection]
[20:59:20] <mhaberler> the way it works, it sucks in the whole tt at preview generation time
[20:59:36] <mhaberler> and works from the sucked copy on M6
[20:59:56] <andypugh> But it could get that either as-required, or by a more rational route.
[21:01:19] <andypugh> Heck, Axis could read the tool table direct from the database.
[21:01:25] <mhaberler> oh, rational. what we need is: toolnumbers are just that and immutable in the sense that their slot number has no meaning; the pocket references tell which is active and prepared/preparing
[21:01:40] <mhaberler> what view, the preview view or the current view...
[21:01:54] <mhaberler> I know what you were about to say now..
[21:03:01] <andypugh> Preview runs a minimal G-code interpreter (I think?) which could just grab tool data as it needed it (no tool "table" at all, just tool-by-tool?
[21:03:14] -!- mevon has quit [Read error: Connection reset by peer]
[21:03:23] <mhaberler> what I am not totally sure about is is: whether guis evaluate tool info during graphical progress display (I dont think so)
[21:03:48] <andypugh> I think I need to see what breaks. :-)
[21:03:48] <mhaberler> I think they work off machine corrdinates by halsample
[21:04:10] <mhaberler> preview runs a castrated interp, yes
[21:04:29] <andypugh> OK, so they might be a long way behind the rest of the system.
[21:04:56] <mhaberler> yes, the way preview is done it is bound to fall apart with reality
[21:05:25] <andypugh> So Axis needs to cache tools internally, but only the ones used. That doesn't mean that every tool needs to live in emc_stat all the time, surely?
[21:05:48] <mhaberler> it would be better to run preview off motion, with a switch saying 'drive hardware at real speed'/'drive preview at full steam' and guis would not have to bother with funny interps
[21:06:08] <mhaberler> the way it currently is - its an identity
[21:06:19] <mhaberler> emcstatus holds all possible tools
[21:06:23] <andypugh> The three cannons?
[21:06:37] <mhaberler> well that comes in a bit
[21:06:59] <mhaberler> the gcodemodule canon is just enough to feed back lines and arcs into python
[21:07:52] <mhaberler> at some point I tried to understand that, see
http://git.mah.priv.at/gitweb/rs274-python.git
[21:08:13] <mhaberler> it is jeplerware 'beyond my paygrade', as cradek would put it
[21:08:23] -!- nstrd has quit [Quit: Page closed]
[21:09:14] -!- kwallace [kwallace!~kwallace@tmb-233.sonnet.com] has joined #linuxcnc-devel
[21:10:20] <andypugh> I think that the tool-table work might shipwreck on the cliffs of my lack of Python.
[21:10:22] <mhaberler> saicanon you can leave out
[21:10:57] <andypugh> Or should saicannon be the only cannon?
[21:11:54] <mhaberler> there are two relevant canon apis - the fake preview canon in gcodemodule, and the real one in emcanon.cc which generates commands on the interplist which feed task
[21:12:31] <mhaberler> saicanon just creates text output when you run the standalon rs274 program - give it a try, then its all clear
[21:15:45] <andypugh> I currently have another project, I need to update firmware on my 8i20s, so I am messing about in Hostmot2 at the moment
[21:18:40] <kwallace> Hello. With cutter diameter compensation on, let's say I am driving in the Z direction on a lathe and I want to come up to a workpiece radius, then follow that radius by invoking an arc g-code. I can calculate the intersection of the tool radius with the target workpiece radius. Should I code the Z move to the intersect point or to where the tool's control point will be? I suppose I'll get a gouge error if I don't have an intermediate arc so
[21:19:37] -!- psha has quit [Quit: Lost terminal]
[21:22:38] <andypugh> kwallace: That is one of those questions I keep meaning to answer for myself.
[21:24:31] <cradek> kwallace: code exactly the part profile, set your cutter orientation correctly, and use g41/g42
[21:25:15] <cradek> kwallace: I don't fully understand your question but I know you'll get the right shape cut if you follow that instruction :-)
[21:25:28] <kwallace> I think the intermediate arc is required due to gouging, and should get me to the main arc intersection. I guess I could just give it a try.
[21:30:16] <cradek> kwallace: can you draw a picture that helps me understand your question?
[21:30:40] <cradek> well - can you draw a picture that you think will help me understand your question? :-)
[21:31:24] -!- tjb1 has quit [Quit: tjb1]
[21:31:53] <kwallace> Thinking more this is just like a cutter path along two intersecting lines. One needs a tangent arc between them to prevent gouging.
[21:40:31] <kwallace> http://wallacecompany.com/machine_shop/Screenshot-1.png
[21:41:26] <kwallace> I think I made this more complicated than it was, oops.
[21:48:50] <cradek> no, cutter comp handles concave corners like that just fine, since 2.4.
[21:50:38] <cradek> kwallace: ^
[21:50:57] <mhaberler> does anyone have this paper: Curtis S. Wilson, "How Close Do You Have to Specify Points In a Cotouring Application?" ?
[21:51:08] <mhaberler> referenced in cubic.c
[21:53:13] -!- ve7it has quit [Remote host closed the connection]
[21:56:28] -!- FinboySlick has quit [Quit: Leaving.]
[21:59:47] <kwallace> cradek: If I don't program an intermediate arc. I don't know where to tell the Z move to stop. With the blending arc, I know the Z value will be the start point of the blending arc.
[22:01:56] <kwallace> I suppose what it comes down to is that compensation has to know what the next move is in order to figure out where on the tool edge the control point is?
[22:03:39] <cradek> yes compensation has to look ahead to future moves, and it does this for you, in order to figure out where those endpoints are
[22:04:58] <cradek> http://timeguy.com/cradek-files/emc/lathe_concavecorners.png
[22:05:30] <cradek> this preview shows both nominal and compensated path (compensated is the one running, turning red)
[22:15:19] -!- DJ9DJ has quit [Quit: bye]
[22:17:27] -!- Yarl has quit [Ping timeout: 260 seconds]
[22:23:47] <kwallace> I'll program Z to be the end point of the line that intersects the arc, then program the arc and see how it works. It shouldn't take more than a minute with a sim config to figure it out. Thanks for the help.
[22:24:35] <cradek> kwallace: ... you have to program the profile of the part. that intersection point in your drawing should be the end of the g1 move.
[22:24:42] <cradek> kwallace: maybe I don't understand what you're saying
[22:35:33] -!- zzolo has quit [Ping timeout: 248 seconds]
[22:40:44] -!- Brandonian has quit [Quit: Brandonian]
[22:45:27] <kwallace> cradek: I think I agree with you. G1 X?? to the diameter, G1 Z?? to the intersection point with the arc, then G2 or G3 the arc center and end point. I think I read too much into this when I started out.
[22:49:31] <andypugh> That's a nice picture cradek
[22:50:03] <andypugh> I assume that lcnc just treats the tool as a disc?
[22:51:38] -!- mhaberler has quit [Ping timeout: 246 seconds]
[22:58:04] <kwallace> andypugh: Now that you mention it, back when I was active there wasn't a G41/2 .1 which seems to be connected via L with tool orientation. I've been meaning to get up to speed with this one. I suppose LinuxCNC errors or stops motion if the tool is driven out of the stated quadrant?
[23:01:11] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[23:02:12] <skunkworks> logger[psha],
[23:07:30] -!- tjb1 has quit [Quit: tjb1]
[23:09:05] toastyde2th is now known as toastydeath
[23:10:41] -!- gmouer has quit []
[23:22:36] <andypugh> kwallace: Not that I have noticed
[23:25:38] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[23:28:22] <kwallace> I looked for the G41/2 source, but haven't found where any of the codes come from yet.
[23:28:31] -!- mhaberler [mhaberler!~mhaberler@extern-181.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[23:39:09] -!- oyildirim has quit [Quit: Leaving]
[23:40:57] -!- skunkworks_ [skunkworks_!~chatzilla@68.115.41.210] has joined #linuxcnc-devel
[23:50:54] -!- pjm has quit [Ping timeout: 244 seconds]
