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

I am continuing my journey and have included my (slightly) cleaned up INI and HAL files to this thread. I don't mind restarting the whole pncconf thing again if there is a driving reason to do so.

Here is where the confusion is/was for me... My comments related directly to the attachments.
HAL line #87-90 have the physical pins from the 7i77 limit. Lets take the NEG X limit switch as an example. For whatever reason, I called this net X_Limit_Left.
LINE 87: net X_Limit_Left <= hm2_5i25.0.7i77.0.0.input-24

Now the problem... The net name is X_Limit_Left, but nowhere is that ever bound to the motion pin axis.N.neg-lim-sw-in. That pin does show up here though

LINE 152: net x-neg-limit => axis.0.neg-lim-sw-in

But the associated net name, x-neg-limit, isn't found anywhere in the document. So, it seems to me as though we have only half of the definitions made. We gotten the physical pin mapped to a net that is never used again, and we have the desired motion pin mapped to a net name that also never is referenced (or set) elsewhere in the document. That doesn't sound good to me.

The expectation in pncconf is that you use the per-determained signal name descriptions available in the combobox selections.
From the selection pncconf writes an appropriate signal name and connects them to appropriate pins.
If you type in a signal name pncconf will only connect them to the IO pin because there is no way for it to know what you are trying to do beyond that. It is used to help with adding custom components.

Chris M

When I first looked at the HAL file, that was my assumption, which is why I asked the question about where to determine the preconfigured names (turns out it is using 'man motion'). However, one of the other moderators here wrote this: "Yes, signals (the first token after a net command) are arbitrary and just chosen for readability." The statement was a little confusing because it seems contradictory in that the "yes" could be interpreted as either "yes, you need preconfigured names" or "yes, you can use anything you want". But the example afterwards seemed to imply that I could use anything I wanted, which is what I originally did.

Using a fixed name that I can find in motion is perfectly fine, or at least modifying HAL so that there are two nets. I'm happy either way. I'll probably go with the fixed simply because it is standardized.

So now for some suggestions, as we always strive to make things easier.

• First, you guys continue to rock. I am completely impressed by how all of the posters here have been so willing to help. It is extremely appreciated, and I hope to follow suit in the future when I figure out my way around everything
• Second, I have to go back to the documentation and see if I missed something. My sense is that the fixed names were not as visible as they might possibly have been. For instance, I don't think I saw them in the homing sequence documentation. I could be wrong though. In the end, there is a lot to read and even more to assimilate. It is easy to miss things.... But if the binding info isn't there then that seems like an a fairly easy add that could help others
• Finally, I don't think I saw the fixed bindings within the pin assignments in pncconf's droplist. I know there were multiple options, but I recall those as being other pins I custom configured, and not the ones in man. Unfortunately, I can't confirm my experience because often when I'm writing these posts I'm not near my machine. I recall reading that without an actual Mesa card installed, I cannot run pncconf. I should probably try that but as it turns out, right now I don't even have a LinuxCNC with me.

Net names _are _completely arbitrary, this does not mean however that configuration tools like pncconf are setup to use arbitrary net names, the simplest path is just use pncconfs names.

There's really no need to expose net names or pin names with a configuration utility (you can always verify connections by editing the hal file)

For example in pncconf, to select 7I77 field input 0 as shared X home /limit I select the SS#0 7I77 I/O tab
then select input 00, then select "Limts/Home Shared" then "X Minimum Limit + Home". then if i had a NC home/ limit switch I would click the "Inv" checkbox. Done.

You do not need a mesa card to be able to run pncconf (you of course need it to run the test panels however)

I loaded up LInuxCNC in a VM and now see the net names in the droplist. I'm a little baffled why I didn't find them before. The only thing I can guess is that I somehow must have opened the list for an physical output pin and didn't, of course, see a home switch (an input) there. That is the only thing that makes sense to me. And now, by the way, I'm able to make selections regarding the homing sequence (greyed out before). I had been baffled why I wasn't able to do this before; now it all makes sense.

One thing I'm still unable to do, however, is successfully 'Launch Test Panel'. The button exists, and is enabled, but pressing it doesn't yield any test UI.

I have always assumed that the most likely source of problems is between the chair and the keyboard, and I have proven that point.

OK. I got a bit of time and I thought I'd give some of the learnings a shot... I fixed the pncconf configuration so that it looks a whole lot better now. I'm very happy about that. As mentioned previously, the internal net names for the limit and home switches were used and that enabled the dialog elements for the home velocity, direction, etc. Cool.

I'm still not sure how I'll deal with some of the other stuff such as pins to clear servo errors and, similarly, pins to report servo faults. But my guess is that this will be in a logic ladder someplace and shouldn't affect some basic attempts to move axis around under LinuxCNC. So...

I decided to power up LinuxCNC, selecting my pncconf created cfg files, of course. I know I need to tune the axis so I pulled the high voltage on the X & Y so I could concentrate on just Z for the time being (no big pieces of metal slamming around, etc... seems safer). My experience wasn't what I expected, though. When I try to tune axis 3 (Z), I never hear the servo even hum or drift. The LED indicators on the amp also strongly suggest that the amp is never getting the enable signal. I'm using the axis ENA lines in the 7i77 card, and I know those work because I can test the jogging within pncconf.

So, I'm a little mystified about that one. Any ideas?

[on edit: OK... I think I have a few different areas here that need work before I can continue. First, I monitored the ENA and realize now that I was missing the 'turn on the machine' (F2) step. Duh. Easy fix there. Slightly bigger issue is my estop chain, which is a little more restrictive right now with external start/stop for safety. Thought I had that figured out but the axis is not moving. That said, I have the HV on (good) and I can see the analog out changing when I job (also good). Now I'm wondering if my amp was never moved into the operate mode and, instead, is ignoring the analog input. If so, that makes a lot of sense. The point is, however, I know there are some things I need to check/fix (good... stuff to do)]

I did also poke around LinuxCNC a bit more and saw the HAL monitor "stuff". I have to do a little reading on that because I'm guessing it will be useful. I wasn't able to control the fault reset (even though I don't presently have a servo fault) though. The pin is bound to a net so I can't issue a command directly to that. And when I try to control the net, I get a syntax error. Anyhow, this is lower priority and is just me being unfamiliar with the halrun commands.

[edit: It would be awfully nice to add a button so I could reset my drive just in case it is in an error mode. I saw one writeup where the guy took several screenshots of his UI. He had a lot of PWM indicates and such, much like the spindle speed widget. I am not sure how to add a simple button that will change the state of a 7i77 output pin (ideally a momentary contact).]
[edit2: Figured out how to add a button and status LED but it isn't quite right. I've bound it to the net names for the 7i77 pins. But when I press the UI button, the output of the port doesn't change (halscope doesn't see the change and I confirmed with a volt meter too). So, I'm doing something wrong there. My guess is that I probably need the two pass option.

This gets to another question though... Is there a way to reload the INI, XML, and HAL files without restarting? I read that you probably cannot do this for the INI but the others were not specifically addressed.

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.]

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.