Thoughts on improving hardware awareness in PNC

So I just fixed up the G540 firmware to work with PNCconf.
It is a classic case of user really needing to know more then he should to use it.

The G540 requires a charge pump - and a step gen can preform that function.
But by specifying a generic step gen in the firmware there is no way that PNCconf can know which step gen should be configured as a charge pump.

Now what I can do is add 'charge pump' as a signal name, then pncconf knows what to do.
This though requires the user to know which one it should be! room for error

The other thing I can do is hard code PNCconf to recognise the G540 firmware and set it up properly. (I do this for some other firmware)
This really is undesirable as I have to do this every time there is another firmware with a charge pump.

Ideally for PNCconf we would create a new component (in hm2) called charge pump that's just an overridden step gen.

Other ideas:
If the firmware PIN/XML file said charge pump even if the component was a step gen, that could work.
A 'hint' in the PIN/XML line that could describe the usual function of a particular component.

I'll point out that this would still be a problem even having PNCconf interrogate a live config, unless the charge pump name is passed to hm2

I personally still prefer the XML file, but we need the linuxcnc repo updated on a fairly regular bases.
By allowing PNCconf to interrogate a live config means I have a thousand firmwares that have to work with it. Not gonna happen with the info PNCconf can get from hm2.
But if we limit it to 50 from the repo that we know work, and the user can try unofficial XML file on there own - I think that is all we can do.

PNCconf is actually pretty flexible it's testing the XML files that's a pain.

I'm kinda stuck - we (linuxcnc) chose a route to go (repo with official firmware and XML) then never kept it updated.

I'm trying to figure out a different way for linuxccnc3

Chris M

Probably what is missing here is a per connector daughtercard hint.

That is, the information that pin 16 of the g540 config is actually a chargepump signal is specific to the G540 "daughtercard" Similarly the directions of several signals is fixed by the daughtercard characteristics.

I dont think the hint belongs in the HM2 info but the daughtercard name hint (better key) probably does. The number of possible daughtercards is not huge, so making some XML descriptors for each daughtercard type would be one way to address this isssue

Currently the XML file contains just a subset of the information that the HM2 IDROM contains
so anything thats done with the current XML files can be done by querying the IDROM. If this is done, supporting 1000s of configs is no harder than supporting 10 as long as the info is read from the card itself (as the driver does)

Hi Gents,

From the standpoint of a new 5i25 owner.

Instead of allowing the user an option to choose any step gen they want to go to the G540 Charge pump, simply assign one. Most users won't care which one is used. The same could be said for the rest of the pins.

If you know the configuration is a standalone 5i25 going to a G540 then the choices are pretty cut and dried.

I have no experience with the other daughtercards but I wonder if the same logic would apply.

I can see how PnCConf then gets locked to the 5i25 firmware which you have no control over.

If the firmware changes, now everyone is back into a pickle trying to make the changes manually to account for the firmware change.

I think that is the function of the xml file. Is that correct?

Firmware changes drive a change in the xml file to allow PnCConf to compensate.

Could there be a standalone xml file generator that a user could load with information generated by the halrun sequence below?

My main issue was a lack of documentation telling me how everything relates.

For instance, I finally found a reference to the following in another place:

From the terminal:

halrun
loadrt hostmot2
loadrt hm2_pci
show pin
show param

This gave me some information. I could see that the 5i25 read back all of it's assigned pins according to it's firmware. However, I couldn't find any information as to how those pin functions related to a hardware output pin.

I'm not sure what the "show param" command did.

I also finally figured out that "loadrt hm2_pci" will not work if the 5i25 is not installed.

I did see that some of the names from the "show pin" command were the same as some of the names in the hal file. That helped me to locate a typo that was showing up as a error when I tried to start LinuxCNC.

In other words, I get the information from the "halrun" as above then enter that into the XML file generator to get a new xml file.

From the 5i25 documentation standpoint I couldn't find anything that told me how the names of the pins or parameters related to physical hardware pins.

Something along the lines of the following might have helped.

"Here is an example of code in the Hal file that sets pin X on P3 of the 5i25 as a step gen for pin C, the X-step input on the G540."

"The following code sets pin Y as a dir signal for the X-Dir input on pin Z of the G540."

From the G540 documentation I know what each pin needs to see from the 5i25. What I couldn't figure out nor find documentation on was how do I configure the hal to setup the pin on the chip which is in turn connected to the output port on the 5i25 for a certain signal.

I'm probably too new at this to really give you any concrete answers but I can tell you where the process got beyond my limited knowledge as a new 5i25 owner.

Thank you both for working on this. I know it can be a thankless job.

So, thanks!

If I can help somehow let me know.

Regards,

Matt

From the G540 documentation I know what each pin needs to see from the 5i25. What I couldn't figure out nor find documentation on was how do I configure the hal to setup the pin on the chip which is in turn connected to the output port on the 5i25 for a certain signal.

This information is in the .pin (a human readable text file) file that accompanies each bit file
you can also get this information by looking at the driver log (run dmesg > logfile after a linuxCNC run)

And of course 'man hostmot2'

Yes a daughter board hint (actually it's a list in some cases isn't it?) would be very helpful.
I could pre-set /sanity check some things that at the moment I must ask the user to select.


Would that hint be added to the IDROM ? and at the moment I can't get access to that other then parsing the dmesg log right? (uggg)

Supporting 1000s of configs is no problem as long as they don't do anything new!
For instance the G540 XML I just rewrote will let you configure all the pins. It will not set up a chargepump without using a custom HAL file.
A chargepump is new. I have to add that info to PNCconf., so it knows what to do with it.

