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

I've made good headway, but I'm not there yet. I seem to be experiencing some issues with my servo amps and I wanted to setup a way that I can easily monitor and clear errors associated with the amps. The following are some of the configuration changes I have made (many of the prototypes came from earlier in this thread):

hurco_kmb1_3axis.hal:
pyvcp-panel.xml:
OK, so now the problem... I can start LinuxCNC without any problems. But the LED widgets (above) never change state. I have looked at both the 'fault.2' and 'air.pressure.ok' inputs with HALSCOPE and I can see them toggling, but the respective LEDs in LinuxCNC are always red.

My thought is that there is some scoping going on here wherein the HAL nets are not available unless I import them or use a different naming convention. But I can't see anything in the configuration guides like that. Further, it doesn't make a whole lot of sense. My feeling is that the designers don't want lots of scoping. They probably want to make signals easily accessible between different components.

Anyhow, that is where I am now.

[edit: The best way to find a solution is to write a post. Invariably, 5 minutes later you have it figured out. I added the extra pyvcp. in the pyvcp_options.hal file. This seems a little inefficient to me but that is OK.]

DeckelHead wrote: It is interesting. I've never gotten a good feeling for how many people are using the Mesa 7i77 or, for that matter, LinuxCNC.

It is hard to be sure, but we think that the ISO files are downloaded a few hundred times a week, and there is a graph of buildbot downloads:
buildbot.linuxcnc.org/~seb/billions-served/

Which are astonishing numbers for a very niche way to get LinuxCNC.

That is cool. I'm happy to see it is doing well.

The learning curve is interesting. I can't say that I've run into anything that is terribly difficult. However, I have struggled with the volume of information one needs to complete a project. There are an awful lot of considerations. Looking back at the start of the project, everything is logical but it has been work. My guess is that this same feeling will carry forward to when I finally finish.

I've made a lot of mistakes and when I figure out a problem, I invariably think, "geez, that was stupid Alan... what were you thinking?" I am making progress with my bindings through HAL. Once I have the basic framework done there, I'll have to figure out the ladder logic... bit worried on that one. I understand the concepts but I won't know how it goes until I jump in.

Probably the biggest challenge for me thus far has been tuning. I'm still not sure I have that correct. The next would be the some of 7i77 configuration, particularly the mode. That was surprisingly difficult/confusing and I only got it working with the expert help on this forum. Ditto on using the (effectively) op-amp HAL object (aka comp) to level shift the 5V FAULT lines to a boolean on a 7i77 with a VField of 24V.

Anyhow... Got a mechanical design question... I haven't created a control console yet but I've been poking around the internet for ideas. I plan on getting a pendant that has an integrated MPG in it. Given that, what are your thoughts on having a separate MPG on a console? Is that just overkill or is it useful?

Huh. I've got the fault clear and axis fault monitor LEDs setup now. They are working well. I just have the Z axis powered up right now (literally no power on the other axis) while I'm getting some experience. I'm getting lots of following error on the joint. That surprises me a little. I know I have a bias I have to add, but I thought someone said here that it wouldn't matter much because the control would issue the reverse voltage to correct the drift.

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. I haven't checked to see if the drift is an identical count when the following error shuts down the control. If it is, then the two axis appear to be bound together somehow. I did a quick check and the encoders look to be all 0 for X, 1 for Y, 2 for Z. I don't see any obvious wiring errors either (and I was able to do a drive level tuning job too.

The cause of the counting isn't known but I haven't spent enough time on it to really be able to eliminate some low hanging fruit.

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.