How to power a Prop for a week. Simple Battery BU

T Chap

I have a Prop board that homes a motor on power up and initializes the Rotary Encoder obj to zero. In cases of power outage or any number of reasons the main board could reset(error lockup, power outage, etc) I want to create a method to avoid rehoming if it has already been homed. So I'm thinking of adding a second Prop that has a battery and it can survive running at 80Meg for around a week. The concept is that the main board can offload the encoder position to the second Prop either at some frequency and on errors so that when the main board boots up, it can check the other Prop and receive that last known encoder position. I have 5V and 3v3 on the main board. There is space for batteries ( several D size or 9V types) but not a large 6V battery. I'd like this to be maintenance free for life(10years+). Any suggestions?


Edit. This is flawed from the start. If there is no power the motors can be moved and the encoder pos is lost. This would require the encoder to be powered and constantly tracking any changes. Maybe that’s an option. Run the encoder power from the second prop board from the battery/regulator at 5v. Parallel the encoder AB to the main board. On boot up the main board can read the encoder position active in the second board and update the position.

frank freedman

You could always borrow a method from a large German medical OEM. They use two methods of positioning on motor driven movements, both absolute and relative. The absolute position is provided by a multi turn pot. Position is then known at power up. The position pot is always monitored for position. Relative is used for motor control and to calculate the current position away from an original position. These two position values are constantly being compared and if different by a given limit will stop movements because something has failed. There are also so excited movements that also use an optical barrier as a zero reference indicator on angular movement.

Tracy Allen

Water level gages that use encoders and beaded cable down to a float typically run for a year or two on a set of C or D batteries by pulsing the excitation, sleeping mostly. The rate of excitation has to be fast enough to catch any slip. The rate of slip in the level gage is constrained at least by the relatively slow changes in the stilling well.

DigitalBob

I guess the big question is what is the total milliamp draw for all the encoder's etc.

frank freedman

If you use an absolute encoder, either optical or potentiometer, it would use power only when the unit is powered up. Zero power when power lost. With an absolute encoder you would want to read the value on power up prior to initiating any movements, just as you would for a remotely stored value. Won't have to worry about any position changes while the unit is off.

jmg

T Chap wrote: »

Edit. This is flawed from the start. If there is no power the motors can be moved and the encoder pos is lost. This would require the encoder to be powered and constantly tracking any changes. Maybe that’s an option. Run the encoder power from the second prop board from the battery/regulator at 5v. Parallel the encoder AB to the main board. On boot up the main board can read the encoder position active in the second board and update the position.

That leads to the key question of how much power does the encoder need, and can you power-save it somehow ?
What is the highest expected count-rate, in the power-save mode ?

Optical encoders can need significant power, to drive the LED side of things, but some allow pulsed LED operation.

Mickster

Check out these capacitive encoders.

The ideal solution would be a BiSS C encoder. They store their own position count and can upload it to the host controller on power up. I think SSI encoders can do the same.

https://www.cui.com/catalog/motion/rotary-encoders.

Mickster

These guys have energy harvesting models.

https://www.posital.com/en/products/kit-encoders/kit-encoders.php

T Chap

Thanks for the info guys. I already have the encoder I have used forever. A simple US Digital E series. I am more looking for the ideal battery to run a prop and encoder for around a week that can charge off the main board 5v. The encoder max current is less than 75ma. I’ll have to check the prop/eeprom/usb components.

Mickster

A few 18650s + a BMS? Dirt cheap.

T Chap

Thanks. 1 - 18650 is 2500ma hour. So if the encoder is 72ma then 2500ma/72ma is 34.72 hours. Parallel another battery should double it. Then determine the prop/eeprom/usb. I could easily stack 10 of those

Mickster

Encoders don't usually like much less than 5v...I was thinking a series/parallel arrangement, regulated to 5v. Battery Management System (BMS) for even charging.

T Chap

Yes the encoder is wanting 5v. I just measured the available space. It can hold this size 6v batttery. Now to sort out the BMS that can run off the built in 27v unreg, 5v, 3v3. I’ll regulate the battery down to 5v with a switching reg. Then build a board for a Prop, eeprom, USB interface. The power for the encoder will come from the battery/regulator. Mult the encoder AB to the main Prop and the backup Prop. On boot up check the backup Prop for a valid previously stored encoder value. If found read it in serially. The next trick will be modifying the Rotay Encoder object to allow the position to be updated. It currently does not allow and update but surely it’s doable. Thanks for the suggestions!

Edit. For this AGM type why bother adding a bms chipset and instead just find a device ready to plug in. First I should study what the pros and cons of lipo v AGM.

12v May she more sense as there will be power all the way down to 5v. Using 6v will have less working depth.

Mickster

An easy way out would be to use the stored encoder count as an offset to the count provided by the object. If I understand correctly, this would avoid lost counts that might occur during writing the stored value to the object.

