On Thu, 28 Jul 2016 14:01:37 -0400 Gene Heskett <[email protected]> wrote:
> On Thursday 28 July 2016 12:12:07 Nicklas Karlsson wrote: > > > > It might be worth reconsidering how unconnected pins are handled. > > > Letting something read or write to dummy can cause nasty bugs. > > > That's particularly true for writing to dummy. > > > > Reading a unconnected pin should result at least in a warning. I guess > > this could be checked beforehand as soon as linuxcnc is started. > > And, since unconnected pins, at least to the external world, read as a > logic 1, how do we discern between the unconnected pin, and the g38.2 > probe that has not yet contacted a grounded object? This is a problem with default value. Some compiler can complain if variable is not initialized which may happen then declared/defined or later. > hal OTOH maintains an internal connection table, and I would think it > would fairly easy to scan the hal files, and detect a "net name source" > statement that was never subjected to adding a target load. I am pretty sure catching used undefined signals are useful although there are seldom a problem so priorty may be low. There may also be cases where set a default value is a good idea. > That still leaves the scenario where one has defined a list of target > loads, intending to feed that list from a previously defined "net name > source", but the names do not match. It can only spot that sort of error > if the list of target loads is known as write only. That is not always > carved in stone when dealing with real hardware. Lets just say that it > has caught ne out a few times, with "interesting results". The hostmot driver send information about available signals/pin then starting and it make complaint if it does not agree with configuration so catching undefined signals before threads are started should be possible. > I have had several occasions where, after an extended uptime, I went to > run a routine to determine the mounted tools tlo, and drove the tool > thru the gauge contact and into the jig or table, crushing the tool. > > The second time it happened I put a meter on the probe line and watched > the contact take place as I jogged it down very slowly. But It was not > being reported on the halmeter. So I shut down and swapped the 5i25 > card, which worked for about a month, then did it again. I verified that > the contact was not visible to the halmeter, and simply rebooted. That > fixed it and it has fixed it 4 or 5 times since. That says its a hal > problem. Yes. Even though periodically sending values use bandwidth all the time it avoid the synchronization problem that happen if only changes are sent. ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
