VistaCNC P4-SE pendant stopped working

JohnnyCNC wrote: I'm investigating as to whether I can just put additional power across the pos & neg on the usb connector.

Do you have any USB3 connectors (blue ones)? Those can supply 900mA rather than the 500mA of USB1 and USB2

Hi Mike,
It is a good idea and something that I pushed around with VistaCNC. I am 99% sure that the answer is "yes, I'm OK" though. There are a few reasons for this. First, although the pendant was originally shipped with a single port boost cable (not sure how that works... no connection to a power supply), I would normally have had to then attached to that cable with a Type 1 to type 2 cable. My EE Box (basically a Y that separates out the pendant's RJ connector to a Type 2 connector and screw terminals for a pole of the E-Stop switch) is close enough to the actual computer USB that I didn't need the supplied boost cable. VistaCNC knows of this layout and didn't identify it as a problem.

More importantly, the system works flawlessly in simulation mode. I've had nary a hiccup there, so I'm inclined to believe that power is not an issue. The problem only shows up when I use my own configuration(s).

Finally, I actually not pressing any interpreted button that are tied to switching LEDs on/off. My last failure mode that I reported involves an EStop switch that has two poles. One is interpreted by the embedded controller inside the pendant. The other is used to electrically interrupt the estop chain so that a relay drops (a safety consideration... this way the pendant/computer could freeze but the estop would still drop power to the amps and VFD).

Johnny/Andy: Although my belief is that the power is probably fine (reasons above), I'm going to find a powered USB hub and try that out if I don't have any USB3 connectors (I'm pretty sure I do not).

Johnny: there is a board inside the pendant through which the power runs. It is inside a heat shrink tube, but I think it has some chokes in it. I'm guessing you may have some wiring problems in there... just a thought. You should contact Lee @ VistaCNC; he has been pretty good at responding.

Because this problem seems to be very repeatable as a function of the HAL file, I think I should rewind to the basic file created by PNCCONF and then add the pendant hooks into that. If that works flawlessly then I can slowly start adding in different parts. I had hoped that someone would see an obvious flaw that was causing the loss of sync with the pendant, but it seems like I've stumbled into a question mark. But at least I have two benchmarks... sim that works, my HAL that doesn't. Hopefully I can take advantage of that. It is a nice pendant and I hope I don't have to can it. All of this is definitely confirming that relying on USB communication for an eStop is obviously not a good idea though. Thankfully I've not had to hit the button for any real reason, but if I had had that scenario, I would have been up a creek.

scenario got many VAR in it
and as you refit all why not the internal Pedant to a new one as xhc-hb03 supports all the best on pedant offers

I'm not sure what you mean... are you using VAR as 'variables' or 'Value Added Retailer'?

Also, I already own this pendant, so I'd like to get it working if it is possible. I haven't given up on it yet. Regarding the XHC stuff. I looked at those and there are a few reasons I stayed away from them.

First, although everything is made in China, I prefer to have support in the US. I've had far too many cases where a request never gets a response when support is in China.

Second, there is nice big EStop button on the XHC stuff that I've seen. I'm a firm believer in having ready access to an estop button.

Third, VistaCNC has a rubber boot on it to help absorb abuse (falls, etc). If there are aftermarket boots for the XHC, I haven't seen them.

Finally, and this is mandatory, I want a hard wired pendant. I know XHC has some hard wired versions and if I ignore the previous points, I'll go after the hardwired one. Why am I so puritanical about that? Well, IF there is an estop button (second point), then I want a pole that is not interpreted. With a wireless link, *everything* is interpreted. I'm also a little worried about the concept of a jog being done wirelessly. What happens with a weak battery or electrical noise in the middle of a jog, etc. Now, I recognize that at some point there is always an interpretation of a signal. Whether you are using USB or a direct connect wire to an interface port, a computer is still interpreting a keypress... But wireless just seems risky to me.

Anyhow, those are my thoughts about the XHC.... I really like the VistaCNC, although it is considerably more expensive compared to the XHC products. I haven't given up on the VistaCNC pendant just yet, but I am starting to lose a little patience with it.

As time goes on, I'm slowing thinking this has more and more to do with the way I've setup EStop and Machine ON. I have to admit that I don't understand *why* these could be interfering with the operation of the pendant, but the fastest way I can cause a fault is to toggle the estop pendant button once the machine is "ON" (F2 pressed). To that end, I thought I would post my schematics for that area of the machine.

It is pretty simple but let me explain again... Vacc controls the 220V power to the VFD as well as the servo power supply (shown in the left side of the HV schematic). The coil for Vacc is controlled by one pole of the COR (control on relay) shown in the lower right of the same sheet.

The relay estop chain starts at +24VDC, the other pole of the COR relay (more on the START button in a second) then through the two estop buttons (front panel and pendant) then the CTL-STOP pole (also described in a bit). If all of those are closed, then the coil for the COR relay energizes and that will turn on Vacc. Wait... a pole is in series with the coil of the same relay. Yes. That is basic latching via a relay. The start button is in parallel with the COR pole (first sentence of this paragraph). So when you press that button, the COR relay will energize; you can then release the Start button and the COR relay will remain energized.

The purpose of the CTL-STOP pole is so that LinuxCNC itself can de-energize the COR relay, which will then kick out the Vacc relay, and with that, the power to the amps and VFD. In essence, LinuxCNC has its own eStop, but one that cannot be reset without a human being manually pressing the START button again.

Now an observation... My feeling is that I'm kind of muddying the waters between what is an estop and what is a machine ON/OFF situation. I am wondering if that isn't somehow causing problems for me. As such, I'm interested in the thoughts you have on that subject. I like the approach I have because I think it affords maximum protection, but somehow I think I must be violating some fundamental tenant of LinuxCNC.

Again, there seems to be a strong correlation between the EStop button on the pendant and the machine on state. I've removed the previously mentioned jumper which simulated START (which would negate the COR pole's value too). Here is a set of reproducible steps that work (remember, no HV to the amps or VFD is available right now, but the machine is fully operable in every other way):

1. Start LinuxCNC
2. I can release/press the pendant estop button as much as I want, and the display shows "Machine Power OFF"
3. Toggle EStop on LinuxCNC (computer screen)
4. Again, I can press/release the pendant estop button and the "Machine Power OFF" continues to flash (no pendant hanging)
5. Toggle Machine power ON on LinuxCNC (computer screen)
6. I can press/release the pendant estop button and the "Machine Power OFF" continues to flash (no pendant hanging)
7. I press the START button, which should do nothing but energize Vacc and COR at this point
8. The pendant hangs

This scenario seems to be the fastest way for me to mess up my machine, so I think it helps hone down where the problem lies....

One more thing... The estop on the pendant is two poles. In addition to the de-energizing of the COR, and then Vacc relays, the embedded controller within the pendant recognizes the EStop state. I'm assuming it notifies LinuxCNC of the EStop condition too.

As far as I can recall, everything on the LinuxCNC side is working normally, even after you press e-stop on the pendant, but somehow doing so crashes the pendant.

If everything LinuxCNC works normally then I don't think it is anything wrong in your HAL or e-stop chain.

Can you confirm that, apart from the pendant, everything works as normal and continues to work as normal after the pendant e-stop is pressed?

Is the source-code of the pendant driver available? Perhaps there is something wrong in there.

Looking at this code in the vc-p4s HAL file: I am wondering what happens if you comment out those three lines. Then, if that seems OK, un-comment them one by one.

(You will need to restart LinuxCNC between edits. It is possible to make the changes online, but I am not confident that I can give clear-enough instructions to be sure that I know what happened when you report back with the results)