What represents, or what should I expect from, a well tuned servo system?

This was a commercial Hurco (albeit old) and I know from when I ran it with the old conversational control that it jogged *way* faster than the max of 60IPM that I have now (edit: looked up the specs and they list 250IPM, so that is pretty close). So, yes, I can certainly say it is capable of greater than 60. I can't get my UI to give me more than 60 but I have to admit that I did not look in the UI HAL file. My guess is that there is a parameter there that will allow me to control the max.

So... Looking at my HALSCOPE attachments, does it look like this is a well tuned system now? If so, then I can confirm that in retrospect I'm wondering why I had so much confusion in he process. It really isn't as hard as I thought. That said, I think the tutorial, although invaluable, could be spruced up a bit. I also think that the Granite process was a huge part of the confusion. I don't think it was very clear.

It has been a journey but I'll be very very happy if the tuning part is in good shape!

250 IPM makes sense because the maximum actual rapids speed needs to be ~20% less than the full speed (at 10v)
so the PID loop still has some headroom at 250 IPM

So, I'm getting the feeling that I'm pretty close then?

There are a few settings that are perplexing me a bit as to what I should set them at. These include: FERROR, MIN_FERROR, DEADBAND, MAX_OUTPUT, OUTPUT_SCALE. I've read some of the documentation at linuxcnc.org/docs/2.6/html/config/ini_config.html and it has helped but not really given me a clear picture of what is 'normal'.

I've also run into a few little strange idiosyncrasies. Although I've upped my HOME_SEARCH_VEL to 2, frankly, the homing sequence seeks the limit switch more rapidly than my supposed 60ipm jog (in the UI) and possibly (although close) to my G1 F150 Z-3.5 Y7.5 X6.5 command.

There is one other very strange thing. I hooked my VistaCNC pendant and holy canoli (batman), that thing jogged insanely fast. It was so fast that I could literally see the overshoot. Now, there are a few things here. First, yes, I am sure I can change the pendant so it isn't as insane. But, the more pressing question is whether or not this overshoot is indicative of my still having a tuning problem. Second, shouldn't the Vista be governed by the same 60IPM that everything else is, after all, it is pulling the max value from the INI file:

setp axis_0_max_velocity [AXIS_0]MAX_VELOCITY

Jogging velocities are determined by these INI file settings

I'm not sure which version of LinuxCNC you are using. I'm only familiar with the development branch. I found the Homing configuration in the docs to be particularly well written. I Would be surprised if the velocities were not respected if its well configured.

Yep, found that and have already made the change, but thank you for the response! One of the reasons that it didn't jump out at me before is that there appear to be some difference in units of measure. Unless I've screwed up, the value one puts into the INI file for the max rate is in IPM (well, for me... I understand that a metric base may be different). So, I have 60 there, which is what shows up in the Axis UI. I did a search for that in my other config files (60) and I didn't have a hit. However, I eventually found documentation that specified the DEFAULT_LINEAR_VELOCITY parameter. I was surprised that it was set to 1. Sure enough, when I changed it to 2, the Axis UI changed to 120IPM as the max value. Obviously the display parameter is in IPS. It seems dangerous/problematic to have different base units within the configuration files and now I'm seriously wondering if I've messed something up somewhere. . Oh, one place where I think there may be a deviation is that the homing velocities follow the same units (IPS) as the UI parameter. Hmmm, as I write this, I'm seriously beginning to wonder if my max velocity of 60 is wrong here. Maybe *it* should be 2 as well. That would nullify almost everything I'm talking about and would make sense. LinuxCNC seems to be well thought out and well developed so I was a little surprised to have different units and, of course, maybe I'm wrong here and I switched values (although I thought the 60 came from my Pncconf session... could be wrong there though).

Regarding the documentation.... Yes, in general I'd agree that the documentation is pretty well written. Most of the problems are between the keyboard and the chair (aka, me!). And, the homing configuration is especially well done. The documentation I had the most problem with was the servo tuning tutorial. Don't get me wrong. It is fabulous compared to nothing! And, of course, now that I've got a tuned system (I think... still waiting for confirmation on that), I am looking back wondering why I was overthinking the whole thing. But there are definitely areas that I believe could be improved. For instance, PCW (think that is who is was... it was in a different page of this thread so I can't check now) did an excellent job of explaining what FF1 means and that completely addressed my concerns as to why my value was pretty different from that which was referenced in the tutorial. In fairness, the document was probably written by someone who may not have had the underlying *meaning* of FF1 as he clearly stated that the value was what was in his system. That was very useful but it did cause some consternation in me when my value didn't roughly agree with his relative percentage.

Another area where I think the tuning document could be enhanced is in specifying some of the other values that should be set when you first start, and possibly a FAQ. I had some strange things going on when I first started and the FAQ could have helped me get to a firm starting point.

