Back
[03:54:00] <skunkworks> KimK: how is it going?
[03:56:08] <KimK> skunkworks: Ha, saw your message earlier, finally got the internet back, so doing better now, lol. Merry Christmas to you and yours, and to everyone in the channel.
[03:56:19] <skunkworks> Thank - same to you!
[03:57:20] <skunkworks> *thanks
[03:58:13] <KimK> I noticed some K&T progress reports on the mailing list, but haven't had a chance to look at them yet. Hope that's going well too.
[03:58:59] <KimK> * KimK is way behind on email, as usual lately.
[04:00:04] <skunkworks> heh
[04:00:29] <skunkworks> going well - next is mounting the spindle encoder.
[04:04:58] <KimK> I am monitoring my host's turkey in the oven for at least 18 more minutes, possibly 48. (Inconceivably 78 more?) Depending on the little plastic doodad.
[04:06:44] <KimK> I'll look forward to seeing your spindle encoder, do you need it for oriented stop before tool change, or doesn't it matter?
[04:07:32] <skunkworks> no - the orient is mechanical
[04:07:54] <KimK> Ah, a hydraulic shot pin, I'll bet?
[04:08:52] <skunkworks> http://www.electronicsam.com/images/KandT/conversion/spindle/spindleencoder.JPG
[04:09:38] <skunkworks> yes - sort of - it pushes a gear that has a dog on one side.
[04:10:15] <skunkworks> http://www.electronicsam.com/images/KandT/conversion/spindle/spindletiminggear.JPG
[04:17:41] <KimK> Nicely done. Dad's work, yours, or both? Belleville washers at the bottom and the "unclamp pusher"(?) at the top (vice-versa in 2nd picture)? How much oil sprays around in that case when it's running, "none"?
[04:22:18] <skunkworks> some :)
[04:22:27] <skunkworks> that end - not much
[04:26:06] <KimK> I'm thinking there might be bugs in CL related to PLC program using certain functions and being above a certain size, but I have to get back to that and do more testing before I can say for sure. Maybe after Christmas and New Year's.
[04:27:16] <KimK> I have to set up some easily repeatable tests.
[04:43:49] <skunkworks> I have not had an issue yet/
[04:43:57] <skunkworks> and the ladder is getting bigger and bigger ;)
[04:45:08] <skunkworks> http://www.electronicsam.com/images/KandT/conversion/spindle/belvel.JPG
[04:47:04] <skunkworks> the gear goes on the smallest hex. the top hex is the cylinder that pushes the belvel and unclamps the collet.
[11:18:26] <morfic-> morfic- is now known as morfic
[14:24:28] <skunkworks> alex_joni: Merry Christmas
[14:29:20] <alex_joni> skunkworks: thanks a lot, same to you
[15:53:32] <Jymmm> Crăciun fericit alex_joni
[19:22:13] <psha> mhaberler: merry cristmas?
[19:22:28] <psha> or it's not today?
[19:22:43] <mhaberler> very much so! was yesterday
[19:22:52] <mhaberler> to yourself as well!
[19:23:32] <psha> in russia cristmas is on 07.01 :)
[19:23:51] <mhaberler> yeah I know, you're so behind
[19:24:04] <psha> since it's religious holiday it differes from catholic counterpart
[19:25:01] <mhaberler> well, I suffered through it ;-)
[19:25:02] <mhaberler> btw I have a working prototype of post-mdi-execue signals
[19:25:25] <psha> btw your patch for 'is_complete' is correct but not perfect - i believe that timeout argument to wait_complete is betetr
[19:25:28] <psha> better
[19:25:43] <mhaberler> ah, good idea
[19:26:00] <psha> i've alread patch for that - somewhere in repo :)
[19:26:11] <psha> it's more universal and pretty minimal
[19:26:52] <mhaberler> proably easier to get accepted
[19:27:01] <mhaberler> go grep a bit..
[19:35:08] <psha> on gladevcp-actions
[19:39:22] <mhaberler> ok, I'm lukewarm about that -you cannot tell wether the MDI run was ok or terminated with RCS_DONE or RCS_ERROR
[19:41:54] <psha> it's equivalent to yours function
[19:42:02] <psha> i mean in terms of return value
[19:42:07] <psha> both return 'status' value
[19:42:15] <psha> ah, sorry
[19:42:17] <psha> not correct
[19:43:15] <psha> hm, stat->status is more suitable then stat->get_address()->status?
[19:43:28] <mhaberler> same thing I'd say
[19:43:48] <psha> i've mocked a bit with theese waiting function in halui and discovered that even if command is aborted return value is same as it's done
[19:43:48] <mhaberler> just an alias
[19:43:57] <psha> then theese functions are equivalent
[19:44:02] <psha> they both return status
[19:44:22] <psha> difference is wait_complete returns -1 when nothing available and yours - 0
[19:45:02] <mhaberler> fine
[19:45:04] <mhaberler> what needs to be added is the RCS_DONE and RCS_ERROR constants
[19:46:00] <mhaberler> ENUMX(4, RCS_DONE);
[19:46:01] <mhaberler> ENUMX(4, RCS_EXEC);
[19:46:03] <mhaberler> ENUMX(4, RCS_ERROR);
[19:46:37] <mhaberler> the advantage of returning 0 is you can use it as list index
[19:46:50] <mhaberler> into list of string msgs
[19:48:17] <mhaberler> well, minor - either way is fine, just need to decide which ;-)
[19:49:16] <mhaberler> do you thik the way I did emit(post-mid-execute) is ok or would you merge that into the main update loop?
[19:50:24] <psha> i feel it's only possible way...
[19:50:37] <psha> i mean with extra timeout loop
[19:50:51] <mhaberler> ok
[19:51:10] <psha> but place where it's connected is not right
[19:51:17] <psha> it's better to place it in GStat
[19:51:51] <psha> but start it from user code
[19:52:22] <mhaberler> fair enough - I wasnt sure
[19:52:23] <mhaberler> the reason why I needed this in the first place: g-code subs modify interpreter state like feed, abs/rel and others
[19:52:25] <mhaberler> these need to be saved/restored
[19:52:26] <mhaberler> wish this animal had a mode stack
[19:52:26] <psha> so you manually emit 'mdi-start' signal and GStat starts timeout loop and emits mdi-stop
[19:52:58] <mhaberler> I see, the signal starts the test in Gstat?
[19:53:04] <psha> yes
[19:53:17] <mhaberler> ah, clever
[19:53:21] <psha> with this approach you'll have both start/stop signals
[19:53:43] <mhaberler> well, go ahead an fix it how you think it's right
[19:53:53] <psha> ok, hang a bit
[19:54:01] <psha> i'll amend last patch with RCS_DONE constants
[19:54:07] <mhaberler> there's no hurry whatsovever
[19:54:28] <mhaberler> I havent pulled it anyway, but I'll drop my branch and merge from you
[19:55:21] <psha> ok
[19:56:16] <psha> also i believe that stripping RCS_ prefix is not right
[19:56:22] <mhaberler> ok
[19:56:35] <psha> what's emc.DONE?
[19:56:48] <mhaberler> good point
[19:58:03] <mhaberler> the real art is constructing the MDI command list.. see this and there will be two more params:
[19:58:04] <mhaberler> O<nprobe> call [0] [${probe_feed-f}] [0-${retract-f}] [${probe_travel-f}] [${probe_diameter-f}] [${ref_system-s}] [${tc_touchoff_x_at-f}] [${do_retract}]
[19:58:29] <mhaberler> looks like a bad modem line ca 1987 ;-)
[20:00:52] <psha> %)
[20:01:06] <psha> AT command is really similar to this %)
[20:05:14] <Jymmm> ATDT9005551212,23,23,43,23,56
[20:05:52] <Jymmm> CONNECTED 9600
[20:05:54] <mhaberler> that was the noise-free part ;-)
[20:06:04] <Jymmm> ATH
[20:06:07] <Jymmm> NO CARRIER
[20:08:13] <KimK> What's this? It seems EMC2 has started to engrave an incoming fax.
[20:08:54] <Jymmm> KimK: Permanted record will withstand tsunami
[20:09:07] <KimK> Ha, there you go.
[20:09:34] <KimK> Hey, Merry Christmas to everyone.
[20:09:47] <Jymmm> Same to you =)
[20:10:09] <Jymmm> My home made all rotten potatoes are almost done =)
[20:10:55] <KimK> Applewood-smoked turkey here.
[20:11:41] <Jymmm> We found a 17lb pre-sooked spiral sliced ham and added slices of fresh pineapple to it, it's in the oven as we speak.
[20:11:47] <Jymmm> for $28
[20:11:52] <Jymmm> cooked
[20:12:27] <JT-Shop> peanut butter sandwiches here... toasted and sprinkled with sugar
[20:12:32] <Jymmm> As soon as the poratotes come out, the apple pie goes in =)
[20:12:38] <Jymmm> JT-Shop: YOU LIE!
[20:13:09] <Jymmm> JT-Shop: I susect you have a prime rib or some such thing going
[20:13:41] <Jymmm> JT-Shop: I should add the rotten potatoes to your recipe thingy
[20:13:51] <JT-Shop> yes, please do
[20:13:56] <Jymmm> link agina?
[20:14:08] <JT-Shop> gnipsel.com
[20:14:17] <Jymmm> k
[20:41:29] <psha> mhaberler: maybe mdi start/stop on MDI widget are better...
[20:41:50] <mhaberler> you mean names?
[20:42:57] <psha> i mean object which is emitting signal
[20:42:59] <mhaberler> I dont understand what you mean :-/
[20:43:08] <psha> hm
[20:43:15] <psha> most of signals are emited by GStat
[20:43:27] <psha> that's right since they represent global state change
[20:43:43] <mhaberler> and a sense, this is too
[20:43:49] <mhaberler> in a sense
[20:44:08] <psha> you've added your mdi-* signals to MDI Action object
[20:44:22] <mhaberler> duh.. sorry
[20:44:43] <psha> it's correct if we have reliable way to wait for given command
[20:45:25] <mhaberler> I am a little unsure what happens if you hit a MDI widget, and then another one while the first is executing
[20:45:36] <psha> commands will be queued
[20:45:45] <psha> and executed one after another
[20:45:46] <mhaberler> you get a new mdi-start, but just a single stop
[20:46:02] <psha> no
[20:46:04] <psha> two stops
[20:46:13] <mhaberler> do you? need to check...
[20:46:15] <psha> but on same time
[20:46:28] <psha> you've get two timeout loops
[20:46:52] <mhaberler> ah, now I know.. this happens when I hit the *same* widget twice
[20:47:15] <mhaberler> actually I think the button should be insensitive during run
[20:49:23] <psha> maybe
[20:49:39] <psha> so it's design descision - where to place theese signals
[20:51:31] <mhaberler> the Action could be associated with different widgets, but the state save/restore problem comes from the mdi command, so I think it should be in the action
[21:00:40] <psha> hm, maybe it's better to implement MDI as ToggleAction?
[21:01:12] <psha> with returning in released state when it's finished?
[21:01:29] <mhaberler> I think so, yes
[21:01:55] <psha> i'll go to bed now and dream about it at night :)
[21:02:10] <mhaberler> excellent plan ;-)
[21:11:38] <psha> bb
[21:11:45] <mhaberler> bb!
[21:21:37] <alex_joni> Jymmm: thanks
[22:12:35] <Jymmm> alex_joni: =)
