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

[OlfCNC]

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.

Your experiment can be viewed the way you viewing it or upside down, because what does CRP recommends to use with their machines?
A LPT port? A smoothstepper?
Both of them has the same problem which you describing here and this means that their machine is unsafe without a charge pump even with the controls options they offering and recommending with their machines.
So IMO the ones who should fix this problem is CRP, because all available hobby controls have this problem.

[A_Camera]

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.

Another possible solution would be if UCCNC could be started with the license key and would only allow motion on the hardware it is licensed for. That is also pretty easy to fix in my opinion, after all, it is checking for the license even today, so all it had to do is to check for the license a little later, for example the first time you load a G-code, enter a G-code line, or start jogging.

[A_Camera]

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.

The LPT is NOT designed to control anything other than a printer, so it is not a good analogy at all.

[RCaffin]

Both of them has the same problem which you describing here and this means that their machine is unsafe without a charge pump even with the controls options they offering and recommending with their machines.
I will respectfully disagree with your basic concepts and leave it at that.

Cheers
Roger

[A_Camera]

Both of them has the same problem which you describing here and this means that their machine is unsafe without a charge pump even with the controls options they offering and recommending with their machines.
I will respectfully disagree with your basic concepts and leave it at that.

Cheers
Roger

It is not necessary to exclude the possibility of useing a charge pump just because the outputs are initialised to a starting state. If you prefer to use a charge pump, that's just fine, but is a bad excuse for not initialising the outputs.

[RCaffin]

I suggest you may be misunderstanding what can be done during the power-up of electronics. Until such time as the SW control section has got itself going, the outputs are NOT controlled by the SW. There is always going to be this brief period of uncertainty.

There is a known, recognised and widely-used solution to this. You design the system such that all output drivers are disabled by default. Only when the system has stabilised do you enable the output drivers. (This is often done these days with Tri-State drivers.) Of course, before you enable the output drivers, you initialise the internal signals which control those drivers to the required state. The only question then is how do you control the output drivers without relying on the SW?

One solution to this is some sort of charge pump system. You arrange for the time constants to be 'long' compared to the rest of the system, and you implement this part of the circuit in hardware, NOT in software. And you also arrange for the system to default to having this start in the off-state. If you then follow the instructions for how to use the system, you will find it works safely and reliably.

The problem we often run into is that some people don't read the instructions (RTFM) and don't set the system up how it was designed to be used. When this happens, things go wrong. But that is not the fault of the system or the manufacturer: it is the fault of the user. Now, you might object to my comments, but remember that many of us do things the right way, and we have no problems.

Me, I favour Darwin.

Cheers
Roger

[vmax549]

Teh other option is to make UCCNC part of teh Power ON circuit. Other OEMS have done this with UCCNC and do NOT rely on a charge pump . Teh power ON circuit cannot energize until UCCNC is up and running and you have cleared teh Reset. THEN you can energize teh Pwoer on Circuit and Power up teh machine hardware.

It WOULD be nice for UCCNC to provide a couple of Software Hooks into teh core for safety functions

To me a charge pump is not the way to go BUT that is just my opinion.

(;-) TP

[ger21]

Teh power ON circuit cannot energize until UCCNC is up and running and you have cleared teh Reset.

And how is that different from using the charge pump to do the same thing? The charge pump can be configured to only output after the Reset is pressed. So, if I configure my power on button to run through my safety relay, which requires the charge pump, it works the same?
If there's a better option, can you elaborate?

[vmax549]

Sorry but the work at teh OEM level has to stay at that level. I can skim around teh edges but that is about it.

Also NOT having to deal with teh chargepump and teh conversion hardware is much easier (;-)

The needed safety functions are ALSO very much a concern for OEMs. That is something most DIYers ignore.


(;-) TP

[A_Camera]

I don't know who is adressed here, but...

I suggest you may be misunderstanding what can be done during the power-up of electronics. Until such time as the SW control section has got itself going, the outputs are NOT controlled by the SW. There is always going to be this brief period of uncertainty.

