Back
[02:53:23] <NTU> NTU is now known as NTU_brb
[09:55:10] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[10:20:44] <jthornton_> jthornton_ is now known as jthornton
[10:44:43] <jthornton_> jthornton_ is now known as jthornton
[11:00:28] <psha> cpresser: are you here?
[12:40:00] <jthornton_> jthornton_ is now known as jthornton
[13:12:25] <alex_joni> always nice to read really old stuff, and see everything that was imagined has been acomplished:
http://emc.cvs.sourceforge.net/viewvc/emc/emc2/README?hideattic=0&revision=1.1&view=markup
[13:12:29] <alex_joni> yay @ jmkasunich
[13:23:13] <micges> yep that's really old
[14:05:44] <skunkworks> emc2 has come a long way. Unreal.
[14:05:51] <skunkworks> Great work everyone.
[14:56:58] <Al_Smt> it was started by Dewey Garrett in May and not finished?
http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=c58b548d01b25b1423c139f71dec33d05da6b21d
[20:10:41] <psha> i was trying to fix bug in halui with delay between pin processing and now trying to clean whole halui.cc
[20:11:02] <micges> psha: by the way thanks for contribute
[20:12:00] <psha> micges: np, it's my work :)
[20:12:49] <micges> what are you doing if may I ask?
[20:14:31] <psha> i was 'contracted' if this word is suitable here to polish emc to fit customers needs
[20:14:43] <psha> safe homing, home-all button and some python g-code generator
[20:15:28] <psha> since i'm not new in oss projects i know how important contributions/bug fixes are
[20:15:35] <micges> cool
[20:16:38] <psha> i scheduled a week for theese patches but now i'm ill and sitting at home
[20:16:50] <psha> so have a bit of spare time :)
[20:22:45] <psha> and now i have halui that don't loose one shot signals )
[20:23:00] <psha> but horrible changed :)
[20:38:40] <psha> cpresser: may I ask you about your patch for named mdi commands?
[20:39:16] <psha> it seem that you are using many commands at once separated with ';'?
[20:40:07] <psha> micges: cpresser gave me patch very close to my first patch adding many MDI commands to halui :))
[20:40:29] <psha> so maybe this feature is not so useless :)
[20:53:01] <psha> 3 files changed, 568 insertions(+), 766 deletions(-)
[20:53:06] <psha> -200 sloc
[20:53:12] <psha> and ~150 may be deleted too
[20:53:24] <psha> not so bad for ~2k sloc file
[21:11:34] <psha> it would be greate if someone will take a look at new halui.cc
[21:12:00] <psha> i'll try to rewrite ugly std::string manipulations tomorrow
[21:12:12] <psha> and if everything is ok i'll post patches to ml
[21:12:43] <psha> http://psha.org.ru/git?p=psha/emc2.git;a=shortlog;h=refs/heads/halui-map
[21:12:53] <psha> git://psha.org.ru/psha/emc2.git
[21:12:56] <psha> branch halui-map
[21:13:01] <psha> based on master
[21:17:03] <psha> if everything is bad then i'll send this patchset to trash
[21:17:40] <psha> no need to merge bad design descisions :)
[21:21:31] <micges> psha: interesting rewrite
[21:22:17] <micges> what was achieved by rewrite?
[21:36:18] <psha> micges: first, bug with loosing pin signal connected to several halui IN pins is gone
[21:36:23] <psha> it was goal
[21:36:35] <psha> second goal was to remove code duplications
[21:36:59] <psha> there were 4 places were each input pin (3 for out) was described
[21:37:17] <psha> halui_data, local_halui_data, pin initalization and comment on top of file
[21:37:30] <psha> now only place containing all pin description is halui_pins.hh
[21:37:37] <SWPadnos> um
[21:37:43] <psha> but
[21:37:50] <psha> old halui has compile time checks
[21:38:04] <psha> it's thing i'm unable to achieve (
[21:38:47] <psha> honestly speaking bug with loosing signals may be fixed in more simple way
[21:39:06] <SWPadnos> what is the description of the bug?
[21:39:07] <psha> but then there will be fifth place with all pins
[21:39:18] <psha> consider this hal config
[21:39:43] <psha> net all-home pyvcp.all.home
[21:39:43] <psha> net all-home => halui.joint.2.home
[21:39:43] <psha> net all-home => halui.joint.1.home
[21:39:44] <psha> net all-home => halui.joint.0.home
[21:39:54] <psha> we place 'home all' button in pyvcp
[21:39:57] <psha> now we press it
[21:40:05] <psha> and we'll get only first axis homed
[21:40:17] <psha> if we press and hold this button - every axis is homed
[21:41:07] <SWPadnos> ok. I would expect them to all home or none to home (depending on how long the signal stays active)
[21:41:32] <SWPadnos> it is expected that halui will miss short pulses on pins, it's a userspace process
[21:41:34] <psha> while halui is processing commands and wait for reply (emcCommandWaitReceived) pins in shared memory are changed
[21:42:01] <SWPadnos> that sounds like a bug then :)
[21:42:22] <psha> there is simple way to fix it - just copy shmem to local mem and process it there
[21:42:52] <psha> but - structure layout (many pointers) makes this impossible without writing ~100 lines of individual field assignment
[21:44:01] <psha> so i thought that some level of automation won't harm
[21:45:11] <SWPadnos> I've been wanting to make a table-driven HAL object creator for a long time
[21:45:49] <psha> what kind of tables? with actions or not?
[21:45:51] <SWPadnos> the halui_pin_t class is a reasonable approach I think, but I haven't looked at all the implementation details carefully
[21:46:08] <psha> halui_pin_t is mostly for runtime checks for pin types
[21:46:29] <SWPadnos> no, just a mechanism where a single call to some function like "hal_create_pins(&me, hal_pin_list)
[21:46:37] <SWPadnos> would do all the pin/param creation
[21:46:53] <psha> so here it is :)
[21:46:56] <SWPadnos> but it's not that trivial, since there are often non-constant sets of pins to be created
[21:47:05] <SWPadnos> yes, I see that :)
[21:47:16] <SWPadnos> not usable in C, but there it is
[21:47:35] <psha> it's usable in c but with external get methods
[21:47:48] <psha> e.g not pin->u32() but get_u32(pin)
[21:47:56] <SWPadnos> yep
[21:48:41] <SWPadnos> regarding the pin reading bug - did you find the cause of that, or did you basically start with the rewrite? :)
[21:49:16] <psha> i've mentioned problem above
[21:49:36] <psha> when halui found pin change it issues NML command and waits for other end to receive it
[21:50:01] <psha> emcCommandWaitReceived sleeps for EMC_COMMAND_DELAY
[21:50:05] <psha> at least once
[21:50:18] <psha> and during that pin in shared memory changes back
[21:50:23] <psha> to low state
[21:50:53] <SWPadnos> ah, ok. I thought you were saying that something in halui was changing the pins, not that they changed state while halui wasn't looking
[21:51:42] <micges> if I may: halui due to this waiting or something else is unable to process many pins changes, it looses intermediate states
[21:52:13] <micges> like driving feed override by phisical roller
[21:53:03] <psha> micges: it's related to nature of 'read and sleep' code
[21:53:18] <SWPadnos> it's not realtime. there can't be any assumption that pin states will remain constant for any length of time
[21:53:20] <psha> it's loosing all changes when it sleep between iterations
[21:53:56] <psha> but it's not so annoying as some pins processed and some - not :)
[21:54:30] <SWPadnos> even bulk copying of HAL data to a local buffer is not guaranteed to fix the problem, since the pins could be updated from a realtime thread during the copy
[21:54:55] <psha> SWPadnos: of cause, but probability of such change is very-very small
[21:55:00] <micges> SWPadnos: problem is that after many commands by pins to halui it's hangs out for few sec and in mean time keyb doesn't work :P
[21:55:22] <micges> other problems are easly fixable
[21:55:45] <SWPadnos> I'm not saying it isn't a problem, just pointing out that a simple fix may not be enough
[21:56:00] <SWPadnos> I haven't looked at psha's code closely enough to decide if it's simple or complex :)
[21:56:07] <psha> micges: this is fixable too by creating internal queue of commands. but it's overkill :)
[21:56:35] <micges> SWPadnos: it's complex ;)
[21:56:54] <psha> micges: and it's problem :(
[21:57:01] <psha> complex solutions are oftern bad ones
[21:57:51] <psha> with o-call interruption patch is pretty small with difficult bug
[21:58:00] <psha> and here patch is huge with simple bug )
[21:59:08] <SWPadnos> hmmm. a HAL pin is actually a pointer to data, not the data itself. that doesn't seem to be the case for the halui_pin_t class. where is the data actually stored in this code?
[22:00:00] <psha> HAL pin _is_ data. But volatile pins are implemented as pointer in shared memory.
[22:00:21] <SWPadnos> no. hal params and signals are data, pins are pointers.
[22:00:30] <psha> For local copy we don't need that sharedness so data is stored in union like in hal internals
[22:01:19] <psha> maybe, so it's my fault in understanding hal terminology
[22:01:40] <psha> but from program point of view we only need to know that it's data
[22:01:47] <SWPadnos> the simplest approach is to just allocate a local copy of the halui_data (a halui_str struct), and memcpy the data from shared to local memory
[22:02:02] <SWPadnos> just don't worry about the extra memory used for output pins and the like
[22:02:09] <psha> SWPadnos: no way
[22:02:15] <psha> we preserve pointer to shmem
[22:02:42] <psha> and we need local copy of data where pointer is pointing
[22:02:45] <psha> not pointer itself
[22:02:50] <SWPadnos> oh right. need to move what the pins *point to* :) (like I just said - silly me)
[22:03:21] <psha> probable solution was to write copy_halui_data function and drop local_halui_data
[22:03:28] <psha> replace it with another halui_data struct
[22:03:56] <psha> but it mean that also new_halui_data for non-shmem memory is needed too :(
[22:04:09] <SWPadnos> that's why it's a different struct - it's the actual data instead of pointers, and not all data needs a local duplicate
[22:04:13] <psha> i meat function allocating memory for pointers
[22:05:02] <psha> I understand :) So as you may see halui_pin_t in my code contains both pointer (NULL by default) and local data
[22:05:45] <SWPadnos> an ugly but efficient way to do it would be to declare a few arrays of data and pointers, and use constants for array indices: if (halui_bits[MACHINE_ON]) { do stuff }
[22:06:14] <SWPadnos> then the data copies can be done in loops
[22:06:19] <psha> hm, not bad...
[22:06:23] <SWPadnos> but I think that's too ugly to consider :)
[22:06:41] <psha> oh no
[22:07:31] <psha> it has same problem my code have - it looses compile time checks :(
[22:08:03] <SWPadnos> yeah, that was the other thing that prevented me from actually solving the object creation thing
[22:08:04] <psha> btw there is a way to copy halui_data :)
[22:08:09] <psha> it's array of pointers
[22:08:18] <psha> pointers all have equal size
[22:08:30] <SWPadnos> sure, but the target data may not
[22:08:36] <psha> so you may treat this struct as array of pointers
[22:08:52] <psha> target data has equal size :)
[22:08:54] <psha> 8 bytes
[22:09:04] <SWPadnos> sure, in your union/class
[22:09:14] <SWPadnos> it doesn't in normal HAL-land
[22:09:26] <psha> it seem it does
[22:09:30] <psha> look in hal/hal_priv.h
[22:09:40] <psha> typedef union { hal_bit_t b; hal_s32_t s; hal_s32_t u; hal_float_t f;
[22:09:40] <psha> } hal_data_u;
[22:10:59] <SWPadnos> that's used as a placeholder for dummy data, not for the actual data (which is contained in a signal)
[22:11:14] <SWPadnos> though it does reserve/use up 8 bytes in the pin struct as well
[22:11:37] <psha> hm, signal struct is empty... only contains data_ptr and no data
[22:11:48] <psha> have to dig a bit deeper...
[22:12:27] <SWPadnos> hal_signal_new in hal_lib.c
[22:12:41] <SWPadnos> the data is allocated separately
[22:13:09] <psha> hm
[22:13:10] <psha> right
[22:13:28] <psha> was hidden too deep :)
[22:14:30] <psha> so copying of halui_data won't work without risk of SIGSEGV on border of shmem page :(
[22:14:56] <SWPadnos> that's true, if you always try to copy 8 bytes
[22:15:13] <SWPadnos> actually, no, I take that back
[22:15:40] <SWPadnos> I think there's one type of data that grows downward from the top of HAL memory, but pin/sig/param structs are allocated from the bottom up
[22:15:46] <SWPadnos> so you'll get garbage
[22:16:05] <SWPadnos> and if you're that close to running out of HAL memory, it's time to increase that limit
[22:17:06] <psha> problem is it became too dependent on hal internals... if somebody will try to make top-down stack for signals in hal everything will break on some conditions...
[22:17:14] <SWPadnos> yes
[22:17:15] <psha> hm
[22:19:00] <psha> at least array with types may be used alongside with halui_data struct...
[22:19:38] <psha> but that may lead to errors due to "added to struct, forgot to add into list"
[22:20:25] <SWPadnos> if you start letting that worry you, you're likely to go insane
[22:20:58] <SWPadnos> there are many many places where things have to be manually synchronized by the programmer. I think many (or even most) are unavoidable
[22:21:28] <alex_joni> can't you do some compiler check that both things have the same number of items?
[22:21:36] <psha> ~6 years ago I'll already got unmaintainable burden at work :) so i fear to get it again :)
[22:22:18] <psha> alex_joni: yes, it's simple #if ((sizeof(...) \n #error ... #endif statement i think
[22:22:34] <alex_joni> psha: right, that's what I had in mind
[22:22:42] <psha> also this list may be autogenerated with simple sed script
[22:22:54] <SWPadnos> uh
[22:23:10] <SWPadnos> sizeof(thing) != sizeof(*thing)
[22:23:33] <psha> sizeof(*thing) == sizeof(*another)
[22:23:40] <SWPadnos> I don't know if there's a gcc struct element counter or anything like that
[22:23:53] <psha> so allocate void *array[] and fill it with (void*) hal_type_t
[22:24:57] <psha> halui_data contains only pointers and pointer arrays
[22:25:52] <psha> element counter won't help
[22:26:05] <psha> since there are arrays like mdi_command[MDI_MAX]
[22:26:14] <psha> but total sizeof() will help
[22:34:24] <psha> SWPadnos: i'll think about it tomorrow
[22:34:51] <psha> it seem to far more better way :)
[22:35:11] <psha> and now it's ~02:30 here at Moscow...
[22:35:18] <psha> bb