> > > 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. > > Something is being lost in translation here. > > Reading and writing unconnected pins happens ALL THE TIME! > And there is absolutely nothing wrong with it. > > Example: PID tuning parameters are pins. 99.9% of they time > they are NOT connected to anything. A series of "setp" commands > in the HAL file sets the unconnected pins to the proper values.
Then they are connected and I expect setp happens before PID is executed. The *.hal file is a kind of netlist and there is not order execution, in sort of all of it are interpreted and connected at once. > ... Outputs are no problem, no need to read the value so they do not need to be connected. > > I guess this could be checked beforehand as soon as linuxcnc is started. > > What exactly do you mean by "started"? I expect *.hal file is interpreted and everything connected before the threads are started. > One of the strengths of HAL is that it can be interactive. You can > make and break HAL connections while the system is running. > In fact, the two-year-old commit that started this whole discussion > only makes sense in that context. If you make all your connections > before you start the real-time code, that commit would have no > effect. I say ideally there should be at least a warning if an input get unconnected because value is undefined. If get implemented of course depend on available time. > > > Checking for a null pointer is pretty fast with today's machines -- even > > > with the ARM and other little processors. > > Yuck. I have two objections. > ... > But that is only an inconvenience. The second objection is: what > should the macro/function do when it detects that the pin is > disconnected? Yes this what should happen then a null pointer is detected is a major problem because code to handle it need to be added. If it is possible to write program so that pointer never is set to null this could be avoided, in some cases it is but in others not. Problem is the same with communication over network while an ordinary function call always work there must be an action in case a call to remote system fail. > This is real-time code. You can't stop and throw an error message. > Code in real-time threads MUST ALWAYS run to completion quickly > and consistently. Code in real-time threads must ALWAYS produce > results that are sane. Consider a component like "sum". The code > must ALWAYS write a legal floating point number to the output pin, > regardless of whether the input pins are connected or not. Yes it is expected to work all the time but what value should there be in case pin is unconnected, default value may do the trick although warning may be better. > And as mentioned above, the "sum" component must continue to > produce sane and timely results even if you disconnect and reconnect > it on the fly. > > > Yes checking is fast but the best is to allow only valid assignment > > because it make software simpler and avoid the problem did not > > remember to check everywhere. Only a few languages however > > have good type checking. > > HAL does have type checking. You cannot connect a float signal > to an s32 pin. But that checking is done when you issue the "linksp" > command (or "net", which invokes linksp behind the scenes). It > is not a realtime thing, and halcmd can refuse to make the link > and return an error message. This is good. > ... > HAL's linksp command allows only one "writer" pin to be connected > to a signal, along with any number of "reader" pins. This is also good. > There is a time and place for everything, including global storage. Yes there are cases and not the least a few exceptions is usually tolerable then other solutions are hard to find. I did not have time to read every row you wrote. ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
