Initial state of relays

[skrap]

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.

It seems that most people do prefer a charge pump signal. Having an enable pulse, not relying on a logic level, for critical components does seem like a good idea. To get relays that are charge pump enabled I'll have to change my electronics, which I was trying to avoid. I wanted the UC300ETH to be a safe and reliable drop in replacement for anyone using this kit without having to change anything.

[cncdrive]

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?

I'm not saying that it is impossible, but the controller was not prepared for this.
The main issue is that the microcontroller gets the firmware into the Flash program memory with a CRC checksum, the CRC is kind of a sum of all the firmware code bytes.
The CRC code is used to verify if the firmware has any errors, it detects even a bit of error.
The bootloaded in the controller reads the whole firmware on every startup, calculates the CRC code,
reads the CRC code written into the end of program memory and compares the calculated and the stored CRC code values.
If the 2 codes are different then it will not run the firmware but will give a firmware error.

So, the issue is that the whole program memory is allocated for the firmware and so there is no room to write the datas to about for example the pins inactive states,
because if the controller writes the data anywhere in the program memory then on next startup the CRC calculation will give a different result,
because the value written anywhere in the memory will count in the CRC calculation, so the controller will give a CRC error.

Another problem is that the program memory has a limited number of possible write cycles which is if I recall 1Million guaranteed cycles for that type of micro, which is a large enough number to rewrite the firmware for firmware updates, but if the value has to be rewritten on every Apply Settings or Save settings action then this 1Million number is probably no more that large and writting a single cell or a row of cells instead of a whole memory area always wears flash memory faster, so in theory it wears the memory out faster than a full firmware memory writting routine.

One idea I have is to build a separate application or put this functionality into the Utility tool we already have which could read the firmware from the controller, place in the initial values somewhere at the end of the program memory location, calculate a new CRC and then write the values and the new CRC. This way the user could define the initial values with the utility tool if it is really required for the application.
The issue with this is that we probably have to modify the bootloader also which is also possible, we did it once already, but if it is really required is yet just speculation from me, will have to check a few things before I can tell if this will be really required or not.
And if we will come to a conclusion that we can add this functionality then it will still take weeks for us to implement this, so please do not expect this functionality to appear very soon,
because it will sure take time for us to investigate and decide and if we can then to add it, but I took note of it now and will give it to my collegues for further investigation.

[skrap]

Thank you for taking the time to explain the boot operation.

Having a utility to write the values makes more sense than writing them on every push of 'save settings'.

I have no expectations of completion. I wanted to use UCCNC over Mach 3 since there is no more development or bug fixes. I appreciate you taking the time to think about it.

[A_Camera]

Thank you for taking the time to explain the boot operation.

Having a utility to write the values makes more sense than writing them on every push of 'save settings'.

I have no expectations of completion. I wanted to use UCCNC over Mach 3 since there is no more development or bug fixes. I appreciate you taking the time to think about it.

If you need a quick and simple solution to this you could implement a simple manual switch between the relay and the BOB for the concerned output(s). This could at least temporarily solve the problem but would require some manual action and discipline from your part so that you routinly flip the switch when UCCNC is up and running.

Another possible solution is to move spindle control from relay on/of to Modbus if your VFD is Modbus capable or to the serial protocol control Dan911 created if you are using the HY type of VFD. Moving to Modbus solved this for me without charge pump, the only slight irritation now is that the steppers are energized because the drivers are enabled unnecessarily when the UC300 is powered up. I am planning to add a simple manual switch but it is not on the top of my priority list, so it is not done yet.

[beefy]

Why not add another relay in circuit to effectively make the 2 combined relays active high.

With a 2nd relay run this active low connection (of relay 1) through a normally open contact of relay 2 to ground/negative.

One side of the coil of relay 2 goes to ground/negative and the other side is the switching side and is active high to engergise relay 2. When relay 2 energises it closes the circuit to ground for your relay.

You could also do something similar with a transistor if you know a little electronics. Google switching a relay with a transistor or a FET.

Keith.

[dezsoe]

You can make an "active cable" to invert those pins that needed. On the UC300 output the pin26 is +5V, so you can make a little board with 74HCT14 between the UC300 and the CNC's inputs to invert some pins. When powering on the UC300, it's pins go LOW and the "active cable" makes the needed pins go HIGH in the moment. No need to change anything in the CNC machine.

[skrap]

Everyone,

Thank you taking time to suggest fixes. I'll peak under the hood of my electronics panel this weekend and see what makes sense. Luckily, I enjoy doing these things. Hopefully whatever comes of this will help others as well.