#linuxcnc-devel Logs

Aug 22 2018

01:06 AM hazzy-lab1 is now known as hazzy-lab
10:55 AM seb_kuzminsky: jepler: sometimes there's a cron job that runs 'apt-get update', which locks the db
03:36 PM hazzy-lab: # TODO: Change to Enum once we drop support
03:36 PM hazzy-lab: # for the almost dead and agonizing Python 2.7
03:36 PM hazzy-lab: # <pitchforks> Death to Python 2.7! </ pitchforks>
03:36 PM hazzy-lab: ^ proof that some gov employees do have a sense of humor
03:36 PM hazzy-lab: Mostly for jepler :D
04:28 PM seb_kuzminsky is now known as python27
04:28 PM python27: i'm not dead yet!
04:29 PM python27 is now known as seb_kuzminsky
04:29 PM hazzy-lab: LOL
04:36 PM Jin^eLD: hi, I'm writing a hal component and I was hoping to get some hints on a few things; why are all input pins defined as (0+*__comp_inst->pin_name) ? I was about to save pin pointers in some local structs, it worked nicely for output pins as those are defined without "0+"
04:36 PM Jin^eLD: I am hesitant to bypass the defines and access __comp_inst directly, or would it be OK to do so?
04:47 PM seb_kuzminsky: if you feel the need to access comp's internal stuff directly you may be happier writing your component in C directly, then you get full access to everything, without having to 'peek behind the curtain'
04:48 PM Jin^eLD: well, I compared .comp code and the generated .c file, the comp version does really help a lot, speeds up the process significantly
04:49 PM Jin^eLD: but from your answer I understand that peeking would be OK if I'm prepared for unexpected redefines by a later halcompile version?
04:50 PM seb_kuzminsky: peeking is definitely ok with me :-)
04:50 PM Jin^eLD: cool, thanks :)
04:50 PM seb_kuzminsky: my main worry would not be that halcompile changes its mind about how to structure its hidden internals
04:50 PM Jin^eLD: ..but?
04:50 PM seb_kuzminsky: my main worry would be to understand the behavior of those internals well enough that what you do doesn't mess up what halcompile is trying to do
04:51 PM Jin^eLD: good point, although I do not think that I am doing anything "dangerious", just trying to access the pins in a sligtly different manner
04:51 PM Jin^eLD: *dangerous
04:51 PM seb_kuzminsky: go for it :-)
04:52 PM Jin^eLD: I have a gearbox that has 12 pins and a combination of those maps to a certain spindle speed... it kind of felt a lot simplier to create an array of those pin pointers and collect their values into a bitmask while looping over the array :)
04:53 PM seb_kuzminsky: that makes sense
04:53 PM Jin^eLD: worked fine with output pins, but the input pin define prevented me from saving &(pin)
04:54 PM Jin^eLD: I assume the 0+ thing is only for marking it as input somehow, at least as far as I understand it would not change anything technically?
04:57 PM seb_kuzminsky: i don't know what the "0+" is doing there... :-/
04:57 PM seb_kuzminsky: halcompile keeps track internally of what pins are inputs vs outputs
04:58 PM seb_kuzminsky: I would expect that when it writes the C output it doesn't annotate the C with that information in any explicit way (other than by making sure to pass in the correct flags when creating the pins)
04:59 PM Jin^eLD: well, the generated C code has those defines... or what did you mean by not annotating?
05:00 PM Jin^eLD: #define spindle_speed_in_abs (0+*__comp_inst->spindle_speed_in_abs)
05:00 PM Jin^eLD: vs
05:00 PM Jin^eLD: #define spindle_speed_out (*__comp_inst->spindle_speed_out)
05:00 PM Jin^eLD: I saw it as a weird way of marking input vs output, but to what end? if I read that correctly, both are the same to the compiler
05:01 PM Jin^eLD: of course if the reason was to prevent doing what I am doing on the input pins.... would be good to know :)
05:02 PM seb_kuzminsky: i agree with you, i think those are the same to the compiler
05:03 PM seb_kuzminsky: i don't know why halcompile makes the #defines different for input pins vs output pins
05:04 PM Jin^eLD: oh crap, that peekingn isn't that because if I try to use &(*__comp_inst->middle_left) then the pin name is of course a macro..
05:04 PM Jin^eLD: *isnt that easy
05:05 PM Jin^eLD: my notebook keyboard broke, typing on an external rubber thingie which is terrible and needs strong presses, sometimes I miss letters, sometmes whole words dammit
05:05 PM Jin^eLD: :)
05:05 PM seb_kuzminsky: i guess you could bypass the macro entirely and use '
05:05 PM seb_kuzminsky: The book is way longer than 8 minutes, and pretty dense:
05:05 PM seb_kuzminsky: oops, i mean:
05:05 PM seb_kuzminsky: use __comp_inst->middle_left without the macro or &
05:06 PM Jin^eLD: well, the macro is defined by halcompile further up
05:06 PM seb_kuzminsky: yes, but you don't have to use the macro
05:06 PM Jin^eLD: and indeed, now that you say it, why the hell am I stilldoing &(*) :))))
05:06 PM Jin^eLD: the macros name matches the pin name in the struct
05:07 PM Jin^eLD: wherever I use middle_left it gets expanded
05:07 PM Jin^eLD: or is there some way to bypass it "locally" without #undef'ing it?
05:08 PM seb_kuzminsky: you can just type "__comp_inst->spindle_speed_out"
05:08 PM seb_kuzminsky: __comp_inst is defined inside the FOR_ALL_INSTS() loop
05:08 PM seb_kuzminsky: and since you're peeking, you can just use it ;-)
05:08 PM seb_kuzminsky: no need to undef any of the macros, just ignore them
05:10 PM Jin^eLD: well.. that does not work that way.. unless you mean something that I am not aware of
05:10 PM seb_kuzminsky: why doesn't it work?
05:11 PM Jin^eLD: any __comp_inst->spindle_speed_out results in __comp_inst->(*__comp_inst->spindle_speed_out)
05:11 PM Jin^eLD: because of the define
05:11 PM Jin^eLD: ok i picked the wrong example (output), but for input its: #define spindle_speed_in_abs (0+*__comp_inst->spindle_speed_in_abs)
05:12 PM Jin^eLD: so any use of "spindle_speed_in_abs" expands
05:12 PM seb_kuzminsky: oh, right
05:12 PM Jin^eLD: let me google...
05:12 PM seb_kuzminsky: ok, so you *do* have to undef the macro, so it doesn't collide with the struct field
05:13 PM seb_kuzminsky: and then use the __comp_inst->field syntax consistently throughout your program
05:14 PM Jin^eLD: seems so...
05:19 PM Jin^eLD: kind of ugly, but I guess thats the price for peeking :P
05:19 PM Jin^eLD: thank you :)
05:21 PM Jin^eLD: time to hibernate, nite!
05:31 PM Jin^eLD: could not leave it alone and just go to sleep heh, but I found the solution
05:31 PM Jin^eLD: #pragma push_macro("reducer_left")
05:31 PM Jin^eLD: #undef reducer_left
05:31 PM Jin^eLD: use __comp_inst->reducer_left as needed
05:31 PM Jin^eLD: #pragma pop_macro("reducer_left")
05:32 PM Jin^eLD: this way I do not have to know how the macro was defined and can restore it after I got my pointer assignments
05:33 PM Jin^eLD: feels safer than just to undef it forever
05:33 PM Jin^eLD: but now really time to sleep, thanks again for your help :)
08:47 PM hazzy-lab: Is there a way to get the INI file that the currently running LCNC session was started with?
08:47 PM hazzy-lab: The INI_FILE_NAME environment variable will not work since it is only available in the environment LCNC is running in.
08:47 PM hazzy-lab: even a log file would do, I tried using linuxcnc_print.txt, but it is only generated when LCNC fails to load ..
08:50 PM hazzy-lab: I am thinking something like `import linuxcnc; linuxcnc.ini_file`
08:50 PM hazzy-lab: I was successfully able to add a new string constant to emcmodule.cc, but not sure if the INI file is available in that context