Swap Mach 3/ESS for UCCNC/UC300ETH-5LPT on CRP PRO with Plug and Play Electronics

[skrap853]

Now that I have all my parts I've been able to do more testing. I had to report a bug to the folks at UCCNC - PORT4/PIN6 can't be used for homing. It wasn't clear what the issue was, I'm assuming firmware. It will be fixed in versions after 1.2036. Since the bug only affected PORT4 I moved to PORT5 - problem solved.

The next issue that I encountered was with fusion360 post for UCCNC and the way my Z-axis was configured. I kept the same configuration that CRP uses - Z homes upward and sets the offset to 8. The UCCNC post commands a G0 G53 Z0 at the beginning and end of the GCode (//retract to safe plane). This causes the Z axis to start driving to machine 0 at rapid speed. I thought of three way to correct the issue:

1. create a zOffSet property in the post and set it to 8. Then the beginning and end move will move to Z<zOffSet> instead of a hardcoded 0.
2. re-configure the Z-axis so 0 is at the top and -8 at the bottom (this is what I did for now)
3. change the retract method in the post (it looks like Mach3 CRP uses a G28 move, still not sure how that retracts)

Otherwise I'm happy with the cut quality so far with UCCNC.

EDIT - I remembered an additional behavior that doesn't seem correct - I'm using a relay in the PnP electronics to control the router. When I first turn on the PnP the router comes on. The relays are active low so that must be the initial state of the outputs on the UC300. The software can't be on before the UC300 because of licensing. I'm not sure if that is an oversight on UCCNC's part, or if there is nothing that can be done other than powering off the router when I power down the PnP. I'll post on the UCCNC support forum and report back.

[A_Camera]

I remembered an additional behavior that doesn't seem correct - I'm using a relay in the PnP electronics to control the router. When I first turn on the PnP the router comes on. The relays are active low so that must be the initial state of the outputs on the UC300. The software can't be on before the UC300 because of licensing. I'm not sure if that is an oversight on UCCNC's part, or if there is nothing that can be done other than powering off the router when I power down the PnP. I'll post on the UCCNC support forum and report back.

I agree with you, this is incorrect behaviour on the UC300 side. I pointed this out a long time ago also but it seems that there is no priority on this and how to solve it. The outputs can't be controlled unless UCCNC is up an running, and it won't run unless the UC300 is there and recognized, so it is a kind of catch 22 situation. But it should only be a problem when you start up for the first time. After first initialisation UCCNC should send the basic start-up configuration to the motion controller which should save that configuration in the firmware and every time the UC300 is powered up it should start with that configuration until it is directed to do something else by UCCNC.

I regard this as a bug in UC300 firmware, but it seems that it is not taken seriously so it is not getting fixed.

[OlfCNC]

EDIT - I remembered an additional behavior that doesn't seem correct - I'm using a relay in the PnP electronics to control the router. When I first turn on the PnP the router comes on. The relays are active low so that must be the initial state of the outputs on the UC300. The software can't be on before the UC300 because of licensing. I'm not sure if that is an oversight on UCCNC's part, or if there is nothing that can be done other than powering off the router when I power down the PnP. I'll post on the UCCNC support forum and report back.

Normally a charge pump circuit is to avoid outputs to be turned on when there is no software control.

[A_Camera]

Normally a charge pump circuit is to avoid outputs to be turned on when there is no software control.

Yes, that's what I was told as well, but I see that more like a watchdog than a solution. It should not replace initialisation, the firmware should set up the outputs automatically. A watchdog is to guard a normally set up system, not to prevent the need of initialisation.

[RCaffin]

No, a charge pump is NOT a watchdog timer.
Do some testing. See what the state the outputs are in when the charge pump is not running. Make that state your default OFF state. This may require that you invert some signals.

Cheers
Roger

[OlfCNC]

I have my plasma torch on my plasma machine and spindle motor control signals on my router wired through a charge pump relay, it just disconnects the signals when there is no software control, it works great.

[ger21]

I noticed this last night. I'm setting up some contactors to switch two spindles on one VFD. The contactor coils are controlled by a relay board. When I turn on the electronics, the contactors pull in, but go off when UCCNC starts up. If I then close UCCNC, they stay off. So it's only the initial power up that is wrong. With my MB2 breakout board, I couldn't figure out any way to avoid this behavior. So, I'll be using one of the charge pump signal to another relay to prevent the this. I'll be using the second charge pump to my safety relay.

[OlfCNC]

My question is how could the controller know what are your inactive signal states prior to the software configuring the I/Os?

[A_Camera]

I noticed this last night. I'm setting up some contactors to switch two spindles on one VFD. The contactor coils are controlled by a relay board. When I turn on the electronics, the contactors pull in, but go off when UCCNC starts up. If I then close UCCNC, they stay off. So it's only the initial power up that is wrong. With my MB2 breakout board, I couldn't figure out any way to avoid this behavior. So, I'll be using one of the charge pump signal to another relay to prevent the this. I'll be using the second charge pump to my safety relay.

Yes, only the initial start up is wrong, so it's all the more reason to regard this as a bug, and it could actually easily be fixed in firmware if it was meant to be fixed.

A charge pump is a workaround, not a fix to the problem and is not a very good solution. Electronics should be initialized properly even if no software is running and safety-wise it is not a good idea to have to rely on even more electrical components just to prevent unintentional start of spindle or enabling of steppers. Normally you would not accept for example, if you'd turn on your VFD and it would start the spindle in ON state at max RPM until you'd set an input to a state. This would be totally unacceptable because a simple faulty wire could cause a disaster. A VFD contains firmware and electronics, but during power up, it is initialized so that if you don't have anything connected the spindle will not turn on. I would expect that the next stage behaves similarly, i.e. the output controlled by the motion controller is initialised so that the spindle, or anything else connected to the motion controller is not starting anything unintentionally, i.e. a relay is not pulled and the spindle is not started or the steppers are not enabled. Personally, because I am not using a relay to control my spindle, this is not a serious issue, even if it is annoying that the steppers are enabled on initial power up, especially since I think that this could be easily fixed by saving the initial state in the firmware after the first start-up, or on a button click. Perhaps the firmware memory is completely full, I don't know, but normally, reset handling should not take many bytes and it should be high priority for the programmer.

[A_Camera]

No, a charge pump is NOT a watchdog timer.
Do some testing. See what the state the outputs are in when the charge pump is not running. Make that state your default OFF state. This may require that you invert some signals.

Cheers
Roger

I didn't say it is a watchdog timer, but yes, it is a sort of a watchdog. A watchdog can be implemented in many ways, timer based is one way, supervising a relay or an input is another.

[A_Camera]

My question is how could the controller know what are your inactive signal states prior to the software configuring the I/Os?

When you start up the UC300 (or any other controller) for the first time it can't know which state which output should have, but after configuration of UCCNC the states are obvious and should be saved in the UC300 permanently so that when the UC300 is powered up it could start in that state. It is a normal procedure for every firmware programmer to start with initialization of the hardware, and to a level it is done also in the UC300, but this part is missed.

[skrap853]

I noticed this last night. I'm setting up some contactors to switch two spindles on one VFD. The contactor coils are controlled by a relay board. When I turn on the electronics, the contactors pull in, but go off when UCCNC starts up. If I then close UCCNC, they stay off. So it's only the initial power up that is wrong. With my MB2 breakout board, I couldn't figure out any way to avoid this behavior. So, I'll be using one of the charge pump signal to another relay to prevent the this. I'll be using the second charge pump to my safety relay.

That is the exact behavior that I see also. For now I'm just turning off my router when I power down the electronics.

Edit - Here is a link to the bug report - forum.cncdrive.com ? View topic - Initial state of relays

[ger21]

You really should not have any power to the router until UCCNC is up and running. Industrial machines do not allow you to turn on the power until the software is running and in control.

[skrap853]

You really should not have any power to the router until UCCNC is up and running. Industrial machines do not allow you to turn on the power until the software is running and in control.

That makes sense how the industrial machines work. In this case the software can not be started until the electronics are powered and communicating over Ethernet due to licensing.

I don't know what type of controller they are using but microcontrollers don't need an interface to operate. They can be programmed to have a default state.

At a minimum there should be a disclaimer in the documentation stating outputs are not controlled until software is communicating with the board.

[OlfCNC]

That makes sense how the industrial machines work. In this case the software can not be started until the electronics are powered and communicating over Ethernet due to licensing.

I don't know what type of controller they are using but microcontrollers don't need an interface to operate. They can be programmed to have a default state.

At a minimum there should be a disclaimer in the documentation stating outputs are not controlled until software is communicating with the board.

I dont think they are not controlled. They all controlled to low level.
Many microcontrollers and most FPGAs don't have EEPROMs.
They could probably store that data in program memory though, but maybe the lifetime of that memory (flash) would be too low if always overwritten.
So the best is to keep the industry standard solution to use a charge pump and enable your controller with that.

[OlfCNC]

And BTW it is the same situation that when you start your computer with a LPT port, does it set your default pins' states? I don't think so.

[ger21]

In this case the software can not be started until the electronics are powered and communicating over Ethernet due to licensing.

Only the UC300ETH needs to be powered. You don't have to have power running to the relay for your router. And imo, you shouldn't.

[skrap853]

I dont think they are not controlled. They all controlled to low level.
Many microcontrollers and most FPGAs don't have EEPROMs.
They could probably store that data in program memory though, but maybe the lifetime of that memory (flash) would be too low if always overwritten.
So the best is to keep the industry standard solution to use a charge pump and enable your controller with that.

You have to remember the purpose of this thread is to determine if the UCCNC/UC300ETH is an acceptable drop in solution for CRP Plug and Play electronics. I'm performing this test with my own time and money and reporting the results in this thread so others can maybe benefit from it.

**And the disclaimer** - CRP knows about this experiment but doesn't support it. I think as a company that offers costly customer support that is the right stance. Ahren and Cory have corrected any issues with my order and answered any questions I've had. I think their customer service is outstanding.

The relays in the CRP PnP electronics don't require a charge pump signal to be active and they are active low. There is one power disconnect for all the CRP PnP electronics. So we know that when the electronics are turned on the output relays are energized until the UCCNC software configures them. This creates a safety concern. Users must be aware and handle the situation accordingly. I've started a thread on the bug report forum with CNC Drive to see if they have interest and/or ability to correct this behavior.

[skrap853]

And BTW it is the same situation that when you start your computer with a LPT port, does it set your default pins' states? I don't think so.

This makes sense why an enable pulse is needed for safe operation of motors and relays - there were no electronics between the computer and motors/relays.

As I mentioned in my previous post - this thread is specifically talking about replacing the ESS with the UC300ETH. Other than historically why a control pulse was needed, parallel port operation is not relevant.

[skrap853]

Only the UC300ETH needs to be powered. You don't have to have power running to the relay for your router. And imo, you shouldn't.

The power supplies in the CRP800 are all controlled by the same main power disconnect. I don't want to alter the internals other than the ESS -> UC300ETH and report my findings. In the future I will either move back to the ESS, add circuitry to the CRP800 electronics, or just make sure that I turn off the router when I power down the electronics.