Initial state of relays

[skrap]

I'm using an active low output on the UC300 to control a relay that my router is plugged into. When the electronics are first powered up the router will come on. When the software starts then the router shuts off. This is an unsafe condition. Because of licensing the software will not start until the UC300 is powered up (even if the software would start, relays should be held in a safe state without the software).

[cncdrive]

The motion controller does not have an idea about your configuration when it is powered up without the software loaded, it only knows your signal configured levels when the software configures the motion controller. The signal inactive levels are defined in the bootloader and are inactive low for the UC300ETH-5LPT.

You should use the charge pump signal to avoid this condition.
A charge pump does not depends on static signal levels, it checks if there is a continous pulsing on the charge pump output and the charge pump circuit should disable the machine controller when that pulse is missing.

[skrap]

Why not write safe defaults of the Port/Pin configuration to non-volatile memory and load that with the bootloader? You could then use that same safe configuration with a watchdog timer or when loss of communication occurs between the motion control board and UCCNC.

Not all electronics have charge pump enabled relays. I'm replacing Mach 3 and ESS with your products but nothing else. The company I bought the electronics package from didn't need charge pump controlled relays since the ESS doesn't send any signals until it is communicating with Mach 3.

[Battwell]

for safety- dont power up the output relays at all until uccnc is up and running.
the charge pump output will hold a relay open and can be used to power the output circuit power feed (this is what i use to make sure nothing is in an unsafe state)
if uccnc crashes- everything is immediately switched off

[skrap]

I'm replacing an Ethernet Smooth Stepper with UC300ETH as I decided to give UCCNC a try instead of Mach 3 and report my findings.

I have no control of the hardware (it is an off the shelf unit I purchased). The relays are simply active low relays. There are other folks that also might want to drop in a UC300 without redesigning their electronics. I will switch back to the ESS and Mach 3 before I go replacing other electronics. If I ever design my own electronics I'll take everything I'm learning from this question and apply it to my design.

UCCNC crashing is not the only fault condition. Without thinking too hard about it three things can happen:

1. UCCNC crashes - motion control board should act accordingly, go to some safe state
2. motion control board is in fault state - is charge pump signal continued to be output? Does it respond to limit switches? Is it in safe state (how does it know that itself is in fault state)?
3. loss of communication between UCCNC and motion control board - go to some safe state

Bottom line is this - what is the issue with having safe default states for outputs instead of arbitrarily selecting active low? CNC Drive is selling a universal motion controller that can be used in many different situations. They will never know if the system has active high or low relays/motors or if a charge pump circuit is present. They should do whatever possible to reach a safe state during start up or fault condition.

[ger21]

Do you think that the ESS does what you're asking? I would think that if you dropped an ESS in a system designed around a UC300ETH, that you'd run into similar issues.

[skrap]

According to the supplier the ESS acts as the charge pump by not allowing outputs to operate without communication with Mach 3.

I know the ESS and UC300 use different hardware (FPGA vs microcontroller). It seems the supplier made a conscious decision to trust the ESS to operate safely without employing a charge pump. They have sold enough systems that they would know if there is a concern.

[cncdrive]

1. UCCNC crashes - motion control board should act accordingly, go to some safe state
2. motion control board is in fault state - is charge pump signal continued to be output? Does it respond to limit switches? Is it in safe state (how does it know that itself is in fault state)?
3. loss of communication between UCCNC and motion control board - go to some safe state

1.) It does switch the outputs to inactive states. Since the motion controller is already under software control the motion controller knows signals inactive states on a software crash event and switches them to that state...
2.) Depends on your settings. You can configure the charge pump to exist only when not in e-stop, if you configure it like that then limit switches will remove the charge pump.
3.) Same as in point 1.

[cncdrive]

Bottom line is this - what is the issue with having safe default states for outputs instead of arbitrarily selecting active low? CNC Drive is selling a universal motion controller that can be used in many different situations. They will never know if the system has active high or low relays/motors or if a charge pump circuit is present. They should do whatever possible to reach a safe state during start up or fault condition.

The output interface in the -5LPT motherboard of the UC300ETH are 74HC14 TTL drivers, they have 2 states high or low, high impedance output is not possible, so the outputs can have 0 or 1 logic levels only.
It is not possible to switch them high-Z.
We've used to build CNC machines about 15 years now and started out from the good old concept idea of always using charge pumps for safety and we've designed our motion controllers keeping this in mind is why we did not even think about anyone not using it and so we did not even think about that tristate of outputs is required and useful since the charge pump protects better than that.

I know the ESS and UC300 use different hardware (FPGA vs microcontroller). It seems the supplier made a conscious decision to trust the ESS to operate safely without employing a charge pump. They have sold enough systems that they would know if there is a concern.

Yes, it is correct that a motion controller also acts as a charge pump to some level, because it can handle communication problems, losses etc. events just like a charge pump can, but I think it is still safer to use a physical charge pump signal, because what if the motion controller hardware physically damages, then the outputs could take random levels if it is an electrical damage and it is then still very very unlikely that they will damage in a way that the board will send a 12kHz PWM, but it will damage to output one of the 3 output states if we talking about the ESS (low, high or high-Z), so it is then 33.33% chance that the machine will activate without a physical charge pump signal. So, I still feel safer with a physical charge pump signal. This is my concern about not using a charge pump signal.

[skrap]

1. UCCNC crashes - motion control board should act accordingly, go to some safe state
2. motion control board is in fault state - is charge pump signal continued to be output? Does it respond to limit switches? Is it in safe state (how does it know that itself is in fault state)?
3. loss of communication between UCCNC and motion control board - go to some safe state

1.) It does switch the outputs to inactive states. Since the motion controller is already under software control the motion controller knows signals inactive states on a software crash event and switches them to that state...
2.) Depends on your settings. You can configure the charge pump to exist only when not in e-stop, if you configure it like that then limit switches will remove the charge pump.
3.) Same as in point 1.

That is good that most conditions are covered after start up.

Is there no way to write those known inactive states so they can be set during startup instead of active-low?