help understanding the difference ...

Cool

well, I'm learning

I see that 'Encoder Scale' isn't listed in the manuals for the .ini files ... (input scale is however)

... as long as the UI has all the stuff it needs from the .ini file you can also use the .ini file to hold user named variables that the .hal file can call ?

It appears that way at least ...

BigJohnT wrote:

Scroll down to the bottom of this page and you can see all the HAL components.

www.linuxcnc.org/docview/html/

John

At first look that site seems more comprehensive in its scope than the manual(s) I have offline - or have I either missed or misread (?) a .pdf version ...

but for instance searching for the string "ilowpass" in any of the manuals gives no hits ...

Question I really want answered: is that info available in a downloadable document ?

Many sources of info to go through

BigJohnT wrote:

That is the man pages actually and are installed on your computer when you install EMC. I find the HTML man pages easier to find HAL components on. There is a list or was in the Integrator Manual... so when setting up a machine it will be more difficult to find things as you have to reference two manuals in the next version...

John

Yup, HTML can be easier - except when you're stuck with no internet for the weekend (me, recently)

ahhh, ok - wasn't aware of the EMC2 manual manual manual - will have a look later on my linux machine - might try to make the website into a 'one link deep' archive also

by the way, thanks for your help guys... chipping away at it.

PNCconf does lots of things differently for sure.
Most are for a purpose some are just cause i have not audited the code in a while.
one of the ideas in mind when Pncconf was built was that It should be to accommodate customization
using custom HAL files that doesn't require editing of the INI or regular HAl file.
User requested instances of components used by PNCconf will always start at zero and work up in sequence - PNCconf will add the ones it needs after.
So for instance if one requires a PID instance for some customization If i just used the regular numbering system the customization HAL code would need to be changed If one added say an A axis afterwards . (for XYZ machine , custom PID instance number would be 3, for a XYZA number would be 4)
The way PNCconf does it is XYZ or A instance is always referenced by letter, users requested instances will always use a number starting at zero.
Many components in EMC where built using 'comp' framework and allow PNCconf to directly name the instances so they don't require alias - but PNCconf still uses the same procedure, users requested components start at zero.

You noted the PNCconf file uses encoder 1 for the X axis and the other uses encoder 0. This is because you chose encoder 1 !
The numbering order of components is designated by the Mesa firmware but you could choose any encoder for any axis.

You noted PNCconf uses 'ENCODER_SCALE' and nothing else does. This is because PNCconf allows configs using stepper with encoders.
It needs a stepper scale and an encoder scale. So I had to add encoder scale. My opinion the rest of EMC should adopt it
ENCODER scale
STEPPER scale and
OUTPUT or PWM scale
would be self explanatory
PNCconf only adds ENCODER so it more closely follows other configs.
PNCconf also creates some signal names and doesn't always use them.
Most of the spindle signals are a good example. - again this is so custom HAL files can have consistent signal names to connect to .
If one builds a custom HAL file with some thought you should be able to add it to any PNCconf config and it work - or this is the theory anyways.
Of course PNCconf is still evolving so things could change a bit in the future.

PNCconf also does some things differently just cause it's easier for me to program it that way.
gladevcp,pyvcp are a prime example there are many different ways to load them depending on what GUI you are using - its just too confusing.
I programmed it to always use a special glade HAL file for the glade panel rather then adding the commands to custom_postgui.hal file (cause TOUCHY does not have that option).

What really needs to be done I guess is I should audit the HAL code it creates and I should write ups some docs for the manual.

cmorley wrote:

PNCconf also creates some signal names and doesn't always use them.

Thanks for the info - lots to digest ...

I think I'm in a sandwich here

To learn how to write a hal file its suggested I reverse engineer a pncconf file - but as you mention it has these redundancies which to a beginner aren't clear, we (or at least I) stare at them wondering what bit of info I'm missing "is this important or not ?!" - it is then suggested I try by trial and experiment to figure out what I can and cant live without - the problem here is that the effects of taking stuff away may not manifest itself in a way a beginner would be aware of...

I have no testing paradigm that I can nail down anything with certainty.

Alternatively I am steered towards the demo configs... but as it turns out they are out of date ...

So here I am -

I know pncconf files would likely just work in my simple case and some of you might be wondering at my pedantry - its just that I plan on extending this case more and more as time goes on - custom kinematics, comp, classic ladder, a new GUI and so on - I need to get to know this stuff well

That's the problem, with any sufficiently rich language, there are many ways to say the same thing, basically just issues of style.

If you really want to understand HAL then you should probably start from the HAL manual (and driver/hardware manuals) and write it all from scratch. That way you will likely understand every line and it will be written in your own style.