Following example code and LIBS

More
22 Sep 2017 15:58 - 22 Sep 2017 16:32 #99275 by scubawarm
Didn't know where to put this so putting it here.

Is it just me or am I missing something?

When trying to follow the code of examples projects, it is nearly impossible to tell what is part
of LinuxCNC,
what is part of the driver (a little easier as they have card number in them)
what is part of the GUI
and what is end user code...

Given how objects can be created on the fly, seems all I am doing is trying to find where these items are coming from.
Therefore not getting anything done.

Having some type of style for Users variables and such would be most helpful for others to read.
At a minimum comments on top laying them out.

IS there something like that? A GOOD example of that? Or am I just stupid?

EDIT: An example I think I intend to use APP and GUI to know where the root of the data comes from.
Examples: get_app_method, app_variable, AppClass or isAppSwitchOpen
isGuiBoolean gui_variable, gui_percent_change

These are obviously written for the application, and if not shown this way, most likely part of LIBS or standards. Let me know if I am doing something really wrong or breaking some coding rule.
Last edit: 22 Sep 2017 16:32 by scubawarm. Reason: Added how I intend to do it.

Please Log in or Create an account to join the conversation.

More
23 Sep 2017 03:38 #99304 by PCW
Replied by PCW on topic Following example code and LIBS
Are you talking about hal pins and parameters?

Normally these have the component name as the first part of the
complete pin or parameter name.

So for example all Mesa hardware pins and parameters start with hm2_CARDNAME,
and all pins and parameters of the "near" component start with "near"

You can list all these with

halcmd show all

Please Log in or Create an account to join the conversation.

More
03 Oct 2017 13:07 #99812 by andypugh
If you are talking about HAL pins (and it is far from obvious that you are) then the first part of the hal pin name is nearly always the name of the module that creates it.
The exception to this rule is motion. This creates some motion.xxx pins but also a lot of axis.xxx and spindle.xxx pins.
The pins created by each module are listed in the manpages.
linuxcnc.org/docs/2.7/html/man/man9/motion.9.html

(And you can find all the other manpages here: linuxcnc.org/docs/2.7/html/ under "Realtime components and kernel modules" or "Commands and userspace components"

Please Log in or Create an account to join the conversation.

Time to create page: 0.076 seconds
Powered by Kunena Forum