Greenie problems configuring 6i25 with 7i77, using Granite Devices VSD-E drives

DeckelHead wrote: The real curiosity, however, is that with only my Z axis powered up (but all encoders live), I am seeing drift on both my Z and Y. That is definitely puzzling. If I pull the 7i77 plug for the Y encoder, then the drift there ceases..

Maybe it is actually moving. Vibration?

As for the Z, you will probably get following errors until the tuning it right.
What is your current f-error limit? You might want to widen it a bit for tuning.

I'm at the very nascent stages at trying to figure out the mystery Y count, but I don't think it is vibration. I say that because there is a good amount of creep in the counts... far too much for vibration. And the X is rock solid. Finally, this is a quill based machine, so there is a pretty good amount of decoupling between the Z and Y. And, yes, I'm implying the two are tied because both are dead still until F2 is pressed.

My sense is that somehow the Y and Z are coupled in software, which would be an error in the HAL file. But I haven't really messed with the configurations in that area that were created using pncconf... and I have no reason to believe the application may have created the file incorrectly. Plus, a *very brief* review of the .hal file looked fine on first blush. And finally, when I removed the Y encoder input to the 7i77, the & Y encoder counting within LinuxCNC (and the HAL monitor) stopped. That would imply a hardware problem, not software.

However, a hardware issue is even more of a mystery. Physically, my machine is wired as follows... Each axis is completely independent. The encoder lead goes to a terminal block (original wiring) and then that goes to my servo amplifier. Internally, the amp uses the encoder as feedback (no tachometer used) and there is also a passthrough for the encoder, to which the 7i77 is connected through a different cable. So, my X, Y and Z are pretty isolated from one another. Even the power for the encoders (but not limit switches) comes from the amp....

Hmmm.... that is an interesting statement.... I hadn't thought about that before. That would mean the Y encoder isn't even powered up right now because I don't have power connected to the Y amplifier. I think it is time to get out my scope and see if I have noise here or something.

LOL. As I said, there is nothing like writing a post. It seems like 9 times out of 10, right after you hit the SEND button you figure out the problem. Although I don't know why I'd have noise only on the Y axis, it is certainly something to look at. I was planning on probing for signals, but now I think I'll be looking at triggering noise (in fairness, looking at a signal with a scope will cover all questions about what that signal is outputting...)

Alan

P.S. regarding the following error... I don't have that value right now, but I'll look for it. I want to nail down this Y axis encoder count thing first.

This is what I have right now (pretty much stock out of pncconf with some minor experimentation changes):
I've tried FERROR of 5.0 but I seem to be getting a lot of "joint 2 following error" faults. I also drift. That isn't so surprising because I haven't tuned yet, although that process is a bit of a mystery for me still.

I am ignoring the Y axis count problem for the time being. I just pulled the 7i77 encoder input until I have a better handle on everything.

Q: while I'm playing around with Calibration, are the limits being used?

[on edit: Yes, limits seem to be working (not completely validated... might just be the software limits on travel... TBD) but there is an odd experience with them that I'll have to figure out at some point. When I hit a limit, I can't move the axis at all. I'd expect that I couldn't move *further* into the limit condition, but I should be able to move away from it. That is the only way to clear the thing.]

When Linuxcnc is configured correctly, if a hard limit switch is triggered (hit), the machine is placed in Off(F2) and the drives are disabled. In order to move or jog, the machine must be re-enabled by turning it back on(F2). If the machine is still against the limit switch, it will not turn back on unless you set the "Ignor Limits" override.

Ah, thanks Todd. That makes sense, although I'm surprised that it is not a little more "intelligent" in its handling. Limiting travel in the direction *away* from the limit seems like it would make a lot more sense and easy to do. But, it is a constantly evolving product. Maybe it is a feature that I, or someone else, can introduce in the future. Open Source is a wonderful thing.

I recall that inside HAL there is a sequence for homing (Z, Y, X, for instance) that one can define. That makes sense. I thought there was an ability to home a single axis though too. Although it might not make sense for a fully configured machine, at my point in the commissioning process, it would certainly be helpful to be able to control a single axis. The UI, however, seems to only have the 'Home All' option. Is there a way around this?

DeckelHead wrote: Ah, thanks Todd. That makes sense, although I'm surprised that it is not a little more "intelligent" in its handling. Limiting travel in the direction *away* from the limit seems like it would make a lot more sense and easy to do.

I think it can do that if there are separate limits for max and min, but for shared limits it can't tell which way is safe.

Huh. Then I'm not sure why it didn't work as I have unique limits on my machine. I do share the home and limit on the +Z, -X, -Y switches, but that is a logical distinction. The travel limits on each of the axis are definitely unique.

. I thought there was an ability to home a single axis though too.

I think you can home one axis if you have a separate home switch for each axis. Go the the machine tab and the function is there to home one axis or un-home an axis depending how you have set linuxcnc up.

DeckelHead wrote: Huh. Then I'm not sure why it didn't work as I have unique limits on my machine. I do share the home and limit on the +Z, -X, -Y switches, but that is a logical distinction. The travel limits on each of the axis are definitely unique.

It might depend on the user interface. Linuxcnc definitely distinguishes between positive and negative hard limits. But I'm not sure which if any of the UIs make a use of that distinction. I'm really only familiar with the Axis UI, and I don't think it does anything different between the two.

I figured it out. Basic lack of familiarity with the tool was the problem, but at least for homing, that is fixed now. Things are moving along, which is great! One thing that is not working, however, is that I must have some limits wrong someplace. After I home the Z axis (currently limiting myself to a single axis), I only have about 100 encoder counts and then I am unable to advance further. My hunch is that I don't have the axis travel specified correctly, but that is a little odd. There are 6 inches of Z travel on the Hurco and I'm sure I put that in.