On Mon, Aug 17, 2015, at 10:59 AM, Kenneth Lerman wrote: > Hi Jeff, > > I agree with you from an information hiding standpoint. > > Here is an example where I found it useful. > > I built a probing program that is tied to my MPG (using xhc-hb04). I > modified the driver so that some of the pins show the direction of the last > motion -- which axis and which direction. > > Then, when I hit the button on the MPG labelled probe-z, the probe will > move in the direction of the last motion and finds the edge. > > This functionality relies on existing code that can cause a gcode > subroutine to be called based on assertion of a hal pin. The called > subroutine is specified in the ini file. > > I could have specified a separate subroutine for each axis and direction > (six in my case), but that would lack elegance. [Actually, I would need six > MDI commands specified in the ini file, but all of them would call the same > subroutine, but with differing arguments. That doesn't seem too bad -- > although it would require additional changes to xhc-hb04.cc.] >
I think we've seen some interesting use cases, and it makes sense to find a way to cover them. I think the part that freaks me out the most is that the signals will be read only when you press RUN. HAL was originally defined as a way to pass data around between REAL-TIME components. Non-real-time components were added later, but the premise was still that components would be reading/writing pins DURING normal operation of the machine. No hard realtime guarantees, but still "pseudo- realtime" in that components see stuff as it happens, or set outputs to make stuff happen. Now we are talking specifically about a use case where the signals will be read only once, when you press run. Can't get any further from realtime. My gut says that this is a case of "HAL can transfer data between processes, we need to transfer data between processes, so lets use HAL". Whether HAL is really the right solution or not.... > I would be happier if the "driver" could just read and set values of > (global) named parameters. [I'd also like MDI commands to have access to > named parameters. -- but that's a different issue.] > > Getting back to your the crux of your argument (I agree) that hal pins are > creatures belonging to developers and integrators, I would suggest that > (named) parameters belong to users. Then using (global) named parameters > for this function would be appropriate. > > Now all we need is a hal component that can convert a pin value into a > named parameter value (and vice versa). That would become a place where the > integrator and user meet. > Hard realtime components have code that runs in a thread at some interval. Non-realtime components have their own processes, and _usually_ run their code in a polling loop of some sort, with a (non-guaranteed) polling interval. This hypothetical component would need to be synchronized to the interpreter somehow, such that it could read its pins at the start of the program. It seems like putting it in a separate process (typical user-space HAL comp) is not the best way to do that. If you start thinking about this from a timing/synchronization perspective, then there is nothing magic about reading the pins when you hit RUN. It could just as easily be "read the pins when you encounter custom M-code Mxxxx", or when you encounter magic comment (halread <halname> <named_param>). Although as Andy has pointed out the actual timing of the read would have to be well documented to avoid confusion. The custom M code or magic comment would want to be a queue breaker and do the read only when all preceding motions are complete. The more I think about it, the more I like the magic comment version. The risk of breaking existing G-code is astronomically small. The fact that things are being read from HAL is clearly documented in the g-code, as well as the names of the HAL and g-code parameters involved. If you want to read 10 things, you write 10 magic comments. If you want to re-read them later in the program you can. If the HAL pin/signal named in the magic comment doesn't exist it is an error. On the flip-side, this adds some serious interp<->HAL coupling, which is bad. I think it is still possible to run the interpreter stand-alone. The existing analog and digital output functions are handled in motion, so the stand-alone interp can simply issue the canonical functions and move on. I'm not sure how the existing analog and digital input functions work. What happens when a stand- alone interpreter encounters those codes? There is no motion component or HAL at all, so where does the data come from? Adding this new functionality would make things worse, I think. Just my $0.02. Of course, I don't have to implement it, so my opinion is worth even less than that. -- John Kasunich [email protected] ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
