These are chat archives for machinekit/machinekit

19th
Jun 2016
zhivko
@zhivko
Jun 19 2016 08:30
Question: while mapping remote component why mapping cannot only be done via component.name ?
Michael Haberler
@mhaberler
Jun 19 2016 08:32
I do not understand the question
zhivko
@zhivko
Jun 19 2016 08:32
I mean - why direction and pin type is mandatory - that would mean that having 2 pins with same name and different type could be mapped as well
Michael Haberler
@mhaberler
Jun 19 2016 08:32
and that buys you what except namespace confusion?
zhivko
@zhivko
Jun 19 2016 08:33
SO question is - does hal allows to have 2 pins - component pin name are same - but type are different - is this possible?
Michael Haberler
@mhaberler
Jun 19 2016 08:33
no, HAL names must be unique
zhivko
@zhivko
Jun 19 2016 08:34
so this means that for binding: component name and pin name should be enough to do binding
why I need to specify pin dir and type...
Michael Haberler
@mhaberler
Jun 19 2016 08:35
because strong typing is a good thing?
note rcomps can re-bind
zhivko
@zhivko
Jun 19 2016 08:35
It is not that I am being lazy: but just thinking - if UI has comp name and pin name - and hal has unique comp name /pin name
this can than be easily matched
but still this rebinding would need to have hal pin counterpart created in front
Michael Haberler
@mhaberler
Jun 19 2016 08:36
and what happens if their type differs? you write a float to a bit pin. great!
zhivko
@zhivko
Jun 19 2016 08:37
no you could get pin type and pin direction from binding process
Michael Haberler
@mhaberler
Jun 19 2016 08:37
what is the problem, describe gives you the exact layout anyway?
that is separated into different steps
explore layout - describe
bind - attach to part of it
what sense does this 'optimization' make?
except duplication?
zhivko
@zhivko
Jun 19 2016 08:38
there is no problem I was just thinking - if comp/pin combination is unique why on earth should UI specify type and dir... in any way if you miss dir or type you would get bind rejected
this is not a problem
Michael Haberler
@mhaberler
Jun 19 2016 08:39
repeat: describe gives you the exact layout anyway
zhivko
@zhivko
Jun 19 2016 08:39
it could be an improvement
Michael Haberler
@mhaberler
Jun 19 2016 08:39
please argue the use case, as I do not see it
you save a describe or what?
zhivko
@zhivko
Jun 19 2016 08:40
yes - OK I could read a describe and than bind PIN. but having what I propose - you could do binding without first describe
Michael Haberler
@mhaberler
Jun 19 2016 08:40
there is a very strong reason for describe and it has nothing to do with your use case - it is the base on which to build introspection and an explorer
zhivko
@zhivko
Jun 19 2016 08:40
yes - you can skip describe
Michael Haberler
@mhaberler
Jun 19 2016 08:41
sorry
if you know what the layout is - no need to describe; if you dont - you better learn it through describe
zhivko
@zhivko
Jun 19 2016 08:43
UI should know compname/pinname combination and the one that is programming UI need to know this....
You could argue if it knows compname/pinname - he should also know type and dir
Michael Haberler
@mhaberler
Jun 19 2016 08:43
"UI should know" .. yes, it can do a describe to learn it
zhivko
@zhivko
Jun 19 2016 08:44
But since compname/pinname is unique - having bind process to require type and dir is by my opinion too much... it is simply not necessary
Michael Haberler
@mhaberler
Jun 19 2016 08:44
that is the idea behing introspection
zhivko
@zhivko
Jun 19 2016 08:44
but... this is just my opinion
Michael Haberler
@mhaberler
Jun 19 2016 08:44
ok, so let us agree to disagree
zhivko
@zhivko
Jun 19 2016 08:45
hehe ok... I could introspect and now find what is dir what is type to be able to bind - another step that needs to be made.
just take it as a comment from novice user of haltalk
Michael Haberler
@mhaberler
Jun 19 2016 08:46
I do not believe in super-smart-do-it-all functions. I believe in single-purpose functions which do not overlap.
zhivko
@zhivko
Jun 19 2016 08:47
but this is just pragmatic aproach - I f we know compname/pinname uniquly define pin - there is no need for additional data to make BIND - that is all
Michael Haberler
@mhaberler
Jun 19 2016 08:48
I think you are missing a point
bind can do two things
it can bind to an existing rcomp
it can create a new rcomp
zhivko
@zhivko
Jun 19 2016 08:48
yes I know that - you have wait in hal... I read example
Michael Haberler
@mhaberler
Jun 19 2016 08:48
so in your optimization scheme, which types will the new comp's pin have
great - another special case to be dealt with
zhivko
@zhivko
Jun 19 2016 08:50
but probably there is place in hal - where you see that comp is already defined so if this is case no type and dir should be necessary to make binding
if hal bind sees there is no component and pin define in hal than this is case for type and dir should be mandatory...
Michael Haberler
@mhaberler
Jun 19 2016 08:50
aha
here is your special case which you would not have needed in the first place
zhivko
@zhivko
Jun 19 2016 08:52
but generally how many implementations of machinekit will use 'lets wait for UI to define component and pins' in percentages?
I think most of the cases wil have remote components define in front in -hal file
Michael Haberler
@mhaberler
Jun 19 2016 08:53
what is the problem with wait now? I am getting confused - this discussion is a bit of a moving target
zhivko
@zhivko
Jun 19 2016 08:54
no problem... just thinking when "wait" aproach is usefull
Michael Haberler
@mhaberler
Jun 19 2016 08:55
simple: you wait for a UI to come up
and you do not want to predefine the rcomp
because the UI might choose otherwise
zhivko
@zhivko
Jun 19 2016 08:55
and then whole component and pin creation is made from ui
Michael Haberler
@mhaberler
Jun 19 2016 08:55
yes
zhivko
@zhivko
Jun 19 2016 08:55
also net binding...
Michael Haberler
@mhaberler
Jun 19 2016 08:56
predefining only works if the layout is fixed
zhivko
@zhivko
Jun 19 2016 08:56
hmm .. thinking about non fixed layout - are this really needed and how much machinekit implementations will use this...
but lack experience in linuxcnc to be able to judge that
ok never mind... My comment was pointed toward more "user friendlines" but I see it could complicate things
Michael Haberler
@mhaberler
Jun 19 2016 08:58
predefining gets rid of the wait but has the disadvantage of forcing a fixed layout, and it is defined in two places thereafter, one of which the UI cannot change - that isnt particularly flexible
yeah, user friendly
like you save a parameter
then have to figure out the case where you need it afterall
zhivko
@zhivko
Jun 19 2016 08:59
but to do whole binding (non fixed layout) you need to remotely start/stop machinekit yes?
Michael Haberler
@mhaberler
Jun 19 2016 08:59
why
how hal is started has no angle on that
that is a session concept
zhivko
@zhivko
Jun 19 2016 09:00
I mean - if you restart UI - hal will still run - yes ?
Michael Haberler
@mhaberler
Jun 19 2016 09:00
yes
zhivko
@zhivko
Jun 19 2016 09:00
and than you miss this point "wait for UI to connect"
Michael Haberler
@mhaberler
Jun 19 2016 09:00
that is the whole point of re-binding
no you dont because HAL can introspect if a rcomp is bound or not
in case that is important
think through the scenario in classic linuxcnc and then you see why it is useless for remote uis
plus, there are two kinds of UI - observational (r/o) and these which actually r/w pins
no reason to get all excited about a r/o UI disconnecting, no impact whatsoever
zhivko
@zhivko
Jun 19 2016 09:03

I meant to say:

# wait the halcmd script until the UI has created the remote component 'motorctrl':
# waitexists motorctrl

I am wondering how this will work when UI resets

Michael Haberler
@mhaberler
Jun 19 2016 09:03
classic case DRO with a HAL group
the comp becomes unbound
in case the UI exits
and if the UI reconnects it becomes bound again
zhivko
@zhivko
Jun 19 2016 09:04
hmm... i dont fully understand "wait the halcmd script"
*.hal is a script that will wait ?
Michael Haberler
@mhaberler
Jun 19 2016 09:05
yes, just like loadusr -W
that waits too - man halcmd
zhivko
@zhivko
Jun 19 2016 09:07

hmm.. I need to get experience

# waitexists motorctrl

I need to make a test case here.

probably lack of linuxcnc knowledge on my side - need to build on that.
first I will try fixed layout with:
newcomp mymotion timer=100
newpin mymotion  mymotion.program-line    int in
ready  mymotion
net mymotion.program-line  <= motion.program-line
zhivko
@zhivko
Jun 19 2016 09:52
And MT_HALRCOMP_BIND_CONFIRM is here :)
Michael Haberler
@mhaberler
Jun 19 2016 09:55
very good