I know exactly what can be done during the power-up of electronics, have quite a few years of experience in firmware design and programming microcontrollers, peripherals, CPUs, microprocessors and hardware design. I have no idea about what is and what is not possible to do in UC300 but if it is different from all of the above then I am willing to learn in which way...

Yes, it is true that when the UC300 is taken out of the box and installed the first time it can not recognize my machine and have no clue about how I want top pins initialized, but as I said above already:

One possible solution:

After the first successful configuration of UCCNC it knows with 100% accuracy what is the reset state, which pins are doing what and which state they should have for which situation. At this stage the start-up condition could be saved in the UC300 flash memory and next time the UC300 is powered down and up it could of course start with that state every time until the configuration is changed. When the configuration is changed it should be downloaded and saved again in the UC300 flash memory and have that as next reset condition. The argument that perhaps the flash memory can get damaged if written to too many times is invalid because through my proposal you have to write less to the flash than as it is done today, since today I believe UCCNC writes something EVERY time you start UCCNC.

Second possible solution:

If the above is not possible to do then UCCNC could start in licensed mode if the license file exist and run in that mode until G code is loaded or any motion command is given. At that stage it should check the hardware and initialize, if the hardware is not existing it could just continue in Demo mode.

Third possible solution:

UCCNC starts in demo mode, just like today, if there is no motion controller sensed by the software. As soon as the motion controller is powered up it will report it's existence to UCCNC and UCCNC could automatically switch from demo to licensed mode and initialize the hardware just like today, sort of second start.

The second and third possible solution are not the best and the first is definitely preferred because in the first case the time for the uncertain output condition can be made to almost zero seconds, while in the second and third solutions are just preventing a common mistake, which I believe is common, that the software is started before the hardware so it starts in demo mode, you have to shut it down and start it again. Starting UCCNC is very slow, so that double start could be made shorter with those two. Also, it is a normal procedure to start software before external hardware is started, but in case of UCCNC the opposite is the case.

There is a known, recognised and widely-used solution to this. You design the system such that all output drivers are disabled by default. Only when the system has stabilised do you enable the output drivers. (This is often done these days with Tri-State drivers.) Of course, before you enable the output drivers, you initialise the internal signals which control those drivers to the required state. The only question then is how do you control the output drivers without relying on the SW?

That would require redesign of the hardware, or specially designed BOB, and that is very expensive and complicated and not everyone could do it.

One solution to this is some sort of charge pump system. You arrange for the time constants to be 'long' compared to the rest of the system, and you implement this part of the circuit in hardware, NOT in software. And you also arrange for the system to default to having this start in the off-state. If you then follow the instructions for how to use the system, you will find it works safely and reliably.

The problem we often run into is that some people don't read the instructions (RTFM) and don't set the system up how it was designed to be used. When this happens, things go wrong. But that is not the fault of the system or the manufacturer: it is the fault of the user. Now, you might object to my comments, but remember that many of us do things the right way, and we have no problems.

Yes, charge pump is a work-around, and an extra safety feature, but like I also said before, it is no excuse for not initialising the hardware. There may be some reason why it is not possible without the UCCNC, but that is not clear from the manual or from any discussion I have seen.

Me, I favour Darwin.

Too hot and too humid...

[RCaffin]

That would require redesign of the hardware, or specially designed BOB
Dunno about that. The very popular Homann Designs MB-02 BoB (often used with the ESS) uses a charge pump to control Tri-State output drivers. I can't see any ' very expensive and complicated' features there.
In this case I would not describe the charge pump as a 'work around'; i would describe it as a core safety design feature.
My 2c
Cheers
Roger

[OlfCNC]

