On 03/07/2013 03:52 AM, Michael Haberler wrote:
> Am 07.03.2013 um 11:31 schrieb andy pugh:
>
>> Are you proposing that output pins of components should propagate a
>> value back in to the component at startup? (viewing a widget as a
>> special case of a HAL component with an output pin)
> Let us stay with requirements for the moment, and do the mechanisms derived
> from that later once we have agreement:
>
> a) is HAL the right place to do persistence as opposed to the current ad-hack
> way
> b) what are new subjects of persistence - pins, signals or both; which
> variety of pins? ('halcmd save' already is a form of persistence)
> c) what is the flow on 'startup', 'intermediate save', and 'shutdown'? Which
> entity triggers this, and how?
> d) how does the halcmd syntax look like to support the above?
Before we talk about requirements, can you describe some use cases
driving this development effort?
I don't understand when you'd want HAL pins (or signals) to be persistent.
Actually, I don't understand what persistence even means for these objects.
I sometimes want hal pins to come up in a known state, and then i just
set them in my hal files, like this chunk starting on line 168:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=configs/hm2-stepper/hm2-stepper.hal;h=433092247750e9fefcc26a65f0e183646c4deb80;hb=36a0f9d8e6c89742c7d14d50ecc5cf59f0065218#l168
--
Sebastian Kuzminsky
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