That's what my one argument is about interrogating live configs as a replacement to XML files.
That would lead users to think it could configure anything you hook up to it. - which I don't think can ever be true.
It can give some hints to PNCconf but I will always need to patch PNCconf to add new features and deal with pin name changes.
But interrogating live configs would be a very good verification / debugging tool.

The hints would really help.

Chris M

blacksmith99 wrote:

Hi Gents,

From the standpoint of a new 5i25 owner.

Instead of allowing the user an option to choose any step gen they want to go to the G540 Charge pump, simply assign one. Most users won't care which one is used. The same could be said for the rest of the pins.

Yes this is what I'm talking of and Peters suggestion of hints would help

If you know the configuration is a standalone 5i25 going to a G540 then the choices are pretty cut and dried.

Close but not quite. eg the g540x2 is for two G540s the user can deselect the second one and use the pins for GPIO. But this is kinda splitting hairs - it is easy to work around this.

I have no experience with the other daughtercards but I wonder if the same logic would apply.

I can see how PnCConf then gets locked to the 5i25 firmware which you have no control over.

If the firmware changes, now everyone is back into a pickle trying to make the changes manually to account for the firmware change.

I think that is the function of the xml file. Is that correct?

The XML file is an easily machine-readable version of the PIN file that describes the firmware. The 5i25 is unique as it linuxcnc does not need this firmware as the 5i25 keeps it on power down. All the other Mesa boards need the firmware loaded each time. Changing firmwares on the 5I25 is not normal (but possible)

Firmware changes drive a change in the xml file to allow PnCConf to compensate.

Could there be a standalone xml file generator that a user could load with information generated by the halrun sequence below?

Hal knows less about the firmware. It knows only what is currently configured to load. ( you can deselt some things inn the firmware then they wo't show in HAL

My main issue was a lack of documentation telling me how everything relates.

For instance, I finally found a reference to the following in another place:

From the terminal:

halrun
loadrt hostmot2
loadrt hm2_pci
show pin
show param

This gave me some information. I could see that the 5i25 read back all of it's assigned pins according to it's firmware. However, I couldn't find any information as to how those pin functions related to a hardware output pin.

I'm not sure what the "show param" command did.

I also finally figured out that "loadrt hm2_pci" will not work if the 5i25 is not installed.

I did see that some of the names from the "show pin" command were the same as some of the names in the hal file. That helped me to locate a typo that was showing up as a error when I tried to start LinuxCNC.

In other words, I get the information from the "halrun" as above then enter that into the XML file generator to get a new xml file.

From the 5i25 documentation standpoint I couldn't find anything that told me how the names of the pins or parameters related to physical hardware pins.

Yes even PNCconf is not great at this, it still requires you to look up in the documentations the component name/number vrs actual pin location. This get muddied up further because the firmware doesn't know about the daughter boards and some of the 5I25's components are actually wired to the daughter board. eg the encoders are decoded on the 5I25 not the daughter board but you connect them to the daughter boards connector. There is no way to know this unless the firmware daughter board hint had this information or it's hard coded into PNCconf.

Something along the lines of the following might have helped.

"Here is an example of code in the Hal file that sets pin X on P3 of the 5i25 as a step gen for pin C, the X-step input on the G540."

"The following code sets pin Y as a dir signal for the X-Dir input on pin Z of the G540."

From the G540 documentation I know what each pin needs to see from the 5i25. What I couldn't figure out nor find documentation on was how do I configure the hal to setup the pin on the chip which is in turn connected to the output port on the 5i25 for a certain signal.

I'm probably too new at this to really give you any concrete answers but I can tell you where the process got beyond my limited knowledge as a new 5i25 owner.

Thank you both for working on this. I know it can be a thankless job.

So, thanks!

If I can help somehow let me know.

Regards,

Matt

It's good to get feedback - If we can improve it then linuxcnc, it's users and Mesa wins

Chris M

cmorley wrote:

Yes a daughter board hint (actually it's a list in some cases isn't it?) would be very helpful.
I could pre-set /sanity check some things that at the moment I must ask the user to select.

Chris M

In the chargepump case a chargepump hint for the step gen would be more useful.
In this way if I modify PNCconf to know about chargepumps then any config with a charge pump anywhere will work.

By just using a daughter board hint, Then only chargepumps in the fimware with G540 hint will work.

If we had both then PNCconf would know a charge pump is needed, where it's needed and what settings it needs

This is the same way that PNCconf knows what to do with a mux encoder vrs a regular encoder and I don't have to patch PNCconf
for each new firmware that uses each - I just new to write a correct XML file.

Chris M

Yes, a daughterboard hint is like the hm2 pin list with every pin described

I think all the information needed is there if the daughterboard hint is complete

(if HM2 ID ROM contains a hint it will only be a daughtecard compatibility hint = a name)

That is the daughterboard hint states that a chargpump is needed on a given pin with a given waveform/frequency

The (live or hand created) XML HM2 pin list has a stepgen output (or just GPIO) on this same pin

pncconf sees whats available and installs the proper HAL boilerplate for the I/O available

Then this is universal and most can be done without any HM2 changes (the user can set the daughtercard manually)

So you mean the daughter board hints would be separate file that pncconf could read?
this would describe all the pins details for a particular daughter board.

Then the firmware file would have a one word reference to that hint page?
Would the reference hint be per connector?
Is there any firmware where more then one daughter board will work?

This is sounding quiet doable.

Chris M

Yes, they would just be xml files with some global and then per pin descriptions
per pin descriptions would include function, direction and any other info that the configuration
utility needs about that pin

There are some sets of daughtercards with common pinouts so for example
a 7I30 name hint in the IDROM will work with 7I30, 7I29, 7I40, etc. so some kind of
aliasing is needed pncconf or the daughtercard hint file