After the first successful configuration of UCCNC it knows with 100% accuracy what is the reset state, which pins are doing what and which state they should have for which situation. At this stage the start-up condition could be saved in the UC300 flash memory and next time the UC300 is powered down and up it could of course start with that state every time until the configuration is changed. When the configuration is changed it should be downloaded and saved again in the UC300 flash memory and have that as next reset condition. The argument that perhaps the flash memory can get damaged if written to too many times is invalid because through my proposal you have to write less to the flash than as it is done today, since today I believe UCCNC writes something EVERY time you start UCCNC.

I guess they write datas into RAM and not to Flash. RAM has virtually infinite lifetime but is volatile.
Flash is always limited in lifetime in the 50k to about 1M write cycles.

If the above is not possible to do then UCCNC could start in licensed mode if the license file exist and run in that mode until G code is loaded or any motion command is given. At that stage it should check the hardware and initialize, if the hardware is not existing it could just continue in Demo mode.

K, but what will be the benefit of doing this?
I mean if UCCNC is not started at all just the motion controller powered then it still gives a low output.
If the outputs are not tristate-able then it will always give low or high logic level, no third option, no high impedance output possible and this is what I saw from my previous measurements and checkings.

[carbotaniuman]

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.

Wahr did you do in the end?

[skrap853]

I've been diligent about turning off the router and disabling the motors before shutting down UCCNC software followed by shutting off power to the electronics.

I power on in the opposite order:

Start UCCNC
After UCCNC is up, power on the electronics
Enable motors
Turn on router when I've changed bits or whatever is needed to get it ready to cut

Maybe not ideal, but has been working fine.

[abakker]

I should have called it alternate. If it works out they will be interchangeable.

Having options is always a good thing. When there is market competition it drives down prices and increases features. Ideally it would be nice if more software and motion controllers were compatible (standards).

People that have been using UCCNC have been reporting great results. The project is active and the developers are responsive to bug fixes and features. The price here in the US is 60 dollars, very affordable. So if a product works well (better is subjective) and it is cheaper why wouldn't I want to use?

It seems Mach 3 grew to popularity since it easily turned a PC with parallel port into an affordable CNC controller. The ability to add motion control boards helped them stay popular. Where they lost me is when they decided to start Mach 4 several years ago and leave Mach 3 behind, while never finishing Mach 4. Mach 3's current state - on the software setup page for CRP they recommend not using the latest version [of Mach 3] as it is known to cause issues. The .062 version that is suggested instead was released in 2012. So one product is not maintained and the other incomplete with no site of being finished (even if it is finished it still might not be a suitable replacement for CNC routers).

I purchased a DIY CNC router because I enjoy learning and improving where I can. If I can learn something, improve my purchase, or just help the community as the whole, it is a win in my book.

JP

I am resurrecting this thread to say that 6 years on, this is still the behavior of the 5LPT board with the UC300ETH. I’m also using the CNCRP board and have done a 1:1 swap.

I think the crux of the problem is that there ISNT a charge pump on the 5LPT board. If I could boot the board without powering all the 26 pin connectors, that would be fine, but alas . The reality is that it is hard to locate a charge pump that can control everything, so you end up needing more than one which is very annoying.

The CNCRP 850 board has its own terminals for 5v power, so I’m going to test removing the pin26 power from the cable and then seen if I can put a charge pump in to control that circuit.

[RCaffin]

Some days I want Mach3 to do X.
Other days I want Mach3 to NOT do X.
Perverse!

But safety features are always good.

Cheers
Roger

[abakker]

Some days I want Mach3 to do X.
Other days I want Mach3 to NOT do X.
Perverse!

But safety features are always good.

Cheers
Roger

Agree. I have a final solution to this thread, though.

The CNCRP-850 board has an external 5v power supply, as well as being designed to get power through the IDC26 cables. For this to work with the 5LPT board safely, you cut the 2 wires for pin 26 (5v power) in the ribbon cables and then put a charge pump on one of the other ribbon cable outputs that can switch the 5v power to the 850 board. This way no sensors or signals will be driven high or low until after UCCNC boots.

For this to work, you need to have an extra port to do this with that works safely, but because you only need 2 ports for the 850 board, you should be fine using any one of the others to do it.