Back
[00:12:46] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[00:44:51] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[02:37:42] <jepler> + rsync --delete --bwlimit=20 -zrtlv EMC2_Developer_Manual.pdf EMC2_Integrator_Manual.pdf EMC2_User_Manual.pdf HAL_User_Manual.pdf html linuxcnc.org:docs/devel/
[02:37:47] <jepler> ssh: linuxcnc.org: Name or service not known
[02:37:50] <jepler> rsync: connection unexpectedly closed (0 bytes received so far) [sender]
[02:38:22] <jepler> I have been getting this intermittently over the last few days .. maybe 1 out of 20 runs. anyone else seeing name lookup issues for linuxcnc.org?
[02:39:15] <cradek> I haven't seen that...
[02:39:58] <jepler> I won't sweat it then
[02:44:43] <jepler> can you do me a favor? Set one of the PWMs to its most positive value and make sure it gives a 100% duty cycle. Then do the same for the most negative value
[02:44:55] <jepler> I haven't tested that yet but I think I got it right
[02:46:45] <cradek> sure
[02:47:07] <jepler> did bill share the spice cake with you?
[02:47:15] <cradek> yes it was very good
[02:47:31] <cradek> I'm getting 70000nsec motion-controller.tmax
[02:47:39] <cradek> does that mean I could run 10kHz servo cycle?
[02:47:45] <jepler> motion-controller is the whole thread?
[02:47:57] <cradek> uhhhh
[02:48:01] <cradek> * cradek shrugs
[02:48:08] <cradek> 04 s32 RW 20424 motion-command-handler.tmax
[02:48:08] <cradek> 04 s32 RW 69015 motion-controller.tmax
[02:48:12] <cradek> 09 s32 RW 58627 pluto-servo.read.tmax
[02:48:12] <cradek> 09 s32 RW 29143 pluto-servo.write.tmax
[02:48:14] <jepler> the EPP communication takes a substantial length of time too
[02:48:43] <jepler> (and remember -- those are cycles, not ns)
[02:48:49] <cradek> oh, oops
[02:49:23] <cradek> chris@max:~$ units 69015/800MHz kHz
[02:49:25] <jepler> I'd start with a more modest 2kHz or 4kHz .. and see if you can detect any improvement
[02:49:28] <cradek> * 11.591683
[02:49:38] <cradek> I'm at 2kHz now
[02:50:19] <jepler> I think you need to add them all up: $ units "(24014+69015+58627+29143)/800MHz" kHz
[02:50:36] <cradek> 4.4
[02:50:40] <cradek> ok I'll leave it at 2
[02:50:57] <cradek> there's a few other things in there too (some ddt, pid)
[02:53:53] <cradek> yuck, I sure think it's a bug that homing moves honor FO
[02:54:18] <cradek> if I have FO set at 200% the axis bumps the stop
[02:54:36] <cradek> that just isn't good
[02:55:19] <jepler> yuck indeed
[02:55:26] <jepler> it just can't decelerate in time?
[02:55:35] <cradek> no the switch travel is pretty short
[02:55:44] <cradek> that's why there are homing velocities
[02:56:00] <cradek> someone always says "it's always been that way" when I bring this up (which is true)
[02:56:11] <jepler> so fix it and then it will never be that way again
[02:56:21] <skunkworks> 'its always been that way.'
[02:56:24] <cradek> that's a decent idea
[02:56:29] <cradek> dammit skunkworks
[02:56:33] <cradek> haha
[02:56:33] <jepler> you can say 'yeah, it used to be that way, but I fixed it'
[02:56:50] <jepler> skunkworks: I imagine you've been watching this conversation with interest
[02:56:57] <skunkworks> Of cource
[02:56:59] <skunkworks> :)
[02:58:09] <skunkworks> I need atleast 10 more hours each day :)
[03:01:05] <jepler> skunkworks: me too
[03:11:55] <cradek> well I wrote "honor FO only when homing" - is that close enough?
[03:13:03] <jepler> that's probably not going to meet with wide approval
[03:14:28] <jepler> backport that to 2.1?
[03:17:43] <jepler> yay
[03:17:52] <jmkasunich> you are gonna get grief for that one
[03:18:01] <cradek> I know
[03:18:10] <jmkasunich> nobody will argue that 200% FO is good while homing
[03:18:28] <jmkasunich> but some will argue that 10% has value
[03:18:37] <jepler> surely you don't get the same home position at 10% FO
[03:18:47] <jmkasunich> you better
[03:18:59] <jmkasunich> if not, your 100% value is too fast
[03:19:51] <jepler> on average the switch actually closed 50% of the way into the servo cycle. That's a different distance at 100% than at 10%. It may not be a big difference, but it's a difference.
[03:20:15] <jmkasunich> you mean into the 1mS cycle?
[03:20:22] <jepler> yes
[03:20:35] <jepler> * jepler does the math
[03:20:42] <jmkasunich> the variability from 0.001mS to 0.999mS is always going to be a random error
[03:20:48] <cradek> jepler: thanks for arguing about this so I don't have to
[03:21:00] <jmkasunich> if that error is greater than one count at 100%, then 100% is too fast
[03:21:06] <jmkasunich> cradek: ;-)
[03:21:09] <jepler> hm
[03:21:19] <cradek> if someone wants to change it to <= 100%, I won't argue
[03:21:34] <jmkasunich> btw, if you have a fanch hardware encoder reader, the servo cycle doesn't matter
[03:21:34] <jepler> OK, maybe you're right -- the truly interested party should complicate the whole planner by adding support for "obey FO but cap at 100%" and use it in the homing code
[03:21:53] <jepler> fanuc?
[03:22:03] <jmkasunich> tancy
[03:22:06] <jmkasunich> fancy
[03:22:07] <jepler> * jepler laughs
[03:22:15] <jmkasunich> :-P
[03:22:32] <cradek> jepler: you mean cap the product of all the feed override override overrides at 100%
[03:22:40] <jmkasunich> the hardware should latch/reset the counter at the instant of the index pulse
[03:24:21] <cradek> "the argument from sematics" says e.g. HOME_SEARCH_VEL should be HOME_SEARCH_MAXVEL if that's what we mean
[03:24:38] <jmkasunich> lol
[03:24:55] <jmkasunich> I didn't say _I_ was gonna argue with you
[03:25:04] <jmkasunich> you know darn well you can't please everybody
[03:25:16] <cradek> yep
[03:25:28] <jmkasunich> * jmkasunich looks for a ballscrew source
[03:25:39] <cradek> skunkworks's mill
[03:26:26] <jmkasunich> I need 18" of ballscrew, 3/4 or smaller (not much smaller) in diameter
[03:26:32] <jmkasunich> with a preloaded nut
[03:26:44] <jmkasunich> and preferrable _finer_ than the usuall 0.200 pitch
[03:27:23] <jmkasunich> 5 tpi * 2:1 belts * 200 full steps/rev = 2000 full steps/inch
[03:27:43] <jmkasunich> I will be doing 10x microstepping, but dunno how fine a step you can actually get
[03:27:57] <jmkasunich> this is the lathe cross-slide, so I want it as good as I can get
[03:28:13] <jmkasunich> for precision bores, etc
[03:28:37] <cradek> you could definitely get 1/4000 then
[03:28:44] <jmkasunich> how?
[03:28:49] <jmkasunich> 10 tpi screws?
[03:28:56] <cradek> I mean half steps are pretty much real
[03:29:02] <jmkasunich> oh, right
[03:29:20] <jmkasunich> the existing acme screws are 10 TPI
[03:29:26] <jmkasunich> but I haven
[03:29:32] <cradek> on my motors they don't seem to really be halfway, but they are certainly 'between' the full steps
[03:29:33] <jmkasunich> haven't seen ballscrews that fine
[03:30:34] <cradek> can you even measure 1/4000 inch?
[03:30:54] <cradek> even with a micrometer that's really pushing it
[03:30:57] <jmkasunich> 1/4000 on the radius is a half-thou on the diameter
[03:30:58] <jmkasunich> I can measure that
[03:31:04] <cradek> oh right
[03:31:23] <cradek> that's easy to forget
[03:31:30] <jmkasunich> heh - etch-cnc got mentioned here:
http://hackaday.com/2006/05/01/team-hack-a-day-cnc/
[03:31:34] <cradek> seems like you want more than .0005 dia resolution
[03:32:37] <jepler> jmkasunich: I think they've linked to me twice now
[03:33:01] <jmkasunich> this one is old, maybe the same?
[03:34:02] <jepler> I bet so -- look at the spike in the #hits on axis.unpy.net back in may:
http://unpy.net/usage_axis/
[03:35:15] <jmkasunich> are you serving unpy from home?
[03:35:26] <jepler> yep
[03:35:28] <jepler> it's just on my dsl
[03:35:31] <jmkasunich> what are you using?
[03:35:31] <jepler> like cvs.linuxcnc
[03:35:44] <jmkasunich> apache? other?
[03:36:01] <jepler> the dsl is 384kbps up; the server is apache/fedora core
[03:36:20] <jepler> the blog software is called "aether" and it's really not high performance -- but that was by no means a "slashdotting"
[03:40:43] <jmkasunich> wow - I won't be getting ballscrews from mcmaster
[03:40:56] <jepler> not cheap?
[03:40:59] <jmkasunich> 20mm dia 5mm pitch, 149 for the screw and 200 for the nut
[03:41:27] <jepler> for 18" of screw?
[03:41:36] <skunkworks> ground screw? with preloaded nut?
[03:42:19] <jmkasunich> ground yes, preloaded no (I don't think)
[03:43:10] <jmkasunich> 1000mm long
[03:43:34] <jmkasunich> all the inch ones have too long of a lead
[03:44:04] <jmkasunich> oh, I read that wrong (damn fractions)
[03:44:12] <jmkasunich> 13/64 is 0.203, so that is OK
[03:44:34] <jmkasunich> 5/8 dia x 13/64 lead, $1.27 per inch
[03:44:47] <cradek> much ebtter
[03:44:53] <cradek> and better
[03:44:57] <jmkasunich> nuts only 23.85 in!
[03:45:08] <jmkasunich> s/in!/in that size!/
[03:45:40] <jmkasunich> 3/4 x same lead $2.00 per inch, and $36.20 nut
[03:45:56] <jmkasunich> all the other sizes are from twice to 10 times the price
[03:55:18] <jmkasunich> looks like theres enough room under the table to mount 2 nuts
[04:00:00] <jmkasunich> I wonder how much preload is appropriate
[04:00:18] <jmkasunich> looks like I can get 50 to 100 lbs pretty easily
[04:04:14] <jmkasunich> 19692.3 steps/inch with 10x microstepping.....
[04:13:37] <jmkasunich> build times: BDI-4.51 - 23 minutes, Breezy RT 16 min, nonRT 8 min (non-rt doesn't build everything)
[04:14:08] <jmkasunich> dapper, running on a non-virtual machine: 3-4 minutes
[13:37:05] <jepler> jmkasunich: that's quite a wide range of build times
[17:15:37] <cradek> I've started thinking about rigid tapping again
[17:15:56] <cradek> (without a servo spindle)
[17:16:26] <cradek> there has to be allowance for the tap to go further than you specify, since the spindle has to stop
[17:16:48] <cradek> so I wonder how you should specify a tap cycle in gcode
[17:20:18] <SWPadnos> aren't some of the G8x or G7x rigid tapping cycles?
[17:20:42] <cradek> you mean currently?
[17:20:51] <cradek> hmmmm
[17:20:55] <SWPadnos> yeah, at least in the spec, if not in the code
[17:21:08] <cradek> not in the code :-)
[17:21:17] <cradek> thanks for the duh, I'll look in the spec
[17:22:11] <SWPadnos> no problem - I'm good with duhs :)
[17:23:59] <SWPadnos> it looks like G84 is the one
[17:24:12] <SWPadnos> interesting that there isn't a left-hand version
[17:25:54] <cradek> I don't like how they use S/F, I prefer a pitch (P word) in the gcode like I did for threading
[17:27:01] <SWPadnos> it seems that would be easier
[17:27:17] <SWPadnos> is there any G84 support in the code?
[17:27:44] <SWPadnos> if not, then there can't be any programs that will break if the spec is changed ...
[17:28:10] <cradek> it currently does nothing except give an error if the spindle isn't turning
[17:28:22] <SWPadnos> oh, well that's helpful
[17:29:12] <cradek> it tries to support multiple planes I think (not mentioned in the spec)
[17:29:44] <jepler> I think all the G8x canned cycles support the planes
[17:29:51] <cradek> what are R- L-?
[17:29:59] <cradek> is that the repeat stuff?
[17:30:01] <jepler> if I remember correctly, there's some generic text to that effect at the top of the G8x
[17:30:05] <cradek> (I have never used that)
[17:30:18] <cradek> aha
[17:30:41] <jepler> "All canned cycles are performed with respect to the currently selected plane. Any of the three planes (XY, YZ, ZX) may be selected. Throughout this section, most of the descriptions assume the XY-plane has been selected. The behavior is always analogous if the YZ or XZ-plane is selected. "
[17:30:50] <SWPadnos> isn't R the "retract height"?
[17:31:09] <SWPadnos> err - retract position, for generic planes
[17:31:17] <cradek> ok
[17:34:21] <cradek> if I have a motor on my lathe's tailstock, what axis would that typically be?
[17:34:35] <cradek> (I doubt it's any of X,Y,Z)
[17:34:57] <SWPadnos> is Z along the axis? (X=radius or diameter)
[17:35:03] <cradek> yes
[17:35:10] <SWPadnos> then tailstock would be W
[17:35:22] <SWPadnos> UVW are parallel to XYZ
[17:39:28] <cradek> when I tap by hand I almost always "peck" - is that not normal when tapping on a mill?
[17:40:00] <skunkworks> cradek: not usually
[17:40:36] <skunkworks> (I do the same thing unless I want the tap to break off in the part ;))
[17:40:38] <cradek> do people not generally tap blind holes on a mill?
[17:41:05] <skunkworks> they use spiral taps that the shavings come out the top
[17:41:06] <cradek> or do they generally use much bigger taps than I do
[17:41:12] <cradek> ahh ok
[17:42:04] <cradek> why are all taps not spiral? harder to start by hand?
[17:42:14] <cradek> I don't think I've ever used a spiral tap
[17:42:33] <skunkworks> I think it is mostly cost
[17:42:56] <skunkworks> I we have some spiral taps that I use by hand with no isse
[17:42:58] <skunkworks> issue
[17:57:55] <alex_joni> where's the password?
[17:59:46] <SWPadnos> isn't that more of an alex question? :)
[18:00:14] <alex_joni> SWPadnos: mail is coming through now
[18:00:35] <SWPadnos> I saw the Gomez mail ...
[18:00:53] <alex_joni> yeah, that one ;)
[18:01:05] <alex_joni> it was trapped by beeing sent when not subscribed
[18:08:51] <SWPadnos> so - this is kind of cool:
http://www.trolltech.com/products/qtopia/greenphone
[18:12:42] <alex_joni> not quite cheap
[18:13:36] <SWPadnos> no, not quite ;)
[18:14:34] <SWPadnos> but actually not all that expensive, compared to other non-plan-provided GSM phones (though I'm not sure that one works in the US, since our system is so backward)
[18:19:15] <alex_joni> a non-plan-provided GSM phone is 100-600 over here
[18:19:21] <alex_joni> one comparable is 200 maybe
[18:19:25] <alex_joni> without the SDK though
[18:19:48] <SWPadnos> I was looking at GSM and CDMA/TDMA, and those are generally more expensive
[18:21:06] <SWPadnos> I may finally buy a UK SIM card and I'll have to rent a phone while I'm there, so I figured I'd look at the price of buying one
[18:22:10] <SWPadnos> phones that don't work in the US are cheap, phones that work in the US aren't as cheap, and phones that can have reasonable rates and work in the US and elsewhere are very not cheap ;)
[18:22:23] <alex_joni> heh
[19:49:07] <cradek> what do people think about stepgen aborting (failing to load) if its maxvel can't be reached according to the period and hold times etc? It already does the math, but it lowers its maxvel silently and then you are guaranteed to get following errors, which I think is a crappy way to report a misconfiguration
[19:50:10] <cradek> I'm looking at Ed's hal file - he has a high scale (16000) and very long hold times set (5-7? periods per step)
[19:50:31] <jepler> I think it's crappy, but I don't think that can be done
[19:50:52] <cradek> what am I missing?
[19:51:05] <jepler> that "does maxvel exceed what is possible" check is done in the slow thread, well after the setps, and even longer after the loadrt
[19:51:27] <cradek> oh, right
[19:51:38] <cradek> it could still log an error I guess
[19:51:46] <cradek> but I'd rather it would not run if misconfigured
[20:45:02] <SWPadnos> another option is to remove the limits from stepgen
[20:45:25] <SWPadnos> though that turns it into freqgen, for the most part
[20:46:21] <cradek> I'm not talking about the limiting, I'm talking more about the max step rate allowed by the period
[20:46:37] <SWPadnos> true - I noticed that after my remarks ;)
[20:46:52] <cradek> the limiting *setting* does give you the number the user hopes he can get
[20:47:31] <SWPadnos> well, one sneaky thing to do is add an output bit that tells whether the requested settings are valid
[20:47:50] <SWPadnos> but there isn't a good way of reporting that to the user
[20:49:36] <cradek> yes I agree that is the problem
[20:49:52] <cradek> stepgen knows when you're out of luck, we should figure out something smarter to do
[20:50:13] <SWPadnos> it only knows after it's been loaded, and all signals/parameters have been set ...
[20:50:35] <cradek> sure, jepler said that too
[20:50:47] <SWPadnos> and since the parameters can change after load, it gets even more fun
[20:51:46] <cradek> maybe we can't check it inside stepgen itself then
[20:52:49] <SWPadnos> well, one generic way of doing it would be to add maxaccel and maxvel inputs to the motion controller, that the lower level drivers can output
[20:52:50] <cradek> I hate to put stepgen-specific validation into emc proper though
[20:53:17] <SWPadnos> the motion controller can then decide that the capabilities aren't good enough to do what's in the ini, and either tell the user or lower the limits
[20:53:20] <jepler> can %f formats be used in rtapi_print_msg?
[20:53:24] <SWPadnos> well, the same is true for other systems
[20:53:26] <cradek> jepler: no
[20:54:03] <cradek> SWPadnos: that sounds like a good possible approach
[20:54:10] <SWPadnos> or a possibly good approach ;)
[20:54:37] <cradek> right
[20:54:49] <SWPadnos> actually, making maxaccel and maxvel into inputs could have other uses (though I can't think of any right now)
[20:55:26] <SWPadnos> does the TP do any precalculation of time constants or the like at startup, or is all that just data-dependent?
[20:56:05] <cradek> I'm pretty sure motion can set maxvel/accel anytime and TP will honor it
[20:56:25] <cradek> I think that's what you're asking?
[20:56:38] <alex_joni> 93868
[20:56:47] <jepler> ??
[20:56:51] <alex_joni> that must be the password
[20:56:53] <cradek> the problem is there are lot of maxvels/accels
[20:56:57] <SWPadnos> zip code
[20:57:03] <alex_joni> SWPadnos: spam again
[20:57:11] <SWPadnos> inded
[20:57:14] <SWPadnos> +d
[20:57:17] <SWPadnos> -d
[20:57:23] <SWPadnos> +e
[20:58:55] <SWPadnos> cradek, yes - that was what I was asking
[21:00:22] <cradek> seems like the base problem is that we need an error reporting mechanism from hal into emc other than dmesg
[21:00:40] <SWPadnos> that could be a separate problem
[21:00:55] <jepler> STEPGEN: Channel 0: The requested maximum velocity of 559999 steps per second is not attainable.
[21:00:58] <jepler> STEPGEN: The maximum number of steps possible is 800 per second
[21:01:02] <jepler> getting this into dmesg is not hard: ^^^
[21:01:06] <cradek> I hate all these problems where the user has to get a calculator (or ask us) to figure out what his misconfiguration is
[21:01:18] <SWPadnos> if the low level driver can tell motion what the underlying hardware can do, then motion can limit itself to that
[21:01:22] <cradek> jepler: that's a great start
[21:01:53] <cradek> SWPadnos: but if the user asked for more in his ini, it's arguably a misconfiguration/error
[21:02:03] <cradek> I'd rather report the error than silently change the numbers
[21:02:04] <SWPadnos> that's true
[21:02:37] <jepler> hm that 800 per second must be wrong
[21:02:45] <SWPadnos> though having those pins would allow us to do a lot of tuning without restarting emc
[21:04:41] <jepler> two observations: this calculation doesn't happen until you turn the machine on, and after that it happens every cycle
[21:04:54] <jepler> but instead, it reports that the requested maximum velocity of 800 steps per second is not attainable
[21:05:02] <jepler> the maximum number of steps possible is 800 per second
[21:05:59] <jepler> maybe what HAL or RTAPI needs is a way to register a function to send the formatted result of rtapi_print_msg to -- by default it would go to dmesg, but emc could patch it so that RTAPI_MSG_ERR are shown to the user via the GUI
[21:06:17] <jepler> I guess it would be in RTAPI
[21:07:15] <SWPadnos> or add RTAPI_MSG_USER
[21:07:47] <SWPadnos> not that it's an RT function, but that's a needed library
[21:08:13] <alex_joni> there is report_error
[21:08:23] <jepler> alex_joni: but that's not rtapi, that's emc
[21:08:28] <alex_joni> right
[21:11:33] <jepler> oh wait -- that 800 is probably right. this is the config where I set weird setup and hold times
[21:11:54] <SWPadnos> use your web config checker and fine out ;)
[21:11:56] <SWPadnos> find
[22:32:58] <alex_joni> * alex_joni has trouble understanding what's going on in Device_EncoderRead(void *arg, long period)
[22:38:27] <alex_joni> it seems somehow unfinished
[22:41:28] <SWPadnos> there isn't aq lot of info about how the hardware works
[22:41:32] <SWPadnos> -q
[22:41:56] <alex_joni> no, just some comments at the begining of the file
[22:41:57] <alex_joni> but..
[22:42:13] <alex_joni> *(pEncoder->pIndex) = (status >> (MOTENC_STATUS_INDEX_SHFT + j)) & 1;
[22:42:13] <alex_joni> *(pEncoder->pIndexLatch) = (status >> (MOTENC_STATUS_INDEX_LATCH_SHFT + j)) & 1;
[22:42:27] <alex_joni> those two do the same thing.. I don't see any difference anywhere
[22:42:38] <SWPadnos> INDEX_SHIFT vs. INDEX_LATCH_SHIFT
[22:42:46] <alex_joni> ahh
[22:42:51] <alex_joni> it's getting late :(
[22:42:53] <SWPadnos> heh
[22:43:04] <alex_joni> pCard->fpga[i].encoderCount[j] = *(pEncoder->pLatchIndex);
[22:43:07] <alex_joni> that also seems odd
[22:43:30] <alex_joni> encoderCount[j] holds the counts presumably
[22:43:40] <alex_joni> setting it with a bit seems odd
[22:43:41] <SWPadnos> one ould think
[22:43:53] <alex_joni> * alex_joni would think
[22:43:58] <alex_joni> but who knows :)
[22:44:47] <jepler> I know how indexing works on my own FPGA :-P
[22:45:11] <alex_joni> jepler: hmm.. then you could change the FPGA on the motenc
[22:45:11] <alex_joni> :))
[22:45:21] <SWPadnos> oh sure - take the easy way out and make your own
[22:45:50] <jepler> I don't know about the motenc but I've sure been thinking about the m5i20
[22:46:13] <SWPadnos> yeah - that's an interesting card
[22:46:18] <SWPadnos> 300k gates and all
[22:46:24] <SWPadnos> or is it 200k?
[22:46:28] <jepler> I don't recall
[22:46:35] <jepler> bigger than the acex1k that's for sure
[22:46:42] <jepler> but a bit more expensive too
[22:46:54] <SWPadnos> 200k
[22:47:14] <SWPadnos> they're not too bad if you can get a few friends to buy at the same time
[22:47:41] <SWPadnos> $159 in qty. 5
[22:47:51] <SWPadnos> which is an excellent discount, if ou ask me
[22:49:12] <jepler> actually I didn't know the qty 1 price was so low
[22:49:22] <jepler> I thought it was at least $100 more than that
[22:49:23] <SWPadnos> eyah - $199 isn't bad either
[22:50:04] <SWPadnos> that's why I was saying that the pluto and/or PCI-8255 may not be the best deal around (especially if you need both)
[22:50:14] <jepler> yeah
[22:52:05] <jepler> they'd have to be local friends -- if you have to split up the 5 and re-ship 4 of them yourself it's barely a savings
[22:52:44] <jepler> but if you want 4 I'll sure buy the 5th from you :-P
[22:52:55] <SWPadnos> heh
[22:53:08] <SWPadnos> well, fest is coming ...
[23:16:52] <alex_joni> good night all
[23:16:59] <cradek> bye alex