VistaCNC P4-SE pendant stopped working

Here is a picture of the inside from when I had mine open. It looks like the E-Stop switch has two contacts. One for the external E-Stop and the other to tell the software that the E-Stop has been activated.

I would have a look to the two wires into the board and either short or cut that signal (I think if I see right it is pluggable).

Good luck

I've kept Lee@Vista up to date on some of the more meaningful steps I've undertaken (also pointed him to this thread if he wanted to follow, although I don't know that he has). He requested that I send the pendant back to him for review/analysis. I think I'll probably send the whole setup (relay, wiring, even the power supply). At this point, I think I've conclusively proven that there is something wrong there (simulator mode with only modification being the addition of the pendant, separate power supply and relay setup that uses the EStop switch's second pole as a simple '(de)energize the relay' mode). It doesn't get simpler than that, and I still have a problem. So, I really think that this is distilled down to a legitimate support/service from the manufacturer.

This, by the way, is one of the reasons why I'm presently happy I purchased the pendant from Vista. I know that it is more expensive. But, in addition to the fact that I like the design and estop implementation better than other offerings, I think the fact that there is *real* US based (in my case) support is a big plus. Yes, all of this is predicated on a successful outcome, but I'm hopeful there. I think I've gotten far more out of the relationship with Vista than I would have if I had had to deal with a factory someplace in China.

So, although I'm still crossing my fingers, I choose to be optimistic that everything will work out. I'll post the results of what Vista says once he has a chance to look at everything. Until then.... happy machining everyone, and a heartfelt thank you for your ideas and thoughts!

Mike_Eitel wrote:

I would have a look to the two wires into the board and either short or cut that signal (I think if I see right it is pluggable).
Good luck

If you are talking about inside heat shrink tubing.... Yes, I agree that it would be the most logical place to look. However, I've been reticent to get into that area because I'd have to cut the heat shrink tubing off. Once I do that, I have to solder the wires all again to replace the tubing. I didn't want to go too far because I kind of feel that this is beyond what Vista wants me to do. If I saw a broken wire, I'd repair it in a heartbeat. It isn't that I'm afraid to resolder, etc, but if Vista is willing to solve the problem then I would rather they do so. It has the added benefit of them understanding the failure too. In the end, I'm sure they want to improve the product and understand where problems may lie. Forensic analysis is the best way for them to gain that knowledge.

I'll be sending them the pendant tomorrow. Hopefully they'll give me the reason why things are not working. If nothing else, this thread (if read, ad nauseam, by another person) should help someone else who has similar issues. The (albeit slow) whittling down of where the failure occurred and how to test for it, will be of benefit to them. And, of course, I'm a big believer is passing it forward. You guys have helped me, and I'll do my best to help someone else where I can.

Johnny:
Yes, the estop switch has two poles.... One side is devoted to the microcontroller so that it can interpret the estop state... The other is the one that is causing me problems. It is just two wires that come out at the other end of the cable. It is what I'm using in my estop chain to concretely shut down power to the servo and spindle VFD. That way, if my computer were hung, or otherwise unable to understand the estop state sent through USB, the system would still shut down power (no logic or computer involved... just removal of power to the relay coil that gives power to the axis/VFD).

Mike:
One of the tests that I performed sometime in the past was to remove the HAL 'binding' between the pendant Estop signal and the rest of LinuxCNC's EStop signal. That (albeit through software) severed the link between the pendant and LinuxCNC EStop. You are correct that electrically the pendant's MCU was still interpreting the switch... But if that is a problem, it would squarely be in Vista's software area and only they could fix that. FWIW, I don't think that is the case, but who knows right now....

Good idea to send it to the supplier and yes, always good if he is nearby.
And no, in my opinion the pendant must not handle the estop in any way. A pendant is a slave, has to follow the master. LCNC. It has to read the estop condition from LCNC and only signal that. Mixed responsibilities will not work after certain amount of updates.
That is my fiere position.

That is actually kind of interesting, because I have a diametrically opposing view, equally fierce, of this (unless we are misunderstanding one another).

While I agree that the interpretation of an ESTOP *software* signal should be in tight coordination with LinuxCNC (I don't really see that a pendant should not not be able to inform LinuxCNC of the desire to enter that state), I am quite convinced that any true EStop should have an electrical interrupt of whatever allows a machine to move (axis and spindle). The best would be power to the responsible amplifiers, but forcing a disablement within those devices may suffice. This is a failsafe that is completely independent of the computer, which is an important and intentional condition.

To me, the estop button on the pendant is the same as any other estop button I may add to the machine. All are wired in series so they all act the same (and, intentionally, a broken wire or disconnected pendant, will result in an estop state). The fact that Vista has two poles on their estop, one of which is wired into the chain (above) and the other is interpreted is a little bit of a curiosity to me. I'm less of a purist about the software interpretation of the switch. I was, and frankly still am, kind of on the fence about that one.

Anyhow, that is just my view. I am always interested in what others feel, and why, because it helps me decide if what I'm doing is still correct (in my mind). Your views, and those of Andy's earlier in the thread, are all welcomed and appreciated. They are thought provoking and that is a good thing. Let's face it... LinuxCNC isn't for the feint of heart. It is for people that want to invest in learning and, hopefully, are open to different ideas that challenge our own. All good stuff.

When I first bought my PS4 it wasn't the version with the EE Box. Shortly after when I was a little further along with doing my CNC conversion I wanted the external E-Stop. VistaCNC allowed me to send my pendant back and they converted it to the EE version for the price difference. If someone was not that concerned with having an external E-Stop the can still have one. I suppose there are some really small CNC machines where it really wouldn't be that unsafe.

Completely agree with independent estop. Simple to the bare metal. Cut power, sometimes, when you need the masses braked to zero, delayed by a simple time delay relais. But for the "high-level" treatment I wasn't to read that signal into master, and he tells the slaves what to do.

Got it, Mike.... You are talking about the interpreted EStop, and I can't argue with you on that one because I fundamentally agree with you. What you are talking about is how I originally envisioned everything would work. The ability of the pendant to separately understand the state of the EStop switch, and to then to independently initiate an estop condition, isn't something I had been aware of when I purchased the unit. However, it really isn't a big deal. I can work around this in one of two different ways. The first is to not bind the pendant estop to the real one. That should do the trick because the pendant definitely can deal with external estop switches. The second would be to open the pendant and physically disconnect the switch pole that goes to the MCU.

I'm looking at all of that "stuff" as secondary integration tasks though. Having the pendant brick as a function of pressing the estop button is a bug that needs to be resolved, IMHO. Even if it might be acceptable behavior (Andy's contention), it is still not something that is OK because it is not doing what was designed. The EStop switch (well, the pole in question) is electrically completely isolated from the USB side of things. As with any bug of this nature, even if the behavior is desired, tomorrow the pendant may brick in the middle of machining (remember, right now my VFD and amps aren't even being provided with HV, so they are pretty "quiet"); that may be Johnny's problems for all I know. So, I regard the bricking as something that needs to be fixed, whether the present end result is OK or not. Vista is helping out here, so hopefully all of this will work its way out.