Re:pncconf - feature requests

Pncconf numbering follows the linuxcnc's/mesa component numbering, not the physical card numbering.
The physical card numbering data is not available from the firmware.

It's annoying but not much can be done without a very large effort.

Mesaflash can report the GPIO --> terminal block numbers of
most daughtercards, though this only works well when there is a
1:1 mapping ( or 1:2, 2:1 for differential signals)

it's as simple as renumbering the statement in the GUI, instead of encoder 1, it becomes encoder Zero, and so on and so forth until the physical adress on the card matches the adress in the confiuguration data in PNCconf.

Hardly a " large effort " If I knew where to find it in the source, I'd probably fix it myself and submit a pull request

Feel free to look at the code and make a PR.
github.com/LinuxCNC/linuxcnc/tree/master...emc/usr_intf/pncconf

I hope your apparent arrogance means you will actually look at the code.
pncconf.py is probably the first file to look at, then private_data.py
If t was as easy as you said I would have done it long ago.

I'd even talk about why if you were really interested.

I know enough about C/c++ to know that a variable declaration in the gui side is relatively easy to change.

So you didn't look at the code... it's python by the way.

The numbering system is 'calculated' from the firmware declarations.
While sometimes you can easily convert that to actual pins numbers,
as Peter said if the daughter board is 1:1 pin mapping, in some cases you don't have enough information to do so.

i don't think having the pins numbers sometimes be actual physical numbering and sometimes be component numbering is helpful.

If you limit the configurable boards to a subset it becomes easier or if you program every daughterboard firmware available into pncconf you could do this or if the daughterboards pin conversions could be read from mesaflash that would be pretty easy.

I've actually been busy working, and in my spare time learning my way around the code base. GTK and Python are new things for me to learn. There seems to be a lot of abstraction in the code base as well.

Calculating pins, why ?? each card has a fixed hardware design, IE a screen mask which declares the relative position on the hardware of where a IO location is.

A simple text file like a INI for each card would have removed a massive user facing error inducing design choice.

Its not simple and the mesa environment does not work that way. I might have a 7i76e plugged in and then I might plug in two more cards. Lets say 2 x 7i76 so now we have 15 stepgens and a heap more IO pins. So lets now add a Mesa 7i73 smart serial device that will add another 40 odd pins. Somehow poor old pncconf has to manage all of that complexity.. 

Computers count starting from 0 (what is the first index into a C based array?), hardware pin numbers start at 1.  There are very good reasons why computers start counting at 0. Its much more efficient at the hardware level. The whole of linuxcnc starts numbering from 0. Why should Mesa be treated any different?

Life will be much simpler if you just accept the paradigm and get a working machine. It does not matter what system in the universe you use, it has an accepted paradigm and if you try to fight the paradigm, life is very unpleasant. That applies to linuxcnc. Remember, linuxcnc is free software and there are no paid developers on standby. Embrace the paradigm and get on with life!

smc.collins wrote:

Calculating pins, why ?? each card has a fixed hardware design, IE a screen mask which declares the relative position on the hardware of where a IO location is.

A simple text file like a INI for each card would have removed a massive user facing error inducing design choice.
 

If you are talking about cards that are fairly hardware unconfiguarable such as 7i76e or most daughter cards, then a hard coded lookup table or INI style file would work fine.

Pncconf covers cards such as the 5i20 (not so popular now) that are completely hardware configurable with custom firmware or the standard firmware by 'turning off' modules such as step components to reveal GPIO.
and probably more importantly Pncconf was built when these were the only cards so all the data paradigms and basic programming were laid out.
Also this is the program I used to learn python. (so ya the programming code is not very nice)

I want to say that - I am not against changes to make this happen, it's just I don't see how to get all the way there without some help on the hardware side and any way to get there will require significant work.
I am certainly not the best coder and would be happy to either remove pncconf for a better program or let someone else to take it over. I am mostly just doing work to keep it running and incorporating code others have offered (there have been many) and bug fixing.

Thank you for your questions and suggestions

Chris