On Nov 6 2013 6:25 AM, Gene Heskett wrote: > 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.
a dashed line to a "Undefined" pin? ------------------------------------------------------------------------------ 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