Essentially what I'm talking about is a living document, which is what everything in LinuxCNC probably should be. In fact, the real solution here is that I should probably write my own (I don't think I can edit the referenced document because that is on a different server and is also copyrighted).

The best sources for tracking the need for changes are people stepping through a process when they are completely green. They can have no inference, "feeling" of what things should be, etc. They are just babes in the woods. So, if those people have similar sets of confusion then it is an indication that something needs to be added, tweaked, etc to documentation. What I don't know is whether or not my experiences where 'normal' or if I was annoyingly unique. LOL. I shudder to know the answer to that one!

Regarding the respecting of velocities... That is an interesting one, if my previous comment about the axis velocity in the INI file turns out to be the case (should be 2, not 60) then that would explain an awful lot. I'd basically be telling my pendant that it is OK to jog at 3600IPM! The machine is capable of 250IPM or so which is why I'm seeing some serious overshoot when it tries to stop after 1 inch! Which would also mean that my acceleration value of 30 is also decidedly incorrect... Hmm. I'd love to hear your thoughts on this one. It could explain a whole lot of 'stuff'

AFAIK all ini file velocities are in machine units per second so 60 IPS is indeed rather fast...

Well, that won't work! The discovery certainly clears a lot of things up. Among other points, it explains why my 1" jog with the pendant causes a massive overshoot and resulting oscillation. The acceleration was set at 30, I think (not at the machine right now).

Interesting, really, how one finds this stuff. The GUI max jog speed is was set to a true 60 IPM so the high acceleration didn't really bug the system dynamics much. But the VistaCNC pendant wasn't governed by that limit. It only hooks into the INI file and the limits there were 3600 IPM and an acceleration of 30. Instant problem.

Cool. Another problem solved! This is great. Thank you all.

LinuxCNC has a concept of device units to cater for metric or imperial units. It is controlled by an INI file variable

[TRAJ]
LINEAR_UNITS = mm

Possible choices are (in, inch, imperial, metric, mm)

Its important all velocities and accelerations respect the device units specified. On a working machine it does not matter becasue you can choose metric or imperial units with G20/G21

See linuxcnc.org/docs/2.7/html/config/ini-config.html#_traj_section

Also you need to look in your Hal file for the MPG settings as it contains a SCALE setting. It can use ilowpass to smooth MPG response. When I tried using ilowpass, I got insane results and I think the default settings were 1 click = 1 metres. When I reread the docs later, it seems to use Ilowpass, I needed to reduce my MPG scale by a factor of 1000! I have not tried to put it back in yet!

I'll look into the scale settings in a bit.... Right now, I have something else that is piquing my interest/concern. I decided to change the Max and Acceleration for the system. That turned out to be a rather significant mistake, specifically the acceleration. I changed that to 1 and then foolishly tried to home the machine. Result: I crashed it! The problem, I think is that there was an unusually long ramp up and ramp down (accel, decel). When the limit switch was met, the distance to deceleration exceeded the physical limits of the machine. Thunk! Fortunately not too fast but an interesting learning experience!

So, I fixed that but I have another problem that cropped up. I saw this before and I thought it was the FERROR or something. What I'm seeing is that on one axis (not the crashed one), it jogs to the limit/home and is supposed to back off to the index. I didn't change any of the settings there, but now it merrily keeps going, as though the index is not ever found.

The last time I had this (again, turned out to be configuration, not hardware) I checked the hardware could see the index pulses with a logic probe. I haven't done that yet because I thought of a different approach... I should be able to see the index on either HALSCOPE or HALMETER. But, strangely, I can't seem to find the index signal. There is one for INDEX_ENABLE, that never toggles and, frankly, its name certainly doesn't jibe with what I'm looking for.

So, this begs the question... Is there a signal (or pin on the 7i77... but I didn't see one) where I can monitor the Index pulses from an encoder using HALMETER?

(edit:
Google is my friend. I found:
gnipsel.com/linuxcnc/tuning/encoder.html
forum.linuxcnc.org/49-basic-configuratio...-encoder-index-pulse
It seems a little funky that there is only a one-shot, but that is OK. I can still make it work. Tomorrow's task to check it out

The easiest way to test index is to "sets" the signal that carries index-enable for example:

halcmd sets x-index-enable true

Then watch x-index-enable with halmeter as you slowly turn the motor shaft (Drives disabled)
If index is working, index enable should be cleared at one angular position of the shaft.

The "sets" = set signal method avoids having to unlink the index-enable pin

Index-enable is not a one-shot, its a bidirectional pin that conveys information from the
encoder hardware to motion and from motion to the low level hardware, for example:

When motions home sequence is searching for index, motion sets index-enable true signalling the
encoder hardware to enable its index detection/count update-on-index logic. When the encoder
hardware detects the index (and updates its position count) it signals motion that index has been detected
by clearing index-enable.

You can also look at the actual index signal with halmeter/halscope but you typically have to move the shaft
very slowly to not miss the index pulse as its very short on high resolution encoders.