Mesa 7i96 and LinuxCNC 2.8 PnCConf

09 Jul 2018 22:16 - 09 Jul 2018 22:17 #113902 by PCW
Yes, just outputs

card = card name
c = card number
ii = ssr instance (only 00 on a 7I96)
nn = output (00..05 on a 7I96)
Last edit: 09 Jul 2018 22:17 by PCW.
09 Jul 2018 23:24 #113907 by cmorley
Based on the print out and a bit of studying - I don't think pnccof's discovery option will ever be able to configure this card. The information from the readhmid just doesn't give enough required information.

eg p3's inputs components are called None, which up to this point meant they are configurable for input or output, but by the manual it seems only input is available (hardware limitation I imagine)
T2 and T3 are combined in the readhmid but broken out and mixed on the card and the pin numbers don't coincide with the physical pins so I can't sort it that way.

I'm not sure how to fix this problem besides hard-coding all that into pncconf which is a lot of work and a maintenance nightmare.

Chris M
09 Jul 2018 23:58 - 10 Jul 2018 00:01 #113908 by PCW
I think readhmid is really not what you want
Probably it would be more useful to list the available pins and parameters

halcmd load hostmot2
halcmd load hm2_%interface
halcmd show all hm2 > allpinsandparams

The GPIO stuff is less necessary with 2.8 (and when supported the 7I96 inputs will become InM's which are no longer GPIO )

2.8 also supports the GPIO aliases so things like stepgen pin polarity
are referenced to the stepgen number, not GPIO pins, so are portable between config files.
Last edit: 10 Jul 2018 00:01 by PCW.
10 Jul 2018 00:23 - 10 Jul 2018 00:24 #113911 by cmorley
One problem with reading the runtime pins is that only tells you about _what is_ rather then _what can be_.
Pncconf is for configuration so it needs to know _what can be_
Also the user really needs to know what the components physical pin number is.

In the beginning the XML file (which are converted readhmid files) told you what it could be and where it was at. - not so true now.

It seems I need info from the hardware about what it can do (based on the components) and a masking template to filter what the physical card limits are.
This mask could possibly map components to physical pins too - I think.
But the mask would have to be made for every card.
more thought needed...
Chris M
Last edit: 10 Jul 2018 00:24 by cmorley.
10 Jul 2018 00:55 #113915 by PCW
The run time pins/parameter do tell you what can be for a given firmware (if you dont limit the number of module instances in the driver config line)

The metadata about a particular card is constant so at some point should probably go into the IDROM, but could be a separate file per card for now

It would be nice to have the physical pin mapping but its not necessarily a 1-1 mapping with GPIO so as long as the manual for things like the 7I96 state the normal pinout the configuration utility really need only deal with module numbers
(and these are available in the pin/parameter listings)
10 Jul 2018 01:22 #113916 by cmorley
Well for instance if the card uses mux encoders you lose two encoders for each instance you turn off. You can't know that from runtime pins. Also from run time pins
you can't tell what components on the card can be turned off to reveal GPIO or not.
It doesn't tell you if the encoder is slow speed or high speed.
It doesn't tell you about modes...

It tells you 'based on how you just loaded me this is what you can configure'

metadata about the card on the card would be great. readhmid used to be enough for most situations but not so anymore.

Physical mapping of pins is a pretty big deal - fairly constant source of questions and surely user stress.. looking up info and mapping from manual is an error prone pain - not to mention linuxcnc doesn't supply Mesacard manuals so it's something else they must download. In fact I recently added a pic of the 7i76/7i77, in pncconf to help with that.

It's an interesting problem :)
Chris M
10 Jul 2018 03:07 #113919 by PCW
Muxed encoders are enabled 1 by 1 in the driver command line just like regular encoders

Not sure what you mean by low and high speed encoders (there are MPG encoders but those have different pin names)

By modes do you mean sserial modes? these can be probed with mesaflash:

mesaflash --device 7i76e --addr --sserial
SSLBP port 0:
SSLBP Version: 1.43
SSLBP Channels: 3
SSLBP Baud Rate: 2500000
sserial device at channel 0: 7I76 GPIO (unit 0x12345678)
SwRevision = 14
HwRevision = 1
NVBaudRate = 2.5Mb
NVUnitNumber = 0x12345678
NVWatchDogTimeout = 50ms
SOFTWARE MODE IO_Spin [index 00]
SOFTWARE MODE IO_Ana_Spin [index 01]
SOFTWARE MODE IO_Enc_Ana_Spin_FV [index 02]
10 Jul 2018 04:58 #113924 by cmorley
I didn't know that about mux encoders.
Yes thats what I meant by encoders. are all MPG encoder named similarly on sserial cards?

Maybe I should knock together a proof of concept of reading runtime pins to see what is possible ... when I get some time :)

Thanks Peter
13 Jul 2018 11:16 #114125 by andypugh

cmorley wrote: One problem with reading the runtime pins is that only tells you about _what is_ rather then _what can be_.

I think that the output lists the software modes available, so it is possible to conceive of the wizard loading and unloading the driver with a different process data mode each time.

This will not capture the hardware data modes, but you could reasonably expect the integrator to have configured that to suit their purposes.
Moderators: cmorley
Time to create page: 0.096 seconds
Powered by Kunena Forum