Successful stepconf user buys Mesa5i25 wants to use experience in pncconf. How??

This really is "basic configuration". I'm a user who has used stepconf a number of times to create and modify parallel port configurations to run--and very importantly, to test and optimize--3- and 4-axis machines. I will some day want to upgrade to an interface card to provide the signals for me in hardware and reduce my system overhead (and improve my responsiveness).

I'm trying to help a friend who has paid for higher performance than software-stepping on a parallel port can provide by buying a Mesa 5i25 interface card and asked me to help set it up.

I was able, fairly quickly, after glancing at the schematic for the JP-3163B controlller in his machine to get the axes moving using stepconf, and went on to "exercise" those axes in stepconf to get some ideas of max velocity and acceleration, as I have become accustomed.

Armed with that, I fired up pncconf, thinking of it as "stepconf for Mesa boards", but I have been completely bewildered by the interface! It seems that nothing I know about stepconf has any usefulness in pncconf. Instead, I was presented with hints that I needed to know a lot more about the 5i25.

As someone presented with a DB25 terminal (which I realize I should not think of as a parallel port because it is under the control of the Mesa card not the PC) from which I'm going to run a parallel cable to the machine that has been running just fine on the PC's parallel port, I just want to somehow use pncconf to tell the 5i25 what I've learned from stepconf! Like "these are the pins WHICH WORK IN STEPCONF to get the machine to do what I want it to do."

Instead, pncconf presents me with jargon about Mesa's "I/O pins" which are numbered differently from parport pins and new wrinkles like "channels" and "PID" and and.

"I just want to tell the card what I already know. Please."

Having writ that as the general case, here's the specific one.

My friend has seen PathPilot and is very high on the idea that that particular GUI to the CNC machine is near-to-perfect for CNC operators who sometimes get lost in the shuffle. Tormach is copacetic with people using PP for non-TM machines, but have made it absolutely clear that anyone who does so is on his own.

So the idea is this:
* PathPilot should, always, think the downstream machine is a standard one in the Tormach line
* ...and load the 5i25's firmware to correspond
* the wiring between the 5i25 and the non-TM machine should be adjusted to Tormach standards to correspond to what the 5i25 expects of a downstream Tormach machine of the selected type

The two questions in the specific case are:
"What signals are expected to be provided and received by the 5i25, and what are their specific formats?"

In the general case, the question is:
"Step-by-step, how should I converse with pncconf to communicate what I know about how the machine was successfully setup with stepconf?"

I hope this is not as hard as it's been seeming. Thanks.

@tommylight Thank you.

It may be as simple as flashing the card with a BIT file generated from a PIN file edited to match the needs of the CNC controller card, but that presumes an understanding of what the terminology in the PIN file means.

I am a stepconf user, new to MESA terminology. From stepconf, I could recognize things like X-axis, X-lim, Spindle, E-stop, and so on, but the PIN files don't have any of those, but do have things that I've never seen, like Channel, and Quad.

From other reading, I'm guessing that the PIN/BIT files only tell me WHAT TYPE of signal is present on the P3 (DB25) pins, (even P3: why can't it be called DB25 in the PIN file for heaven's sake? and P2/P3? what's P1?) and that HAL file will later identify WHICH THING uses the signal on that pin.

This underscores my original post, which was:
* when I fire up pncconf, I don't see terms familiar to me, but if pncconf is not going to build on what a stepconf user has learned, where can that user learn how to take what he knows about his working parport setup to configure and test the same system with pncconf?

I don't recall having to deep-dive to get stepconf to set up a parallel port to match the needs of my controller in a fairly short time. pncconf is proving to be something else.

"Gee it would be nice if..." a utility could read my parport-based INI/HAL and pump out 5i25 replacements. Failing that, I'm asking how I can do it in a systematic way.

Basically you cannot map stepconf hal configuration easily into a 5i25 (or any Mesa FPGA card) hal configuration because they are too different.

A parallel port configurations pin functions are determined entirely by the hal file
(with only restriction being parallel port pins hard wired directions)

Mesa FPGA card pin functions for high speed I/O (step gens, PWM gens, encoder counters etc) are "baked" into the specific firmware used, so you must first choose firmware that matches the pinout of your breakout/drive etc.

You _can_ use most of a stepconfs ini file constants in a pncconf ini file

Thanks, Peter. I have read many of your prior posts wrt Mesa cards.xxx

