PnCConf rework

I didn't mean to hijack BigJohnT's thread here , and I guess the appropriate thing is to start a new thread here in the GUI's section anyway, so here it is!

So, to continue the discussion from the above thread:

cmorley wrote:

The particular line you quoted is part of an initializing sequence of data. (and it's a class of data as well)
Here is a very shortened version:

class Data:
def __init__(self):

for temp in("x","y","z","a","s"):

self[temp+"drivertype"]= "custom"
self[temp+"steprev"]= 200
self[temp+"microstep"]= 5

def __getitem__(self, item):
return getattr(self, item)
def __setitem__(self, item, value):
return setattr(self, item, value)

The two special methods allow self[ ] to work.
In this case I am using them to allow me to use a for loop to initialize common data to all the axes.

I see. Some googling gives that it is a form of operator overloading, which explains it to me.

cmorley wrote:

If you would like to hack on PNCconf - that would be great.

I would like to break it up a bit into a couple of files.
There is dead code to remove ( the never-could-get-it-to-work-happily test panel)
The HAL file printing should be broken out of the data class I think.
I need to figure out what I am going to do about the glade problem (The druid widget is broken in newer versions then dropped in the newest version)
and the assistant widget that replaces it has problems too - or at least it did the last time I looked.
And I really need a different data model for Mesa pins....

I am preoccupied at the moment with Gscreen....

Chris M

Well, I'll see what I can do! I think that what I have in mind is more of a major rework to get it properly object oriented. That would make both maintenance and extension (more Mesa cards etc) a lot easier. I don't know what to do about the glade situation... I guess I'll start looking at it and then we'll see if you like the results and if we can take it all the way.

I spent yesterday evening coding, mostly to figure out how Python works. I like it a lot, except that it is so loosely typed (I miss the static analysing done by a compiler!). I came up with this which could act as an example of what I mean by object oriented approach. It doesn't really do anything useful; it prints out a list of connectors and (probably not entirely correct) HAL pin names for 7i77 and/or 7i76 cards attached to one or more 5i25 boards. It should run on any computer with Python-2.7:

I think it should be relatively straight forward to support arbitrary "chains" of cards (i.e. 5i25->7i77->some SSerial card...) -- that's what I had in mind, actually. Also, think about the problems people have with missing Field power on the 7i77/7i76. It seems many (including me) like to set up the machine while waiting for the cards, or before having everything connected.

Of course that doesn't exclude an "auto detect" feature.

It is possible to issue hal commands from python, that's what pncconf does today to e.g. run the open loop test. (I think it starts a shell and runs halcmd in it.)


Question: are there nets with special meaning to LinuxCNC? Or are all nets used only by explicitly connected components?

Question: the motmod module (which supplies the axis and motion components) seems to be automatically loaded? Is that correct? Are there more such modules?

Question: is there any reason not to use two-pass loading of HAL files? It would make it somewhat easier to automatically generate a HAL file, I think.

andypugh wrote:

Bear in mind that new sserial cards keep appearing. And new operating modes appear whenever Mesa get bored.
The 7i73 is a tiny, cheap card. It has 24 possible pinouts depending on the jumper and software settings.

Even if you auto-detect the HAL pin names, how would you know what the user could do with them? Of course, one could recognise, say, "encoder" and guess that this is a quadrature encoder input... but that seems prone to error?

Thanks for answering my other questions!

This is the other side of live config interrogation. You get the pinnames and location and that's about it. Without context it's insufficient.

Peter has talked of adding daughter board hints and that would help.
But there is no way currently (or with live interrogation) to plug a new daughterboard in and expect PNCconf to know much about it.
But making it easier to add new board info would be very helpful.
Interrogation could be very helpful as an aid to configuration for the user. eg (won't show boards options that are not connected)
We would need away to 'fake' interrogation so we can do testing without having the boards.

I'm not a fan of twopass simply cause it's programmed in TCL
And I think TCL will be phased out in linuxcnc3 (I sure hope so)

The concept of two pass seems fine, though unless it become more main stream I'd prefer PNCconf to build HAL files as close to 'normal' as practical.

Chris M