On Wednesday 06 November 2013 08:20:21 Michael Haberler did opine:
> Am 06.11.2013 um 10:59 schrieb andy pugh <[email protected]>:
> > On 6 November 2013 06:27, Michael Haberler <[email protected]> wrote:
> >> - on startup, rather than using the hal Python comp to connect
> >> directly to HAL, collect all pin names, types and direction, and
> >> pass this list to an HALrcomp API class instance; this would be the
> >> basis for the initial bind operation
> >
> > Rather than explicitly add new pins, would it be practical to change
> > the function of the "net" command to provisionally create/register any
> > pins that don't exist when it is called?
>
> hm, interesting idea; I need to think this through
>
> what once could do is say state in halcmd
>
> autocreate gladevcp.*
>
> which would cause net's to gladevcp.* not fail but rather put them in a
> dormant state, and have halserver gooble those up and create the
> unbound component around them
>
> the key problem I see with this idea is: one cannot determine the pin
> direction just because the pin is named in a net statement; there might
> be several net commands to link more pins to the same signal and one
> would have to look at the complete set
>
> even if you have the complete net - pins and the signal, it isnt a valid
> conclusion to draw that if all other pins except the gladevcp.* pin are
> input, then the gladevcp.* pin must be output - it might have been
> intended as input, but the whole signal/pin net left unconnected to a
> writer for now
>
> both pro-forma declaration by 'newpin foo in float' and remote creation
> by the bind message handle this case unambiguously
>
> > The obvious problem with this is that simple typos in pin names will
> > not be picked up on the first pass, but then I suppose there is a
> > similar problem with the newpin command.
>
> yes, if the remote component is created by the UI through the bind
> commmand, typos would surface once the component is bound (after the
> 'waitbound gladevcp' completes and halcmd continues)
>
> if you go the extra mile and declare the component pro-forma and
> immediately start halserver and wait for bound, then the mismatch would
> appear as soon as the UI binds and the requested pinlist is validated
> against the existing pins
>
> > I don't know how you would test for whether a pin was "real" or
> > "typo". It is perfectly reasonable to create pins and not connect to
> > them, most of the HAL components do that all the time. Nor is it
> > unusual to create a net and signal and not have any "writer" in the
> > net. (Many of the sample configs do this)
>
> this is still possible in the current scenario, both with pro-forma or
> remote creation. Actually this would be information a UI could make use
> of; for instance, to grey out unconnected input pins.
>
>
> -m
>
I like where this is going. That is one of the places where rockhopper
fails as it only draws a logic line if it has both a source and a load.
I'd like a line stubbed out if I forget to hook it up.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Hey, waiter! I want a NEW SHIRT and a PONY TAIL with lemon sauce!
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
law-abiding citizens.
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