Here's an idea about what I'm trying to get at: practical methods a stepconf person can use to home in on what's needed. [Followers, BEWARE throwing the baby out with the bathwater with a careless grep; for example, I did a "grep -v 25" thinking to eliminate lines with that I/O#, and lost everything, because they all had "5i25". Einstein reportedly said, "Simplify as much as possible, but never more than that."]

There are 7, or 5, questions embedded in here,

1. Is the approach following reasonable?
2. If I don't get a perfect match, how to get one?
3. After getting and flashing a perfect match, how to assign signals to pins?
(Stuff that stepconf just seemed to "do" for me.)

I've unzipped the 5i25[support software].zip file from Mesanet.com .

In a terminal, based on tommylight's post, I changed into the top 5i25/ directory and hunted for the PIN files:
% cd 5i25/
% find . -iname \*pin
[many many]
% cd configs/hostmot2/
because that's where all the PIN files live
% ls *pin
[the same many]

[UPDATE: you'll note I changed the grep method below to eliminate search '7iNN' daughter cards. If I'd done that here, none of the
TX/RXData lines would have shown, on the files containing:
15 3 IOPort None
[/UPDATE]
Now, I know from my schematic that my controller card wants pin 15 to be "Emergency stop". From what I see in the candidate files, I conclude that I am not interested in any firmwares that have pin 15 as, say, "Step, Dir, PWM" so I can eliminate those:
% for i in *pin; do grep "^15 " $i | grep -v Step | grep -v Dir | grep -v PWM; done
15 3 IOPort None
15 3 IOPort SSerial 1 RXData4 (In)
15 3 IOPort SSerial 0 RXData4 (In)
15 3 IOPort SSerial 0 TXData2 (Out)
15 3 IOPort SSerial 0 TXData5 (Out)
15 3 IOPort SSerial 0 TXData4 (Out)

[UPDATE: as a result of the search eliminating TX/RXData lines, questions 4, 5, and 6 reduce to:
4a. Why is there no (In) or (Out) associated with:
15 3 IOPort None?
[/UPDATE]
This leaves me with:
4. Do I want a secondary of None, or SSerial?
5. If SSerial, do I want channel 1 or 0, RXData or TXData, Data2, or 4 or 5?

I'll guess that I need an (Out) Pin-dir, reasoning that the machine already has a hardware, manual E-stop switch, and this provides a way for an operator to E-stop from the software GUI.
That reduces me to:
6. TXData2, 4 or 5?

Moving on to something I think I understand better, simple limits, my controller expects pins 11,12,13 to be "X-,Y-,Z-lim", presumably inputs to the Mesa to indicate limits/homes have been hit. I grep again, eliminating "7iNN" cards and IOPorts over 16 as non-P3:
% grep "^11 " *pin | grep -v 7i | grep -v "31 IOPort" [NB not clever but 31 was the only one I saw].

This leaves:
5i25_5ABOBx2.pin:11 14 IOPort QCount 0 Quad-A (In)
5i25_c11gx2.pin:11 14 IOPort QCount 0 Quad-B (In)
5i25_c11x2.pin:11 14 IOPort QCount 0 Quad-B (In)
5i25_dmmbob1x2.pin:11 14 IOPort QCount 0 Quad-A (In)
5i25_g540_enc.pin:11 14 IOPort QCount 0 Quad-B (In)
5i25_g540x2.pin:11 14 IOPort QCount 0 Quad-B (In)
5i25_hdbb2.pin:11 14 IOPort QCount 0 Quad-B (In)
5i25_mx3660x2.pin:11 14 IOPort QCount 0 Quad-B (In)
5i25_prob_rfx2.pin:11 14 IOPort QCount 0 Quad-A (In)
5i25_r990x2.pin:11 14 IOPort QCount 0 Quad-A (In)

A veritable handful, and my 3 "suspect" firmwares are still on the list,
7. But what's QCount? And do I want Quad-A, Quad-B? or is this the wrong track?

My next search would be for a PIN file that has step/dirs on the pin-pairs my controller expects them; e.g, 2/3, 4/5, 6/7:
% grep "^ 2 " 5i25_[a-z]*pin|grep -v "19 IO"|grep " Step "
5i25_c11gx2.pin: 2 2 IOPort StepGen 0 Step (Out)
5i25_c11x2.pin: 2 2 IOPort StepGen 0 Step (Out)
5i25_g540_7i76.pin: 2 2 IOPort StepGen 0 Step (Out)
5i25_g540_enc.pin: 2 2 IOPort StepGen 0 Step (Out)
5i25_g540x2.pin: 2 2 IOPort StepGen 0 Step (Out)
5i25_hdbb2.pin: 2 2 IOPort StepGen 0 Step (Out)
5i25_mx3660x2.pin: 2 2 IOPort StepGen 0 Step (Out)
5i25_prob_rfx2.pin: 2 2 IOPort StepGen 0 Step (Out)

% grep "^ 3 " 5i25_[a-z]*pin|grep -v 21|grep " Dir "
5i25_c11gx2.pin: 3 4 IOPort StepGen 0 Dir (Out)
5i25_c11x2.pin: 3 4 IOPort StepGen 0 Dir (Out)
5i25_g540_7i76.pin: 3 4 IOPort StepGen 0 Dir (Out)
5i25_g540_enc.pin: 3 4 IOPort StepGen 0 Dir (Out)
5i25_g540x2.pin: 3 4 IOPort StepGen 0 Dir (Out)
5i25_hdbb2.pin: 3 4 IOPort StepGen 0 Dir (Out)
5i25_mx3660x2.pin: 3 4 IOPort StepGen 0 Dir (Out)
5i25_prob_rfx2.pin: 3 4 IOPort StepGen 0 Dir (Out)

Similarly for the other step/dir pairs.
% grep "^ 4 " 5i25_[a-z]*pin|grep -v "23 IOP"|grep " Step "
% grep "^ 5 " 5i25_[a-z]*pin|grep -v "25 IOP"|grep " Dir "
% grep "^ 6 " 5i25_[a-z]*pin|grep -v "26 IOP"|grep " Step "
% grep "^ 7 " 5i25_[a-z]*pin|grep -v "27 IOP"|grep " Dir "

and the remaining pins I want.

At the end of all the searches, if I find one or more PIN files at the intersection of the sets of positive results, any of those should work fine to flash the 5i25 with. Except that, I'm reminded that I still don't know (Qcount, Channel, None, SSerial, etc.) WHAT I'm talking about. (I feel like Lou Costello.)

I think I would just look at the pin files and find one that's close to what you need

I would also read the hostmot2 manual page

Note that a PWM, Step/DIr or encoder pin _can_ be used as GPIO
if you can disable it (you disable some modules by setting the number of instances in the driver load config line) so for example if you had an unwanted PWM gen on a pin you wanted for GPIO, you could set the number of PWM gens to 0 and the PWM pin would revert to GPIO

PCW wrote:

I think I would just look at the pin files and find one that's close to what you need

But that's the problem: I'm finding it difficult to match what I need with what I find in the pin files.

I would also read the hostmot2 manual page

I thought I had, but what I found wasn't what I read, which I guess now was motmod. There's a lot in there addressing my questions about Mesa terminology, but of course it's a lot to swallow too for someone who "just" wants to do a simple conversion like must have been done dozens of times. (After all, pncconf is called a wizard . Wizards wave wands for people and the right stuff happens without going into a lot of detail. :^) )

Note that a PWM, Step/DIr or encoder pin _can_ be used as GPIO

if you can disable it (you disable some modules by setting the number of instances in the driver load config line) so for example if you had an unwanted PWM gen on a pin you wanted for GPIO, you could set the number of PWM gens to 0 and the PWM pin would revert to GPIO

I don't understand well enough to know when I'd want a pin for GPIO, which I take as "general-purpose IO". Are pins GPIO when they don't have pulse trains, either step/dir or PWM, on them? used perhaps for lims and enables?

Thanks, tommylight.

I guess it's turning on the phrase "find something usable." Just not sure newcomers can see the forest in all those trees. Still, my grep methods above are hunting for things that match my controller's schematic.

How about considering the other direction?

A lot of CNC operators declare Tormach's PathPilot just what the doctor ordered from an operator's standpoint. But when booted, it will insist that the Mesa card it finds be configured for a "standard" Tormach firmware.

Have you an idea about how to go about letting PathPilot and the 5i25 believe they are talking to a Tormach model and "fixing" the wiring to match what the 5i25 expects?

Can the necessary information be found as simply as reading the PIN file, if it exists, for the "Tormach standard firmware" after it is installed?

Thank you all.

Yes, GPIO pins are simple bit I/O like parallel port pins so suitable for things like
limit switch inputs, spindle enable out etc etc

All pins that don't have an _enabled_ secondary function are available as GPIO
That is, if you set num_stepgens=0, num_pwmgens=0, num_encoders=0, you would have
all pins available as GPIO. (but no stepgens etc)

Unlike parallel port pins GPIO pins must be explicitly set to output mode in the hal file
( GPIO pins default to inputs )