Step/Dir with following error setup

Hi everyone,

I apologize if this has been covered before. I've tried to search for it and come up empty handed.

I am using CNCDrive DG4S-16035 drives (Step/Dir) on some Glentek DC servos (150V, 9A) using AMT113Q-V encoders. I have a Mesa 5i25 + 7i85S + 7i73 for interface. XYZ mill configuration.

I have split the signal coming from the encoders so that they will feed the drives, as well as feed back to the 7i85S. My intention was to have the system emergency stop on following errors, as the DG4S (with all its claims of error detection) will runaway in the event of an encoder channel failure. Not even an entire channel, even dropping one of the differential signals will cause them to run away.

I managed to drop the .XML files for the 7i85S into the firmware folder so I could configure the system through PNCCONF, and minus some small glitches all has gone well. EXCEPT:

There is only the option to run the Step/Dir drives in feedback mode. If you assign the encoders in PNCCONF, it automatically sets up PID loops for all axes, without allowing you to tune the axes in PNCCONF. That's all well and good, I can tune the loops through HALScope later, and I'm ok working with HAL in a text editor.

The real problem is that I don't need to close a feedback loop through LinuxCNC. It's already handled by the drives, I just want to monitor for runaway conditions. I have no idea how to implement this. I've found a couple threads that seem to indicate that this is very simple, but it's over my head at this point.

Thread 1
Thread 2

I am looking for no handouts, I just need someone to point me in the right direction. I'm missing something simple, but I can't find it.

Any help is appreciated!

If it's of interest/relevance, this is on a Bridgeport Series II Interact II. Very sturdy machine, the scraping on the ways is still pristine, I'm really looking forward to getting the old gal running again.

It is very simple to switch the config from open to closed loop feedback.
There are two levels you can take, 1st is completely closed loop, 2nd is only using the encoder feed back for following error but still leaving the stepgens open loop.
The 1st is actually the simplest to change to.
All you need to do is find all of the the stepgen's position feedback and velocity feedback pins are and replace them with the encoder position and velocity pins.
That would be 2 pins for each stepgen and the pin names will look something likeThen replace them with the encoder feedback pins.The 2nd way is a little more complicated, There you need to leave the stepgen's feedbacks connected to the PID loops, but connect the encoder feedback to Linuxcnc's position feedback "axis.N.motor-pos-fb"

Either way Linuxcnc will fault and shut down if the following error becoms too large, you don't need to do anything to "make it go to e-stop".

Also don't forget to do things like setup the encoder scale and change the PID P term from 1000 to something much lower before you start Linuxcnc as well.

For got to address this question of yours

PNCconfig uses a PID loop to control any hardware stepgen whether or not it is using closed loop feedback. Just because it put in a PID loop does not necessarily mean that Linuxcnc is controlling the motors closed loop.

It sounds like option 2 is the one for me.

"Just because it put in a PID loop does not necessarily mean that Linuxcnc is controlling the motors closed loop."
In this case, it seems definite that LinuxCNC is controlling them in closed-loop. If I disable the encoders, the system jogs just fine, holds position, no drift. If I enable the encoders, the axes barely respond to jogging, they drift, and they will eventually begin to oscillate (poor PID tuning, which I am not able to modify within PNCCONF) It seems like inverting encoder direction has almost no affect.

Since I am attempting to run the drives in open-loop mode, I would want to retain the Pgain=1000, FF=1, correct?

Yes, and you'll need to maintain the existing stepgen position and velocity feedbacks to the PID.

Probably the best way to change that would be to create new signal names for the feedbacks.

PNCconfig will probably have created lines something like this in your hal file for the X-axisChange them to something like this.

I've been setting up limits and just now got back to this.^Those appear whether or not encoders are enabled.

I attempted writing the changes you mentioned starting with the encoders enabled, but it complained about every line. If I started from a config without encoders, no complaints. Does this sound correct?
Honestly, short of stalling the drives I don't know how I'd go about verifying this. I could set the following error super low I guess. I've attached copies of my original PNCCONF HAL & INI, as well as the HAL modified for X.

Thanks a ton for your help. I ran the engrave sample in open-loop mode, that's exciting! I definitely need to re-tune the drives though, these servos are noisy.

I think you also need to initialize the encoder, at least with the scale. Like this (from my)

Yes, nearly forgot about all that. Here is the same snip-bit of code from my 5i25/7i85S hal file
Hakan's bit of code is setting the encoder scale explicitly in the hal file (to 1000)mine is referencing a variable in the ini file. (so you'd also need to add that line to your ini)

In fact here is my main hal file and ini file.

My cereal revealed to me something awkward this morning... That you can't use encoders if they're not even assigned. Hahaha.

Thanks for the examples Todd and Hakan, this evening I'll give that a shot. At first it seems odd that LinuxCNC wouldn't complain about the encoders being referenced in the modified HAL, but I guess the encoder pins get created by default. They're just not assigned to anything.

Just for the sake of curiosity, could one build a controller solely on a HAL file, leaving INI out? Hakan's example is the first time I've seen a configurable value placed directly in HAL. I'd prefer to keep everything in the INI, but it's just interesting.