Classic Ladder (as we use it) is basically a HAL application. It uses HAL threads to evaluate the ladder rungs and HAL pins to connect to I/O. Then there is a user-space part (the GUI) that builds the ladder itself, in an independent shared memory block.
I guess I see HAL as a set of tools. You start with the core library, the halcmd user interface, and the comp component builder tool. You add the critical testing tools of halscope and halmeter. Then to do anything useful you need a library of both hardware driver components and "internal" components like PID and mux and limit3 and many others. I assume that a standalone HAL would come with a bunch of components and drivers, but a key aspect of the HAL concept is that it is very modular and additional drivers and/or components can be added by anyone. Classicladder is one such special purpose HAL component (or perhaps it makes more sense to call it a HAL application, since it consists of more than just the realtime ladder execution engine). I don't have a strong opinon about whether it should be separately packaged. I guess if we look at standalone HAL as a toolkit for building control systems, the more complete that kit is the better. So having a nice ladder logic PLC as one of the core components seems good, rather than making people seek out and install a separate package. I would also expect that gladevcp and/or pyvcp would be part of the HAL toolkit, as would vismach. I'm having a harder time wrapping my mind around Michael's larger messaging proposal(s). Non-scalar HAL types certainly have benefits for some applications, but they introduce new mental models. How do you troubleshoot such things? Tools like halscope and halmeter don't apply to non-scalars, I think. I haven't given the whole messaging thing much thought. As soon as I got home from Wichita I started preparing for a hiking trip, last weekend I was in the woods far from the internet, and this week I'm trying to catch up at work. On Tue, Jul 2, 2013, at 10:16 AM, EBo wrote: > good point. Where should the classic ladder be grouped? In its own > bin, with HAL, with a generic parser/PLC? > > On Jul 2 2013 7:43 AM, Dave wrote: > > I would also make sure that you can still use it with Classic Ladder > > as > > a standalone also. That could be very useful. > > > > Dave Cole > > > > On 7/2/2013 3:24 AM, Anders Wallin wrote: > >> Some random thoughts/discussion. > >> > >> To be useful a stand-alone HAL package also needs tools for building > >> HAL > >> networks. > >> These include halscope, halmeter, siggen, etc. as well as any future > >> insanely great visual HAL-netlist creation and visualization > >> software. > >> Hardware-drivers should also be included in the HAL-package, or > >> perhaps > >> packaged individually so you only need to install the ones you want. > >> > >> Non-conventional HAL-applications (temperature-controller, > >> datalogger, > >> weather-station, etc) require non-conventional hardware drivers. > >> There's a > >> bunch of work on DAQ cards with linux at http://www.comedi.org/ I > >> wonder > >> how much work is involved in using a comedi driver through HAL? > >> > >> I am interested in developing small embedded > >> controllers/user-interfaces > >> for various lab-applications such as temperature control, > >> datalogging etc. > >> These would also require some sort of user-interface, similar to > >> pyvcp or > >> gladevcp, which would work on a minimal linux-install (some embedded > >> boards > >> do not have gpu/cpu power to run a full X install). > >> > >> Anders > >> > >> > >> > >> On Mon, Jul 1, 2013 at 8:04 AM, Chris > >> Morley<chrisinnana...@hotmail.com>wrote: > >> > >> > >>> This was a tabled item from the last meeting. > >>> The consensus seemed to be the idea had merit but discussion was > >>> needed. > >>> > >>> Micheal's proposal was a 'machiekit' package that included: > >>> > >>> "Machinekit would be HAL+RTAPI+NML replacement (zeromq+protobuf)" > >>> > >>> The idea here is that HAL is a great piece of code that has a > >>> fairly easy > >>> boundary > >>> to break it out of liuxcnc. > >>> > >>> Then other projects could use it and hopefully improve it and maybe > >>> join > >>> our group. > >>> Modularity also makes it easier for people to digest the code so as > >>> to be > >>> able to contribute. > >>> John K's original idea for HAL was similar (as I understand it). > >>> > >>> I'm for all it. > >>> > >>> I'm not sure of the downside other then it's work to do. > >>> I assume others wish to discuss the NML replacement > >>> > >>> Chris M > >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ > >>> This SF.net email is sponsored by Windows: > >>> > >>> Build for Windows Store. > >>> > >>> http://p.sf.net/sfu/windows-dev2dev > >>> _______________________________________________ > >>> Emc-developers mailing list > >>> Emc-developers@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/emc-developers > >>> > >>> > >> > >> ------------------------------------------------------------------------------ > >> This SF.net email is sponsored by Windows: > >> > >> Build for Windows Store. > >> > >> http://p.sf.net/sfu/windows-dev2dev > >> _______________________________________________ > >> Emc-developers mailing list > >> Emc-developers@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/emc-developers > >> > >> > > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
