It took me the longest time on the sample ini files to figure out that half of the bloat was not really needed but only there to attempt to put all variables into one place. This make for an overly complicated ini file and difficult to explain. One glaring example is EMCMOT = motmod which seems to be the only one so why complicate the ini file with it? loadrt [EMCMOT]EMCMOT should be just loadrt motmod in the hal file in the example configurations imho.
I also was wondering what was the bare bones ini that would run but have not had time to experiment. John On 8/25/2012 1:11 PM, Michael Haberler wrote: > The forum has several cases of folks trying HAL+GladeVCP configurations (and > nothing else) and they are clearly having issues with startup and shutdown. > > The problem is: linuxcnc.in is overly clever about what it is actually > supposed to start up, and about defaults. By making it 'easy' to start a > standard configuration it assumes it needs to start some default components > because it thinks NML is always in place and used, and fails to support > configurations where such components arent needed or desired. > > In particular, it tries to start TASK, EMCIO plus linuxcncserver even if > there is no ini section telling it to do so. For extra confusion, even if you > dont have an EMCIO section, iocontrol gets started but fails miserably > because it wont find a tool table. > > My suggestions longer term are: > > 1. a component not specified in the ini does not get started. Only arguable > exceptions I could think of: RTAPI. > 2. as for linuxcncserver: that could be started if NML is clearly used, e.g. > if TASK and EMCIO are specified. > 3. ALL guis, not just Axis, need to eventually learn how to start a > POSTGUI_HALFILE if there is any chance itself or a subprocess creates > additional HAL objects. To do so, they need to understand that they are the > primary UI component. This suggests a per-ui command line flag like > '--primary-ui'. > 4. The documentation of (at least) the INI variables gives examples, but is > silent on required versus optional parameters, and whether the example is > just that, or a default. We should make it a habit to specify required vs > optional, and any default value for ALL configurable values. The current > approach makes for uselessly bloated and overspecified ini configs - 'I'm not > sure if there's a reasonable default so just let me add this incantation'. > > For now I will do 1) and 2) for linuxcnc.in, 3) for gladevcp, and 4) for > gladevcp and will give a complete ini config for a Gladevcp+HAL application, > plus a cursory check of all the configs such that TASK and EMCIO sections are > completely specified. > > I'll merge that into master and when the dust settles it could be backpatched > into v2.5ff . > > - Michael > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
