Axis 2.9.0~pre: jogging moves the tool cone, but not the steppers

It has been a long time since I've set up something with PNConfig. I thought it used to be that the stepper test did not use the enable signals. It was a common mistake that would catch people. They'd set up their stepper drives with the enable wire connected and it would work in the test, but it wouldn't work in Linuxcnc because the enable wire would disable the drive when Linuxcnc was started. It is common for the enable/disable signal on stepper drives to be enabled with nothing connected and disabled when connected. Be certain that the drives are in fact enabled when you are trying to jog them in Axis.

Many thanks to everyone who has responded to me on this forum, including PCW. Let me respond to the last three posts.

rodw: The problem is related to signals coming out of the 7i96s card. They are present when I use pncconf and absent when I use axis. I monitor them with an oscilloscope. FWIW, the mill is one that works just fine with my older computer and the 5i25 card. It's just that I need to discard to old computer (it's a 32 bit without life support) and I don't have any remaining that have a PCI (not PCIe) slot.

Todd: I am monitoring the electrical signals that come from the card. They are all at correct levels with pncconf, but there are no signals present with axis.

tommylight: Your response is hardest to respond to because they are good suggestions. However, I'm told by PCW that he's made my configuration work without difficulty at his facility, including with the .ini files that I sent him. I'm also skeptical that the basic axis code is a problem, but haven't been able to rule it out. However, that PCW can make it work with an otherwise identical configuration suggests that the odds of this are pretty low.

I thought it was probably something that I did in the way that I configured my machine and compiled the code that was the root cause, but that the problems traveled to different computers with different OS's suggests not.

It seems pretty clear that the communication paths between pncconf and the 7i96s and axis and the 7i96s are different, but probably not at the lower levels of the comms stack. So, there is still some potential problem in the differences between axis and pncconf, but in any case the card remains suspect.

Today is pack the mill day. So, I'm sending the card back to Mesa with the hopes that they can find the problem and send me something back that works as well for me as it does for them.

Thanks again for everyone's help.

OK, here's the latest. Mesa reports that the 7i96s card that I returned to them has no problems. It's pretty much as I expected, though, I confess, not as I had hoped. So the situation remains as follows:

- pncconf works; axis does not.
- this is the case on two separate computers, different hardware, different OS's.
- all of the indications are that network communications between the computer and the card is working fine: no dropped packets and all packets contain data in accordance with the protocol specified by Mesa, both for the axis and pncconf cases.

In other words, all indications point to a problem with axis, or something that is somewhat unique to me that affects axis. I think that, given that PCH has a system with my configuration files that works as expected with axis, the most probable cause is something that is unique to me, but that isn't related to the computing hardware or networking.

I'm no longer in the situation where I can troubleshoot with the mill, but I can still troubleshoot using an oscilloscope. The absence of signals coming from the I/O card while running axis is quite evident. Their presence when running pncconf is too. I'll be happy if we can make those signals appear when running axis.

A HUGE problem for me is understanding the communications stacks. They are apparently different between pncconf and axis. If anybody can help me with the details of this, from the point where the axis python code emits a command to where that command is sent via a UDP connection and every step in between, that will be immensely helpful. Likewise for pncconf. In this way I can begin by inserting traces in the respective comms stacks that help me identify where the communications fail.

Thanks again for your help.

Neither Axis/LinuxCNC nor pncconf communicate directly to the 7I96S card,
they both setup a hal session which in turn uses the hm2_eth driver to
communicate hal variables to/from the FPGA card. The communication
paths are identical.

Dr. wrote:

- pncconf works; axis does not.
- this is the case on two separate computers, different hardware, different OS's.

*snip*

In other words, all indications point to a problem with axis, or something that is somewhat unique to me that affects axis. I think that, given that PCH has a system with my configuration files that works as expected with axis, the most probable cause is something that is unique to me, but that isn't related to the computing hardware or networking.

So what's left? The fact that it's neither your card nor a specific computer (with a specific installation of LinuxCNC) nor your config files that's causing the issue doesn't leave much.

* Some kind of electrical issue with your setup: power, enable signals, excessive noise on the power supply etc. There are also a lot of pitfalls using a 'scope, but I recall you saying you know what you're doing there, so... Maybe post a picture of your test setup? Perhaps someone can spot something wrong.

.. and that's pretty much all I can think of. I assume you've pulled a current linuxcnc-2.9 (i.e. tried at least two different commits). The chance that two commits separated by several weeks should have this issue with noone noticing it should be vanishingly small. So in my mind this rules out any issue with the code.

Possibly, let's say PCW needed to modify your config and re-save it before testing, then *maybe* some combination of, say, weird characters in your configuration files that somehow messes up the pulse width settings under Axis, or something like that. Have you tried any example configs without touching them at all? Perhaps use a different editor (e.g. nano in the terminal) if you need to change ip address or such.

Other than that, I'm at a loss.

Also, what does linuxcnc say when it's started? Run it from the terminal and post the output here (use the code tag).

While the communication path between Axis/Linuxcnc and PNCconfig may be identical, (Through Hal and the Hm2_eth driver.) That doesn't mean they are configured the same. If it is working one place and not the other you need to compare the differences between the two. There are a lot of communication settings made in Hal to the Hm2_eth driver, that could be different between what is used in the PNCconf test and a regular machine config. (and no I have no idea what the PNCconf test's Hal settings are or where to find them.) I'd probably start by opening a hal window from a terminal while the PNCconf's test is running and see what info I could glean about the Hm2_eth settings from there.

(I really should butt out of this, since I have zero experience with Mesa Ethernet cards.)

PWC, thanks for your response. We have discussed this before, but I need a point of clarification. When I put a trace on halcmd, should I, or should I not expect to see communications traffic from axis? I do see communications traffic from pncconf specifically related to jogging. I don't with axis. Actually, except for the initial configuation, I don't see anything from axis via halcmd. But, from one of our previous communications on the subject, I gathered that was an incorrect expectation. What expectation should I have? If axis communications takes another path that bypasses halcmd, then I see two different communications paths. Please elaborate and correct me if I'm wrong.

To arvidb and Todd, again thanks for your interest. Todd, you raise the point of configuration, the main area where I suspect problems. I'm just not sure how to go about triangulating it. Comparing the differences between the two has proven immensely difficult. Hence the request for a diagram of the communication stack for both programs. In this way I can put traces in them that will enable me to better isolate the failure.

To arvidb, I'll see what LinuxCNC says when I get the card back. I assume that it's currently in transit.

To all, remember Murphy's law: if something can go wrong, it will. It is evident that something has gone wrong. Given that it has, it probably will again, although not necessarily with a high probability nor high frequency. My guess is that it is related to "configuration" in which I include the possibility that the build scripts don't take into consideration every aspect of what can go wrong on every platform. Given that the main code works on the vast majority of platforms, I think that the probability of a problem lying there is relatively low, but certainly not zero.

In order to triangulate this problem, I need to know about how things work in enough detail so that I can design tests to rule out/rule in possibilities. For now, I'm ruling out the possibility of a failure of the I/O card, the networking associated with it, computer hardware, computer OS, and probably hm2_eth. It seems to early to rule out anything else yet. However, if I get feedback that the same identical communication paths are used by pncconf and axis for higher levels of the code, I would rule them out as well. After all, pncconf works.

Thanks for your help.