Mickster

I wonder if a cleaner solution would be to have an external quad counter, with battery-backed power and use SPI instead of the encoder object?

I had the LS7366 up and running in no time at all.

I used the Click module:
https://www.mikroe.com/blog/counter-click-released

LS7366 datasheet attached.

T Chap

That is interesting, but in this case the motors are already built with special shaft to accommodate the US Digital quad encoder. This battery feature is an option only and I want to be able to retro fit if easily. I can lift a few pins and connect the second Prop board very easily so this method is a matter of a few minutes to modify the system. I just need to make the backup Prop pcb and I think this will be very simple.

Mickster

I am totally with you as I have been considering similar...

Nothing changes regarding the encoder....Instead of bringing A, B, Index to 2 Props (one of which is battery backed), you bring the encoder signals to a dedicated counter that has the battery-backed supply. This counter is interfaced to the volatile Prop via SPI. So instead of having the Prop decode the quadrature signals, using the encoder object, you fetch the preserved count via an SPI object.

The powered up Prop will need to re-establish communication with the counter chip (7366) that didn't power down and this is my only question mark.

T Chap

Couple of issues. One is I’d have to add an SPi cog and it’s slready maxed out. Even though I’d be able to drop the encoder object it would still require an extra dedicated cog to read SPI and update the position. That is unless the SPI object could be modified to include reading the device and update the position. But I’m not sure I’m seeing the benefit of a SPI quad counter vs the Prop as a counter. Maybe I’m missing what your seeing.

Mickster

T Chap wrote: »

That is unless the SPI object could be modified to include reading the device and update the position.

Yeah, exactly. What you read is the position and you just keep on reading it. Don't bother with the encoder object at all. Furthermore, the LS7366 has digital filtering and can preload the counter (if required) on the occurrence of the Index pulse. Keeping the LS7366 alive requires negligible power but obviously the encoder needs to be kept powered up.

I also retrofit machinery fitted with existing encoders and I have been considering this battery-backed alternative to absolute encoders for quite some time.

Mickster

The encoder object gives you position.

The SPI object gives you position but keep the LS7366 alive and you don't have to look at a separate Prop to restore your position following a Prop reset.

T Chap

Yeah I see a possible advantage there. I’ll try to get one in and test the concept soon.

Mickster

That would be a marketable device. I don't do anything under four axes and I currently handle as many as twenty one. Having to re-home after, say, a brown-out is a royal pain in the posterior.

T Chap

I have to pseudonsynchronize three systems. Not a Cnc. But if it has to home then special care is needed to avoid collisions and that is a big headache since nothing knows where it is. My plan is to home once with an attendant setting things in the right place to do a home process. After that never home again In a reboot it just knows where it is. I am designing a prop based LCD touchscreen to manage all three systems. RS485 to do all the synchronization.

Mickster

Big blue extrusions are the servo drives? Which make/model?

T Chap

Those are transformers. Motors not shown. I use BLDC motors. Main board, power, motor driver board.

Mickster

Looks like my world....Fun stuff. I also do a lot with servo hydraulics.

idbruce

Those are transformers.

Paying for extrusions instead of amperage? I opt for more wire and cooling fans.

DigitalBob

I've done some CNC retrofits on some large machines. They had a series of micro switches placed strategically in sequences to avoid collisions. So if the computer failed it had a hardwired backup to initiate an emergency stop.

Mickster

DigitalBob wrote: »

I've done some CNC retrofits on some large machines. They had a series of micro switches placed strategically in sequences to avoid collisions. So if the computer failed it had a hardwired backup to initiate an emergency stop.

Oh sure, some elect to open the e-stop loop and others disable the servo drive. Most drives feature separate FWD and REV enables which is a nice way to go because if you hit say, the FWD limit, you are still able to power the axis in the opposite direction.

I think that what T Chap is referring to, though, is the problem of losing power at the point where the machine's axes are either overlapping or buried in a workpiece. Once the power is restored, the control system has no idea where the axes are and blindly commanding them to retract and search for their respective home positions might cause a collision.

There's usually a very expensive-sounding loud bang before someone gets around to hitting the e-stop button 😁

T Chap

I have a number of cases where homing is a problem and time consuming. One case is the travel is 50’ at slow pace moving 2500 lb. Another is there are 3 motors moving 600lb each that would need to be homed on an error or outage and things have to move in an order to avoid conflicts. The items being automated in one case cost the client 500k.

Mickster

T Chap wrote: »

I have a number of cases where homing is a problem and time consuming. One case is the travel is 50’ at slow pace moving 2500 lb. Another is there are 3 motors moving 600lb each that would need to be homed on an error or outage and things have to move in an order to avoid conflicts. The items being automated in one case cost the client 500k.

Yup it's the downtime that's the killer.