Another huge failure tonight

[ger21]

in response to a major UCCNC failure

The problem is with the pendant/plugin, not UCCNC itself.

[CT63]

You asked for input on E-stops for the servos and VFD and I tried to be helpful. Its clear you only want to complain and have no desire to make your machine safe. You have no idea how a VFD works. Yet criticize sugestions to check and adjust the deaccel time and install a line contactor on the 3 phase AC supply.

Facts are:
You were told its a plug-in problem UCCNC is working on it.
Refused to stop using the pendant even after crashing and damaging the 1000 pound gantry twice. Even after knowing the pendant/plug-in is the problem.
Operating a large machine without hard wired e-stops. I hope you aren't a commercial shop with employees that operates this machine.

You have other options:
Buy another pendant.
Buy Mach 4 or another cnc program if you don't like UCCNC's program.

"The definition of insanity is doing the same thing over and over expecting a different result."... Albert Einstein

Moderator: Suggest locking this threat.

[beefy]

@ Balazs,

I don't know if it's of any relevance to this issue, but Candcnc had a very similar issue when they first brought out their PN200 remote pendant.

The pendant was fantastic with all sorts of capabilities. This is when Mach3 was the motion controller. Only problem was the X axis would unexpectedly rapid some distance, I used to crap myself.

Very interesting that a very similar issue is happening with the Cncdrive pendant.

The problem got reported by quite a few users, and some pendants were sent back to Candcnc for testing, but from memory all I ever heard was they could not reproduce the issue. I cut my losses and never used the PN200.

I have no idea if Candcnc managed to sort out the problem before moving over to Linuxcnc.

[Vmax549]

HIYA Beefy , NOPE candcnc never solved the problem. I always said it was interference from EMI and PathPilot/Linuxcnc has some problem with it as well with USB devices.

Just a thought(;-) TP

[cncdrive]

So far we have found the reason why the pendant plugin messes up the probing in the last few versions.
It is a bug in the motion control API in a function which is only called by pendants running through plugin.
We already fixed that.

We don't know why the movements issue is happening at some users, but we expecting radio interferences.
So, what we currently working on is we changing the communication protocol encryption from 8 bits CRC to 32 bits CRC.
This will sure make the communication bulletproof to RFI noise, because with 32bits CRC the changes are that RFI noise can change an invalid packet to valid is about 0.
With the 8 bits CRC we figured that there is still a possible chance that heavy RFI noise could possibly do that.

So, this is what we working on now.
Will make a new development release as soon as this will be done.

[beefy]

Hi Balazs,

I am correct in saying this change in the communication protocol encryption from 8 bits CRC to 32 bits CRC is something that can be done in software only, i.e. there's no hardware changes needed in the pendant.

[cncdrive]

Yes, it will be a firmware update in the UCR201. The UCR201 bootloader is prepared to change the firmware. The plugin can upload a new firwmware via the wireless connection.

[Parkgrr]

@ Balazs, just as a heads up and in case it's helpful one of the many things I've done to try to eliminate this issue was I brought in an RF professional with sophisticated scanning equipment to the shop. We found that the channel I was operating on was very busy. I found a channel that had absolutely 0 activity on it (my shop is in a former bomb shelter) and switched to that channel. The freq change had no effect on the problem.

[Parkgrr]

It's been 5 months, any update on this promised fix?

[Parkgrr]

Any update on this promised fix?