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 > > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
