On 10/31/2016 7:47 AM, andy pugh wrote: > On 30 October 2016 at 14:47, Jim Craig <[email protected]> wrote: >> Since the current functionality reads a running configuration, I would >> like to be able to read the .ini file that is currently loaded to get >> access to the .hal files that make up the current running configuration. > I would actually suggest that the tool should start by asking for a > single HAL file, or the INI file for the config to be examined. I plan on adding separate methods to load from an ini or a HAL file directly without a running configuration. However I also plan on working from a running configuration.
The reason I keep coming back to working from a running configuration is that it provides a better way to access pins of some components. For instance a postgui.hal file may have many pins that cannot be determined unless the linuxcnc GUI is running. The same issues have been raised about the Pico Systems configurations and the Mesa configurations. While it may be possible to access the components and pins by loading and unloading each component the postgui.hal file pins are not possible to access without a running configuration and the GUI being operational. Does this seem reasonable or is there another way around this? Is there any way to determine what the current .ini file is for the running configuration? > > In the case of an INI file being the top-level, each HAL file from the > INI could be represented by a meta-block, joined by the shared HAL > signals. What I was envisioning here is to have each .hal file on a separate layout page. Signals that go between pages will have "connectors" that can be double clicked on to jump to the other layout page showing the continued signal path. These would be similar to cross page connectors on P&IDs or reference connectors on a schematic. > > Double-clicking the block would take you into that specific HAL file. > > I have done a fair bit of graphical programming in LabView, and my > current job working on engine control software requires me to pore > over a total of 28,000 PDF pages of block diagrams that describe the > software function (much of the software is defined in Simulink then > auto-coded) so I have a pretty good handle on how this is normally > done. > I do find myself wondering if Xcos would be a good basis for a HAL editor. I will look at Xcos to see how it works and the availability for this type of project. Thanks for the feedback Andy. Jim ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
