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

I think I may have solved the index problem... If I'm right, then you were correct and it was a connection issue. While the wire was snug in the terminal block, I think it was actually pushed in too far. The terminal is of the type that pulls up on a U-bar to provide the clamping pressure. I think the clamp may actually have been on the insulated portion and not the stripped copper. As such, there could be a poor connection.

Before my eyes, the homing sequence started to fail again (good!) and I noticed that as soon as I put a probe on the terminal screw, the y-index-enable turned false. So, clearly the wiring to that point withIN the machine was fine. I checked the wire and it was solid, but I decided to reseat it and then everything worked fine. Because I cannot visually confirm the manner in which it was originally clamped, however, I will just have to wait and see if the problem crops up again. I can also see my DVM very unhappy (unable to settle on a voltage, at the proper intervals (1 rev of the encoder). I can jog ON and OFF this behavior through 0.0001" movements. At those locations I am at logic LOW.

I did notice an odd thing about the y-index-enable signal, however. I am 99.9% sure this is correct and is how LinuxCNC works, but I wanted to confirm... Let's say I perform a home and then job 2" so I'm well away from the actual soft limit location. If I then manually execute a 'sets y-index-enable true' and perform a subsequent jog, as soon as the y-index-enable reports back FALSE again, I get an error indicating that I've hit my soft limit. I'm assuming this is correct. That is bolstered by the fact that the only time I see y-index-enable being reset (by the control) to true is during a home sequence after the travel limit has been detected.

OK, so assuming limits are working now, my next task is to finalize the integration of the pendant. I had to comment out some lines in HAL and I want to be sure those are OK. I also have a little work, I think, on the coolant logic. I can open a new thread if that is easier/better than continuing this one. Of course, the best would be if I can figure it out on my own.... But the main purpose of the thread here seems to be pretty well in hand. The axis seem to be doing what they should and I couldn't be happier. Thank you to each of the respondents that have helped me on this journey.

Actually, there is one related topic to axis control that I just thought of.... If I hit E-Stop then my axis amps will fault with a low power alarm. That is logical enough. However, to get out of that situation, I need to pulse a clear pin. I'd like to automate that as part of the ON sequence (powering down a servo amp is a common occurrence, after all, and is not limited to just emergencies). Is this something that requires I setup a logic ladder or is there an easier way? I've never done a logic ladder; I looked through the documentation but, thus far, have not had any need for one.

Actually, there is one related topic to axis control that I just thought of.... If I hit E-Stop then my axis amps will fault with a low power alarm. That is logical enough. However, to get out of that situation, I need to pulse a clear pin. I'd like to automate that as part of the ON sequence (powering down a servo amp is a common occurrence, after all, and is not limited to just emergencies). Is this something that requires I setup a logic ladder or is there an easier way? I've never done a logic ladder; I looked through the documentation but, thus far, have not had any need for one.
Report This

Using Classic ladder for this a bit like swatting a fly with a sledgehammer

I would think this could be done with the oneshot component and a bit of logic

That was my feeling. I'll look into how to do this within HAL. I guess I didn't even think about that, although it makes sense. I am using a COMParator so obviously they have more complex artifacts/widgets than just a simple OR gate. Good suggestion. Thanks.

OK, I got it working, but I was wondering if the was a 'cleaner' way to do it. Fundamentally, what I was wondering was whether or not there was a way to use the NET operand with multiple *signals*. Let me explain.... In my system I have the following outputs for clearing the amps (yes, I could have used one pin but I have three now):

X clear: hm2_5i25.0.7i77.0.0.output-08
Y clear: hm2_5i25.0.7i77.0.0.output-09
Z clear: hm2_5i25.0.7i77.0.0.output-10

Let's say that for readability reasons, I want to define a signal for each of these so that I know, while reading the file, what the function of a pin is for. So I define:

Now I define a oneshot that will trigger when I clear (press) the estop button (artificially long pulse so I can see it):
If I want self documenting HAL 'code' I might want to do something like this:or better yet (but totally illegal):But the first leads to an error because I cannot tie oneshot.0.out to multiple signals. So the only way I could get this to work was to use this (and, of course, I could get rid of the whole first block where I tied stuff to clear.fault.[0-1]):
So, am I off base here or is this the correct way to do it? My approach is clearer, at least in my convoluted mind, but if there is a good reason why I can't/shouldn't be able to do that, I'd love to hear it. Maybe the explanation will help identify some deficiency in my approach or thoughts on how everything works.

Try

You can connect a signal like "clear.fault" to multiple output pins and to my mind the above code remains nice and "clear".

Also If your drives are all the same and there's no specific reason to clear one at a time
why not just have a single clear drive hardware output?
That is, why use 3 physical outputs that carry the same signal?

[response to rod]
That will certainly do it, but I lose the concept of what 08, 09, and 10 are for. I'd rather assign signals to all of my I/O pins in one spot. Of course, the logical answer then is to put the clear.fault => in the area where I would otherwise have assigned those signals. That could work, but I'd have to put a comment block ahead of it as the actual pin doesn't really "mean" anything and now the signal doesn't either.

[response to PCW]
There is no reason, frankly. In my query about the signals, I mentioned that I could tie them all to a single output pin and I still can. I think the main reason I don't want to is that I generally don't like pairing up many wires onto the same terminal.

In the end, I can tie them together as Rod suggests and not have to rewire anything. Documentation can be done through # blocks and I'll probably go down that route.

I did learn an additional thing though... I actually have to make my pulse longer as the fault can only be cleared when the power is 90% of the expected value. But lengthening the pulse is easy enough to do, so now I'm off to the next challenge, which is to look at some of those signals that I had to comment out when setting up the pendant.

I'm assuming there is a page someplace that details the pins and signals that are core to LinuxCNC. Thus far, however, I haven't been able to find it. Do you guys have a pointer?

There are no signals that are core to LinuxCNC since signals are really just the equivalent of wire names
and are entirely arbitrary, though usually chosen for readability. That is you could name all signals
signal1001,signal1002,signal1003 etc and have a fully functional LinuxCNC configuration but perhaps
not a readable one .


The pins, parameters, and functions of LinuxCNCs core components are listed in the manual pages
for the component, perhaps the most important being the motion component, so
man motion
details all of motions pins and parameters

I would like to thank the above folks with the nice clear explanations and reasons with the hal file. This is very good info for us all that are still to learning .

Oh good! I am soooo happy that someone else is finding this useful and benefitting from my experiences. I'd hate to have all of this excellent attention I have been getting be limited to myself.

PCW: Ah, yes! 'man motion' was what I had found previously and what I was trying to remember. However, this does beg another question. I get that signals are, essentially, ephemeral things. But when I look at all of the signals in the HAL Configuration control within LinuxCNC, I'm pretty sure (memory only here) that there are a lot that are not part of the HAL files I have. I recall taking one of these and then searching for it within the HAL files without success. That would imply that within LinuxCNC itself there is some binding between pins and signals. That was the basis for the question about signals. (full disclosure: this was a week or two ago when I did that search and I don't have any examples off the top of my head).

One last thing. It turns out that the edge on my clear pulse was wrong. I had noticed that my initial estop release did not clear the amps (but subsequent ones did). Originally I thought identified that as the power supply not having reached capacity so I lengthened the pulse (although I was thinking it should get to 90V pretty quickly). That didn't do anything. Upon reflection, I realized my edge was wrong so I changed to the NOT of the oneshot and shortened my pulse to about 0.1 seconds. Problem solved.