On 10/28/2016 10:02 AM, John Kasunich wrote:
>
> On Fri, Oct 28, 2016, at 10:29 AM, Jim Craig wrote:
>> I did some more debugging of Crapahalic last night. So some brief
>> overview of how it works so far. It uses halcmd show to generate output
>> that is then parsed through to determine the loaded hal components, the
>> pins for each component and the signals that are all loaded in the
>> current configuration. I like this general methodology as it keeps from
>> having to look up component definitions in the man pages to determine
>> pins. It also solves the issues that have been brought up about
>> components generating pins at run time.
>>
>> The issue that I am having right now is that the parsing logic is
>> barfing on the inconsistency of the "Loaded HAL Components:" section of
>> the halcmd show output. Some lines have a PID value and others don't.
>> Currently it is splitting each line into 5 variables but sometimes there
>> are only 4 items in the split due to the missing PID value. This causes
>> it to barf at the split command.
>>
>> Would it make more sense to modify halcmd show, actually the subfunction
>> print_comp_info to add a placeholder for missing PID values such as a -1
>> or a "-" or some other value? Would modifying this output break other
>> applications? Would it make sense to make additional functions for
>> halcmd that would be specific for the Crapahalic? Or should I just
>> update the parsing code to handle each condition separately?
> Is crapahalic already using halcmd's "script mode"? Refer to the man page
> http://linuxcnc.org/docs/html/man/man1/halcmd.1.html
> If you add -s to the halcmd command line it will produce output that
> is easier to parse. Changing the script-mode output format should be
> done with caution (to avoid breaking existing scripts that use it), but at
> the same time, script-mode output should be designed to be as consistent
> and parser-friendly as possible. If there are inconsistencies in script-mode
> output that could be considered a bug.
No, it is not using the -s option. However it does not appear that it
will fix the issue either. Below is a snippet of the component
information section
27 User halcmd12604 12604 ready
25 User axisui 12542 ready
23 User inihal 12539 ready
22 RT match8 ready
21 RT wcomp ready
20 RT comp ready
19 RT or2 ready
18 User hal_manualtoolchange 12523 ready
16 RT near ready
15 RT lowpass ready
14 RT limit2 ready
13 RT sim_spindle ready
12 RT hypot ready
11 RT ddt ready
10 RT __servo-thread ready
9 RT motmod ready
8 RT trivkins ready
7 User halui 12503 ready
5 User iocontrol 12501 ready
As you can see the PID column does not always have a value. So splitting
the line will result in 4 variable lines and 5 variable lines.
>> eWhat is yor opinion of this general method of working with a running
>> HAL configuration? The only drawback that I see at the moment is that it
>> would make editing a broken configuration with the tool impossible as it
>> would not load properly and therefore you could not view or edit it with
>> the tool.
> I have mixed feelings on the topic. As an electrical engineer who is used to
> both drawing and reading schematics, I am 100% convinced that NO auto-
> generated drawing will ever be as readable as a human-created drawing.
> The layout of components on a good schematic naturally conveys the
> design intent of the human who drew it as far as signal flows and such.
> Autogenerated schematics tend to resemble bowls of meaningless spaghetti.
>
> So my interest in such tools has always been to "compile" a schematic
> drawn by a human (me) into a hal file. Going the other way is less
> interesting.
>
> But as has been pointed out, the challenge of components that change
> their pin-list based on loadrt parameters makes it tough.
I agree completely about auto-generated schematics. That is another
feature that I plan to add to this application. The first time the
application is ran with a new HAL file it will auto-generate the
schematic. Once it is auto-generated the user will have the ability to
lay out the schematic as they like. The locations of components, pins
and signals will all be stored in a separate file, probably a xml file,
that will be kept up to date while using the graphical configurator.
This will allow for neat and tidy schematics of the overall
configuration for any future modifications.
Of course this functionality is all to be completed. I can't even get it
to load a complete auto-generated schematic yet!
Thanks for the feedback.
------------------------------------------------------------------------------
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
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
